Re: [HACKERS] Refreshing subscription relation state inside atransaction block

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Refreshing subscription relation state inside atransaction block
Дата
Msg-id CA+TgmoayW833+ndMkadwgysfxVwoczUWdopTnfhdn_CBvo=YGw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Refreshing subscription relation state inside atransaction block  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [HACKERS] Refreshing subscription relation state inside atransaction block  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitorprogression of long running SQL queries/utilities
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Change in "policy" on dump ordering?