From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Poorly thought out code in vacuum |
Date: | 2012-01-06 08:50:26 |
Message-ID: | CA+U5nMLjPGe0J1e8P_8aQxQFjViyYk_7andy2Ot_sBcgrT544g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 6, 2012 at 12:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> We could fix the direct symptom by inserting UnlockReleaseBuffer()
> in front of the continue, but AFAICS that just makes this into a
> busy-waiting equivalent of waiting unconditionally, so I don't really
> see why we should not revert the above fragment altogether. However,
> I suppose Robert had something more intelligent in mind than a tight
> loop when the buffer can't be exclusively locked, so maybe there is
> some other change that should be made here instead.
Skipping the block completely isn't feasible. The only options are to
wait or to do out of order cleaning.
The conditional behaviour in vacuum_scan_heap() is much more important
that it is here, so just waiting for the lock wouldn't be too bad. Out
of order cleaning could be very expensive in terms of I/O and could
make that less robust. So I'd say lets just wait normally for the
lock.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-01-06 09:08:15 | Re: CLOG contention |
Previous Message | Tom Lane | 2012-01-06 07:26:07 | Re: pgsql: Fix breakage from earlier plperl fix. |