On 02/07/2018 10:24 AM, Pavan Deolasee wrote:
> ...
> Here is v15 of the patch.

I've been looking at this version of the patch, mostly to educate myself
before attempting to write the "status summary".

One bit that I don't quite understand is GetXactWALBytes(). It pretty
much just returns XactLastRecEnd and is used in ExecMerge like this:

       int64 startWAL = GetXactWALBytes();
       bool     qual = ExecQual(action->whenqual, econtext);

        * SQL Standard says that WHEN AND conditions must not
        * write to the database, so check we haven't written
        * any WAL during the test. Very sensible that is, since
        * we can end up evaluating some tests multiple times if
        * we have concurrent activity and complex WHEN clauses.
        * XXX If we had some clear form of functional labelling
        * we could use that, if we trusted it.
       if (startWAL < GetXactWALBytes())
                    errmsg("cannot write to database ...")));

I think this actually fails to enforce the rule, because some writes may
not produce WAL (think of unlogged tables). I also suspect it may be
incorrect "in the opposite direction" because a query may not do any
changes and yet it may produce WAL (e.g. due to wal_hint_bits=true).

So we may need to think of a different way to enforce this ...


Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply via email to