On 2010-02-10 03:20 +0200, Tom Lane wrote:
> Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> writes:
>> On 2010-02-10 02:19 +0200, Tom Lane wrote:
>>> You still haven't explained why it's a good idea to change the snapshot
>>> after the executor has started. Right at the moment I'm prepared to
>>> reject the patch on that ground alone.
>
>> The patch only touches the snapshot's curcid. That's needed to allow
>> the queries see the tuples of the DML WITHs ran before that particular
>> query.
>
> ... and they will also see, for example, tuples inserted by triggers
> fired by those queries. I thought the plan for this feature was to
> store and re-read the RETURNING data, not to go back and re-read the
> underlying tables.
I originally suggested this approach about four months ago. During this
whole time you haven't expressed any concerns about this, but suddenly
it's a reason to reject the patch?
Anyway, if we want to avoid modifying the snapshot, we can't bump the
CID between queries. I haven't thought this through, but it seems like
this could work. However, none of the WITH queries can see the previous
statement's tuples, which means that someone may be suprised when they
try to modify the same tuples twice just to discover that only the first
modification took place. I don't see this as a huge problem though.
This will also solve the problem I started this thread for and makes the
patch smaller, simpler and even a bit prettier. Unless someone sees a
problem with this approach, I'm going to make the change.
Regards,
Marko Tiikkaja
