Re: CommandCounterIncrement versus plan caching

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

That would eliminate the other big use case where users can run out of command
ids, batch inserts. If you're importing data from a tool which either
generates tons of INSERT statements, uses a plpgsql loop to insert many
records, or uses prepared queries and then executes them a few billion times
you can run into the same limitation.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!