From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory |
Date: | 2022-04-19 05:12:21 |
Message-ID: | Yl5EtSXDO4paYgLF@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-04-19 05:19:45 | Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths |
Previous Message | Erik Rijkers | 2022-04-19 05:00:30 | Re: TRAP: FailedAssertion("tabstat->trans == trans", File: "pgstat_relation.c", Line: 508 |