Postgres Pro
Downloads
Home   >   mailing lists

Thread: Re: [HACKERS] Logical decoding on standby

Re: [HACKERS] Logical decoding on standby

From
sanyam jain
Date:

Hi,

In this patch in walsender.c sendTimeLineIsHistoric is set to true when current and ThisTimeLineID are equal.

sendTimeLineIsHistoric = state->currTLI == ThisTimeLineID;


Shouldn't sendTimeLineIsHistoric is true when state->currTLI is less than ThisTimeLineID.


When i applied the timeline following patch alone pg_recvlogical quits in startup phase but when i made the above change pg_recvlogical works although timeline following doesn't work.


Thanks,

Sanyam Jain

From: pgsql-hackers-owner@postgresql.org <pgsql-hackers-owner@postgresql.org> on behalf of Robert Haas <robertmhaas@gmail.com>
Sent: Wednesday, April 5, 2017 3:25:50 PM
To: Andres Freund
Cc: Craig Ringer; Simon Riggs; Thom Brown; Michael Paquier; Petr Jelinek; PostgreSQL Hackers
Subject: Re: [HACKERS] Logical decoding on standby
 
On Wed, Apr 5, 2017 at 10:32 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2017-04-05 17:18:24 +0800, Craig Ringer wrote:
>> On 5 April 2017 at 04:19, Andres Freund <andres@anarazel.de> wrote:
>> > On 2017-04-04 22:32:40 +0800, Craig Ringer wrote:
>> >> I'm much happier with this. I'm still fixing some issues in the tests
>> >> for 03 and tidying them up, but 03 should allow 01 and 02 to be
>> >> reviewed in their proper context now.
>> >
>> > To me this very clearly is too late for v10, and now should be moved to
>> > the next CF.
>>
>> I tend to agree that it's late in the piece. It's still worth cleaning
>> it up into a state ready for early pg11 though.
>
> Totally agreed.

Based on this exchange, marked as "Moved to next CF".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical decoding on standby

From
sanyam jain
Date:
Hi,
After changing 
sendTimeLineIsHistoric = state->currTLI == ThisTimeLineID;
to
sendTimeLineIsHistoric = state->currTLI != ThisTimeLineID;

I was facing another issue.
On promotion of a cascaded server ThisTimeLineID in the standby server having logical slot becomes 0.
Then i added a function call to GetStandbyFlushRecPtr in StartLogicalReplication which updates ThisTimeLineID.

After the above two changes timeline following is working.But i'm not sure whether this is correct or not.In any case please someone clarify.

Thanks,
Sanyam Jain

Re: [HACKERS] Logical decoding on standby

From
sanyam jain
Date:

Hi,
>After changing 
>sendTimeLineIsHistoric = state->currTLI == ThisTimeLineID;
>to
>sendTimeLineIsHistoric = state->currTLI != ThisTimeLineID;
>
>I was facing another issue.
>On promotion of a cascaded server ThisTimeLineID in the standby server having >logical slot becomes 0.
>Then i added a function call to GetStandbyFlushRecPtr in StartLogicalReplication >which updates ThisTimeLineID.
>
>After the above two changes timeline following is working.But i'm not sure whether >this is correct or not.In any case please someone clarify.


Please anyone with experience can explain whether the steps i have done are correct or not.


Thanks,
Sanyam Jain

Re: [HACKERS] Logical decoding on standby

From
Craig Ringer
Date:
On 21 June 2017 at 13:28, sanyam jain <sanyamjain22@live.in> wrote:
> Hi,
>
> In this patch in walsender.c sendTimeLineIsHistoric is set to true when
> current and ThisTimeLineID are equal.
>
> sendTimeLineIsHistoric = state->currTLI == ThisTimeLineID;
>
>
> Shouldn't sendTimeLineIsHistoric is true when state->currTLI is less than
> ThisTimeLineID.

Correct, that was a bug. I thought it got fixed upthread though.


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

Re: [HACKERS] Logical decoding on standby

From
Craig Ringer
Date:
On 21 June 2017 at 17:30, sanyam jain <sanyamjain22@live.in> wrote:
> Hi,
> After changing
> sendTimeLineIsHistoric = state->currTLI == ThisTimeLineID;
> to
> sendTimeLineIsHistoric = state->currTLI != ThisTimeLineID;
>
> I was facing another issue.
> On promotion of a cascaded server ThisTimeLineID in the standby server
> having logical slot becomes 0.
> Then i added a function call to GetStandbyFlushRecPtr in
> StartLogicalReplication which updates ThisTimeLineID.
>
> After the above two changes timeline following is working.But i'm not sure
> whether this is correct or not.In any case please someone clarify.

That's a reasonable thing to do, and again, I thought I did it in a
later revision, but apparently not (?). I've been working on other
things and have lost track of progress here a bit.

I'll check more closely.

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

Re: [HACKERS] Logical decoding on standby

From
Craig Ringer
Date:
On 27 June 2017 at 13:24, Craig Ringer <craig@2ndquadrant.com> wrote:
On 21 June 2017 at 17:30, sanyam jain <sanyamjain22@live.in> wrote:
> Hi,
> After changing
> sendTimeLineIsHistoric = state->currTLI == ThisTimeLineID;
> to
> sendTimeLineIsHistoric = state->currTLI != ThisTimeLineID;
>
> I was facing another issue.
> On promotion of a cascaded server ThisTimeLineID in the standby server
> having logical slot becomes 0.
> Then i added a function call to GetStandbyFlushRecPtr in
> StartLogicalReplication which updates ThisTimeLineID.
>
> After the above two changes timeline following is working.But i'm not sure
> whether this is correct or not.In any case please someone clarify.

That's a reasonable thing to do, and again, I thought I did it in a
later revision, but apparently not (?). I've been working on other
things and have lost track of progress here a bit.

I'll check more closely.


Hi all.

I've had to backburner this due to other work. In the process of looking into an unrelated bug recently though, I noticed that the way we handle snapshots may not be safe for historic snaphots on a standby. Historic snapshots don't ever set takenDuringRecovery, which allows heapgetpage to trust PD_IS_VISIBLE on a page. According to comments on heapgetpage that could be an issue.

Minor compared to some of the other things that'll come up when finishing this off, but worth remembering.


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