Re: [HACKERS] CONSTRAINTS... - Mailing list pgsql-hackers

Vadim wrote:

>
> Jan Wieck wrote:
> >
> (Note that now in the case of UPDATE t_ctid of OLD tuples
> points to TID of NEW tuples.)
>
> Two things define data visibility: SnapShot & CommandId.
> We would have to save them for deffered rules and restore them
> before run rule actions. But there is one issue: for what
> scans old visibility should be used? There are scans from
> user query and there are scans added by rule action. Ok,
> let's assume that for added scans current visibility will be used
> - this is what we need for RI rules (actually, something more -
> see below).

    I  addressed  that problem (different visibility required for
    scans in one command) also in my other mail.

    Anyway, I just checked what happens in the following case:

        T1:  begin;
        T1:  select ...

        T2:  update ...

        T1:  select ... (gets the same (old) values)

    That's the result as long as T1 doesn't run in READ COMMITTED
    mode.   And  that's  fine,  because  it doesn't have to worry
    about concurrent transactions of others.

    So the only problem left is the different visability. I think
    it  is  possible  to  change the visibility code not to check
    against the global command counter. Instead it might look  at
    a  command  counter value in the range table entry related to
    the scan node.  So the rewrite system and  tcop  could  place
    the correct values there during query rewrite/processing.

    The   range  table  of  a  rules  rewritten  parsetree  is  a
    combination of the range tables from the original user query,
    applied  view  rules  and  the  the rule itself. For deferred
    rules, only the those coming with the rule action itself must
    have  the  command counter at COMMIT. All others must get the
    command counter value that is there when the query that fired
    this rule get's executed.

    The  deferred  querytrees  can first be held in a new list of
    the rewritten querytree for the original user statement.  The
    rewrite    system    puts   into   the   rangetable   entries
    USE_CURRENT_CMDID or USE_COMMIT_CMDID depending on where they
    are coming from.

    Before tcop calls the executor, a new function in the rewrite
    system is called to set the actual  values  for  the  command
    counter  to use into the rangetable entries for one query and
    it's deferred ones.  Then it adds all the deferred queries to
    the global deferred list and runs the query itself.

    At  commit  time,  when  all the deferred queries have to get
    run, those RTE's in them having USE_COMMIT_CMDID are  set  to
    the  command  counter  at  commit  before  running the plans.
    Voila.

> >     And  it's  a  problem I've came across just writing this note
> >     where MVCC already could  have  broken  rewrite  rule  system
> >     semantics.
>
> How?

    Yes it did!

    If a transaction runs in READ COMMITTED mode,  the  scan  for
    the  rules  actions  (performed  first)  could have different
    results than that for the original query (performed last).

    For now I see only one solution. READ COMMITTED is  forbidden
    for  anything that invokes non-view rules. This check must be
    done in the tcop and SPI, because saved SPI plans can be  run
    without  invoking the rewrite system at any time. So the plan
    must remember somewhere if READ COMMITTED is allowed  for  it
    or not.


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) #