Re: BUG #15293: Stored Procedure Triggered by Logical Replication isUnable to use Notification Events
От | Andres Freund |
---|---|
Тема | Re: BUG #15293: Stored Procedure Triggered by Logical Replication isUnable to use Notification Events |
Дата | |
Msg-id | 20180724220630.zu5w3m25xzqa6jqp@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #15293: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #15293: Stored Procedure Triggered by Logical Replication isUnable to use Notification Events
Re: BUG #15293: Stored Procedure Triggered by Logical Replication isUnable to use Notification Events |
Список | 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
В списке pgsql-hackers по дате отправления: