Re: SET WITHOUT OIDS and VACUUM badness?

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SET WITHOUT OIDS and VACUUM badness?
Date: 2004-01-21 11:20:47
Message-ID: Pine.LNX.4.58.0401212218570.17265@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kris Jurka 2004-01-21 11:33:32 Re: SQL Exception Relation xxx does not exist
Previous Message Gavin Sherry 2004-01-21 10:54:13 Re: SET WITHOUT OIDS and VACUUM badness?