Re: [HACKERS] Refreshing subscription relation state inside atransaction block - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Refreshing subscription relation state inside atransaction block
Date
Msg-id CA+TgmoayW833+ndMkadwgysfxVwoczUWdopTnfhdn_CBvo=YGw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Refreshing subscription relation state inside atransaction block  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] Refreshing subscription relation state inside atransaction block
List pgsql-hackers
On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada <sawada.mshk@gmail.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?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitorprogression of long running SQL queries/utilities
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Change in "policy" on dump ordering?