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
|
Список | 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 по дате отправления: