Re: [BUGS] BUG #1118: Misleading Commit message - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [BUGS] BUG #1118: Misleading Commit message
Date
Msg-id 200407091416.i69EGUX02335@candle.pha.pa.us
Whole thread Raw
Responses Re: [BUGS] BUG #1118: Misleading Commit message  (elein <elein@varlena.com>)
Re: [BUGS] BUG #1118: Misleading Commit message  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Do we want to add this to TODO:
*  Issue an extra message when COMMIT completes a failed transaction

---------------------------------------------------------------------------

elein wrote:
> 
> 
> 
> On Sun, Mar 28, 2004 at 10:23:26AM -0500, Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.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@postgresql.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@varlena.com
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Klaus Naumann
Date:
Subject: Re: User Quota Implementation
Next
From: Rod Taylor
Date:
Subject: Re: User Quota Implementation