Re: refactoring basebackup.c
От | Dilip Kumar |
---|---|
Тема | Re: refactoring basebackup.c |
Дата | |
Msg-id | CAFiTN-u8FGWedkSoyTOCZ96ZBWL8EJ-SfO4MYdQ_p6uY8Fc02A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: refactoring basebackup.c (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: refactoring basebackup.c
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: