Skip site navigation (1) Skip section navigation (2)

Re: notification payloads

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Hannu Krosing <hannu(at)skype(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: notification payloads
Date: 2007-03-27 11:28:59
Message-ID: 4608FFFB.6030801@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Hannu Krosing wrote:
> Now that I think about it again, maybe we should NOT go for a 
> shared memory implementation after all, as we now have HOT updates and 
> thanks to the fact, that we have 1:1 correspondence between the backends
> and 
> deleters in LISTEN/NOTIFY we can have much more exact DEAD-ness
> conditions and 
> can reuse space even in presence of long-running transactions.
>
> IOW, once we have deleted the message, we can be sure that no other 
> backend will ever be interested in that row.
>
> That means it may be possible to use a design similar to the one I just
> sent and just make the tables not wal-logged and have dead space reused
> in HOT-like manner.
>
> Straight HOT wil not be useful here, as usage is INSERT/DELETE instead
> of UPDATE, but similar principles, including heap space and index
> pointer reuse could probably be done.
>
>   

The only advantage to this ISTM is that we would eliminate the 
possibility of blocking.

But it still strikes me as rather more complex and thus possibly more 
fragile that what was previously discussed.

cheers

andrew



In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-03-27 11:33:08
Subject: Re: sorted results on pgbuildfarm
Previous:From: Andrew DunstanDate: 2007-03-27 11:16:45
Subject: Re: notification payloads

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group