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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: SET WITHOUT OIDS and VACUUM badness?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: Re: SET WITHOUT OIDS and VACUUM badness?
Следующее
От: Michael Brusser
Дата:
Сообщение: Re: Slow query - index not used