On Wed, Jul 27, 2022 at 1:19 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Another thing that seems to have happened here is that catversion ought
> to have been touched and wasn't. Trying to start a cluster that was
> initdb'd with the previous code enters an infinite loop that dies each
> time with
>
> 2022-07-27 19:17:27.589 CEST [2516547] LOG: database system is ready to accept connections
> 2022-07-27 19:17:27.589 CEST [2516730] FATAL: could not read file "global/pg_filenode.map": read 512 of 524
> 2022-07-27 19:17:27.589 CEST [2516731] FATAL: could not read file "global/pg_filenode.map": read 512 of 524
> 2022-07-27 19:17:27.589 CEST [2516547] LOG: autovacuum launcher process (PID 2516730) exited with exit code 1
> 2022-07-27 19:17:27.589 CEST [2516547] LOG: terminating any other active server processes
>
> Perhaps we should still do a catversion bump now, since one hasn't
> happened since the commit.
Hmm, interesting. I didn't think about bumping catversion because I
didn't change anything in the catalogs. I did think about changing the
magic number for the file at one point, but unlike some of our other
constants, there's no indication that this one is intended to be used
as a version number. But in retrospect it would have been good to
change something somewhere. If you want me to bump catversion now, I
can. If you or someone else wants to do it, that's also fine.
--
Robert Haas
EDB: http://www.enterprisedb.com