Re: Changeset Extraction v7.6.1 - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> Having now had a little bit of opportunity to reflect on the State Of
> This Patch, I'd like to step back from the minutia upon which I've
> been commenting in my previous emails and articulate three high-level
> concerns about this patch.  In so doing, I would like to specifically
> request that other folks on this mailing list comment on the extent to
> which they do or do not believe these concerns to be valid.
> ...

> 1. How safe is it to try to do decoding inside of a regular backend?
> What we're doing here is entering a special mode where we forbid the
> use of regular snapshots in favor of requiring the use of "decoding
> snapshots", and forbid access to non-catalog relations.  We then run
> through the decoding process; and then exit back into regular mode.
> On entering and on exiting this special mode, we
> InvalidateSystemCaches().

How often is such a mode switch expected to happen?  I would expect
frequent use of InvalidateSystemCaches() to be pretty much disastrous
for performance, even absent any of the possible bugs you're worried
about.  It would likely be better to design things so that a decoder
backend does only that.

> 2. I think the snapshot-export code is fundamentally misdesigned.

Your concerns here sound reasonable, but I can't say I've got any
special insight into it.

> 3. As this feature is proposed, the only plugin we'll ship with 9.4 is
> a test_decoding plugin which, as its own documentation says, "doesn't
> do anything especially useful."  What exactly do we gain by forcing
> users who want to make use of these new capabilities to write C code?

TBH, if that's all we're going to ship, I'm going to vote against
committing this patch to 9.4 at all.  Let it wait till 9.5 when we
might be able to build something useful on it.  To point out just
one obvious problem, how much confidence can we have in the APIs
being right if there are no usable clients?  Even if they're right,
what benefit do we get from freezing them one release before anything
useful is going to happen?

The most recent precedent I can think of is the FDW APIs, which I'd
be the first to admit are still in flux.  But we didn't ship anything
there without non-toy contrib modules to exercise it.  If we had,
we'd certainly have regretted it, because in the creation of those
contrib modules we found flaws in the initial design.
        regards, tom lane