Re: BUG #1118: Misleading Commit message

From: elein <elein(at)varlena(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, elein <elein(at)norcov(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1118: Misleading Commit message
Date: 2004-03-28 17:37:13
Message-ID: 20040328093713.V28300@cookie.varlena.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Sun, Mar 28, 2004 at 10:23:26AM -0500, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > PostgreSQL Bugs List wrote:
> >> In a block transaction, whether or not there were errors in the transaction
> >> issuing a commit; returns a COMMIT confirmation.
>
> > Uh, the tag indicates the COMMIT completed, not that it was a success.
>
> The current philosophy on command tags is "the tag is the same as the
> command actually issued". However we are talking about breaking that
> rule for EXECUTE, and if we do that, it's hard to say that we should
> continue to enforce the rule for COMMIT. It would clearly be useful
> for a COMMIT that ends a failed transaction to report ROLLBACK instead.
>
> > If we throw an error on a COMMIT, people willl think we did not close
> > the transacction,
>
> ... which we wouldn't have. That won't work.
>
> > and if we return a ROLLBACK, they will think they issued a rollback.
>
> Which, in effect, is what they did. Is it likely that this would break
> any clients? The intention of the current design rule is that clients
> can match the tag against the command they issued, but I don't know of
> any client code that actually does that.
>
> In any case, we already have some inconsistencies:
>
> regression=# begin;
> BEGIN
> regression=# end;
> COMMIT
> regression=# begin;
> BEGIN
> regression=# abort;
> ROLLBACK
> regression=#
>
> so it seems that in some cases we're already following a rule more like
> "the tag is the same as the command actually *executed*".
>
> I started out not wanting to make this change either, but the more
> I think about it the harder it is to hold that position.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

The message could be something like:
COMMIT: Transaction rolled back due to errors

That way, it would reflect both the command and the action.
But I am concerned about the information rather than
the exact message if someone has better ideas.

My reason for submitting the bug was as Tom stated:
> It would clearly be useful
> for a COMMIT that ends a failed transaction to report ROLLBACK instead.

A commit that fails does not commit. It rolls back.

In general, this would make it friendlier for new people and
space cadets that don't notice the last statement failed :-)

Elein
elein(at)varlena(dot)com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PostgreSQL Bugs List 2004-03-28 18:44:17 BUG #1119: DatabaseMetaData.getTables() returns not a lot
Previous Message Tom Lane 2004-03-28 15:23:26 Re: BUG #1118: Misleading Commit message

Browse pgsql-hackers by date

  From Date Subject
Next Message Manfred Spraul 2004-03-28 18:21:11 Re: Flush to Disk
Previous Message Tom Lane 2004-03-28 17:33:59 Fuzzy cost comparison to eliminate redundant planning work