Re: pg_get_domaindef

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_get_domaindef
Дата
Msg-id 15495.1169708786@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_get_domaindef  (Gavin Sherry <swm@alcove.com.au>)
Ответы Re: pg_get_domaindef  (Gavin Sherry <swm@alcove.com.au>)
Список pgsql-patches
Gavin Sherry <swm@alcove.com.au> writes:
> I was talking to AndrewSN on irc about this. He proposed that we supply
> two versions (yes I hear the collective groan) of the SQL functions: a
> fast one (SnapshotNow) and an accurate one (which doesn't use
> SnapshotNow).

Um, that's such a fundamental misconception that it's got to be nipped
in the bud.  The reason the backend tends to operate on SnapshotNow is
that it can't afford to be working with obsolete schema data.  As an
example, you'd certainly not be happy if your updates to a table
disappeared into nowhere because your backend was working against a
snapshot that said table X was in tablespace Y, when meanwhile someone
had committed a transaction that moved it to tablespace Z.  On the other
hand, pg_dump is entirely not about applying updates; it would like to
have a consistent read-only snapshot as of a time that might be many
hours ago by the time it's done.  Both viewpoints are "accurate" for
their respective purposes; neither is chosen because it is "fast".

We might indeed need two sets of functions, but if you categorize them
like that you'll never get it right.

            regards, tom lane

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

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: Re: pg_get_domaindef
Следующее
От: Jeremy Drake
Дата:
Сообщение: Re: [HACKERS] unprivileged contrib and pl install