• Tom Lane's avatar
    Rethink recent fix for pg_dump's handling of extension config tables. · 9e5f1f21
    Tom Lane authored
    Commit 3eb3d3e7 was a few bricks shy of a load: while it correctly
    set the table's "interesting" flag when deciding to dump the data of
    an extension config table, it was not correct to clear that flag
    if we concluded we shouldn't dump the data.  This led to the crash
    reported in bug #16655, because in fact we'll traverse dumpTableSchema
    anyway for all extension tables (to see if they have user-added
    seclabels or RLS policies).
    
    The right thing to do is to force "interesting" true in makeTableDataInfo,
    and otherwise leave the flag alone.  (Doing it there is more future-proof
    in case additional calls are added, and it also avoids setting the flag
    unnecessarily if that function decides the table is non-dumpable.)
    
    This investigation also showed that while only the --inserts code path
    had an obvious failure in the case considered by 3eb3d3e7, the COPY
    code path also has a problem with not having loaded table subsidiary
    data.  That causes fmtCopyColumnList to silently return an empty string
    instead of the correct column list.  That accidentally mostly works,
    which perhaps is why we didn't notice this before.  It would only fail
    if the restore column order is different from the dump column order,
    which only happens in weird inheritance cases, so it's not surprising
    nobody had hit the case with an extension config table.  Nonetheless,
    it's a bug, and it goes a long way back, not just to v12 where the
    --inserts code path started to have a problem with this.
    
    In hopes of catching such cases a bit sooner in future, add some
    Asserts that "interesting" has been set in both dumpTableData and
    dumpTableSchema.  Adjust the test case added by 3eb3d3e7 so that it
    checks the COPY rather than INSERT form of that bug, allowing it to
    detect the longer-standing symptom.
    
    Per bug #16655 from Cameron Daniel.  Back-patch to all supported
    branches.
    
    Discussion: https://postgr.es/m/16655-5c92d6b3a9438137@postgresql.org
    Discussion: https://postgr.es/m/18048b44-3414-b983-8c7c-9165b177900d@2ndQuadrant.com
    9e5f1f21
pg_dump.c 558 KB