From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: heap vacuum & cleanup locks |
Date: | 2014-07-01 02:47:07 |
Message-ID: | CA+TgmoY6p4T-9Xm-qtXWWgUwi7eTWvvL36pkc4==vLkoJXmizw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 30, 2014 at 7:55 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Wed, Nov 2, 2011 at 3:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Jun 7, 2011 at 3:24 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
>>> Well it's super-exclusive-vacuum-lock avoidance techniques. Why
>>> shouldn't it make more sense to try to reduce the frequency and impact
>>> of the single-purpose outlier in a non-critical-path instead of
>>> burdening every other data reader with extra overhead?
>>>
>>> I think Robert's plan is exactly right though I would phrase it
>>> differently. We should get the exclusive lock, freeze/kill any xids
>>> and line pointers, then if the pin-count is 1 do the compaction.
>>
>> I wrote a really neat patch to do this today... and then, as I
>> thought about it some more, I started to think that it's probably
>> unsafe. Here's the trouble: with this approach, we assume that it's
>> OK to change the contents of the line pointer while holding only an
>> exclusive lock on the buffer. But there is a good deal of code out
>> there that thinks it's OK to examine a line pointer with only a pin on
>> the buffer (no lock). You need a content lock to scan the item
>> pointer array, but once you've identified an item of interest, you're
>> entitled to assume that it won't be modified while you hold a buffer
>> pin. Now, if you've identified a particular tuple as being visible to
>> your scan, then you might think that VACUUM shouldn't be removing it
>> anyway. But I think that's only true for MVCC scans - for example,
>> what happens under SnapshotNow semantics?
>
> Well now that you've done all that amazing work eliminating
> SnapshotNow ...
Thank you. :-)
> ... maybe this patch deserves another look? I see
> anti-wraparound vacuums more and more often as database transaction
> velocity increases and vacuum takes longer and longer as database
> sizes increase. Having a faster vacuum that can skip vacuuming pages
> but is still guaranteed to freeze every page is pretty tempting.
>
> Of course the freeze epoch in the header obviating the need for
> freezing is an even more attractive goal but AIUI we're not even sure
> that's going to work and this is a nice easy win.
Well, there's still SnapshotSelf, SnapshotAny, SnapshotDirty, ...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2014-07-01 03:26:43 | Re: Escaping from blocked send() reprised. |
Previous Message | Robert Haas | 2014-07-01 02:44:58 | Re: Spinlocks and compiler/memory barriers |