| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Ken Yeung <Ken(dot)Yeung(at)rib-software(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Problem upgrading from 10 to 14 with pg_upgrade: unexpected error upgrading "template1" database for some clusters |
| Date: | 2022-07-13 05:49:54 |
| Message-ID: | b9ced700734c3c9bb1e12361df8f958d0876df5b.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, 2022-07-13 at 02:53 +0000, Ken Yeung wrote:
> From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
> Sent: Wednesday, July 13, 2022 3:16 AM
>
> > You configured "pg_hba.conf" so that a local login without password is
> > not possible. The easiest solution is to change the "pg_hba.conf"
> > entries for "localhost" in IPv4 and IPv6 to "trust" for the duration of
> > the upgrade.
>
> I am afraid this workaround may not be suitable for our case because of certain security consideration.
If you want to make your life difficult, that's ok. Remember that this change
would only be for *local* connections for the duration of the upgrade.
As an alternative, you could create a password file or, if that is also too
insecure, set the PGSSLCERT and PGSSLKEY environment variables so that you can
use a client certificate to connect. Other authentication methods might also
be possible; you'll have to experiment.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | André Hänsel | 2022-07-13 13:35:54 | Issues with upserts |
| Previous Message | Ken Yeung | 2022-07-13 02:53:30 | Re: Problem upgrading from 10 to 14 with pg_upgrade: unexpected error upgrading "template1" database for some clusters |