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

Re: sinval.c / sinvaladt.c restructuring

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Pg Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: sinval.c / sinvaladt.c restructuring
Date: 2008-03-17 00:33:47
Message-ID: 9134.1205714027@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> One side effect of this change is that the call to SendPostmasterSignal
> now occurs after the lock has been released.  ISTM this is a good idea
> on general principles (no syscalls in lwlocked code), but I'm wondering
> if I created a thundering hoard problem that did not exist before.

Forgot to reply to this earlier, but I think this is OK.  The test for
setting signal_postmaster is for exact equality of numMsgs to a
threshold, so at least in simple cases only one backend will send the
signal.  You could imagine scenarios where the slowest backend is trying
to catch up and numMsgs oscillates around the threshold, but it seems
unlikely to be a problem in practice.  I concur that moving the signal
out of the locked code is a good thing.  (Maybe move the elog(DEBUG4)
as well?)

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2008-03-17 02:20:39
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Previous:From: Tom LaneDate: 2008-03-16 23:23:27
Subject: Re: Hash Index Build Patch v2

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