Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Sergei Kornilov <sk@zsrv.org>, pgsql-hackers@postgresql.org, Peter Eisentraut <peter_e@gmx.net>, Marc Dean <marc.dean.jr@gmail.com>, Petr Jelinek <petr@2ndquadrant.com>, "michael.paul.powers@gmail.com" <michael.paul.powers@gmail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2018-07-24T22:06:30Z
Lists: pgsql-bugs, pgsql-hackers
On 2018-07-24 18:01:33 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > One other thing, somewhat independent, I wonder is if it's actually
> > problematic that we don't do ProcessCompletedNotifies() in a bunch of
> > processes, because that means we'll not necessarily call
> > asyncQueueAdvanceTail().  Perhaps that means we actually *do* need to do
> > it around CommitTransactionCommand()?
> 
> As far as that goes, we should probably ensure that a process that hasn't
> executed any LISTENs is ignored for purposes of whether to advance the
> queue tail.  I think it might be like that already.

It indeed is:
	min = QUEUE_HEAD;
	for (i = 1; i <= MaxBackends; i++)
	{
		if (QUEUE_BACKEND_PID(i) != InvalidPid)
			min = QUEUE_POS_MIN(min, QUEUE_BACKEND_POS(i));
	}

what I am wondering is what happens if there's a background worker (like
the replication worker, but it could be other things too) that queues
notifications, but no normal backends are actually listening. As far as
I can tell, in that case we'd continue to queue stuff into the slru, but
wouldn't actually clean things up until a normal session gets around to
it? Which might be a while, on e.g. a logical replica.

Greetings,

Andres Freund


Commits

  1. Disallow LISTEN in background workers.

  2. Send NOTIFY signals during CommitTransaction.

  3. Make some efficiency improvements in LISTEN/NOTIFY.