Re: [HACKERS] CONSTRAINTS...

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(at)debis(dot)com (Jan Wieck) #