From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: ThisTimeLineID is used uninitialized in basebackup.c, too |
Date: | 2021-10-29 18:09:53 |
Message-ID: | CA+TgmoZGG70p2C-t2pbPzZXjjYvdo5mJKFWS-hmMVxGMOr91hg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 29, 2021 at 7:28 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Yes, I agree that it is a good idea to cut the dependency of those
> code paths with ThisTimeLineID, expecting IDENTIFY_SYSTEM to have done
> the job beforehand. One argument in favor of your change, though I'd
> like to think that nobody does so, is that users could run BASE_BACKUP
> with a replication connection. So no need to hack pg_basebackup to be
> able to finish with a WAL sender that has no TLI set in the backend.
Right. I mean, I think the current behavior is both unprincipled and
unintentional. It's not like somebody would have intentionally
designed the BASE_BACKUP command to rely on a global variable
happening to have been set by a previous command. And if for some
crazy reason they had done that, surely there would be some comments
or something talking about it. It's just a (minor) mistake.
> Your patch seems correct to me.
Thanks, committed.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-10-29 18:23:34 | Re: Add support for ALTER INDEX .. ALTER [COLUMN] col_num {SET, RESET} |
Previous Message | Pavel Stehule | 2021-10-29 18:09:21 | Re: Better localization of errors in plpgsql variable initialization |