| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_upgrade version checking questions |
| Date: | 2021-03-02 13:20:40 |
| Message-ID: | e048d212-f72e-cff5-36fd-3e867e7d7267@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 23.02.21 17:14, Daniel Gustafsson wrote:
> This exports validate_exec to reduce duplication, and implements a custom
> find_other_exec-like function in pg_upgrade to check each binary for the
> version number. Keeping a local copy of validate_exec is easy to do if it's
> deemed not worth it to export it.
This looks mostly okay to me.
The commit message says something about "to ensure the health of the
target cluster", which doesn't make sense to me. Maybe find a better
wording.
The name find_exec() seems not very accurate. It doesn't find anything.
Maybe "check"?
I'm not sure why the new find_exec() adds EXE. AFAIK, this is only
required for stat(), and validate_exec() already does it.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2021-03-02 13:20:45 | [PATCH] Support empty ranges with bounds information |
| Previous Message | David Steele | 2021-03-02 12:53:25 | Re: 2019-03 CF now in progress |