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
>>> wrote:
> I think that either of the options you suggested no
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 suggested now would be better.
We'll need that for stopping the tablesync
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 progress during
>>> DropSubscription as well as th
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. I
>> guess we could sim
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 be forcibly stopping
>>> anythi
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 (and
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 rem
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 ddd7b22b225ae41d16ceb218b387645cb9becfdc makes table sync
>
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
>>> workers stop when subscription relation entry is r
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 inside transaction block. I think
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
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 S
12 matches
Mail list logo