From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: post-freeze damage control |
Date: | 2024-04-16 23:20:25 |
Message-ID: | 55342358604f64437608ff7b8aaa8b296208e6ab.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2024-04-08 at 15:47 -0400, Robert Haas wrote:
> - I couldn't understand why the "Operate
> XLogCtl->log{Write,Flush}Result with atomics" code was correct when I
> read it.
I reviewed ee1cbe806d. It followed a good process of discussion and
review. It was a bit close to the feature freeze for comfort, but did
not feel rushed, to me.
Additional eyes are always welcome. There are also some related commits
in that area like f3ff7bf83b, c9920a9068 and 91f2cae7a4.
> But, a spinlock
> protecting two variables together guarantees more than atomic access
> to each of those variables separately.
We maintain the invariant:
XLogCtl->logFlushResult <= XLogCtl->logWriteResult
and the non-shared version:
LogwrtResult.Flush <= LogwrtResult.Write
and that the requests don't fall behind the results:
XLogCtl->LogwrtRqst.Write >= XLogCtl->logWriteResult &&
XLogCtl->LogwrtRqst.Flush >= XLogCtl->logFlushResult
Are you concerned that:
(a) you aren't convinced that we're maintaining the invariants
properly? or
(b) you aren't convinced that the invariant is strong enough, and
that there are other variables that we aren't considering?
And if you think this is right after all, where could we add some
clarification?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2024-04-16 23:25:48 | Re: pg_combinebackup does not detect missing files |
Previous Message | Justin Pryzby | 2024-04-16 22:36:21 | Re: pg17 issues with not-null contraints |