Re: Phantom segment upon promotion causing troubles.

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, gregburek(at)heroku(dot)com
Subject: Re: Phantom segment upon promotion causing troubles.
Date: 2017-06-20 13:11:32
Message-ID: 0fd2a6ea-7249-a718-9534-fbc1d4b1424e@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/19/2017 10:30 AM, Andres Freund wrote:
> Greg Burek from Heroku (CCed) reported a weird issue on IM, that was
> weird enough to be interesting. What he'd observed was that he promoted
> some PITR standby, and early clones of that node work, but later clones
> did not, failing to read some segment.
>
> The problems turns out to be the following: [explanation]

Good detective work!

> The minimal fix here is presumably not to use XLByteToPrevSeg() in
> RemoveXlogFile(), but XLByteToSeg(). I don't quite see what purpose it
> serves here - I don't think it's ever needed.

Agreed, I don't see a reason for it either.

> There seems to be a larger question ehre though: Why does
> XLogFileReadAnyTLI() probe all timelines even if they weren't a parent
> at that period? That seems like a bad idea, especially in more
> complicated scenarios where some precursor timeline might live for
> longer than it was a parent? ISTM XLogFileReadAnyTLI() should check
> which timeline a segment ought to come from, based on the historY?

Yeah. I've had that thought for years as well, but there has never been
any pressing reason to bite the bullet and rewrite it, so I haven't
gotten around to it.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendranath Gurram 2017-06-20 13:18:50 Re: Regarding Postgres Dynamic Shared Memory (DSA)
Previous Message Amit Kapila 2017-06-20 11:37:37 Re: Setting pd_lower in GIN metapage