diff options
| author | Robert Haas <rhaas@postgresql.org> | 2022-07-28 16:03:42 -0400 |
|---|---|---|
| committer | Robert Haas <rhaas@postgresql.org> | 2022-07-28 16:03:42 -0400 |
| commit | bbe08b8869bd29d587f24ef18eb45c7d4d14afca (patch) | |
| tree | d4be33aa407e3fdd3cf6de07fee0a14bad5a5450 /src/backend/parser/parse_expr.c | |
| parent | e09d7a1262c659578065eaf7edafe606d2c8ebf2 (diff) | |
| download | postgresql-bbe08b8869bd29d587f24ef18eb45c7d4d14afca.tar.gz postgresql-bbe08b8869bd29d587f24ef18eb45c7d4d14afca.zip | |
Use TRUNCATE to preserve relfilenode for pg_largeobject + index.
Commit 9a974cbcba005256a19991203583a94b4f9a21a9 arranged to preserve
the relfilenode of user tables across pg_upgrade, but failed to notice
that pg_upgrade treats pg_largeobject as a user table and thus it needs
the same treatment. Otherwise, large objects will appear to vanish
after a pg_upgrade.
Commit d498e052b4b84ae21b3b68d5b3fda6ead65d1d4d fixed this problem
by teaching pg_dump to UPDATE pg_class.relfilenode for pg_largeobject
and its index. However, because an UPDATE on the catalog rows doesn't
change anything on disk, this can leave stray files behind in the new
cluster. They will normally be empty, but it's a little bit untidy.
Hence, this commit arranges to do the same thing using DDL. Specifically,
it makes TRUNCATE work for the pg_largeobject catalog when in
binary-upgrade mode, and it then uses that command in binary-upgrade
dumps as a way of setting pg_class.relfilenode for pg_largeobject and
its index. That way, the old files are removed from the new cluster.
Discussion: http://postgr.es/m/CA+TgmoYYMXGUJO5GZk1-MByJGu_bB8CbOL6GJQC8=Bzt6x6vDg@mail.gmail.com
Diffstat (limited to 'src/backend/parser/parse_expr.c')
0 files changed, 0 insertions, 0 deletions