From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | Queue order of backends waiting on WALWriteLock |
Date: | 2013-05-07 05:06:30 |
Message-ID: | CA+HiwqFZJhPw8LZz+Q6YL8pxCuvCi_CCTWx6mZt6SozT0M9RKg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Hello,
I am not sure if pgsql-novice is place for this but this sounds like a
basic locking understanding question so here:
While studying group commit implementation (commit_delay=0 in this
case) in PostgreSQL, I am having some trouble understanding how
sometimes a particular backend with earlier WAL flush location has to
wait for WALWriteLock.
In XLogFlush()
when a backend waits on WALWriteLock by a call to
LWLockAcquireOrWait(), is it a case that it is queued in the
increasing order of flush location.
For example, if 3 backends with flush location A, B, C are waiting on
WALWriteLock with A < B < C. Is it possible for backend 2 (with B) to
get lock earlier than backend 1, causing 1 to have to wait.
How does it happen that a backend with flush location which is greater
than some of the waiting backends gets WALWriteLock earlier thus
causing the flush/fsync piggybacking to happen?
--
Amit Langote
From | Date | Subject | |
---|---|---|---|
Next Message | David Alvarez | 2013-05-07 14:34:44 | Hibernate + PostgreSQL (?) error |
Previous Message | David Johnston | 2013-05-02 21:51:20 | Re: *Proper* solution for 1..* relationship? |