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