Alvaro Herrera <alvherre@commandprompt.com> writes:
> No, that's for the workers. The launcher needs all the entries anyway.
> (I'm assuming it will be able to check visibility of tuples, correct?
> Hmm, it will need to run transactions in order to do that ...)
No, you don't need to be in a transaction to check visibility.
flatfiles.c is already doing that without being in a transaction,
in some cases. What you need a transaction for is to be able to
hold AccessShareLock on the table you're scanning. For pg_database
it's not possible for any schema changes (like relfilenode changes)
to happen anyway. But it is possible for vacuum to try to truncate
away empty end pages, which could result in a failure of a concurrent
heapscan without a lock. The code in flatfiles.c is safe because it's
only doing that during the startup process when nobody else could be
running vacuum, but I don't suppose we can assume that for the AV
launcher.
I just noticed that we are depending on flatfiles.c to do a couple of
things other than generate the flat files. In particular, we piggyback
on its scan of pg_database to produce the initial transaction ID wrap
limit value, and we rely on it to find all the databases that
RelationCacheInitFileRemove needs to be called for. I had been thinking
of replacing the latter bit with a directory search, but I don't see how
to get rid of scanning pg_database for the wrap limit setting. So it
seems like there is still going to need to be a linear scan of
pg_database during system startup. Annoying ...
regards, tom lane