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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html