Re: Refactor pg_dump as a library? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactor pg_dump as a library?
Date
Msg-id 24820.1460991850@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactor pg_dump as a library?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Refactor pg_dump as a library?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 15, 2016 at 2:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The problem here is the connection to syscache; changing the behavior
>> of that, in a general context, is very scary.  What we might be able to
>> do that would satisfy pg_dump's needs is to invent a mode in which you
>> can run a read-only transaction that uses the transaction snapshot to
>> populate syscache (and then flushes the syscache at the end).

> I think that we could have an alternate set of functions which have
> the same interface as the syscache functions but using the transaction
> snapshot and don't actually cache anything, and it would be fine for
> what the pg_dump support functions need.

The problem with that approach is that then you are talking about building
duplicate copies of entire layers of the system.  For example, namespace.c
would have to be duplicated into one copy that uses syscache and one that
uses this not-quite-cache.  If it were *only* syscache.c that had to be
duplicated, probably this would work, but ruleutils.c depends on an awful
lot of code above that level.  Indeed, if it did not, the idea of
reimplementing it on the client side wouldn't be so unattractive.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: snapshot too old, configured by time
Next
From: Tom Lane
Date:
Subject: Re: Spinlocks and semaphores in 9.2 and 9.3