Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case) - Mailing list pgsql-bugs

From Jeff Davis
Subject Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)
Date
Msg-id 1347558334.24686.27.camel@jdavis
Whole thread Raw
In response to Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote:
> On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> > This bug seems particularly troublesome because the right fix would be
> > to include the relpersistence in the WAL records that need it. But that
> > can't be backported (right?).
>
> No, because if a WAL record was written at all, then by definition the
> table is RELPERSISTENCE_PERMANENT.  So there's probably a localized
> fix.

Oh, of course (I was worried there for some reason). I suppose we just
need to set the relpersistence to permanent in CreateFakeRelcacheEntry,
kind of like ReadBufferWithoutRelcache.

And we should probably assert that both functions are only called during
recovery (though perhaps redundant for CreateFakeRelcacheEntry, which is
in xlogutils.c).

Trivial patch attached.

Regards,
    Jeff Davis

Attachment

pgsql-bugs by date:

Previous
From: Fujii Masao
Date:
Subject: Re: BUG #7534: walreceiver takes long time to detect n/w breakdown
Next
From: Tom Lane
Date:
Subject: Re: BUG #7516: PL/Perl crash