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

2012-09-14 Thread Robert Haas
On Thu, Sep 13, 2012 at 1:45 PM, Jeff Davis pg...@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 pg...@j-davis.com wrote: This bug seems particularly troublesome because the right fix would be to include the relpersistence

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

2012-09-13 Thread Robert Haas
On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis pg...@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

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

2012-09-13 Thread Jeff Davis
On Thu, 2012-09-13 at 12:39 -0400, Robert Haas wrote: On Wed, Sep 12, 2012 at 7:19 PM, Jeff Davis pg...@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

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

2012-09-12 Thread Jeff Davis
Indeed, this is a nasty bug that leads to data corruption. The following sequence results in corruption of the visibility map, but I believe it can be shown to cause problems for a btree or GIN index as well. So it's recoverable if you do a VACUUM or a reindex. drop table foo; create table foo(i