| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Jeremy Schneider <schnjere(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: proposal: change behavior on collation version mismatch |
| Date: | 2023-11-28 02:28:20 |
| Message-ID: | eec6ecc8f25e698c7ab29b3384d190bd4a4a4485.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2023-11-27 at 15:35 -0800, Jeremy Schneider wrote:
> For many enterprise customers, if they ask why their database
> wouldn't accept connections after an OS upgrade and we explained that
> durability & correctness is prioritized over availability, I think
> they would agree we're doing the right thing.
They may agree, but their database is still down, and they'll be
looking for a clear process to get it going again, ideally within their
maintenance window.
It would be really nice to agree on such a process, or even better, to
implement it in code.
> After some years of ICU and PG, I'm just coming to a conclusion that
> the right thing to do is stay safe and don't change ICU versions (or
> glibc versions) for existing databases in-place.
I don't disagree, but for a lot of users that depend on their operating
system and packaging infrastructure, that is not very practical.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2023-11-28 03:13:39 | Re: Synchronizing slots from primary to standby |
| Previous Message | Tom Lane | 2023-11-28 02:04:23 | Re: SSL tests fail on OpenSSL v3.2.0 |