| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alfred Perlstein <bright(at)mu(dot)org> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pgbench vs. wait events |
| Date: | 2016-10-07 17:42:02 |
| Message-ID: | 20161007174202.pfjp4wy7hlhfpgmn@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2016-10-06 20:52:22 -0700, Alfred Perlstein wrote:
> This contention on WAL reminds me of another scenario I've heard about that
> was similar.
>
> To fix things what happened was that anyone that the first person to block
> would be responsible for writing out all buffers for anyone blocked behind
> "him".
We pretty much do that already. But while that's happening, the other
would-be-writers show up as blocking on the lock. We don't use kind of
an odd locking model for the waiters (LWLockAcquireOrWait()), which
waits for the lock to be released, but doesn't try to acquire it
afterwards. Instead the wal position is rechecked, and in many cases
we'll be done afterwards, because enough has been written out.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-10-07 17:48:58 | Re: pg_dump getBlobs query broken for 7.3 servers |
| Previous Message | Andres Freund | 2016-10-07 17:39:29 | Re: pgbench vs. wait events |