Re: Issues in Replication Progress Tracking

On May 22, 2015 10:23:06 PM PDT, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>On Fri, May 22, 2015 at 11:20 PM, Andres Freund <andres(at)anarazel(dot)de>
>wrote:
>>
>> On 2015-05-21 09:40:58 +0530, Amit Kapila wrote:
>> > On Thu, May 21, 2015 at 12:42 AM, Andres Freund
><andres(at)anarazel(dot)de>
>wrote:
>> > >
>> > > On 2015-05-20 19:27:05 +0530, Amit Kapila wrote:
>> > >
>> > > > 13.
>> > > > In function replorigin_session_setup() and or
>> > > > replorigin_session_advance(), don't we need to WAL log the
>> > > > use of Replication state?
>> > >
>> > > No, the point is that the replication progress is persisted via
>an
>extra
>> > > data block in the commit record. That's important for both
>performance
>> > > and correctness, because otherwise it gets hard to tie a
>transaction
>> > > made during replay with the update to the progress. Unless you
>use 2PC
>> > > which isn't really an alternative.
>> > >
>> >
>> > Okay, but what triggered this question was the difference of those
>functions
>> > as compare to when user call function
>pg_replication_origin_advance().
>> > pg_replication_origin_advance() will WAL log the information during
>that
>> > function call itself (via replorigin_advance()). So even if the
>transaction
>> > issuing pg_replication_origin_advance() function will abort, it
>will
>still
>> > update
>> > the Replication State, why so?
>>
>> I don't see a problem here. pg_replication_origin_advance() is for
>> setting up the initial position/update the position upon
>configuration
>> changes.
>
>Okay, I am not aware how exactly these API's will be used for
>replication
>but let me try to clarify what I have in mind related to this API
>usage.
>
>Can we use pg_replication_origin_advance() for node where Replay has
>to happen, if Yes, then Let us say user of
>pg_replication_origin_advance()
>API set the lsn position to X for the node N1 on which replay has to
>happen, so now replay will proceed from X + 1 even though the
>information related to X is not persisted, so now it could so happen
>X will get written after the replay of X + 1 which might lead to
>problem
>after crash recovery?

Then you'd use the session variant - which does tie into transactions. Is there a reason that's be unsuitable for you?

Andres

---
Please excuse brevity and formatting - I am writing this on my mobile phone.