From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CommandCounterIncrement versus plan caching |
Date: | 2007-12-01 23:16:43 |
Message-ID: | 8763zixaxw.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Gregory Stark" <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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's PostgreSQL training!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-12-01 23:46:52 | Re: [HACKERS] BUG #3774: create table like including index doesn't update pg_constraints with primary key |
Previous Message | Gregory Stark | 2007-12-01 21:59:23 | Re: CommandCounterIncrement versus plan caching |