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

From Robert Haas
Subject Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)
Date
Msg-id CA+TgmobxoDMCg7jTJQE8GVkd7bJvbN2B=YssTww3v+ukXbPnAw@mail.gmail.com
Whole thread Raw
In response to Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-bugs
On Thu, Sep 13, 2012 at 1:45 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> 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.

Committed and back-patched to 9.1.  Thanks for the report, diagnosis, and fix.

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

pgsql-bugs by date:

Previous
From: Amit kapila
Date:
Subject: Re: BUG #7534: walreceiver takes long time to detect n/w breakdown
Next
From: Tom Lane
Date:
Subject: Re: initdb.exe changes --locale option