On Sat, May 23, 2015 at 11:19 AM, Andres Freund <
andres@anarazel.de> wrote:
>
> On May 22, 2015 10:23:06 PM PDT, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> >On Fri, May 22, 2015 at 11:20 PM, Andres Freund <
andres@anarazel.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@anarazel.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?
>
I don't know because I have not thought about how one can
use these API's in various ways in design of the Replication
system, but I think ideally we should prohibit the use of API
in circumstances where it could lead to problem or if that is
difficult or not possible or not worth, then at least we can mention
the same in docs.