Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers