Hi, On 2017-06-11 17:17:07 -0400, Tom Lane wrote: > I am not very sure why it's so hard to duplicate the misbehavior; perhaps, > in order to make the failure happen with the current regression tests, > it's necessary for a background auto-analyze to happen and consume some > OIDs (for pg_statistic TOAST entries) at just the wrong time. However, > I can definitely demonstrate that there are uncontrolled relfilenode > assignments happening during pg_upgrade's restore run. I stuck an > elog() call into GetNewObjectId(), along with generation of a stack > trace using backtrace(), and here is one example:
Yea, that's not all that surprising :/ > Judging by when we started to see buildfarm failures, I think that > commit 3d79013b9 probably broke it, but the problem seems latent > in the whole concept of transactional sequence information. Hm. > Not sure what we want to do about it. One idea is to make > ALTER SEQUENCE not so transactional when in binary-upgrade mode. I think what you proposed downthread makes sense - I'd ripped out fairly similar code in my recent changes, because it was only introduced to address the concurrency problems the new sequence code had, and it didn't seem to buy sufficiently much... - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
