On 2014-08-15 09:54:01 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-08-14 12:21:38 -0400, Robert Haas wrote:
> >> And what does that actually do? Send back a result-set, or a new
> >> protocol message?
>
> > What I was thinking of was to return "COMMIT X/X" instead of
> > "COMMIT". Since that's only sent when COMMIT WITH (report_commit_lsn ON)
> > was set it won't break clients/libraries that don't need it.
>
> Au contraire: it will break any piece of code that is expecting a COMMIT
> command tag to look like exactly "COMMIT" and not "COMMIT something".
Well, if your code doesn't support it. Don't use it.
> The risk still remains, therefore, that one layer of the client-side
> software stack might try to enable this feature even though another
> layer is not prepared for it.
Well, then the user will have to fix that. It's not like the feature
will magically start to be used by itself.
One alternative would be to expose a pg_get_last_commit_lsn(); function
that'd return the the last commit's lsn stored in a static variable if
set. That'll increase the window in which the connection can break, but
that window already exists.
> And, again, I think that controlling this via something as widely
> changeable as a GUC is sheer folly, potentially even reaching the point
> of being a security bug. (Applications that fail to recognize when
> their transactions have committed would be broken in very nasty ways.)
*I*'ve never suggested making this depend on a guc. I think that'd a
major PITA.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
