On 4/20/17 22:57, Michael Paquier wrote:
> On Fri, Apr 21, 2017 at 11:34 AM, Petr Jelinek
> wrote:
>> On 20/04/17 23:30, Peter Eisentraut wrote:
>>> On 4/20/17 10:19, Petr Jelinek wrote:
Hmm well since this only affects the synchronization of table
states/names, I guess we could just sim
On Fri, Apr 21, 2017 at 11:34 AM, Petr Jelinek
wrote:
> On 20/04/17 23:30, Peter Eisentraut wrote:
>> On 4/20/17 10:19, Petr Jelinek wrote:
>>> Hmm well since this only affects the synchronization of table
>>> states/names, I guess we could just simply do that before we create the
>>> slot as ther
On 20/04/17 23:30, Peter Eisentraut wrote:
> On 4/20/17 10:19, Petr Jelinek wrote:
>> Hmm well since this only affects the synchronization of table
>> states/names, I guess we could just simply do that before we create the
>> slot as there is no expectancy of consistency between slot and the table
On 4/20/17 10:19, Petr Jelinek wrote:
> Hmm well since this only affects the synchronization of table
> states/names, I guess we could just simply do that before we create the
> slot as there is no expectancy of consistency between slot and the table
> list snapshot.
I suppose that wouldn't hurt.
On 4/20/17 08:41, Michael Paquier wrote:
> As subscription is a self-contained concept, it seems to me that any
> errors happening should at least try to do some cleanup action before
> just giving up processing, that would be a less frustrating
> experience.
This is the way it's designed.
The al
On 20/04/17 14:41, Michael Paquier wrote:
> On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek
> wrote:
>> Or you can drop the slot manually on upstream.
>
> Sure, but the point here is that if for example users have
> client_min_messages set at least at warning, they may have no idea
> that an underl
On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek
wrote:
> Or you can drop the slot manually on upstream.
Sure, but the point here is that if for example users have
client_min_messages set at least at warning, they may have no idea
that an underlying slot has been created. This is a confusing
experie
On 20/04/17 09:35, Michael Paquier wrote:
> On Thu, Apr 20, 2017 at 4:22 PM, Michael Paquier
> wrote:
>> I am adding an open item.
>
> Just adding something... When a subscription is created, if the step
> synchronizing tables fails then CREATE SUBSCRIPTION fails but the slot
> remains present on
On 20/04/17 09:22, Michael Paquier wrote:
> Hi,
>
> I have noticed the following behavior with DROP SUBSCRIPTION followed
> by a cancel request. If the remote replication slot is dropped, the
> subscription may still be present locally:
> =# CREATE SUBSCRIPTION mysub CONNECTION 'port=5432 user=mpa
On Thu, Apr 20, 2017 at 4:22 PM, Michael Paquier
wrote:
> I am adding an open item.
Just adding something... When a subscription is created, if the step
synchronizing tables fails then CREATE SUBSCRIPTION fails but the slot
remains present on the publisher side, so trying to re-create the same
su
Hi,
I have noticed the following behavior with DROP SUBSCRIPTION followed
by a cancel request. If the remote replication slot is dropped, the
subscription may still be present locally:
=# CREATE SUBSCRIPTION mysub CONNECTION 'port=5432 user=mpaquier
dbname=mpaquier' PUBLICATION mypub, insert_only;
11 matches
Mail list logo