Re: SET WITHOUT OIDS and VACUUM badness?
От | Gavin Sherry |
---|---|
Тема | Re: SET WITHOUT OIDS and VACUUM badness? |
Дата | |
Msg-id | Pine.LNX.4.58.0401212218570.17265@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: SET WITHOUT OIDS and VACUUM badness? (Gavin Sherry <swm@linuxworld.com.au>) |
Ответы |
Re: SET WITHOUT OIDS and VACUUM badness?
Re: SET WITHOUT OIDS and VACUUM badness? |
Список | 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 по дате отправления: