Re: refactoring basebackup.c
От | Andres Freund |
---|---|
Тема | Re: refactoring basebackup.c |
Дата | |
Msg-id | 20220312015253.zokhkwdn5xbbd4vf@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: refactoring basebackup.c (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: refactoring basebackup.c
|
Список | pgsql-hackers |
Hi, On 2022-03-11 10:19:29 -0500, Robert Haas wrote: > Thanks for the report. The problem here is that, when the output is > standard output (-D -), pg_basebackup can only produce a single output > file, so the manifest gets injected into the tar file on the client > side rather than being written separately as we do in normal cases. > However, that only works if we're receiving a tar file that we can > parse from the server, and here the server is sending a compressed > tarfile. The current code mistakely attempts to parse the compressed > tarfile as if it were an uncompressed tarfile, which causes the error > messages that you are seeing (and which I can also reproduce here). We > actually have enough infrastructure available in pg_basebackup now > that we could do the "right thing" in this case: decompress the data > received from the server, parse the resulting tar file, inject the > backup manifest, construct a new tar file, and recompress. However, I > think that's probably not a good idea, because it's unlikely that the > user will understand that the data is being compressed on the server, > then decompressed, and then recompressed again, and the performance of > the resulting pipeline will probably not be very good. So I think we > should just refuse this command. Patch for that attached. You could also just append a manifest as a compresed tar to the compressed tar stream. Unfortunately GNU tar requires -i to read concated compressed archives, so perhaps that's not quite an alternative. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: