Re: Possible corruption by CreateRestartPoint at promotion

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Rui Zhao <875941708(at)qq(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible corruption by CreateRestartPoint at promotion
Date: 2022-04-27 05:27:00
Message-ID: YmjUJPDcWx2eqS7r@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2022-04-27 05:29:28 Re: range of composite types!
Previous Message Tom Lane 2022-04-27 05:26:00 Re: Fwd: range of composite types!