Hi, Alexander and Andres!
On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov
wrote:
> Hi,
>
> On Mon, Apr 8, 2024 at 12:40 AM Andres Freund wrote:
> > On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
> > > I've pushed 0001, 0002 and 0006.
> >
> > I briefly looked at 27bc1772fc81 and I don't
Hello.
I noticed that NLS doesn't work for pg_combinebackup. The cause is
that the tool forgets to call set_pglocale_pgservice().
This issue is fixed by the following chage.
diff --git a/src/bin/pg_combinebackup/pg_combinebackup.c
b/src/bin/pg_combinebackup/pg_combinebackup.c
index 1b07ca3fb6..
At Mon, 08 Apr 2024 16:27:02 +0900 (JST), Kyotaro Horiguchi
wrote in
> Hello.
>
> I noticed that NLS doesn't work for pg_combinebackup. The cause is
> that the tool forgets to call set_pglocale_pgservice().
>
> This issue is fixed by the following chage.
>
> diff --git a/src/bin/pg_combinebac
On Mon, Apr 08, 2024 at 10:22:40AM +0900, Michael Paquier wrote:
> For now I have applied 997db123c054 to make the GIN tests with
> injection points repeatable as it was an independent issue, and
> f587338dec87 to add the local function pieces.
Bharath has reported me offlist that one of the new t
On Mon, Apr 08, 2024 at 04:27:02PM +0900, Kyotaro Horiguchi wrote:
> I noticed that NLS doesn't work for pg_combinebackup. The cause is
> that the tool forgets to call set_pglocale_pgservice().
>
> This issue is fixed by the following chage.
Indeed. Good catch.
--
Michael
signature.asc
Descrip
> On 8 Apr 2024, at 10:33, Michael Paquier wrote:
>
> Thoughts?
As an alternative we can make local injection points mutually exclusive.
Best regards, Andrey Borodin.
Hello Michael,
08.04.2024 08:23, Michael Paquier wrote:
On Fri, Apr 05, 2024 at 06:19:20PM +0200, Jelte Fennema-Nio wrote:
Agreed. While not a full solution, I think this patch is still good to
address some of the pain: Waiting 10 seconds at the end of my build
with only 1 of my 10 cores doing
On 05.04.24 18:19, Jelte Fennema-Nio wrote:
On Fri, 5 Apr 2024 at 17:24, Andres Freund wrote:
I recommend opening a bug report for clang, best with an already preprocessed
input file.
We're going to need to do something about this from our side as well, I
suspect. The times aren't great with
> On 29 Feb 2024, at 11:24, Benoit Lobréau wrote:
>
> Yes, thanks for the proposal, I'll work on it on report here.
Hi Benoit!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Thanks!
Best regards, Andrey
> On 22 Sep 2023, at 18:50, Matthias van de Meent
> wrote:
Hi Matthias!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Thanks!
Best regards, Andrey Borodin.
[0] https://commitfest.postgresql.org/47/454
On 2024-Apr-07, Jeff Davis wrote:
> On Sun, 2024-04-07 at 14:19 +0200, Alvaro Herrera wrote:
> > I pushed the "copy" pointer now, except that I renamed it to
> > "insert",
> > which is what we call the operation being tracked. I also added some
> > comments.
>
> The "copy" pointer, as I called i
On Mon, 8 Apr 2024 at 10:00, Alexander Lakhin wrote:
> As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
> is fixed already.
> Perhaps it's worth rechecking...
Using the attached script I got these timings. Clang is significantly
slower in all of them. But especially with -
On 08/04/2024 04:25, Heikki Linnakangas wrote:
One important open item now is that we need to register a proper ALPN
protocol ID with IANA.
I sent a request for that:
https://mailarchive.ietf.org/arch/msg/tls-reg-review/9LWPzQfOpbc8dTT7vc9ahNeNaiw/
--
Heikki Linnakangas
Neon (https://neon.te
Hi Andrey,
On Sun, Mar 31, 2024 at 2:03 PM Andrey M. Borodin wrote:
> > On 6 Dec 2023, at 23:52, Robert Haas wrote:
> >
> > I hope that it's at least somewhat useful.
>
> > On 5 Jan 2024, at 15:46, vignesh C wrote:
> >
> > There is a leak reported
>
> Hi Amit,
>
> this is a kind reminder that
On Mon, Apr 08, 2024 at 10:42:08AM +0300, Andrey M. Borodin wrote:
> As an alternative we can make local injection points mutually exclusive.
Sure. Now, the point of the test is to make sure that the local
cleanup happens, so I'd rather keep it as-is and use the same names
across reloads.
--
Mich
On Mon, 8 Apr 2024 at 10:02, Peter Eisentraut wrote:
> I have tested this with various compilers, and I can confirm that this
> shaves off about 5 seconds from the build wall-clock time, which
> represents about 10%-20% of the total time. I think this is a good patch.
Great to hear.
> Interesti
Hello Jelte,
08.04.2024 11:36, Jelte Fennema-Nio wrote:
On Mon, 8 Apr 2024 at 10:00, Alexander Lakhin wrote:
As I wrote in [1], I didn't observe the issue with clang-18, so maybe it
is fixed already.
Perhaps it's worth rechecking...
Using the attached script I got these timings. Clang is sign
On Mon, Apr 8, 2024 at 2:02 PM jian he wrote:
> On Mon, Apr 8, 2024 at 11:21 AM jian he wrote:
> >
> > On Mon, Apr 8, 2024 at 12:34 AM jian he wrote:
> > >
> > > On Sun, Apr 7, 2024 at 9:36 PM Amit Langote
> > > wrote:
> > > > 0002 needs an expanded commit message but I've run out of energy to
Hi,
On Mon, 8 Apr 2024 at 11:00, Alexander Lakhin wrote:
>
> Hello Michael,
>
> 08.04.2024 08:23, Michael Paquier wrote:
> > On Fri, Apr 05, 2024 at 06:19:20PM +0200, Jelte Fennema-Nio wrote:
> >> Agreed. While not a full solution, I think this patch is still good to
> >> address some of the pain
> On 8 Apr 2024, at 11:55, Michael Paquier wrote:
>
> the point of the test is to make sure that the local
> cleanup happens
Uh, I did not understand this. Because commit message was about stabiilzizing
tests, not extending coverage.
Also, should we drop function wait_pid() at the end of a t
On Mon, Apr 8, 2024 at 10:18 AM Pavel Borisov wrote:
> On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov wrote:
>>
>> Hi,
>>
>> On Mon, Apr 8, 2024 at 12:40 AM Andres Freund wrote:
>> > On 2024-03-30 23:33:04 +0200, Alexander Korotkov wrote:
>> > > I've pushed 0001, 0002 and 0006.
>> >
>> > I brie
> On 27 Sep 2023, at 16:06, tender wang wrote:
>
>Do you have any comments or suggestions on this issue? Thanks.
Hi Tender,
there are some review comments in the thread, that you might be interested in.
I'll mark this [0] entry "Waiting on Author" and move to next CF.
Thanks!
Best rega
On 21.03.24 12:23, Peter Eisentraut wrote:
All the examples in the tests append "value" to this, presumably by
analogy with CHECK constraints, but it looks as though anything works,
and is simply ignored:
ALTER DOMAIN d ADD CONSTRAINT nn NOT NULL xxx; -- works
That doesn't seem particularly sat
On Mon, 8 Apr 2024 at 13:34, Alexander Korotkov
wrote:
> On Mon, Apr 8, 2024 at 10:18 AM Pavel Borisov
> wrote:
> > On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov
> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Apr 8, 2024 at 12:40 AM Andres Freund
> wrote:
> >> > On 2024-03-30 23:33:04 +0200, Alexa
Hi,
> There are many more interesting and scary libraries in the dependency
> tree of "postgres", so just picking off one right now doesn't really
> accomplish anything. The next release of libsystemd will drop all
> the compression libraries as hard dependencies, so the issue in that
> sense is
On Mon, Apr 8, 2024 at 12:19 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Saturday, April 6, 2024 12:43 PM Amit Kapila
> wrote:
> > On Fri, Apr 5, 2024 at 8:05 PM Bertrand Drouvot
> > wrote:
> >
> > Yeah, that could be the first step. We can probably add an injection point
> > to
> > control the bgwr
On Sun, 7 Apr 2024 at 14:41, David Rowley wrote:
> Looking at the code in socket_putmessage_noblock(), I don't understand
> why it's ok for PqSendBufferSize to be int but "required" must be
> size_t. There's a line that does "PqSendBufferSize = required;". It
> kinda looks like they both should b
Hi all,
I went through the MERGE/SPLIT partition codes today, thanks for the
works. I found some grammar errors:
i. in error messages(Users can see this grammar errors, not friendly).
ii. in codes comments
Alexander Korotkov 于2024年4月7日周日 06:23写道：
> Hi, Dmitry!
>
> On Fri, Apr 5, 2024 at 4:
Andrey M. Borodin 于2024年4月8日周一 17:40写道：
>
>
> > On 27 Sep 2023, at 16:06, tender wang wrote:
> >
> >Do you have any comments or suggestions on this issue? Thanks.
> Hi Tender,
>
> there are some review comments in the thread, that you might be interested
> in.
> I'll mark this [0] entry "Wai
Hi, Alexander
On Mon, 8 Apr 2024 at 13:59, Pavel Borisov wrote:
>
>
> On Mon, 8 Apr 2024 at 13:34, Alexander Korotkov
> wrote:
>
>> On Mon, Apr 8, 2024 at 10:18 AM Pavel Borisov
>> wrote:
>> > On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Mon, Apr 8,
On Tue, 2 Apr 2024 at 15:01, Tom Lane wrote:
> "Tharakan, Robins" writes:
> > So although HEAD ran fine, but I saw multiple failures (v12, v13, v16)
all of which passed on subsequent-tries,
> > of which some were even"signal 6: Aborted".
>
> Ugh...
parula didn't send any reports to buildfarm fo
Hi Tender Wang,
08.04.2024 13:43, Tender Wang wrote:
Hi all,
I went through the MERGE/SPLIT partition codes today, thanks for the works.
I found some grammar errors:
i. in error messages(Users can see this grammar errors, not friendly).
ii. in codes comments
On a quick glance, I saw also
Em seg., 8 de abr. de 2024 às 07:42, Jelte Fennema-Nio
escreveu:
> On Sun, 7 Apr 2024 at 14:41, David Rowley wrote:
> > Looking at the code in socket_putmessage_noblock(), I don't understand
> > why it's ok for PqSendBufferSize to be int but "required" must be
> > size_t. There's a line that do
Hi James,
There are some review in the thread that need to be addressed.
it seems that we need to mark this entry "Waiting on Author" and move to
the next CF [0].
Thanks
[0] https://commitfest.postgresql.org/47/4355/
On Sat, 10 Jun 2023 at 05:27, James Coleman wrote:
> I've previously noted i
Hi, John!
On Mon, 8 Apr 2024 at 03:13, John Naylor wrote:
> On Mon, Apr 8, 2024 at 2:07 AM Andres Freund wrote:
> >
> > Looking at the code, the failure isn't suprising anymore:
> > chardata[MaxBlocktableEntrySize];
> > BlocktableEntry *page = (BlocktableEntry *) dat
On Sun, Apr 7, 2024 at 9:08 AM John Naylor wrote:
>
> I've attached a mostly-polished update on runtime embeddable values,
> storing up to 3 offsets in the child pointer (1 on 32-bit platforms).
> As discussed, this includes a macro to cap max possible offset that
> can be stored in the bitmap, wh
On Sun, 7 Apr 2024 at 11:34, David Rowley wrote:
> That seems to require modifying the following function signatures:
> secure_write(), be_tls_write(), be_gssapi_write(). That's not an area
> I'm familiar with, however.
Attached is a new patchset where 0003 does exactly that. The only
place wher
On Sat, Apr 6, 2024 at 5:44 AM Jeff Davis wrote:
>
> >
> > It sounds like a data structure that mixes the hash table and the
> > binary heap and we use it as the main storage (e.g. for
> > ReorderBufferTXN) instead of using the binary heap as the secondary
> > data structure. IIUC with your idea,
On Mon, 8 Apr 2024 at 16:27, John Naylor wrote:
> On Sun, Apr 7, 2024 at 9:08 AM John Naylor
> wrote:
> >
> > I've attached a mostly-polished update on runtime embeddable values,
> > storing up to 3 offsets in the child pointer (1 on 32-bit platforms).
> > As discussed, this includes a macro to
On Mon, Apr 8, 2024 at 7:42 PM Pavel Borisov wrote:
>
>> I pushed both of these and see that mylodon complains that anonymous
>> unions are a C11 feature. I'm not actually sure that the union with
>> uintptr_t is actually needed, though, since that's not accessed as
>> such here. The simplest thin
On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier wrote:
> And, as of the moment of typing this email, I get:
> =# select '2024-04-08 00:00-12:00' - now() as time_remaining;
> time_remaining
> -
> 13:10:35.688134
> (1 row)
>
> So there is just a bit more than half a day remaining be
On 2024-04-07 Su 20:58, Tom Lane wrote:
Coverity complained that this patch leaks memory:
/srv/coverity/git/pgsql-git/postgresql/src/bin/pg_combinebackup/load_manifest.c:
212 in load_backup_manifest()
206 bytes_left -= rc;
207 json_parse
On Monday, April 8, 2024 6:32 PM Amit Kapila wrote:
>
> On Mon, Apr 8, 2024 at 12:19 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Saturday, April 6, 2024 12:43 PM Amit Kapila
> wrote:
> > > On Fri, Apr 5, 2024 at 8:05 PM Bertrand Drouvot
> > > wrote:
> > >
> > > Yeah, that could be the first st
Robert Haas writes:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combined. I don't know. I think this mad
On 05.04.24 17:11, Robert Haas wrote:
4. Consolidate the "Generic WAL Records" and "Custom WAL Resource
Managers" chapters, which cover related topics, into a single one. I
didn't see anyone object to this, but David Johnston pointed out that
the patch I posted was a few bricks short of a load, b
Tom Lane wrote:
> I've reconsidered after realizing that implementing FETCH_COUNT
> atop traditional single-row mode would require either merging
> single-row results into a bigger PGresult or persuading psql's
> results-printing code to accept an array of PGresults not just
> one. Either
On Mon, Apr 8, 2024 at 9:26 AM Robert Haas wrote:
>
> On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier wrote:
> > And, as of the moment of typing this email, I get:
> > =# select '2024-04-08 00:00-12:00' - now() as time_remaining;
> > time_remaining
> > -
> > 13:10:35.688134
> > (
On Mon, Apr 8, 2024 at 10:27 AM Melanie Plageman
wrote:
> On Mon, Apr 8, 2024 at 9:26 AM Robert Haas wrote:
> > On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier wrote:
> > > And, as of the moment of typing this email, I get:
> > > =# select '2024-04-08 00:00-12:00' - now() as time_remaining;
> > >
On Mon, 2024-04-08 at 09:26 -0400, Robert Haas wrote:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combine
> On 8 Apr 2024, at 17:26, Melanie Plageman wrote:
>
> What if we pick the actual feature freeze time randomly? That is,
> starting on March 15th (or whenever but more than a week before), each
> night someone from RMT generates a random number between $current_day
> and April 8th. If the numb
On 08/04/2024 16:43, Tom Lane wrote:
Robert Haas writes:
And maybe we need to think of a way to further mitigate this crush of
last minute commits. e.g. In the last week, you can't have more
feature commits, or more lines of insertions in your commits, than you
did in the prior 3 weeks combined
On Mon, Apr 8, 2024 at 10:41 AM Robert Treat wrote:
>
> On Mon, Apr 8, 2024 at 10:27 AM Melanie Plageman
> wrote:
> > On Mon, Apr 8, 2024 at 9:26 AM Robert Haas wrote:
> > > On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier
> > > wrote:
> > > > And, as of the moment of typing this email, I get:
>
> On 19 Feb 2024, at 11:33, Peter Eisentraut wrote:
>
> Ok, I didn't see that my feedback had been addressed. I have committed this
> patch.
Justin, Peter, I can't determine actual status of the CF entry [0]. May I ask
someone of you to move patch to next CF or close as committed?
Thanks!
On Mon, 8 Apr 2024 at 18:42, Heikki Linnakangas wrote:
> On 08/04/2024 16:43, Tom Lane wrote:
> > Robert Haas writes:
> >> And maybe we need to think of a way to further mitigate this crush of
> >> last minute commits. e.g. In the last week, you can't have more
> >> feature commits, or more line
Heikki Linnakangas writes:
> On 08/04/2024 16:43, Tom Lane wrote:
>> I was just about to pen an angry screed along the same lines.
>> The commit flux over the past couple days, and even the last
>> twelve hours, was flat-out ridiculous. These patches weren't
>> ready a week ago, and I doubt they
Hello Daniel and Tom,
08.04.2024 17:25, Daniel Verite wrote:
So I whacked the patch around till I liked it better, and pushed it.
Thanks for taking care of this!
Now that ExecQueryUsingCursor() is gone, it's not clear, what does
the following comment mean:?
* We must turn off gexec_flag
Pavel Borisov writes:
> IMO the fact that people struggle to work on patches, and make them better,
> etc. is an immense blessing for the Postgres community. Is the peak of
> commits really a big problem provided we have 6 months before actual
> release? I doubt March patches tend to be worse than
Alexander Lakhin writes:
> Now that ExecQueryUsingCursor() is gone, it's not clear, what does
> the following comment mean:?
> * We must turn off gexec_flag to avoid infinite recursion. Note that
> * this allows ExecQueryUsingCursor to be applied to the individual query
> * results.
08.04.2024 18:08, Tom Lane wrote:
Alexander Lakhin writes:
Now that ExecQueryUsingCursor() is gone, it's not clear, what does
the following comment mean:?
* We must turn off gexec_flag to avoid infinite recursion. Note that
* this allows ExecQueryUsingCursor to be applied to the indi
On 4/8/24 16:59, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 08/04/2024 16:43, Tom Lane wrote:
>>> I was just about to pen an angry screed along the same lines.
>>> The commit flux over the past couple days, and even the last
>>> twelve hours, was flat-out ridiculous. These patches were
On 4/8/24 11:05, Tom Lane wrote:
Pavel Borisov writes:
IMO the fact that people struggle to work on patches, and make them better,
etc. is an immense blessing for the Postgres community. Is the peak of
commits really a big problem provided we have 6 months before actual
release? I doubt March p
Hi,
On 2024-04-08 09:26:09 -0400, Robert Haas wrote:
> On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier wrote:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in
Hi,
On 2024-04-08 11:17:51 +0400, Pavel Borisov wrote:
> On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov
> > I was under the impression there are not so many out-of-core table
> > AMs, which have non-dummy analysis implementations. And even if there
> > are some, duplicating acquire_sample_rows(
On Mon, 8 Apr 2024 at 17:21, Tomas Vondra wrote:
>
>
>
> On 4/8/24 16:59, Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> On 08/04/2024 16:43, Tom Lane wrote:
> >>> I was just about to pen an angry screed along the same lines.
> >>> The commit flux over the past couple days, and even the last
On Mon, Apr 8, 2024 at 4:04 AM Amit Kapila wrote:
> Fix the intermittent buildfarm failures in 040_standby_failover_slots_sync.
>
> It is possible that even if the primary waits for the subscriber to catch
> up and then disables the subscription, the XLOG_RUNNING_XACTS record gets
> inserted betwe
On Mon, 8 Apr 2024 at 19:48, Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Mon, 8 Apr 2024 at 17:21, Tomas Vondra
> wrote:
> >
> >
> >
> > On 4/8/24 16:59, Tom Lane wrote:
> > > Heikki Linnakangas writes:
> > >> On 08/04/2024 16:43, Tom Lane wrote:
> > >>> I was just about to
On 2024-04-08 08:37:44 -0700, Andres Freund wrote:
> On 2024-04-08 11:17:51 +0400, Pavel Borisov wrote:
> > On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov
> > > I was under the impression there are not so many out-of-core table
> > > AMs, which have non-dummy analysis implementations. And even i
On 4/8/24 10:05, Andrey M. Borodin wrote:
Hi Benoit!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Hi thanks for the reminder,
The past month as been hectic for me.
It should calm down by next week at wich
On Mon, 2024-04-08 at 10:24 +0200, Alvaro Herrera wrote:
> My trouble with the "copy" term is that we don't use that term
> anywhere
> in relation to WAL.
I got the term from CopyXLogRecordToWAL().
> This "copy" is in
> reality just the insertion, after it's finished. The "Result" suffix
> is in
Hi,
On 2024-04-08 16:01:41 +0530, Amit Kapila wrote:
> Pushed.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=adder&dt=2024-04-08%2012%3A04%3A27
This unfortunately is a commit after
commit 6f3d8d5e7cc
Author: Amit Kapila
Date: 2024-04-08 13:21:55 +0530
Fix the intermittent buil
On 4/8/24 8:29 AM, Andres Freund wrote:
Hi,
On 2024-04-08 09:26:09 -0400, Robert Haas wrote:
On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier wrote:
And maybe we need to think of a way to further mitigate this crush of
last minute commits. e.g. In the last week, you can't have more
feature commi
On Mon, Apr 8, 2024 at 11:48 AM Matthias van de Meent
wrote:
> I also think there is already a big issue with a lack of interest in
> getting existing patches from non-committers committed, reducing the
> set of patches that could be considered is just cheating the numbers
> and discouraging peopl
On 2024-Apr-08, Robert Haas wrote:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combined. I don't know. I
On Mon, Apr 8, 2024, 19:08 Andres Freund wrote:
> On 2024-04-08 08:37:44 -0700, Andres Freund wrote:
> > On 2024-04-08 11:17:51 +0400, Pavel Borisov wrote:
> > > On Mon, 8 Apr 2024 at 03:25, Alexander Korotkov
> > > > I was under the impression there are not so many out-of-core table
> > > > AMs
On Tue, Apr 9, 2024 at 12:30 AM Andres Freund wrote:
>
> Hi,
>
> On 2024-04-08 09:26:09 -0400, Robert Haas wrote:
> > On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier wrote:
> > And maybe we need to think of a way to further mitigate this crush of
> > last minute commits. e.g. In the last week, you
>>> There is pg_read_all_stats as well, so I don't see a big issue in
>>> requiring to be a member of this role as well for the sake of what's
>>> proposing here.
>>
>> Well, that tells you quite a bit more than just which PIDs correspond to
>> autovacuum workers, but maybe that's good enough for n
On 4/8/24 17:48, Matthias van de Meent wrote:
> On Mon, 8 Apr 2024 at 17:21, Tomas Vondra
> wrote:
>>
>> ...
>>
>> For me the main problem with the pre-freeze crush is that it leaves
>> pretty much no practical chance to do meaningful review/testing, and
>> some of the patches likely went throu
On Fri, Apr 5, 2024 at 5:14 PM Michael Paquier wrote:
> Saying that, my spidey sense tingles at the recent commit
> 3311ea86edc7, that had the idea to introduce a 20k line output file
> based on a 378 line input file full of random URLs. In my experience,
> tests don't require to be that large to
On Mon, Apr 8, 2024 at 12:33 PM Alexander Korotkov wrote:
> Yes, it was my mistake. I got rushing trying to fit this to FF, even doing
> significant changes just before commit.
> I'll revert this later today.
Alexander,
Exactly how much is getting reverted here? I see these, all since March 23r
On Mon, 2024-04-08 at 21:29 +0900, Masahiko Sawada wrote:
> For v17, changes for #2 are smaller, but I'm concerned
> that the new API that requires a hash function to be able to use
> binaryheap_update_{up|down} might not be user friendly.
The only API change in 02 is accepting a hash callback rat
Hi,
On 4/8/24 14:15, Tomas Vondra wrote:
I think we need to
fix & improve that - not to rework/push it at the very end.
This is going to be very extreme...
Either a patch is ready for merge or it isn't - when 2 or more
Committers agree on it then it can be merged - the policy have to be
di
On Mon, 8 Apr 2024 at 20:15, Tomas Vondra wrote:
> I 100% understand how frustrating the lack of progress can be, and I
> agree we need to do better. I tried to move a number of stuck patches
> this CF, and I hope (and plan) to do more of this in the future.
>
> But I don't quite see how would thi
On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas wrote:
> Can you elaborate, which patches you think were not ready? Let's make
> sure to capture any concrete concerns in the Open Items list.
Hi,
I'm moving this topic to a new thread for better visibility and less
admixture of concerns. I'd li
On Mon, Apr 8, 2024 at 3:32 PM Jelte Fennema-Nio wrote:
> Maybe a better solution to this problem would be to spread impactful
> reviews by committers more evenly throughout the year. Then there
> wouldn't be such a rush to address them in the last commit fest.
Spreading activity of all sorts mor
Alexander Lakhin wrote:
> >> Now that ExecQueryUsingCursor() is gone, it's not clear, what does
> >> the following comment mean:?
> >> * We must turn off gexec_flag to avoid infinite recursion. Note that
> >> * this allows ExecQueryUsingCursor to be applied to the individual
>
Alexander Lakhin writes:
> 08.04.2024 18:08, Tom Lane wrote:
>> Hmm, the point about recursion is still valid isn't it? I agree the
>> reference to ExecQueryUsingCursor is obsolete, but I think we need to
>> reconstruct what this comment is actually talking about. It's
>> certainly pretty obscur
On 2024-04-08 21:29 +0200, Daniel Gustafsson wrote:
> Over in [0] I asked whether it would be worthwhile converting all our README
> files to Markdown, and since it wasn't met with pitchforks I figured it would
> be an interesting excercise to see what it would take (my honest gut feeling
> was tha
> On 8 Apr 2024, at 22:30, Erik Wienhold wrote:
> On 2024-04-08 21:29 +0200, Daniel Gustafsson wrote:
> I've only peeked at a couple of those READMEs, but they look alright so
> far (at least on GitHub). Should we settle on a specific Markdown
> flavor[1]? Because I'm never sure if some markups
Hi!
Attached fix for the problems found by Alexander Lakhin.
About grammar errors.
Unfortunately, I don't know English well.
Therefore, I plan (in the coming days) to show the text to specialists
who perform technical translation of documentation.
--
With best regards,
Dmitry Koval
Postgres
On Mon, Apr 8, 2024 at 9:54 PM Robert Haas wrote:
> On Mon, Apr 8, 2024 at 12:33 PM Alexander Korotkov
> wrote:
> > Yes, it was my mistake. I got rushing trying to fit this to FF, even doing
> > significant changes just before commit.
> > I'll revert this later today.
It appears to be a non-tr
Hi! Thank you for your work on this issue!
Your patch required a little revision. I did this and attached the patch.
Also, I think you should add some clarification to the comments about
printing 'exact' and 'loosy' pages in show_hashagg_info function, which
you get from planstate->stats, wher
On Tue, Apr 9, 2024 at 7:47 AM Robert Haas wrote:
> - The streaming read API stuff was all committed very last minute. I
> think this should have been committed much sooner. It's probably not
> going to break the world; it's more likely to have performance
> consequences. But if it had gone in soo
On 2024-04-08 Mo 14:24, Jacob Champion wrote:
Michael pointed out over at [1] that the new tiny.json is pretty
inscrutable given its size, and I have to agree. Attached is a patch
to pare it down 98% or so. I think people wanting to run the
performance comparisons will need to come up with thei
Hi Postgres hackers,
I'm reaching out to gather some comments on enhancing the efficiency of
migrating particularly large tables with significant data volumes in
PostgreSQL.
When migrating a particularly large table with a significant amount of
data, users sometimes tend to split the table i
On 2024-04-08 Mo 09:29, Andrew Dunstan wrote:
On 2024-04-07 Su 20:58, Tom Lane wrote:
Coverity complained that this patch leaks memory:
/srv/coverity/git/pgsql-git/postgresql/src/bin/pg_combinebackup/load_manifest.c:
212 in load_backup_manifest()
206 bytes_left -= rc;
207
On Tue, 9 Apr 2024 at 09:52, David Zhang wrote:
> However, when executing SELECT min(ctid) and max(ctid), it performs a
> Seq Scan, which can be slow for a large table. Is there a way to
> retrieve the minimum and maximum ctid other than using the system
> functions min() and max()?
Finding the e
On 4/8/24 21:32, Jelte Fennema-Nio wrote:
> On Mon, 8 Apr 2024 at 20:15, Tomas Vondra
> wrote:
>> I 100% understand how frustrating the lack of progress can be, and I
>> agree we need to do better. I tried to move a number of stuck patches
>> this CF, and I hope (and plan) to do more of this i
On 2024-04-08 Mo 12:07, Alvaro Herrera wrote:
On 2024-Apr-08, Robert Haas wrote:
And maybe we need to think of a way to further mitigate this crush of
last minute commits. e.g. In the last week, you can't have more
feature commits, or more lines of insertions in your commits, than you
did in
Erik Wienhold writes:
> On 2024-04-07 06:33 +0200, Tom Lane wrote:
>> I suspect it'd be much more robust if we could remove the comment from
>> the expr->query string. No idea how hard that is.
> I slept on it and I think this can be fixed by tracking the end of the
> last token before THEN and
On Tue, Apr 09, 2024 at 09:35:00AM +1200, Thomas Munro wrote:
> Mr Paquier this year announced his personal code freeze a few weeks
> back on social media, which seemed like an interesting idea I might
> adopt. Perhaps that is what some other people are doing without
> saying so, and perhaps the t
1 - 100 of 140 matches
Mail list logo
