Re: CommandCounterIncrement
От | Denis Perchine |
---|---|
Тема | Re: CommandCounterIncrement |
Дата | |
Msg-id | 0011022248410E.31936@dyp.perchine.com обсуждение исходный текст |
Ответ на | Re: CommandCounterIncrement (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: