Re: Reporting the commit LSN at commit time - Mailing list pgsql-hackers

On Mon, Aug 18, 2014 at 12:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Aug 15, 2014 at 9:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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, I remember debating this with you once before, when we were
>> deciding whether to make SELECT INTO and CREATE TABLE AS return row
>> counts in the command tag.  That change went into 9.0 and, while I
>> think we may have gotten maybe one complaint about it, on the whole I
>> believe it went pretty smoothly.
>
> I think it's a serious, serious mistake to equate the number of clients
> that deal with COMMIT specially with the number that have special logic
> for (or even use at all) SELECT INTO/CREATE TABLE AS.  So I don't find
> that argument to have any merit.
>
> The precedent that seems more relevant to me is our disastrous attempt to
> put in server-side autocommit behavior, back in 7.3.  We thought that that
> wouldn't break too much client code; we were wrong.  And IMO a large part
> of the reason we were wrong was that we exposed the switch as a GUC,
> whereby anybody could twiddle it regardless of whether the relevant
> client-side layer(s) would cope.

1. That seems like a false parallel, because that sounds like it was
an actual behavior change, not just a reporting change.

2. I agree that it's not good to have this get controlled by a GUC.
If the behavior change is big enough that it's going to break clients,
adding a GUC isn't a sufficient remedy.  If it's not, adding a GUC is
unnecessary.

3. I really doubt people are relying on the COMMIT command tag to know
the transaction status.  Surely the right way to get that information
is from the transaction state code in the ReadyForQuery message; isn't
the whole point of having that there that it avoids the need for
fine-grained knowledge of what other protocol messages mean?
Moreover, even if somebody is (rather oddly, IMV) checking for
command_tag == "COMMIT", it's not going to be a difficult change to
check for command_tag == "COMMIT" or substr(command_tag,0,7) ==
"COMMIT ".  That's a level of incompatibility that would certainly
deserve mention in the release notes, but it doesn't seem worth
worrying more about than that.

>> All that having been said, I'm not convinced that we should do this at
>> all unless we've got a libpq implementation of client-side failover so
>> that people can actually use this without having to put all of the
>> logic in their application.
>
> There's that, too.  The whole proposal is a solution in search of a
> problem at the moment, or maybe better to say that it's 1% of a solution
> with no clear path to getting the other 99% done.

Yeah, and I think that's the much more worrying problem.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company