Re: Add basic tests for the low-level backup method.
От | David Steele |
---|---|
Тема | Re: Add basic tests for the low-level backup method. |
Дата | |
Msg-id | 4980aba2-9cd4-4bd6-b2e1-e873639ab7ee@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Add basic tests for the low-level backup method. (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Add basic tests for the low-level backup method.
|
Список | pgsql-hackers |
On 2/29/24 16:55, Michael Paquier wrote: > On Thu, Feb 29, 2024 at 10:30:52AM +1300, David Steele wrote: >> On 11/12/23 08:21, David Steele wrote: >>> As promised in [1], attached are some basic tests for the low-level >>> backup method. >> >> Added to the 2024-03 CF. > > There is already 040_standby_failover_slots_sync.pl in recovery/ that > uses the number of your test script. You may want to bump it, that's > a nit. Renamed to 042_low_level_backup.pl. > +unlink("$backup_dir/postmaster.pid") > + or BAIL_OUT("unable to unlink $backup_dir/postmaster.pid"); > +unlink("$backup_dir/postmaster.opts") > + or BAIL_OUT("unable to unlink $backup_dir/postmaster.opts"); > +unlink("$backup_dir/global/pg_control") > + or BAIL_OUT("unable to unlink $backup_dir/global/pg_control"); > > RELCACHE_INIT_FILENAME as well? I'm not trying to implement the full exclusion list here, just enough to get the test working. Since exclusions are optional according to the docs I don't think we need them for a valid tests. > +# Rather than writing out backup_label, try to recover the backup without > +# backup_label to demonstrate that recovery will not work correctly without it, > +# i.e. the canary table will be missing and the cluster will be corrupt. Provide > +# only the WAL segment that recovery will think it needs. > > Okay, why not. No objections to this addition. I am a bit surprised > that this is not scanning some of the logs produced by the startup > process for particular patterns. Not sure what to look for here. There are no distinct messages for crash recovery. Perhaps there should be? > +# Save backup_label into the backup directory and recover using the primary's > +# archive. This time recovery will succeed and the canary table will be > +# present. > > Here are well, I think that we should add some log_contains() with > pre-defined patterns to show that recovery has completed the way we > want it with a backup_label up to the end-of-backup record. Sure, I added a check for the new log message when recovering with a backup_label. Regards, -David
Вложения
В списке pgsql-hackers по дате отправления: