Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Fri, Jul 28, 2017 at 1:13 PM, Masahiko Sawada wrote: > On Thu, Jul 27, 2017 at 9:31 AM, Masahiko Sawada > wrote: >> On Wed, Jul 26, 2017 at 10:29 PM, Robert Haas wrote: >>> On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Thu, Jul 27, 2017 at 9:31 AM, Masahiko Sawada wrote: > On Wed, Jul 26, 2017 at 10:29 PM, Robert Haas wrote: >> On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada >> wrote: I think that either of the options you

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Wed, Jul 26, 2017 at 10:29 PM, Robert Haas wrote: > On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada > 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

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada 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.

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Thu, Jun 15, 2017 at 11:49 PM, Petr Jelinek wrote: > On 15/06/17 15:52, Peter Eisentraut wrote: >> On 6/15/17 02:41, Petr Jelinek wrote: >>> Hmm, forcibly stopping currently running table sync is not what was >>> intended, I'll have to look into it. We should not

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On 15/06/17 15:52, Peter Eisentraut wrote: > On 6/15/17 02:41, Petr Jelinek wrote: >> Hmm, forcibly stopping currently running table sync is not what was >> intended, I'll have to look into it. We should not be forcibly stopping >> anything except the main apply worker during drop subscription

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On 6/15/17 02:41, Petr Jelinek wrote: > Hmm, forcibly stopping currently running table sync is not what was > intended, I'll have to look into it. We should not be forcibly stopping > anything except the main apply worker during drop subscription (and we > do that only because we can't drop the

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On 13/06/17 18:33, Masahiko Sawada wrote: > On Wed, Jun 14, 2017 at 1:02 AM, Masahiko Sawada > wrote: >> On Tue, Jun 13, 2017 at 4:53 PM, Petr Jelinek >> wrote: >>> On 13/06/17 09:06, Masahiko Sawada wrote: Hi, The commit

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Wed, Jun 14, 2017 at 1:02 AM, Masahiko Sawada wrote: > On Tue, Jun 13, 2017 at 4:53 PM, Petr Jelinek > wrote: >> On 13/06/17 09:06, Masahiko Sawada wrote: >>> Hi, >>> >>> The commit ddd7b22b225ae41d16ceb218b387645cb9becfdc makes table sync

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Tue, Jun 13, 2017 at 4:53 PM, Petr Jelinek wrote: > On 13/06/17 09:06, Masahiko Sawada wrote: >> Hi, >> >> The commit ddd7b22b225ae41d16ceb218b387645cb9becfdc makes table sync >> workers stop when subscription relation entry is removed. It doesn't >> work fine

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On 13/06/17 09:06, Masahiko Sawada wrote: > Hi, > > The commit ddd7b22b225ae41d16ceb218b387645cb9becfdc makes table sync > workers stop when subscription relation entry is removed. It doesn't > work fine inside transaction block. I think we should disallow to use > the following subscription DDLs

[HACKERS] Refreshing subscription relation state inside a transaction block

Hi, The commit ddd7b22b225ae41d16ceb218b387645cb9becfdc makes table sync workers stop when subscription relation entry is removed. It doesn't work fine inside transaction block. I think we should disallow to use the following subscription DDLs inside a transaction block. Attached patch. * ALTER