Re: post-freeze damage control

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

In response to

Responses

Browse pgsql-hackers by date

  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