Re: [HACKERS] MERGE SQL Statement for PG11

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: [HACKERS] MERGE SQL Statement for PG11
Дата
Msg-id 0bd07f01-8c0e-1205-df90-a9ae77dafa5b@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [HACKERS] MERGE SQL Statement for PG11  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Ответы Re: [HACKERS] MERGE SQL Statement for PG11  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список pgsql-hackers
Hi,

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())
           ereport(ERROR,
                   (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
                    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 ...

regards

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: ldapi support
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Disabling src/test/[ssl|ldap] when not building with SSL/LDAP support