On Fri, Sep 10, 2021 at 5:25 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Sep 8, 2021 at 3:39 PM Robert Haas <robertmhaas@gmail.com> wrote:
> > The way the gzip APIs I used work, you tell it how big the output
> > buffer is and it writes until it fills that buffer, or until the input
> > buffer is empty, whichever happens first. But this seems to be the
> > other way around: you tell it how much input you have, and it tells
> > you how big a buffer it needs. To handle that elegantly, I think I
> > need to make some changes to the design of the bbsink stuff. What I'm
> > thinking is that each bbsink somehow tells the next bbsink how big to
> > make the buffer.
>
> Here's a new patch set with that design change (and a bug fix for 0001).
Seems like nothing has been done about the issue reported in [1]
This one line change shall fix the issue,
--- a/src/backend/replication/basebackup_gzip.c
+++ b/src/backend/replication/basebackup_gzip.c
@@ -264,6 +264,8 @@ bbsink_gzip_end_archive(bbsink *sink)
bbsink_archive_contents(sink->bbs_next, mysink->bytes_written);
mysink->bytes_written = 0;
}
+
+ bbsink_forward_end_archive(sink);
}
[1] https://www.postgresql.org/message-id/CAFiTN-uhg4iKA7FGWxaG9J8WD_LTx655%2BAUW3_KiK1%3DSakQy4A%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com