Re: CommandCounterIncrement versus plan caching - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: CommandCounterIncrement versus plan caching
Date
Msg-id 8763zixaxw.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: CommandCounterIncrement versus plan caching  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
"Gregory Stark" <stark@enterprisedb.com> writes:

> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> I think this can be fixed by changing the Executor so that it doesn't
>> use snapshot->curcid for this purpose.  Instead, add a field to EState
>> showing the CommandID to mark tuples with.  ExecutorStart, which has
>> enough information to know whether the query is read-only or not,
>> can set this field, or not, and tell GetCurrentCommandId to mark the
>> command ID "dirty" (or not).  
>
> ExecutorStart could also determine when the query is a "write-only" query for
> which the provided command id won't be used for any snapshot checks (ie, a
> simple INSERT) and tell CCI not to bump the CCI if the previous CC even if
> it's dirty.

oops, garbled that. "tell CCI not to bump the counter even if it's dirty"q


--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: CommandCounterIncrement versus plan caching
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #3774: create table like including index doesn't update pg_constraints with primary key