Re: pgsql: Move btbulkdelete's vacuum_delay_point() - Mailing list pgsql-committers

From Simon Riggs
Subject Re: pgsql: Move btbulkdelete's vacuum_delay_point()
Date
Msg-id 1140018743.12131.21.camel@localhost.localdomain
Whole thread Raw
In response to Re: pgsql: Move btbulkdelete's vacuum_delay_point()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Move btbulkdelete's vacuum_delay_point()
List pgsql-committers
On Tue, 2006-02-14 at 17:13 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > Perhaps if vacuum_delay_point() contained a timer check, we'd be able to
> > see if any gap between vacuum delays was more than the actual delay
> > itself. It would be nice to know they are all gone, forever.
>
> vacuum_delay_point is intended to be cheap enough (in the non-delay
> case) that no one would have any hesitation about dropping it into
> loops.  With a timer check in there, that might not be true, so I'm
> resistant to doing it unconditionally.  But I could see having some
> #ifdef'd code that could be conditionally compiled in to measure the
> maximum inter-delay-point time in a development build.

I'm thinking something like this might work better, since this is the
issue I/we really care about:

   if (LWLockNumHeldByMe() == 0)
       pg_usleep(msec * 1000L);
   else
        elog(WARNING, "losing sleep because internal locks are held");

or is it not worth losing sleep over? ;-)

The additional code is only executed *if* we are going to sleep, so a
few extra cycles won't hurt when we are just about to sleep for at least
10 milliseconds.

We could make similar checks at most of the other sleep locations,
modifying the number of held locks appropriately.

Best Regards, Simon Riggs


Attachment

pgsql-committers by date:

Previous
From: jwp@pgfoundry.org (James William Pye)
Date:
Subject: python - be: Add and use interface to deleting function cache entries.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Move btbulkdelete's vacuum_delay_point()