Re: Adding a test for speculative insert abort case

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Adding a test for speculative insert abort case
Дата
Msg-id 20200207070258.7henoclgdeq7xe46@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Adding a test for speculative insert abort case  (Melanie Plageman <melanieplageman@gmail.com>)
Ответы Re: Adding a test for speculative insert abort case
Список pgsql-hackers
Hi,

On 2019-08-21 13:59:00 -0700, Melanie Plageman wrote:
> >> > +step "controller_print_speculative_locks" { SELECT
> >> locktype,classid,objid,mode,granted FROM pg_locks WHERE
> >> locktype='speculative
> >> > +token' ORDER BY granted; }
> >>
> >> I think showing the speculative locks is possibly going to be unreliable
> >> - the release time of speculative locks is IIRC not that reliable. I
> >> think it could e.g. happen that speculative locks are held longer
> >> because autovacuum spawned an analyze in the background.
> >>
> >>
> > I actually think having the "controller_print_speculative_locks"
> > wouldn't be a problem because we have not released the advisory lock
> > on 4 in s2 that allows it to complete its speculative insertion and so
> > s1 will still be in speculative wait.

Hm. At the very least it'd have to be restricted to only match locks in
the same database - e.g. for parallel installcheck it is common for
there to be other concurrent tests.  I'll add that when committing, no
need for a new version.

I'm also a bit concerned that adding the pg_locks query would mean we can't
run the test in parallel with others, if we ever finally get around to
adding a parallel isolationtester schedule (which is really needed, it's
too slow as is).
https://postgr.es/m/20180124231006.z7spaz5gkzbdvob5@alvherre.pgsql
But I guess we we'll just deal with not running this test in parallel.


> > The step that might be a problem if autovacuum delays release of the
> > speculative locks is the "controller_show" step, because, at that
> > point, if the lock wasn't released, then s1 would still be waiting and
> > wouldn't have updated.
> >
> So, what should we do about this? Do you agree that the "controller_show"
> step would be a problem?

It hasn't caused failures so far, I think. Or are you saying you think
it's more likely to cause failures in the added tests?

Had planned to commit now, but I'm not able to think through the state
transitions at this hour, apparently :(. I'll try to do it tomorrow
morning.

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: WIP: expression evaluation improvements
Следующее
От: keisuke kuroda
Дата:
Сообщение: Re: In PG12, query with float calculations is slower than PG11