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

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: RFC: Making TRUNCATE more "MVCC-safe"
Дата
Msg-id CA+U5nM+ypvDX7-RbGLmDkGXhkAg9AFGPjg_6jgYSnRX+Ukd7DQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: Making TRUNCATE more "MVCC-safe"  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Mar 5, 2012 at 5:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> Well, there's no point that I can see in having two checks.  I just
> dislike the idea that we have to remember to add this check for every
> method of accessing the relation - doesn't seem terribly future-proof.
>  It gets even worse if you start adding checks to DDL code paths - if
> we're going to do that, we really need to cover them all, and that
> doesn't seem very practical if they're going to spread out all over
> the place.

Understood. Will look.

> I don't understand your comment that a snapshot doesn't get associated
> with a relation until scan time.  I believe we associated a snapshot
> with each query before we even know what relations are involved; that
> query then gets passed down to all the individual scans.  The query
> also opens and locks those relations.  We ought to be able to arrange
> for the query snapshot to be cross-checked at that point, rather than
> waiting until scan-start time.

What's to stop other code using an older snapshot explicitly? That
fear may be bogus.

Any suggestions? ISTM we don't know whether we're already locked until
we get to LockAcquire() and there's no easy way to pass down snapshot
information through that, let alone handle RI snapshots. Ideas please.

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


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

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Our regex vs. POSIX on "longest match"
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: elegant and effective way for running jobs inside a database