Re: Multixid hindsight design

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Multixid hindsight design
Дата
Msg-id CANP8+jLo_q_m5Svt2P5L2LVTuGQ2zvQPZBTLAG7UBi8LNCkHcw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Multixid hindsight design  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 5 June 2015 at 11:02, Andres Freund <andres@anarazel.de> wrote:
On 2015-06-05 10:45:09 +0100, Simon Riggs wrote:
> On 1 June 2015 at 20:53, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
>
> > On Tue, May 12, 2015 at 9:20 AM, Heikki Linnakangas <hlinnaka@iki.fi>
> > wrote:
> > > The beauty of this would be that the TED entries can be zapped at
> > restart,
> > > just like pg_subtrans, and pg_multixact before 9.3. It doesn't need to be
> > > WAL-logged, and we are free to change its on-disk layout even in a minor
> > > release.
> >
> > What about prepared transactions?  They can lock rows FOR SHARE that
> > survive server restarts.
> >
>
> Interesting comment. I'm not aware that we do.
>
> If we do support row locking that survives server restart, how did it work
> before 9.3?

Multixacts were persistent before 9.3 as well. A good number of the bugs
existed then as well, but their effect was much more limited. The
difference is that now multixacts don't just have to survive till the
last locker isn't running anymore (which was determined by a horizon),
but that they have to live till they're vacuumed away, since xmax might
be stored in the multixact.

Phew! Had me worried for a minute.

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

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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Multixid hindsight design
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1