Re: notification payloads - Mailing list pgsql-hackers

From Tom Lane
Subject Re: notification payloads
Date
Msg-id 11551.1174969293@sss.pgh.pa.us
Whole thread Raw
In response to Re: notification payloads  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: notification payloads  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> ... But ISTM that means we just need to pick a few strategic spots 
> that will call CHECK_FOR_NOTIFICATIONS() even in the middle of a 
> transaction and store them locally.

Minor comment --- I don't believe in having a separate "sprinkle" of
notify-specific checks.  It needs to be set up so that
CHECK_FOR_INTERRUPTS will deal with the catch-up-please signal.  We've
already done (most of) the work of making sure CHECK_FOR_INTERRUPTS is
called often enough, and AFAICS we'd end up needing
CHECK_FOR_NOTIFICATIONS in exactly those same loops anyway.

It definitely helps here that CHECK_FOR_NOTIFICATIONS need affect only
localized state of a particular subsystem that nothing else depends on.
I've been wishing we could handle SI inval at more places than we do
now, but that seems a lot harder :-(
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: [BUGS] "Relation not found" error but table exits.
Next
From: Hannu Krosing
Date:
Subject: Re: notification payloads