From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos |
Date: | 2017-06-07 00:20:56 |
Message-ID: | CAB7nPqQ-PQh1Qknrv_cwGf3kH0aReoThby0+37xiRp=MC7M+Mw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
The coverage of pg_basebackup is reaching 50%, which is not bad:
https://coverage.postgresql.org/src/bin/pg_basebackup/index.html
In this set pg_receivewal.c is the bad student with less than 20%.
There are a couple of causes behind that, with no tests like:
- option interactions like --create-slot and --drop-slot.
- replication slot drop.
- end of streaming.
- check handling of history files.
- looking at compressed and uncompressed WAL data.
- restart of pg_receivewal on an existing folder.
- pg_basebackup's tests don't use the progress report.
While it is possible to tackle some of those issues independently,
like pg_basebackup stuff, it seems to me that it would be helpful to
make the tests more deterministic by having an --endpos option for
pg_receivewal, similarly to what exists already in pg_recvlogical.
Thoughts?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-06-07 00:30:14 | Re: sketchy partcollation handling |
Previous Message | Peter Geoghegan | 2017-06-07 00:19:28 | Re: PG10 transition tables, wCTEs and multiple operations on the same table |