On Fri, Jun 27, 2025 at 03:28:18PM +0300, Mikhail Gribkov wrote:
> Attached is the updated version of the patch with test additions.
Thanks for the updated versions. A bit more variance with the LZ4
levels, even if we cannot track everything, does not sound like a bad
thing to me for the server-s
Hi Michael,
> I think that it would be nice to have some test coverage for such
> cases in pg_verifybackup for both the client side and the server side
> of backups compressed, relying on the backend to generate some random
> data dumped into a file at the root of a data folder.
Yes, good p
On Wed, Jun 25, 2025 at 11:07:32PM +0300, Mikhail Gribkov wrote:
> The same situation can be reproduced using randomly filled files. Let’s
> imagine the extension saves its own statistics in pg_stat:
> dd if=/dev/urandom of=$PGDATA/pg_stat/junk bs=1M count=16
Original, I like that. It's not hard
Hi hackers,
While developing my extension, I faced some problems in using
pg_basebackup/pg_verifybackup on a cluster with additional custom files
saved. The extension saves its own format files, which may have a variety
of sizes and usually quite low compression potential.
The same situation can
