Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)
Date: 2012-09-13 17:45:34
Message-ID: 1347558334.24686.27.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)j-davis(dot)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 Content-Type Size
fakerelcache.patch.gz application/x-gzip 626 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-09-13 17:48:04 Re: BUG #7516: PL/Perl crash
Previous Message Fujii Masao 2012-09-13 17:27:52 Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown