Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case)
От | Robert Haas |
---|---|
Тема | Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case) |
Дата | |
Msg-id | CA+TgmobxoDMCg7jTJQE8GVkd7bJvbN2B=YssTww3v+ukXbPnAw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: Probable bug with CreateFakeRelcacheEntry (now with reproducible test case) (Jeff Davis <pgsql@j-davis.com>) |
Список | 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 по дате отправления: