Re: SET WITHOUT OIDS and VACUUM badness? - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: SET WITHOUT OIDS and VACUUM badness?
Date
Msg-id Pine.LNX.4.58.0401212218570.17265@linuxworld.com.au
Whole thread Raw
In response to Re: SET WITHOUT OIDS and VACUUM badness?  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: SET WITHOUT OIDS and VACUUM badness?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: SET WITHOUT OIDS and VACUUM badness?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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

Gavin


pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: SET WITHOUT OIDS and VACUUM badness?
Next
From: Michael Brusser
Date:
Subject: Re: Slow query - index not used