Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory
Date
Msg-id Yl5EtSXDO4paYgLF@paquier.xyz
Whole thread Raw
In response to Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory
List pgsql-hackers
On Mon, Apr 18, 2022 at 02:50:17PM +0530, Bharath Rupireddy wrote:
> Thanks for sharing this. Will the write operations (in
> dir_open_for_write) for PG_COMPRESSION_GZIP and PG_COMPRESSION_LZ4
> take longer compared to prepadding for non-compressed files?

The first write operations for gzip and lz4 consists in writing their
respective headers in the resulting file, which should be a couple of
dozen bytes, at most.  So that's surely going to be cheaper than the
pre-padding done for a full segment with the flush induced after
writing WalSegSz bytes worth of zeros.

> I would like to know if there's any problem with the proposed fix.

There is nothing done for the case of compressed segments, meaning
that you would see the same problem when being in the middle of
writing a segment compressed with gzip or lz4 in the middle of writing
it, and that's what you want to avoid here.  So the important part is
not the pre-padding, it is to make sure that there is enough space
reserved for the handling of a full segment before beginning the work
on it.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: TRAP: FailedAssertion("tabstat->trans == trans", File: "pgstat_relation.c", Line: 508
Next
From: Michael Paquier
Date:
Subject: Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths