Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-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;
> regression=# end;
> regression=# begin;
> regression=# abort;
> 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 :-)


In response to


pgsql-hackers by date

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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group