Re: synchronized snapshots

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: synchronized snapshots
Дата
Msg-id 5CE1DA2E-B989-4BD8-B042-EB3C2CC6F39F@phlo.org
обсуждение исходный текст
Ответ на Re: synchronized snapshots  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: synchronized snapshots
Список pgsql-hackers
On Oct19, 2011, at 18:17 , Tom Lane wrote:
> Joachim Wieland <joe@mcknight.de> writes:
>> [ synchronized-snapshots patch ]
> 
> Looking through this code, it strikes me that SET TRANSACTION SNAPSHOT
> is fundamentally incompatible with SERIALIZABLE READ ONLY DEFERRABLE
> mode.  That mode assumes that you should be able to just take a new
> snapshot, repeatedly, until you get one that's "safe".  With the patch
> as written, if the supplied snapshot is "unsafe", GetSafeSnapshot()
> will just go into an infinite loop.
> 
> AFAICS we should just throw an error if SET TRANSACTION SNAPSHOT is done
> in a transaction with those properties.  Has anyone got another
> interpretation?  Would it be better to silently ignore the DEFERRABLE
> property?

Hm, both features are meant to be used by pg_dump, so think we should
make the combination work. It'd say SET TRANSACTION SNAPSHOT should throw
an error only if the transaction is marked READ ONLY DEFERRABLE *and*
the provided snapshot isn't "safe".

This allows a deferrable snapshot to be used on a second connection (
by e.g. pg_dump), and still be marked as DEFERRABLE. If we throw an
error unconditionally, the second connection has to import the snapshot
without marking it DEFERRABLE, which I think has consequences for
performance. AFAIR, the SERIALIZABLE implementation is able to skip
almost all (or all? Kevin?) SIREAD lock acquisitions in DEFERRABLE READ
ONLY transaction, because those cannot participate in dangerous (i.e.
non-serializable) dependency structures.

best regards,
Florian Pflug




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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Log crashed backend's query v3
Следующее
От: Greg Jaskiewicz
Дата:
Сообщение: Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)