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 |
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 |