Re: [PATCH] Fix stale relation close in sequence synchronization - Mailing list pgsql-hackers

From Ayush Tiwari
Subject Re: [PATCH] Fix stale relation close in sequence synchronization
Date
Msg-id CAJTYsWW8QdW7cFfWUGsoOMRpR-s2PB39cZZ=dv5vibtdeqErFw@mail.gmail.com
Whole thread
In response to Re: [PATCH] Fix stale relation close in sequence synchronization  (vignesh C <vignesh21@gmail.com>)
Responses Re: [PATCH] Fix stale relation close in sequence synchronization
List pgsql-hackers
Hi,

On Fri, 1 May 2026 at 09:54, vignesh C <vignesh21@gmail.com> wrote:
On Fri, 1 May 2026 at 08:58, Ajin Cherian <itsajin@gmail.com> wrote:
>
> This seems to be causing the below buildfarm failure:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2026-04-30%2018%3A50%3A23

Thanks for reporting this, we are analyzing this. We will analyze and
propose a patch for the same.


From what I see it the failure is 
not in the sequence-copy logic itself. It happens before 
the test reaches the privilege check: after the test 
switches the subscription connection to user=regress_seq_repl, 
Windows tries SSPI auth for that login role and rejects it. 

I could not run a native Windows SSPI test locally, 
but this follows the existing TAP harness pattern 
used by tests that authenticate as non-default roles. 
The failure occurs because regress_seq_repl is used in 
the subscription connection string but is not passed via 
auth_extra, so pg_regress --config-auth does not add a 
Windows SSPI ident mapping for it.

Meanwhile I'll try to set up a windows machine
and run the test 

meson test -C build subscription/036_sequences --print-errorlogs --verbose


Regards,
Ayush
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Having problems generating a code coverage report
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] Don't call ereport(ERROR) from recovery target GUC assign hooks