Re: Instability in select_parallel regression test

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Instability in select_parallel regression test
Date: 2017-02-19 15:02:13
Message-ID: CA+TgmoaOZRuL_FZGYk__rTEysLZNWMi3M=VfoJhuf7j33f8ncg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 19, 2017 at 6:50 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> To close the remaining gap, don't you think we can check slot->in_use
> flag when generation number for handle and slot are same.

That doesn't completely fix it either, because
ForgetBackgroundWorker() also does
BackgroundWorkerData->parallel_terminate_count++, which we might also
fail to see, which would cause RegisterDynamicBackgroundWorker() to
bail out early. There are CPU ordering effects to think about here,
not just the order in which the operations are actually performed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-02-19 15:23:42 Re: drop support for Python 2.3
Previous Message Robins Tharakan 2017-02-19 14:42:49 Re: Allow pg_dumpall to work without pg_authid