From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: measuring lwlock-related latency spikes |
Date: | 2012-03-31 22:01:52 |
Message-ID: | CAM-w4HPteZ-4DGjTycQ8GGsG-WA99M0ZiaOHFqHJF19-U7gE4g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 31, 2012 at 10:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Isn't that lock held while doing visibility checks?
>
> Nope. heap_update() and friends do a very complicated little dance to
> avoid that.
...
>> What about I/O
>> waiting for a clog page to be read?
>
> I'm pretty sure that can happen
I'm confused because i thought these two sentences were part of
describing the same case.
> because TransactionIdIsCommitted()
> can get called from HeapTupleSatisfies*() which pretty much only gets
> called while holding the page lock. I don't know whether it's the
> cause of these particular stalls, but it's plausible if the CLOG cache
> is getting thrashed hard enough.
I wonder if it would make sense to, if we come across an xid that
isn't in the slru release the lock while we read in the clog page.
When we reobtain it we can check if the LSN has changed and if it has
restart the visibility checks. If it hasn't pick up where we left off.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-04-01 00:10:05 | new group commit behavior not helping? |
Previous Message | Tom Lane | 2012-03-31 21:44:05 | Re: [HACKERS] Re: pg_dump incredibly slow dumping a single schema from a large db |