Re: pg_get_domaindef - Mailing list pgsql-patches

From Tom Lane
Subject Re: pg_get_domaindef
Date
Msg-id 15495.1169708786@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_get_domaindef  (Gavin Sherry <swm@alcove.com.au>)
Responses Re: pg_get_domaindef
List 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 by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: pg_get_domaindef
Next
From: Jeremy Drake
Date:
Subject: Re: [HACKERS] unprivileged contrib and pl install