On Tue, 2010-01-19 at 19:05 -0500, Tom Lane wrote:
> I guess Joachim is trying to provide a similar guarantee for the new
> implementation, but I'm not clear on why it would require locking.
> The new implementation is broadcast and ISTM it shouldn't require the
> modifying transaction to know which processes are listening.
I think there is a better way. I'll dig into it a little more.
> I haven't read the patch but I agree that the description you give is
> pretty scary from a performance standpoint. More locks around
> transaction commit doesn't seem like a good idea.
I was also worried about holding multiple LWLocks at once -- is such
practice generally avoided in the rest of the code?
> If they're only taken
> when an actual LISTEN or NOTIFY has happened in the current transaction,
> that'd be okay (certainly no worse than what happens now) but the naming
> suggested that this'd happen unconditionally.
It appears that the locks are only taken when LISTEN or NOTIFY is
involved.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
