Re: Committed updates don't seem to be committed.

I just wanted to thank everyone for their help.
I believe that I've tracked down the problem and it basically boils down
to the fact that I was inadvertently engaging in Hibernate abuse. Since
this is a postgres forum, not a hibernate forum, I'll spare you the
details.

I do have one remaining comment/question. In the postgres logs, every
query is followed by a "CommitTransactionCommand", but this is not
really a commit. The only time a commit really takes place is when the
debug log includes something like "query: commit;". What exactly is the
meaning of "CommitTransactionCommand" if it doesn't represent a commit?

Thanks again,

Frank


On Wed, 2004-06-23 at 10:26, Tom Lane wrote:
> Frank Kurzawa <fkurzawa@topazsoftware.com> writes:
> > Let's assume that there is a bug in hibernate that is causing it to
> > start a transaction behind my back. I'm trying to understand what
> > footprints it would leave and I see three possibilities:
> > a) It later commits the transaction behind my back
> > b) It later rolls back the transaction behind my back
> > c) It just leaves the transaction uncommitted/unrolledback/just
> > dangling out there.
> > ...
> > That leaves (c): What would this look like?
> > If I do a 'ps -efl' should I find a postgres process in a particular
> > state? ('idle waiting on transaction', 'idle in transaction', or
> > something else)?
>
> "idle in transaction" would be the usual state in such a case.
>
> > Should there be some other footprints lying around that I can look at?
> > Some record of the pending transaction in some postgres system tables?
>
> pg_locks will show an entry with (IIRC) an ExclusiveLock on a
> transaction number for each open transaction.
>
> You could also enable query logging and just look for begin/commit commands.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
--
Frank Kurzawa