Re: Refreshing subscription relation state inside a transaction block

On Wed, Jul 26, 2017 at 10:29 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>> I think that either of the options you suggested now would be better.
>>> We'll need that for stopping the tablesync which is in progress during
>>> DropSubscription as well as those will currently still keep running. I
>>> guess we could simply just register syscache callback, the only problem
>>> with that is we'd need to AcceptInvalidationMessages regularly while we
>>> do the COPY which is not exactly free so maybe killing at the end of
>>> transaction would be better (both for refresh and drop)?
>>
>> Attached patch makes table sync worker check its relation subscription
>> state at the end of COPY and exits if it has disappeared, instead of
>> killing table sync worker in DDL. There is still a problem that a
>> table sync worker for a large table can hold a slot for a long time
>> even after its state is deleted. But it would be for PG11 item.
>
> Do we still need to do something about this? Should it be an open item?
>

Thank you for looking at this.

Yeah, I think it should be added to the open item list. The patch is
updated by Petr and discussed on another thread[1] that also addresses
other issues of subscription codes. 0004 patch of that thread is an
updated patch of the patch attached on this thread.

[1] https://www.postgresql.org/message-id/4c6e7ab3-091e-6336-df38-28937b153e64%402ndquadrant.com

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center