Re: Reporting the commit LSN at commit time

On 08/19/2014 01:03 AM, Robert Haas wrote:
> 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.

There's plenty of agreement on "not a GUC" - but what about alternatives?

I mentioned setting an option in the startup packet, to be processed
directly not set as a GUC like some of the other startup packet options
already are, but didn't see any real response there.

I presume the concern there is that, while it's not a GUC as far as the
server is concerned, libpq at least will still send a value for it in
the startup packet if it's defined in

PGOPTIONS='-c protocol_affecting_option_here=on'

so while it isn't a GUC to the server, clients can still twiddle it w/o
making specific new API calls.

I'm not entirely sure why the answer isn't what we excuse other
problematic or potential user-foot-gun behaviour with: "Well, don't do
that".

> 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?

I wouldn't assume anything about how people are using the protocol,
after some of the things I've seen in client code and client drivers
recently. Especially where I've fixed version detection code.

If it can be done badly, it's going to be done badly.

> 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.

I'm not convinced the relnotes get read by a lot of users. They're very
important for professional and/or serious admins an devs, but the number
of questions I see about stuff that's already highlighted in the
relnotes for a version suggests that it's not somewhere Joe Average goes
to find out what's going on.

Unfortunately.

As for whether relnoting it would be enough - that depends a great deal
on how exactly different clients failed. With the number of direct
protocol implementations out there, that's pretty hard to determine.

I'm somewhat confused by why messing with the commit command tag for all
clients is more acceptable than adding a new protocol message, enabled
only by clients that explicitly request it - and no, not by a GUC, I got
that message.

>> 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.

It was just an RFC, and I certainly got the C, which I appreciate.

OTOH, knowing if/how inter-node catchup can be requested by a client is
a pre-req for designing anything else useful in this area IMO.

That part of the discussion has Tom's input to the effect that LSNs
shouldn't be exposed, but I don't think anybody's made any suggestions
about what could be acceptable or could work instead.

Server-reported timestamps would work if commit timestamp tracking is
merged.

As for being 1% of the problem, I disagree. I've already outlined some
simple use cases where having this information reported already provides
the client with all it needs. It'd only be a tiny part of fully
transparent client side failover, sure, but that's not something it's
realistic to aim for right from the start. Reporting of a position
indicator that can be used to see if replicas have replayed up to that
position is useful for simpler things too, and to allow clients
themselves to provide failover as part of application logic.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services