Re: Testing LISTEN/NOTIFY more effectively - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Testing LISTEN/NOTIFY more effectively
Date
Msg-id CAH2-WznKGybvVOhP06MPxGMD6zyWYQtL8u+XLc4K2wtB1a19Hg@mail.gmail.com
Whole thread Raw
In response to Re: Testing LISTEN/NOTIFY more effectively  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 27, 2019 at 12:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Unfortunately, I just found out that on a slow enough machine
> (prairiedog's host) there *is* some variation in when that test's
> notices come out.  I am unsure whether that's to be expected or
> whether there's something wrong there --- Peter, any thoughts?

I don't know why this happens, but it's worth noting that the plpgsql
function that raises these notices ("blurt_and_lock()") is marked
IMMUTABLE (not sure if you noticed that already). This is a deliberate
misrepresentation which is needed to acquire advisory locks at just
the right points during execution.

If I had to guess, I'd guess that it had something to do with that. I
might be able to come up with a better explanation if I saw the diff.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Andres Freund
Date:
Subject: Re: tap tests driving the database via psql