Re: Possible corruption by CreateRestartPoint at promotion - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Possible corruption by CreateRestartPoint at promotion
Date
Msg-id YmjUJPDcWx2eqS7r@paquier.xyz
Whole thread Raw
In response to Re:Possible corruption by CreateRestartPoint at promotion  ("Rui Zhao" <875941708@qq.com>)
Responses Re: Possible corruption by CreateRestartPoint at promotion  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 27, 2022 at 12:36:10PM +0800, Rui Zhao wrote:
> Do you have interest in adding a test like one in my patch?

I have studied the test case you are proposing, and I am afraid that
it is too expensive as designed.  And it is actually racy as you
expect the restart point to take longer than the promotion with a
timing based on an arbitrary (and large!) amount of data inserted into
the primary.  Well, the promotion should be shorter than the restart
point in any case, but such tests should be designed so as they would
work reliably on slow machines while being able to complete quickly on
fast machines.

It would much better if the test is designed so as the restart point
is stopped at an arbitrary step rather than throttled, moving on when
the promotion of the standby is done.  A well-known method, that would
not work on Windows, is to rely on SIGSTOP that could be used on the
checkpointer for such things.  Anyway, we don't have any mean to
reliably stop a restart point while in the middle of its processing,
do we?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fwd: range of composite types!
Next
From: Tom Lane
Date:
Subject: Re: Possible corruption by CreateRestartPoint at promotion