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
|
Список | 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 по дате отправления: