You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Handle extension members when first setting object dump flags in pg_dump.
pg_dump's original approach to handling extension member objects was torun around and clear (or set) their dump flags rather late in its datacollection process. Unfortunately, quite a lot of code expects those flagsto be valid before that; which was an entirely reasonable expectationbefore we added extensions. In particular, this explains Karsten Hilbert'srecent report of pg_upgrade failing on a database in which an extensionhas been installed into the pg_catalog schema. Its objects are initiallymarked as not-to-be-dumped on the strength of their schema, and later wechange them to must-dump because we're doing a binary upgrade of theirextension; but we've already skipped essential tasks like making associatedDO_SHELL_TYPE objects.To fix, collect extension membership data first, and incorporate it in theinitial setting of the dump flags, so that those are once again correctfrom the get-go. This has the undesirable side effect of slightlylengthening the time taken before pg_dump acquires table locks, but testingsuggests that the increase in that window is not very much.Along the way, get rid of ugly special-case logic for deciding whetherto dump procedural languages, FDWs, and foreign servers; dump decisionsfor those are now correct up-front, too.In 9.3 and up, this also fixes erroneous logic about when to dump eventtriggers (basically, they were *always* dumped before). In 9.5 and up,transform objects had that problem too.Since this problem came in with extensions, back-patch to all supportedversions.