database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-06 19:59:18 +03:00
Code

Stabilize NOTIFY behavior by transmitting notifies before ReadyForQuery.

Browse Source 
This patch ensures that, if any notify messages were received during
a just-finished transaction, they get sent to the frontend just before
not just after the ReadyForQuery message.  With libpq and other client
libraries that act similarly, this guarantees that the client will see
the notify messages as available as soon as it thinks the transaction
is done.

This probably makes no difference in practice, since in realistic
use-cases the application would have to cope with asynchronous
arrival of notify events anyhow.  However, it makes it a lot easier
to build cross-session-notify test cases with stable behavior.
I'm a bit surprised now that we've not seen any buildfarm instability
with the test cases added by commit b10f40bf0.  Tests that I intend
to add in an upcoming bug fix are definitely unstable without this.

Back-patch to 9.6, which is as far back as we can do NOTIFY testing
with the isolationtester infrastructure.

Discussion: https://postgr.es/m/13881.1574557302@sss.pgh.pa.us
This commit is contained in:
Tom Lane 2019-11-24 14:42:59 -05:00
parent 295054411e
commit 377d1b95bf
2 changed files with 18 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/backend/commands/async.c
View File

@ -1721,11 +1721,13 @@ HandleNotifyInterrupt(void)
/* /*
* ProcessNotifyInterrupt * ProcessNotifyInterrupt
* *
* This is called just after waiting for a frontend command. If a * This is called if we see notifyInterruptPending set, just before
* interrupt arrives (via HandleNotifyInterrupt()) while reading, the * transmitting ReadyForQuery at the end of a frontend command, and
* read will be interrupted via the process's latch, and this routine * also if a notify signal occurs while reading from the frontend.
* will get called. If we are truly idle (ie, *not* inside a transaction * HandleNotifyInterrupt() will cause the read to be interrupted
* block), process the incoming notifies. * via the process's latch, and this routine will get called.
* If we are truly idle (ie, *not* inside a transaction block),
* process the incoming notifies.
*/ */
void void
ProcessNotifyInterrupt(void) ProcessNotifyInterrupt(void)

11
src/backend/tcop/postgres.c
View File

@ -4099,7 +4099,18 @@ PostgresMain(int argc, char *argv[],
} }
else else
{ {
/* Send out notify signals and transmit self-notifies */
ProcessCompletedNotifies(); ProcessCompletedNotifies();
/*
* Also process incoming notifies, if any. This is mostly to
* ensure stable behavior in tests: if any notifies were
* received during the just-finished transaction, they'll be
* seen by the client before ReadyForQuery is.
*/
if (notifyInterruptPending)
ProcessNotifyInterrupt();
pgstat_report_stat(false); pgstat_report_stat(false);
set_ps_display("idle", false); set_ps_display("idle", false);