Tom Lane said:
But I think you might be confusing that with the feature-or-bug
(depending on one's point of view) that duplicate notifications can be
merged into one event. I'm inclined to preserve that behavior,
primarily because not doing so would create a tremendous penalty on
Neil, Jim, All:
Personally, I think delivering all notifications by default is simpler
behavior for the application programmer to understand. If you want to
avoid doing work for duplicate notifications, you realistically need to
implement that yourself anyway.
I agree with Neil; I don't
On Thu, Oct 06, 2005 at 10:30:24AM -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
It might make sense to change the semantics so that we never lose a
notification, if we're going to implement NOTIFY 'msg', but that's another
discussion.
That's pretty much a given
Jim C. Nasby [EMAIL PROTECTED] writes:
Maybe I'm missing something, but is it possible to ensure notifications
aren't lost using Heikki's method, since everything's only in shared
memory? Or is the idea that stuff would not survive a backend crash?
Listen/notify state has never survived a
On Sat, Oct 08, 2005 at 04:59:22PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Maybe I'm missing something, but is it possible to ensure notifications
aren't lost using Heikki's method, since everything's only in shared
memory? Or is the idea that stuff would not survive a
On Thu, Oct 06, 2005 at 01:32:32AM -0400, Neil Conway wrote:
On Thu, 2005-06-10 at 01:14 -0400, Tom Lane wrote:
The idea of blocking during commit until shmem becomes available might
work. There's some issues here about transaction atomicity, though:
how do you guarantee that all or none
Neil Conway [EMAIL PROTECTED] writes:
However, I don't really like the idea of blocking the backend for a
potentially significant amount of time in a state half-way between
committed and ready for the next query.
I wonder whether we could use something comparable to pg_multixact
or
On Thu, Oct 06, 2005 at 09:12:58AM -0400, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
However, I don't really like the idea of blocking the backend for a
potentially significant amount of time in a state half-way between
committed and ready for the next query.
I wonder whether
First of all, I'd like to give a name to the thing that a backend listens
to. The code talks about listening to a relation, but as the
comments there point out, the name doesn't actually identify a relation.
I'm going to call it a topic from now on.
I'd like to point out that we don't really
Heikki Linnakangas [EMAIL PROTECTED] writes:
It might make sense to change the semantics so that we never lose a
notification, if we're going to implement NOTIFY 'msg', but that's another
discussion.
That's pretty much a given --- the ability to pass some payload data in
notifications has
Tom Lane [EMAIL PROTECTED] writes:
I like your suggestion of topic for the notify name, and am tempted to
go fix the documentation to use that term right now ...
Fwiw, I think the more conventional word here would be channel.
But whatever.
--
greg
---(end of
Neil Conway [EMAIL PROTECTED] writes:
[ various ideas about reimplementing LISTEN/NOTIFY ]
I really dislike the idea of pushing notifies out to the shared queue
before commit. That essentially turns forever do notify foo into
a global DOS tool: you can drive everybody else's backend into swap
On Thu, 2005-06-10 at 01:14 -0400, Tom Lane wrote:
The idea of blocking during commit until shmem becomes available might
work. There's some issues here about transaction atomicity, though:
how do you guarantee that all or none of your notifies get sent?
(Actually, supposing that the notifies
13 matches
Mail list logo
