| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Move backup-related code to xlogbackup.c/.h |
| Date: | 2022-10-14 08:33:14 |
| Message-ID: | Y0keygE5J0U2/ncO@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 14, 2022 at 10:24:41AM +0200, Alvaro Herrera wrote:
> However, what's most problematic about this patch is that it introduces
> a pretty serious bug, yet that bug goes unnoticed if you just run the
> builtin test suites. I only noticed because I added an elog(ERROR,
> "oops") in the area protected by ENSURE_ERROR_CLEANUP and a debug
> elog(WARNING) in the cleanup area, then examined the server log after
> the pg_basebackup test filed; but this is not very workable. I wonder
> what would be a good way to keep this in check. The naive way seems to
> be to run a pg_basebackup, have it abort partway through (how?), then
> test the server and see if forced page writes are enabled or not.
See around the bottom of 010_pg_basebackup.pl, where a combination of
IPC::Run::start('pg_basebackup') with --max-rate and
pg_terminate_backend() is able to achieve that.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-10-14 08:35:53 | Re: Fix error message for MERGE foreign tables |
| Previous Message | Alvaro Herrera | 2022-10-14 08:24:41 | Re: Move backup-related code to xlogbackup.c/.h |