On 2021-Sep-01, Matthew Tice wrote:
> Hi Alvaro, thanks for the quick reply.
Hi. Glad to hear that your problem is now behind.
> I'm scheduled to do my patching maintenance at the end of this month -
> but at this point I don't think I'm going to make it.
>
> Other than patching, is there a work around?
Hm, in my previous reply I had written a suggestion to vacuum
pg_database in the offending database after deleting the
pg_internal.init file, but evidently I edited it out before sending.
(Probably because I wasn't sure if you need to delete file, connect,
vacuum, or rather connect, delete file, vacuum.)
> For example, in #2 above:
> >The fix for 2) is simpler,
> > simply always remove both the shared and local init files.
>
> I'm not familiar with the differences between 'shared' and 'local'
> init files (I'd imagine I referenced a 'local' file in my original
> post)?
The global file is in the global/ subdirectory of the data directory,
and the "local" ones are each in the corresponding database directory:
cd $PGDATA
$ find . -name pg_internal.init
./base/12758/pg_internal.init
./base/46212/pg_internal.init
./global/pg_internal.init
$ psql -c "select oid, datname from pg_database"
oid | datname
-------+------------
12757 | postgres
12758 | alvherre
1 | template1
12756 | template0
46212 | regression
(5 filas)
So in the above there are cache files for databases regression and
alvherre, plus the global one.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)