Re: [HACKERS] TIME QUALIFICATION - Mailing list pgsql-hackers

Vadim wrote:

> It seems too complex to me. I again propose to use refcount
> inside snapshot itself to prevent free-ing of snapshots.
> Benefits: no copying in Executor, no QueryId --> Snapshot
> lookup. Just add pointer to RTE. Parser will put NULL there:
> as flag that current snapshot has to be used. ExecutorStart
> and deffered rules will increment refcount of current snapshot.
> Deffered rules will also set snapshot pointers of appropriate
> RTEs (to the current snapshot).

    Yes,  the  parser  could  allways  put  NULL  into  the RTE's
    snapshot name field (or the name later for named  snapshots).
    But  it's  the  rewrite  system  that has to tell for unnamed
    snapshots, which ones have to be used on which RTE's.

    Let's have two simple tables with a rule (and assume  in  the
    following that snapshot includes scan command Id):

        create table t1 (a int4);
        create table t2 (b int4);

        create rule r1 as on delete to t1
            do delete from t2 where b = old.a;

    We execute the following commands:

        begin;
        delete from t1 where a = 5;
        insert into t2 values (5);
        commit;

    If 5 is in t2 after commit depends on if the rule is deferred
    or not.  If it isn't deferred, 5 should be  there,  otherwise
    not.

    The rule will create a parsetree like this:

        delete from t2 where t1.a = 5 and b = t1.a;

    So the tree has a rangetable containing t2 and t1 (along with
    some other unused entries). But only the rule  system  knows,
    that  the  RTE  for t2 came from the rule and must be scanned
    with the visibility of commit time while  t1  came  from  the
    original  query  and must be scanned with the visibility that
    was when the original delete from t1 was executed  (they  are
    already deleted, but the rule actions scan must find em).

    And  there  could  also be rules fired on t2. This results in
    recursive rewriting and it's not that  easy  to  foresee  the
    order  in  which  all  these commands will then get executed.
    During recursion there is no  difference  between  a  command
    coming  from  the  user  and one that is already generated by
    another rule.

    The problem here is, that the RTE's in a rule generated query
    resulting  from the former command (that fired them) must get
    scanned against the snapshot of  the  time  when  the  former
    command  get's  executed.  But the RTE's coming from the rule
    action itself must get the snapshot when the rules command is
    executed.  Only this way the quals added to the rule from the
    former command will see what the former command saw.

    The executor cannot know where all  the  RTE's  where  coming
    from. Except we have a QueryId and associate the QueryId with
    a snapshot at the time of execution. And I think we  must  do
    this lookup, because the order commands are executed will not
    be the same as they got created.  The executor  only  has  to
    override  the RTE's snapshot if the RTE's snapshot name isn't
    NULL.

>
> >     In  v6.6  we  could  also  implement  the   suggested   named
> >     snapshots.   This  only  requires  that  a  query  Id  can be
> >     associated with a name.  The CREATE SNAPSHOT utilities  query
> >     Id is that of the snapshot and during parse this Id is placed
>                                      ^^^^^^^^^^^^
> Snapshot names have to be resolved by Executor or just before
> execution: someday we'll implement stored procedures/functions:
> no parsing before execution...
> We could add bool to RTE: use name from snapshot pointer
> to get real snapshot. Or something like this.

    That's a point I forgot and I will allready have that problem
    in  prepared  SPI  plans. One SPI query could also fire rules
    resulting in multiple plans.

    So I must change it. The parser rewrite combo  allways  put's
    QueryId's  starting  with 0 into the queries and their RTE's,
    telling which RTE's belong to which queries execution  times.
    And  these  must  then  be offset when the plans get actually
    added to either  the  current  execution  tree  list  or  the
    deferred execution tree list.

    And  SPI  must  know  about  deferred  queries,  because  for
    prepared plans, one must get deferred for  every  SPI_execp()
    call.  It's not the rewriter who's managing the deferred tree
    list. It must be it's caller. So the deferred information  is
    part of the querytree.

    Better now, thanks Vadim.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #