Re: [HACKERS] recent deadlock regression test failures

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: [HACKERS] recent deadlock regression test failures
Дата
Msg-id CACjxUsOg5gDViLZSwjMqfW0bi+OfXc3-q2N5ZeyxQZ6beR==8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] recent deadlock regression test failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] recent deadlock regression test failures
Re: [HACKERS] recent deadlock regression test failures
Список pgsql-hackers
On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> Here's a pair of draft patches for review:

Thanks.

> Pushed with cosmetic improvements.

Thanks.

> I notice that the safe-snapshot code path is not paying attention to
> parallel-query cases, unlike the lock code path.  I'm not sure how
> big a deal that is...

Parallel workers in serializable transactions should be using the
transaction number of the "master" process to take any predicate
locks, and if parallel workers are doing any DML work against
tuples, that should be using the master transaction number for
xmin/xmax and serialization failure testing.  If either of those
rules are being violated, parallel processing should probably be
disabled within a serializable transaction.  I don't think
safe-snapshot processing needs to do anything special if the above
rules are followed, nor can I see anything special it *could* do.

--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] logical replication and SIGHUP
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] Variable substitution in psql backtick expansion