Re: Instability in TRUNCATE regression test

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Instability in TRUNCATE regression test
Дата
Msg-id 27983.1151514822@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Instability in TRUNCATE regression test  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Instability in TRUNCATE regression test  ("Jim C. Nasby" <jnasby@pervasive.com>)
Re: Instability in TRUNCATE regression test  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> 1. Find a way to make the processing order consistent (eg by driving it
>> off OID ordering).  Doesn't seem easy, but maybe I'm missing an idea.

> Hmm, what about

> 1. get the complete list of tables to truncate, AccessShareLock'ed, get
> their names
> 2. release locks
> 3. sort the list lexicographically (or by Oid, whatever)
> 4. acquire the stronger locks, in list order, taking care of not
> aborting if a table is no longer there
> 5. truncate

Releasing locks is no good ... what if someone adds/drops FK constraints
while you've not got any lock?

One thing I was toying with was to add an index to pg_constraint on,
say, (confrelid, conrelid), and to replace the existing seqscans for FK
constraints with scans using this index.  The second-column ordering
would guarantee everybody visits the entries in the same order.  Not
sure about overall performance implications ... in a small database,
several indexscans might take more time than one seqscan.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Fixed length datatypes. WAS [GENERAL] UUID's as primary keys
Следующее
От: mark@mark.mielke.cc
Дата:
Сообщение: Re: Fixed length datatypes. WAS [GENERAL] UUID's as primary keys