Tom Lane [EMAIL PROTECTED] 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
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] 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
Gregory Stark [EMAIL PROTECTED] writes:
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.
Ummm ... I'm
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
... I am
tempted to remove that from CCI and call it from just a selected few CCI
call sites, instead --- maybe only CommitTransactionCommand. OTOH this
step might reasonably be considered too risky for late beta, since it
would
I wrote:
One fairly simple answer is to insert a CCI call at the start of
RevalidateCachedPlan. I dislike that solution, at least by itself,
on two grounds:
...
I've also thought about rearranging the current conventions for where to
call CCI. This particular form of the problem would go
Tom Lane wrote:
Once we have the knowledge of whether the current command ID is dirty,
we can skip everything inside CommandCounterIncrement when it is not;
except for the AtStart_Cache() call, ie, AcceptInvalidationMessages().
What that is looking for is asynchronous DDL-change notifications
I was able to reproduce the problem complained of here
http://archives.postgresql.org/pgsql-bugs/2007-11/msg00322.php
with this function:
create or replace function foo() returns int as $$
declare r int;
begin
drop table if exists temptable cascade;
create temp table temptable as select *
Tom Lane [EMAIL PROTECTED] writes:
One fairly simple answer is to insert a CCI call at the start of
RevalidateCachedPlan. I dislike that solution, at least by itself,
on two grounds:
* A patch of that form would approximately double the number of CCI
calls involved in executing a plpgsql
Gregory Stark [EMAIL PROTECTED] writes:
Wait, shouldn't it be sufficient to do a CCI only in the if (!plan) case?
No. The problem is that if you don't do the CCI then you don't get the
invalidation events that might-or-might-not be pending in the inval
queue. So testing for whether the plan is
Denis Perchine [EMAIL PROTECTED] 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
Hello,
Small technical question: what exactly CommandCounterIncrement do?
And what exactly it should be used for?
I use it to see data which is changed in current transaction.
If to be more
exact when I write BLOB in transaction each time I write additional piece I
do CommandCounterIncrement.
11 matches
Mail list logo
