Re: Should we SetQuerySnapshot() between actions of a rule?

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Should we SetQuerySnapshot() between actions of a rule?
Date: 2003-05-02 09:51:25
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA4961F93@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> I just noticed that there is an inconsistency between the way that
> PREPARE executes multiple queries (since PREPARE itself accepts
> only one SQL statement, any such multiple queries must have been
> generated by rule expansion) and the way that it is done in
> pg_exec_query_string(). The latter will do a SetQuerySnapshot()
> between actions of the rule, the former only does
> CommandCounterIncrement().

> ISTM we had better make the behavior consistent between PREPARE and
> interactive execution. But which one do we want? I could see an
> argument that it'd be best for all the actions of a rule to see a
> consistent snapshot of the state of other transactions; and not doing
> the extra SetQuerySnapshot() calls would save some cycles.

Agreed.
Actions generated by a rule should definitely all get the same snapshot.
Thus I think we only want to CommandCounterIncrement inside one statement.

For multiple statement statements, the main issue is usually to gain
performance. So I guess we could also only CommandCounterIncrement there.
Especially since for (session local) FK PK issues that is sufficient.
Also in the light of implicit subtransactions I guess we will want to
start only one subtransaction per multi statement. Seems to fit well with
above.

> But in READ COMMITTED mode this means that later actions
> in the rule may be able to see the effects of other transactions that
> committed while earlier actions were running.

Whether rows that get committed during single statement execution should
be instantly visible (in read committed) is imho a different consideration.
It should definitely be handeled equivalenty between a rule action and a second
pass at a table (e.g. for a join).

Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message Kaare Rasmussen 2003-05-02 10:55:52 Will the Real Database Leader Please Stand Up?
Previous Message Manfred Koizar 2003-05-02 09:27:47 comp.databases.postgresql.patches not working