BUG #15467: The database subdirectory "pg_tblspc/1932420460/PG_10_201707211/16400" is missing.

The following bug has been logged on the website:

Bug reference: 15467
Logged by: Jay
Email address: tsuraan(at)gmail(dot)com
PostgreSQL version: 10.1
Operating system: Linux 4.1.18/AWS
Description:

I have a system running on AWS that had been processing data without any
apparent issues, when the main database apparently just stopped existing.
The postgres logs (considerably snipped) look like this:

...
[2018-10-29 15:51:30 UTC]STATEMENT: INSERT INTO ... RETURNING inserted
[2018-10-29 15:52:05 UTC]FATAL: database "db" does not exist
[2018-10-29 15:52:05 UTC]DETAIL: The database subdirectory
"pg_tblspc/1932420460/PG_10_201707211/16400" is missing.
[2018-10-29 15:52:05 UTC]FATAL: database "db" does not exist
[2018-10-29 15:52:05 UTC]DETAIL: The database subdirectory
"pg_tblspc/1932420460/PG_10_201707211/16400" is missing.
[2018-10-29 15:52:05 UTC]FATAL: database "db" does not exist
[2018-10-29 15:52:05 UTC]DETAIL: The database subdirectory
"pg_tblspc/1932420460/PG_10_201707211/16400" is missing.
...

Prior to the INSERT statement there are about six months of other insert,
select, update, etc statements (well, not really because of log rotation,
but that's the idea). After that final INSERT, postgres apparently decided
that it has table spaces in use, and the main db is stored on them. At
"SELECT * FROM pg_tablespace" looks like this:
psql (10.1)
Type "help" for help.

root=# select * from pg_tablespace ;
spcname | spcowner | spcacl | spcoptions
------------+----------+--------+------------
pg_default | 10 | |
pg_global | 10 | |
(2 rows)

So, I don't know why it thinks it needs to look for the main database in
some other tablespace. We've never declared any explicit tablespaces, so
that pg_tblspc directory is always empty, on every system we run (including
this one). I've stopped postgres, copied the data onto a system running
postgres 10.5, and started it there. The behaviour is identical, so I assume
the tablespace info must be stored somewhere other than in the pg_tablespace
table. Maybe I could clean it up, if I knew where the info was stored? I'm
curious how postgres could get into this state, but mostly I'd be happy to
get it functional again.