database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-04 20:11:56 +03:00
Code Activity

Use TRUNCATE to preserve relfilenode for pg_largeobject + index.

Browse Source 
Commit 9a974cbcba 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 d498e052b4 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
This commit is contained in:
Robert Haas
2022-07-28 16:03:42 -04:00
parent e09d7a1262
commit bbe08b8869
4 changed files with 120 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
src/backend/utils/cache/relcache.c vendored
View File

@@ -41,6 +41,7 @@
#include "access/tupdesc_details.h"
#include "access/xact.h"
#include "access/xlog.h"
#include "catalog/binary_upgrade.h"
#include "catalog/catalog.h"
#include "catalog/indexing.h"
#include "catalog/namespace.h"
@@ -3707,9 +3708,36 @@ RelationSetNewRelfilenumber(Relation relation, char persistence)
TransactionId freezeXid = InvalidTransactionId;
RelFileLocator newrlocator;
/* Allocate a new relfilenumber */
newrelfilenumber = GetNewRelFileNumber(relation->rd_rel->reltablespace,
NULL, persistence);
if (!IsBinaryUpgrade)
{
/* Allocate a new relfilenumber */
newrelfilenumber = GetNewRelFileNumber(relation->rd_rel->reltablespace,
NULL, persistence);
}
else if (relation->rd_rel->relkind == RELKIND_INDEX)
{
if (!OidIsValid(binary_upgrade_next_index_pg_class_relfilenumber))
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("index relfilenumber value not set when in binary upgrade mode")));
newrelfilenumber = binary_upgrade_next_index_pg_class_relfilenumber;
binary_upgrade_next_index_pg_class_relfilenumber = InvalidOid;
}
else if (relation->rd_rel->relkind == RELKIND_RELATION)
{
if (!OidIsValid(binary_upgrade_next_heap_pg_class_relfilenumber))
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("heap relfilenumber value not set when in binary upgrade mode")));
newrelfilenumber = binary_upgrade_next_heap_pg_class_relfilenumber;
binary_upgrade_next_heap_pg_class_relfilenumber = InvalidOid;
}
else
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("unexpected request for new relfilenumber in binary upgrade mode")));
/*
* Get a writable copy of the pg_class tuple for the given relation.
@@ -3724,9 +3752,37 @@ RelationSetNewRelfilenumber(Relation relation, char persistence)
classform = (Form_pg_class) GETSTRUCT(tuple);
/*
* Schedule unlinking of the old storage at transaction commit.
* Schedule unlinking of the old storage at transaction commit, except
* when performing a binary upgrade, when we must do it immediately.
*/
RelationDropStorage(relation);
if (IsBinaryUpgrade)
{
SMgrRelation srel;
/*
* During a binary upgrade, we use this code path to ensure that
* pg_largeobject and its index have the same relfilenumbers as in
* the old cluster. This is necessary because pg_upgrade treats
* pg_largeobject like a user table, not a system table. It is however
* possible that a table or index may need to end up with the same
* relfilenumber in the new cluster as what it had in the old cluster.
* Hence, we can't wait until commit time to remove the old storage.
*
* In general, this function needs to have transactional semantics,
* and removing the old storage before commit time surely isn't.
* However, it doesn't really matter, because if a binary upgrade
* fails at this stage, the new cluster will need to be recreated
* anyway.
*/
srel = smgropen(relation->rd_locator, relation->rd_backend);
smgrdounlinkall(&srel, 1, false);
smgrclose(srel);
}
else
{
/* Not a binary upgrade, so just schedule it to happen later. */
RelationDropStorage(relation);
}
/*
* Create storage for the main fork of the new relfilenumber. If it's a