You've already forked pgbackrest
mirror of
https://github.com/pgbackrest/pgbackrest.git
synced 2025-07-05 00:28:52 +02:00
Remove dependency on pg_database.datlastsysoid.
This column has been removed in PostgreSQL 15. Rather than add a lot of special handling, it seems better just to update all versions to not depend on this column. Add centralized functions to identify the type of database (i.e. system or user) by name and use FirstNormalObjectId when a name is not available. The new query in the db module will still return the prior result for PostgreSQL <= 15, which will be stored in the manifest. This is important to preserve behavior when downgrading pgBackRest. There are no concerns here for PostgreSQL 15 since older versions of pgBackRest won't be able to restore backups for PostgreSQL 15 anyway.
This commit is contained in:
@ -213,4 +213,50 @@ typedef PageHeaderData *PageHeader;
|
||||
*/
|
||||
#define PageIsNew(page) (((PageHeader) (page))->pd_upper == 0)
|
||||
|
||||
/***********************************************************************************************************************************
|
||||
Types from src/include/access/transam.h
|
||||
***********************************************************************************************************************************/
|
||||
|
||||
// FirstNormalObjectId define
|
||||
// ---------------------------------------------------------------------------------------------------------------------------------
|
||||
/*
|
||||
* Object ID (OID) zero is InvalidOid.
|
||||
*
|
||||
* OIDs 1-9999 are reserved for manual assignment (see .dat files in
|
||||
* src/include/catalog/). Of these, 8000-9999 are reserved for
|
||||
* development purposes (such as in-progress patches and forks);
|
||||
* they should not appear in released versions.
|
||||
*
|
||||
* OIDs 10000-11999 are reserved for assignment by genbki.pl, for use
|
||||
* when the .dat files in src/include/catalog/ do not specify an OID
|
||||
* for a catalog entry that requires one. Note that genbki.pl assigns
|
||||
* these OIDs independently in each catalog, so they're not guaranteed
|
||||
* to be globally unique. Furthermore, the bootstrap backend and
|
||||
* initdb's post-bootstrap processing can also assign OIDs in this range.
|
||||
* The normal OID-generation logic takes care of any OID conflicts that
|
||||
* might arise from that.
|
||||
*
|
||||
* OIDs 12000-16383 are reserved for unpinned objects created by initdb's
|
||||
* post-bootstrap processing. initdb forces the OID generator up to
|
||||
* 12000 as soon as it's made the pinned objects it's responsible for.
|
||||
*
|
||||
* OIDs beginning at 16384 are assigned from the OID generator
|
||||
* during normal multiuser operation. (We force the generator up to
|
||||
* 16384 as soon as we are in normal operation.)
|
||||
*
|
||||
* The choices of 8000, 10000 and 12000 are completely arbitrary, and can be
|
||||
* moved if we run low on OIDs in any category. Changing the macros below,
|
||||
* and updating relevant documentation (see bki.sgml and RELEASE_CHANGES),
|
||||
* should be sufficient to do this. Moving the 16384 boundary between
|
||||
* initdb-assigned OIDs and user-defined objects would be substantially
|
||||
* more painful, however, since some user-defined OIDs will appear in
|
||||
* on-disk data; such a change would probably break pg_upgrade.
|
||||
*
|
||||
* NOTE: if the OID generator wraps around, we skip over OIDs 0-16383
|
||||
* and resume with 16384. This minimizes the odds of OID conflict, by not
|
||||
* reassigning OIDs that might have been assigned during initdb. Critically,
|
||||
* it also ensures that no user-created object will be considered pinned.
|
||||
*/
|
||||
#define FirstNormalObjectId 16384
|
||||
|
||||
#endif
|
||||
|
Reference in New Issue
Block a user