>> I think it should be set up
>> so that if the window function fails to call that, then something in
>> mainline execution of nodeWindowAgg.c throws an error when there had
>> been a RESPECT/IGNORE NULLS option. With that idea, you could drop
>> the allowNullTreatment argument and just have the
Hi Shubham,
Here are some v15 review comments.
==
IIUC the test cases #3 and #4 are supposed to reuse an existing publication.
There is logging in the code:
+ /* Reuse existing publication on publisher. */
+ pg_log_info("use existing publication \"%s\" in database \"%s\"",
+ dbinfo[i].pubnam
On 2025-Oct-09, Nathan Bossart wrote:
> On Thu, Oct 09, 2025 at 06:36:58PM +0200, Álvaro Herrera wrote:
> > On 2025-Oct-09, Nathan Bossart wrote:
> >> It looks like this was introduced by commit 9e4f914, which was
> >> back-patched, but the code path in question first appears in v15. So,
> >> pre
On 2025-Oct-09, Aleksander Alekseev wrote:
> diff --git a/src/backend/backup/basebackup.c b/src/backend/backup/basebackup.c
> index bb7d90aa5d9..0a8d621a373 100644
> --- a/src/backend/backup/basebackup.c
> +++ b/src/backend/backup/basebackup.c
> @@ -36,7 +36,6 @@
> #include "postmaster/syslogger.
Hi,
Thank you for your comments. I updated patch to v0003.
> Do we still need the cancel_flags? I cannot find other reasons to terminate
> workers. Also the things I don't like is that
> BGWORKER_CANCEL_ADMIN_COMMANDS must
> have the same value as BGWORKER_EXIT_AT_DATABASE_DROP. Only one
> flag e
On Fri, Oct 10, 2025 at 08:33:33AM +1300, David Rowley wrote:
> On Thu, 9 Oct 2025 at 16:47, Michael Paquier wrote:
>> Yes, a comment can be adapted here. Sounds good to me.
>
> Thanks. v3 looks good to me.
Thanks for double-checking. Applied after running an indent.
--
Michael
signature.asc
On Sun, Oct 12, 2025 at 1:00 AM Alexander Lakhin wrote:
> !!!wrapper_handler[1988]| postgres_signal_arg: 30, PG_NSIG: 33
> !!!wrapper_handler[1989]| postgres_signal_arg: 30, PG_NSIG: 33
> !!!wrapper_handler[3284]| postgres_signal_arg: 14, PG_NSIG: 33
> !!!wrapper_handler[3284]| postgres_signal_arg
While playing around with the test cases for pg_dump compression,
I was startled to discover that the performance of compress_lz4's
"stream API" code is absolutely abysmal. Here is a simple test
case to demonstrate, using the regression database as test data:
$ pg_dump -Fd --compress=lz4 -f rlz4.
On Sat, Oct 11, 2025, at 08:43, Joel Jacobson wrote:
> In addition to previously suggested optimization, there is another major
> one that seems doable, that would mean a great improvement for workload
> having large traffic differences between channels, i.e. some low traffic
> and some high traffi
