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

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: RFC: Making TRUNCATE more "MVCC-safe"
Дата
Msg-id CA+U5nM+=Wopi9nU=QLcTjEyY4s7qWdJcb+1pZBSOn_amWuOUBQ@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 Mon, Mar 5, 2012 at 4:46 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

>> 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.
>
> err, very good point. Doh.
>
>> 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.
>
> OK, that makes sense and works if we need to rebuild relcache.

Except the reason to do it at the start of the scan is that is the
first time a specific snapshot has been associated with a relation and
also the last point we can apply the check before the errant behaviour
occurs.

If we reject locks against tables that might be used against an
illegal snapshot then we could easily prevent valid snapshot use cases
when a transaction has multiple snapshots, one illegal, one not.

We can certainly have a looser test when we first get the lock and
then another test later, but I don't think we can avoid making all
scans apply this test. And while I'm there, we have to add tests for
things like index build scans.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Our regex vs. POSIX on "longest match"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: RFC: Making TRUNCATE more "MVCC-safe"