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 ...
"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, wh
"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 q
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
>>
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 notifica
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
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 pla
"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
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 * from
I have added this to the developers FAQ. However, the developers FAQ
isn't accessible from the web site, and I have contacted Vince on this.
---
13) What is CommandCounterIncrement()?
Normally, transactions can not see the
> 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 r
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 earli
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.
13 matches
Mail list logo
