Re: SET WITHOUT OIDS and VACUUM badness?

On Wed, 11 Feb 2004, Bruce Momjian wrote:

> Gavin Sherry wrote:
> > On Wed, 21 Jan 2004, Gavin Sherry wrote:
> >
> > > On Wed, 21 Jan 2004, Christopher Kings-Lynne wrote:
> > >
> > > > This is what we did:
> > > >
> > > > 0. BEGIN;
> > > >
> > > > 1. ALTER TABLE ... SET WITHOUT OIDS
> > >
> > > > 12. ROLLBACK;
> > > >
> > > > 13. VACUUM FULL forums_posts;
> > >
> > > The problem here is that this conditional doesn't take into account the
> > > change in state which the above transaction causes:
> > >
> > > if (onerel->rd_rel->relhasoids &&
> > > !OidIsValid(HeapTupleGetOid(&tuple)))
> > >
> > > Tuples inserted after step one have no (valid) OID. However, since we
> > > rollback, the change to pg_class.relhasoids => 'f' is rolled back. The
> > > only solution I can think of is removing the test or storing relhasoids as
> > > a per tuple flag (argh).
> >
> > What am I talking about. Can't we test for:
> >
> > (&tuple)->t_infomask & HEAP_HASOID
> >
> > Instead of:
> >
> > onerel->rd_rel->relhasoids
>
> I can confirm we still have this bug:
>

[sample]

Tom had two suggestions later in the thread:

http://archives.postgresql.org/pgsql-hackers/2004-01/msg00467.php

Gavin