Re: CommandCounterIncrement - Mailing list pgsql-hackers

From Denis Perchine
Subject Re: CommandCounterIncrement
Date
Msg-id 0011022248410E.31936@dyp.perchine.com
Whole thread Raw
In response to Re: CommandCounterIncrement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Denis Perchine <dyp@perchine.com> writes:
> > Small technical question: what exactly CommandCounterIncrement do?
>
> It increments the command counter ;-)
>
> > And what exactly it should be used for?
>
> You need it if, within a chunk of backend code, you want subsequent
> queries to see the results of earlier queries.  Ordinarily a query
> cannot see its own output --- else a command like
>     UPDATE foo SET x = x + 1
> for example, would be an infinite loop, since as it scans the table
> it would find the tuples it inserted, update them, insert the updated
> copies, ...
>
> Postgres' solution is that tuples inserted by the current transaction
> AND current command ID are not visible.  So, to make them visible
> without starting a new transaction, increment the command counter.

Perfect. That what I thought it is.

> > I ask this question because I found out that when I run postgres with
> > verbose=4 I see lot's of StartTransactionCommand &
> > CommitTransactionCommand pair in the place where BLOB is written. And I
> > have a feeling that something is wrong. Looks like explicitly commit all
> > changes. That's really bad...
>
> These do not commit anything, assuming you are inside a transaction
> block.  Offhand I don't think they will amount to much more than a
> CommandCounterIncrement() call in that case, but read xact.c if you want
> to learn more.

Yeps. I get this... But there's still a problem when people try to use BLOBs 
outside of TX. I like to detect it...

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CommandCounterIncrement
Next
From: Jade Rubick
Date:
Subject: Another remove request