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

Re: CommandCounterIncrement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Denis Perchine <dyp(at)perchine(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: CommandCounterIncrement
Date: 2000-11-02 16:43:56
Message-ID: 25579.973183436@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Denis Perchine <dyp(at)perchine(dot)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.

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

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Denis PerchineDate: 2000-11-02 16:48:41
Subject: Re: CommandCounterIncrement
Previous:From: Tom LaneDate: 2000-11-02 16:33:49
Subject: Re: Transaction costs?

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