Horton

Re: post-freeze damage control

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-04-16T23:20:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. revert: Transform OR clauses to ANY expression

  2. Fix incorrect calculation in BlockRefTableEntryGetBlocks.

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