| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Amul Sul <sulamul(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_waldump: support decoding of WAL inside tarfile |
| Date: | 2026-03-21 14:45:46 |
| Message-ID: | 2250061.1774104346@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I also noticed a possible bug in astreamer, where the decompressor
> finalize functions send bbs_buffer.maxlen bytes to the next streamer
> when flushing remaining data at end-of-stream. This seems wrong because
> the buffer may only be partially filled with valid decompressed data.
> Possible patch for that attached. (But I don't think it's related to
> these failures).
Ugh. That's surely very broken, but how did we not notice?
Do all the consumers know enough to ignore garbage trailing data?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-03-21 14:55:10 | Re: another autovacuum scheduling thread |
| Previous Message | Tatsuo Ishii | 2026-03-21 14:16:29 | Re: Row pattern recognition |