Simon Riggs <simon@2ndQuadrant.com> writes:
> It does *not* pass in a raw snapshot. All it does is to allow pg_dump
> to use an API that is already exposed by the backend for this very
> purpose, one that has been in Postgres since 9.2.
> http://www.postgresql.org/docs/devel/static/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION
> Minor patch, no amazing new functionality, no drama.
You're ignoring the objection ...
The snapshot-transfer facility is intended for supporting, in essence,
multi-threaded closed applications. In such a context we can expect
that the leader knows enough about the followers to predict which locks
need to be acquired before the to-be-shared snapshot is acquired.
Exposing that in pg_dump, without doing a lick of other work (which is
what I take to be your proposal), would leave us with a situation
wherein an application wishing to invoke pg_dump safely would need to
know what locks pg_dump will take --- something that's rather a moving
target. If it gets that wrong, it will be at risk of obtaining
inconsistent dumps without any warning.
I think a minimum requirement before we can accept this feature is that
there be a way to obtain all the same locks that pg_dump would get when
given the same command-line arguments. This would, perhaps, be a good
test criterion for the fabled library-ization of pg_dump.
regards, tom lane
