Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers