public inbox for [email protected]
help / color / mirror / Atom feedpgsql: tests: Fix race condition in postmaster/002_connection_limits
3+ messages / 2 participants
[nested] [flat]
* pgsql: tests: Fix race condition in postmaster/002_connection_limits
@ 2025-03-07 18:22 Andres Freund <[email protected]>
2025-03-10 22:46 ` Re: pgsql: tests: Fix race condition in postmaster/002_connection_limits Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Andres Freund @ 2025-03-07 18:22 UTC (permalink / raw)
To: [email protected]
tests: Fix race condition in postmaster/002_connection_limits
The test occasionally failed due to unexpected connection limit errors being
encountered after having waited for FATAL errors on another connection. These
spurious failures were caused by the the backend reporting FATAL errors to the
client before detaching from the PGPROC entry. Adding a sleep(1) before
proc_exit() makes it easy to reproduce that problem.
To fix the issue, add a helper function that waits for postmaster to notice
the process having exited. For now this is implemented by waiting for the
DEBUG2 message that postmaster logs in that case. That's not the prettiest
fix, but simple. If we notice this problem elsewhere, it might be worthwhile
to make this more general, e.g. by adding an injection point.
Reported-by: Tomas Vondra <[email protected]>
Diagnosed-by: Heikki Linnakangas <[email protected]>
Reviewed-by: Heikki Linnakangas <[email protected]>
Tested-by: Tomas Vondra <[email protected]>
Discussion: https://postgr.es/m/ggflhkciwdyotpoie323chu2c2idpjk5qimrn462encwx2io7s@thmcxl7i6dpw
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/71d1ed6fe129935ce2764c5d34924512ed046f69
Modified Files
--------------
src/test/postmaster/t/002_connection_limits.pl | 35 +++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgsql: tests: Fix race condition in postmaster/002_connection_limits
2025-03-07 18:22 pgsql: tests: Fix race condition in postmaster/002_connection_limits Andres Freund <[email protected]>
@ 2025-03-10 22:46 ` Andrew Dunstan <[email protected]>
2025-03-10 23:34 ` Re: pgsql: tests: Fix race condition in postmaster/002_connection_limits Andres Freund <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Dunstan @ 2025-03-10 22:46 UTC (permalink / raw)
To: Andres Freund <[email protected]>; [email protected]
On 2025-03-07 Fr 1:22 PM, Andres Freund wrote:
> tests: Fix race condition in postmaster/002_connection_limits
>
> The test occasionally failed due to unexpected connection limit errors being
> encountered after having waited for FATAL errors on another connection. These
> spurious failures were caused by the the backend reporting FATAL errors to the
> client before detaching from the PGPROC entry. Adding a sleep(1) before
> proc_exit() makes it easy to reproduce that problem.
>
> To fix the issue, add a helper function that waits for postmaster to notice
> the process having exited. For now this is implemented by waiting for the
> DEBUG2 message that postmaster logs in that case. That's not the prettiest
> fix, but simple. If we notice this problem elsewhere, it might be worthwhile
> to make this more general, e.g. by adding an injection point.
>
New test breaks when log_error_verbosity=verbose. It's adding an SQL
ERRCODE to the DEBUG string.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgsql: tests: Fix race condition in postmaster/002_connection_limits
2025-03-07 18:22 pgsql: tests: Fix race condition in postmaster/002_connection_limits Andres Freund <[email protected]>
2025-03-10 22:46 ` Re: pgsql: tests: Fix race condition in postmaster/002_connection_limits Andrew Dunstan <[email protected]>
@ 2025-03-10 23:34 ` Andres Freund <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Andres Freund @ 2025-03-10 23:34 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: [email protected]
Hi,
On 2025-03-10 18:46:12 -0400, Andrew Dunstan wrote:
> On 2025-03-07 Fr 1:22 PM, Andres Freund wrote:
> > tests: Fix race condition in postmaster/002_connection_limits
> >
> > The test occasionally failed due to unexpected connection limit errors being
> > encountered after having waited for FATAL errors on another connection. These
> > spurious failures were caused by the the backend reporting FATAL errors to the
> > client before detaching from the PGPROC entry. Adding a sleep(1) before
> > proc_exit() makes it easy to reproduce that problem.
> >
> > To fix the issue, add a helper function that waits for postmaster to notice
> > the process having exited. For now this is implemented by waiting for the
> > DEBUG2 message that postmaster logs in that case. That's not the prettiest
> > fix, but simple. If we notice this problem elsewhere, it might be worthwhile
> > to make this more general, e.g. by adding an injection point.
> >
>
>
> New test breaks when log_error_verbosity=verbose. It's adding an SQL ERRCODE
> to the DEBUG string.
Ugh, that's annoying. I guess no good deed (fixing the test) goes
unpunished...
Pushed a fix.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-03-10 23:34 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-03-07 18:22 pgsql: tests: Fix race condition in postmaster/002_connection_limits Andres Freund <[email protected]>
2025-03-10 22:46 ` Andrew Dunstan <[email protected]>
2025-03-10 23:34 ` Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox