Re: RFC: Making TRUNCATE more "MVCC-safe"

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: RFC: Making TRUNCATE more "MVCC-safe"
Дата
Msg-id CA+TgmoY1V-NPiMiwK08ZqPjJnzeQ1uVRLnoFoFSPUsc0_sE-Kg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: Making TRUNCATE more "MVCC-safe"  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: RFC: Making TRUNCATE more "MVCC-safe"
Список pgsql-hackers
On Sun, Mar 4, 2012 at 11:39 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Marti, please review this latest version which has new isolation tests added.
>
> This does both TRUNCATE and CREATE TABLE.

I don't see any need for a GUC to control this behavior.  The current
behavior is wrong, so if we're going to choose this path to fix it,
then we should just fix it, period.  The narrow set of circumstances
in which it might be beneficial to disable this behavior doesn't seem
to me to be sufficient to justify a behavior-changing GUC.

It does not seem right that the logic for detecting the serialization
error is in heap_beginscan_internal().  Surely this is just as much of
a problem for an index-scan or index-only-scan.  We don't want to
patch all those places individually, either: I think the check should
happen right around the time we initially lock the relation and build
its relcache entry.

The actual text of the error message could use some work.  Maybe
something like "could not serialize access due to concurrent DDL",
although I think we try to avoid using acronyms like DDL in
translatable strings.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Our regex vs. POSIX on "longest match"
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)