Re: pg_dump --snapshot - Mailing list pgsql-hackers

* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2013-05-06 20:18:26 -0400, Stephen Frost wrote:
> > Because parallel pg_dump didn't make the problem any *worse*..?  This
> > does.  The problem existed before parallel pg_dump.
>
> Yes, it did.

That's not entirely clear- are you agreeing with my statements, or not?

> > The API exposes it, yes, but *pg_dump* isn't any worse than it was
> > before.
>
> No, but its still broken. pg_dump without the parameter being passed
> isn't any worse off after the patch has been applied. With the parameter
> the window gets a bit bigger sure...

I'm not entirely following the distinction you're making here.  What I
think you're saying is that "pg_dump is still busted" and "pg_dump when
the parameter isn't passed is busted" and "pg_dump creates a bigger
window where it can break if the parameter is passed".  All of which I
think I agree with, but I don't agree with the conclusion that this
larger window is somehow acceptable because there's a very small window
(one which can't be made any smaller, today..) which exists today.

> Given that we don't have all that many types of objects we can lock,
> that task isn't all that complicated.

Alright, then let's provide a function which will do that and tell
people to use it instead of just using pg_export_snapshot(), which
clearly doesn't do that.

> But I'd guess a very common usage
> is to start the snapshot and immediately fork pg_dump. In that case the
> window between snapshot acquiration and reading the object list is
> probably smaller than the one between reading the object list and
> locking.

How would it be smaller..?  I agree that it may only be a few seconds
larger, but you're adding things to the front which the current code
doesn't run, yet running everything the current code runs, so it'd have
to be larger..

> This all reads like a textbook case of "perfect is the enemy of good" to
> me.

I believe the main argument here is really around "you should think
about these issues before just throwing this in" and not "it must be
perfect before it goes in".  Perhaps "it shouldn't make things *worse*
than they are now" would also be apt..

> A rather useful feature has to fix a bug in pg_dump which a) exists for
> ages b) has yet to be reported to the lists c) is rather complicated to
> fix and quite possibly requires proper snapshots for internals?

I've not seen anyone calling for this to be fixed in pg_dump first,
though I did suggest how that might be done.  Rather, it shouldn't make
things *worse* than they are now, which apparently isn't difficult, per
your comments above...  so why not fix this to at least not make things
worse?
Thanks,
    Stephen