On Fri, May 10, 2024 at 02:23:09PM +0200, Alvaro Herrera wrote:
> Ah, I ran 'git clean -dfx' and now it works correctly. I must have had
> an incomplete rebuild.
I am going to assume that this is an incorrect build. It seems to me
that src/common/ was compiled with a past version not sufficient
On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
wrote:
> On Sat, May 11, 2024 at 4:13 AM Mark Dilger
> wrote:
> > > On May 10, 2024, at 12:05 PM, Alexander Korotkov
> > > wrote:
> > > The only bt_target_page_check() caller is
> > > bt_check_level_from_leftmost(), which overrides
On 5/5/24 20:01, jian he wrote:
hi.
I hope I understand the problem correctly.
my understanding is that we are trying to solve a corner case:
create table t(a int4range, b int4range, primary key(a, b WITHOUT OVERLAPS));
insert into t values ('[1,2]','empty'), ('[1,2]','empty');
I think the
On Sat, May 11, 2024 at 5:00 PM Alexander Lakhin wrote:
> 11.05.2024 07:25, Thomas Munro wrote:
> > On Sat, May 11, 2024 at 4:00 PM Alexander Lakhin
> > wrote:
> >> 11.05.2024 06:26, Thomas Munro wrote:
> >>> Perhaps a no-image, no-change registered buffer should not be
> >>> including an
On Sat, May 11, 2024 at 11:45:33AM +0500, Andrey M. Borodin wrote:
> I see that you store condition in private_data. So "private" means
> that this is a data specific to extension, do I understand it right?
Yes, it is possible to pass down some custom data to the callbacks
registered, generated
On Sun, May 12, 2024 at 10:48:51AM -0700, Noah Misch wrote:
> This looks correct, and it works well in my tests. Thanks.
Thanks for looking. While looking at it yesterday I've decided to
split the change into two commits, one for the infra and one for the
module. While doing so, I've noticed
On Mon, May 13, 2024 at 12:26 AM Andrew Dunstan wrote:
> Well, this is more or less where I came in back in about 2002 :-) I've been
> trying to help support it ever since, mainly motivated by stubborn
> persistence than anything else. Still, I agree that the lack of support for
> the Windows
David Rowley writes:
> On Mon, 6 May 2024 at 15:06, Tom Lane wrote:
>> My best guess is that that changed the amount of WAL generated by
>> initdb just enough to make the problem reproduce on this animal.
>> However, why's it *only* happening on this animal? The amount of
>> WAL we generate
On 11/05/2024 23:45, Jelte Fennema-Nio wrote:
On Fri, 10 May 2024 at 15:50, Heikki Linnakangas wrote:
New proposal:
- Remove the "try both" mode completely, and rename "requiredirect" to
just "direct". So there would be just two modes: "postgres" and
"direct". On reflection, the automatic
On Sat, May 11, 2024 at 4:13 AM Mark Dilger
wrote:
> > On May 10, 2024, at 12:05 PM, Alexander Korotkov
> > wrote:
> > The only bt_target_page_check() caller is
> > bt_check_level_from_leftmost(), which overrides state->target in the
> > next iteration anyway. I think the patch is just
On Mon, 6 May 2024 at 15:06, Tom Lane wrote:
> My best guess is that that changed the amount of WAL generated by
> initdb just enough to make the problem reproduce on this animal.
> However, why's it *only* happening on this animal? The amount of
> WAL we generate isn't all that system-specific.
On 07.05.24 09:43, Jakub Wartak wrote:
NOTE: in case one will be testing this: one cannot ./configure with
--enable-debug as it prevents the compiler optimizations that actually
end up with the ".cold" branch optimizations that cause backtrace() to
return the wrong address.
Is that
On Fri, May 10, 2024 at 10:04:17AM +0900, Michael Paquier wrote:
> Attached is an updated patch for now, indented with a happy CI. I am
> still planning to look at that a second time on Monday with a fresher
> mind, in case I'm missing something now.
This looks correct, and it works well in my
XLogReadBufferForRedoExtended() precedes RestoreBlockImage() with
RBM_ZERO_AND_LOCK. Per src/backend/storage/buffer/README:
Once one has determined that a tuple is interesting (visible to the current
transaction) one may drop the content lock, yet continue to access the
tuple's data for as
On 2024-05-12 Su 08:26, Andrew Dunstan wrote:
On 2024-05-12 Su 01:34, Tom Lane wrote:
BTW, I've also been wondering why hamerkop has been failing
isolation-check in the 12 and 13 branches for the last six months
or so. It is surely unrelated to this issue, and it looks like
it must be due
On 5/12/24 05:55, Matthias van de Meent wrote:
> pg=# CREATE UNIQUE INDEX ON temporal_testing USING gist (id, valid_during);
> ERROR: access method "gist" does not support unique indexes
To me that error message seems correct. The programmer hasn't said anything
about the special
temporal
On 17.04.24 04:36, Nathan Bossart wrote:
On Wed, Feb 28, 2024 at 02:21:49PM -0600, Nathan Bossart wrote:
I see many projects have files like SECURITY.md, CODE_OF_CONDUCT.md, and
CONTRIBUTING.md, and I think it would be relatively easy to add content to
each of those for PostgreSQL, even if they
Hi!
Attached draft version of fix for [1].
[1]
https://www.postgresql.org/message-id/86b4f1e3-0b5d-315c-9225-19860d64d685%40gmail.com
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.comFrom ece01564aeb848bab2a61617412a1d175e45b934 Mon Sep 17 00:00:00 2001
From:
On 24.04.24 01:43, Thomas Munro wrote:
Rebased over ca89db5f.
These patches look fine to me. The new cut-off makes sense, and it does
save quite a bit of code. We do need to get the Cirrus CI Debian images
updated first, as you had already written.
As part of this patch, you also sneak
On Sat, 11 May 2024 at 21:36, AJ ONeal wrote:
>
> I just joined the mailing list and I don't know how to respond to old
> messages. However, I have a few suggestions on the upcoming TLS and ALPN
> changes.
>
> TL;DR
>
> Prefer TLS over SSLRequest or plaintext (from the start)
>
>
On Sun, 12 May 2024 at 05:26, Paul Jungwirth
wrote:
> On 5/9/24 17:44, Matthias van de Meent wrote:
> > I haven't really been following this thread, but after playing around
> > a bit with the feature I feel there are new gaps in error messages. I
> > also think there are gaps in the
On 2024-05-12 Su 01:34, Tom Lane wrote:
BTW, I've also been wondering why hamerkop has been failing
isolation-check in the 12 and 13 branches for the last six months
or so. It is surely unrelated to this issue, and it looks like
it must be due to some platform change rather than anything we
On 01.05.24 19:04, Greg Sabino Mullane wrote:
Thank you for taking the time to review this. I've attached a new
rebased version, which has no significant changes.
There is a comment in the patch that states:
/* We do not need clean_ipv6_addr here: just report verbatim */
I am not
On 06.03.24 16:59, Greg Sabino Mullane wrote:
Someone on -general was asking about this, as they are listening on
multiple IPs and would like to know which exact one clients were
hitting. I took a quick look and we already have that information, so I
grabbed some stuff from inet_server_addr
On 19.04.24 11:47, Aleksander Alekseev wrote:
Thanks. I see a few pieces of code that use special FOO_NUMBER enum
values instead of a macro. Should we refactor these pieces
accordingly? PFA another patch.
I think this is a sensible improvement.
But please keep the trailing commas on the last
On 14.12.23 14:40, Nazir Bilal Yavuz wrote:
On Fri, 6 Oct 2023 at 17:07, Tom Lane wrote:
As a quick cross-check, I searched our commit log to see how many
README-only commits there were so far this year. I found 11 since
January. (Several were triggered by the latest round of pgindent
code
On 16.03.24 05:25, Bharath Rupireddy wrote:
Postgres has a good amount of code for dealing with backtraces - two
GUCs backtrace_functions and backtrace_on_internal_error,
errbacktrace; all of which use core function set_backtrace from
elog.c. I've not seen this code being tested at all, see code
> On Tue, Apr 23, 2024 at 10:18:15AM +0200, Dmitry Dolgov wrote:
> > On Mon, Apr 15, 2024 at 06:09:29PM +0900, Sutou Kouhei wrote:
> >
> > Thanks. I'm not familiar with this code base but I've
> > reviewed these patches because I'm interested in this
> > feature too.
>
> Thanks for the review! The
Hello Tom,
12.05.2024 08:34, Tom Lane wrote:
BTW, I've also been wondering why hamerkop has been failing
isolation-check in the 12 and 13 branches for the last six months
or so. It is surely unrelated to this issue, and it looks like
it must be due to some platform change rather than anything
> I am able to apply all your patches. I found that a similar thing
> happened before [0] and I guess your case is similar. Adding Thomas to
> CC, he may be able to help more.
Ok. Thanks for the info.
> Nitpick: There is a trailing space warning while applying one of your patches:
> Applying:
Hi,
On Sun, 12 May 2024 at 09:50, Tatsuo Ishii wrote:
>
> After sending out my v18 patches:
> https://www.postgresql.org/message-id/20240511.162307.2246647987352188848.t-ishii%40sranhm.sra.co.jp
>
> CFbot complains that the patch was broken:
> http://cfbot.cputube.org/patch_48_4460.log
>
> ===
After sending out my v18 patches:
https://www.postgresql.org/message-id/20240511.162307.2246647987352188848.t-ishii%40sranhm.sra.co.jp
CFbot complains that the patch was broken:
http://cfbot.cputube.org/patch_48_4460.log
=== Applying patches on top of PostgreSQL commit ID
32 matches
Mail list logo
