Re: Small TRUNCATE glitch

Поиск
Список
Период
Сортировка
От Alex Shulgin
Тема Re: Small TRUNCATE glitch
Дата
Msg-id 87iohk1pd1.fsf@commandprompt.com
обсуждение исходный текст
Ответ на Re: Small TRUNCATE glitch  (Alex Shulgin <ash@commandprompt.com>)
Ответы Re: Small TRUNCATE glitch  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Alex Shulgin <ash@commandprompt.com> writes:
>
> Bruce Momjian <bruce@momjian.us> writes:
>>
>> Added to TODO:
>>
>>         o Clear table counters on TRUNCATE
>>
>>           http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
>
> Hello,
>
> Attached is a WIP patch for this TODO.

This part went as an attachment, which wasn't my intent:
========================================================

It does the trick by tracking if a TRUNCATE command was issued under a
(sub)transaction and uses this knowledge to reset the live/dead tuple
counters later if the transaction was committed.  Testing in simple
cases shows that this clears the counters correctly, including use of
savepoints.

The 2PC part requires extending bool flag to fit the trunc flag, is this
approach sane?  Given that 2PC transaction should survive server
restart, it's reasonable to expect it to also survive the upgrade, so I
see no clean way of adding another bool field to the
TwoPhasePgStatRecord struct (unless some would like to add checks on
record length, etc.).

I'm going to add some regression tests, but not sure what would be the
best location for this.  The truncate.sql seems like natural choice, but
stats are not updating realtime, so I'd need to borrow some tricks from
stats.sql or better put the new tests in the stats.sql itself?

--
Alex



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: moving from contrib to bin
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: moving from contrib to bin