Re: Assertion failing in master, predicate.c
От | Mark Dilger |
---|---|
Тема | Re: Assertion failing in master, predicate.c |
Дата | |
Msg-id | 09359045-9919-b9d9-d458-17e2b9f28c1b@gmail.com обсуждение исходный текст |
Ответ на | Re: Assertion failing in master, predicate.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Assertion failing in master, predicate.c
|
Список | pgsql-hackers |
On 11/22/19 11:07 AM, Tom Lane wrote: > Mark Dilger <hornschnorter@gmail.com> writes: >> On 11/21/19 8:03 PM, Tom Lane wrote: >>> I also confirm that it only happens in HEAD, not v12. I've not >>> actually bisected, but a look at the git history for predicate.c >>> sure makes it look like db2687d1f ("Optimize PredicateLockTuple") >>> must be to blame. > >> `git bisect` shows the problem occurs earlier than that, and by >> chance the first bad commit was one of yours. I'm not surprised >> that your commit was regarding LISTEN/NOTIFY, as the error is >> always triggered with a LISTEN statement. (I've now hit this >> many times in many tests of multiple SQL statements, and the >> last statement before the error is always a LISTEN.) > > Oh my, that's interesting! I had wondered a bit about the LISTEN > changes, but it's hard to see how those could have any connection > to serializable mode. This will be an entertaining debugging > exercise ... predicate.c was changed a few times after REL_12_STABLE was branched from master but before Thomas's change that you initially thought might be to blame. I checked whether rolling back the changes in predicate.c while keeping your LISTEN/NOTIFY changes might fix the bug, but alas the bug is still present. I'll go familiarize myself with your LISTEN/NOTIFY changes now.... -- Mark Dilger
В списке pgsql-hackers по дате отправления: