Re: Logical decoding slots can go backwards when used from SQL, docs are wrong - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Logical decoding slots can go backwards when used from SQL, docs are wrong
Date
Msg-id CAMsr+YHCKWMD_7fxx7LY+s44n1RckXoy4ft77qNo6jwrkpkEVg@mail.gmail.com
Whole thread Raw
In response to Re: Logical decoding slots can go backwards when used from SQL, docs are wrong  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: Logical decoding slots can go backwards when used from SQL, docs are wrong
List pgsql-hackers
Attached is a patch to mark a logical replication slot as dirty if its confirmed lsn is changed.

Aesthetically I'm not sure if it's better to do it per this patch and call ReplicationSlotMarkDirty after we release the spinlock, add a new ReplicationSlotMarkDirtyLocked() that skips the spinlock acquisition, or add a bool is_locked arg to ReplicationSlotMarkDirty and update all call sites. All will have the same result.

I've confirmed this works as expected as part of the failover slots test suite but it'd be pretty seriously cumbersome to extract. If anyone feels strongly about it I can add a test that shows that 

- start master
- create slot
- do some stuff
- replay from slot
- fast-stop master
- start master
- replay from slot

doesn't see the same data a second time, but if we repeat it using immediate stop it will see the same data when replaying again.

Also attached is another patch to amend the docs to reflect the fact that a slot can actually replay the same change more than once. I avoided the strong temptation to update other parts of the docs nearby.

Both these are fixes that should IMO be applied to 9.6.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Odd oid-system-column handling in postgres_fdw
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Support for N synchronous standby servers - take 2