db/pgbackrest
1
0
Fork 0
mirror of https://github.com/pgbackrest/pgbackrest.git synced 2025-07-05 00:28:52 +02:00
Code Issues Releases Activity
Files
899b8927888f3930f07f5607902d0493bd3b8f05
pgbackrest/src/postgres/interface/version.intern.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

166 lines
13 KiB
C
Raw Normal View History

Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
/***********************************************************************************************************************************
PostgreSQL Version Interface
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
Macros for building version-specific functions that interface with the types in version.vendor.h. Due to the way PostgreSQL types
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
evolve over time, this seems to be the easiest way to extract information from them.
These macros should be kept as simple as possible, with most of the logic contained in postgres/interface.c.
***********************************************************************************************************************************/
Use an extension to denote vendorized code. Vendorized code is copied from another project when a library is not available and a git subproject won't work. Currently all the vendorized code is copied from PostgreSQL but it makes sense to have a more general mechanism for indicating vendorized code. The .vendor extension will be used to denote vendorized code in the same way that .auto is used to denote auto-generated code.
2020-05-18 19:11:26 -04:00
#include "postgres/interface/version.vendor.h"
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
#include "postgres/version.h"
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
/***********************************************************************************************************************************
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
Determine if the supplied pg_control is for this version of PostgreSQL. When CATALOG_VERSION_NO_MAX is defined then the catalog will
be accepted as a range that lasts until the end of the encoded year. This allows pgBackRest to work with PostgreSQL during the
alpha/beta/rc period without needing to be updated, unless of course the actual interface changes.
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
***********************************************************************************************************************************/
#if PG_VERSION > PG_VERSION_MAX
Remove support for PostgreSQL 9.3. Per our policy to support five EOL versions of PostgreSQL, 9.3 is no longer supported by pgBackRest. Remove all logic associated with 9.3 and update the tests.
2023-11-09 12:59:12 -03:00
#elif PG_VERSION >= PG_VERSION_94
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
Add PostgreSQL 14 support. There are no code changes from PostgreSQL 13 so simply add the new version. Add CATALOG_VERSION_NO_MAX to allow the catalog version to "float" during the PostgreSQL beta/rc period so new pgBackRest versions are not required when the catalog version changes. Update the integration tests to handle new PostgreSQL startup messages.
2021-05-24 17:17:03 -04:00
#ifdef CATALOG_VERSION_NO_MAX
#define PG_INTERFACE_CONTROL_IS(version) \
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
static bool \
Add PostgreSQL 14 support. There are no code changes from PostgreSQL 13 so simply add the new version. Add CATALOG_VERSION_NO_MAX to allow the catalog version to "float" during the PostgreSQL beta/rc period so new pgBackRest versions are not required when the catalog version changes. Update the integration tests to handle new PostgreSQL startup messages.
2021-05-24 17:17:03 -04:00
pgInterfaceControlIs##version(const unsigned char *controlFile) \
{ \
ASSERT(controlFile != NULL); \
\
return \
((ControlFileData *)controlFile)->pg_control_version == PG_CONTROL_VERSION && \
((ControlFileData *)controlFile)->catalog_version_no >= CATALOG_VERSION_NO && \
((ControlFileData *)controlFile)->catalog_version_no < (CATALOG_VERSION_NO / 100000 + 1) * 100000; \
}
#else
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
#define PG_INTERFACE_CONTROL_IS(version) \
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
static bool \
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
pgInterfaceControlIs##version(const unsigned char *controlFile) \
{ \
ASSERT(controlFile != NULL); \
\
return \
((ControlFileData *)controlFile)->pg_control_version == PG_CONTROL_VERSION && \
((ControlFileData *)controlFile)->catalog_version_no == CATALOG_VERSION_NO; \
}
#endif
Add PostgreSQL 14 support. There are no code changes from PostgreSQL 13 so simply add the new version. Add CATALOG_VERSION_NO_MAX to allow the catalog version to "float" during the PostgreSQL beta/rc period so new pgBackRest versions are not required when the catalog version changes. Update the integration tests to handle new PostgreSQL startup messages.
2021-05-24 17:17:03 -04:00
#endif
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
/***********************************************************************************************************************************
Read the version specific pg_control into a general data structure
***********************************************************************************************************************************/
#if PG_VERSION > PG_VERSION_MAX
Remove support for PostgreSQL 9.3. Per our policy to support five EOL versions of PostgreSQL, 9.3 is no longer supported by pgBackRest. Remove all logic associated with 9.3 and update the tests.
2023-11-09 12:59:12 -03:00
#elif PG_VERSION >= PG_VERSION_94
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
#define PG_INTERFACE_CONTROL(version) \
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
static PgControl \
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
pgInterfaceControl##version(const unsigned char *controlFile) \
{ \
ASSERT(controlFile != NULL); \
\
return (PgControl) \
{ \
.systemId = ((ControlFileData *)controlFile)->system_identifier, \
Improve PostgreSQL version identification. Previously, catalog versions were fixed for all versions which made maintaining the catalog versions during PostgreSQL beta and release candidate cycles very painful. A version of pgBackRest which was functionally compatible was rendered useless by a catalog version bump in PostgreSQL. Instead use only the control version to identify a PostgreSQL version when possible. Some older versions require a catalog version to positively identify a PostgreSQL version, so include them when required. Since the catalog number is required to work with tablespaces it will need to be stored. There's already a copy of it in backup.info so use that (even though we have been ignoring it in the C versions).
2020-09-18 16:55:26 -04:00
.catalogVersion = ((ControlFileData *)controlFile)->catalog_version_no, \
Add timeline and checkpoint checks to backup. Add the following checks: * Checkpoint is updated in pg_control after pg_start_backup(). This helps ensure that PostgreSQL and pgBackRest have a consistent view of the storage and that PGDATA paths match. * Timeline of backup start WAL file matches pg_control. Hard to see how this one could get hit, but we have the power... * Standby is on the same timeline as the primary. If not, this standby is not following the primary. * Last standby checkpoint is not greater than the backup checkpoint. If so, this standby is not following the primary. This also requires some additional plumbing to read/write timeline/checkpoint from pg_control and parse timelines from WAL filenames. There were some changes in the backup tests caused by the fact that pg_control now has different contents for each backup. The check to ensure that the required checkpoint was reached on the standby should also be updated to use pg_control (it currently uses pg_control_checkpoint()), but that requires non-trivial changes to the test harness and will need to wait.
2021-12-07 09:21:07 -05:00
.checkpoint = ((ControlFileData *)controlFile)->checkPoint, \
.timeline = ((ControlFileData *)controlFile)->checkPointCopy.ThisTimeLineID, \
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
.pageSize = ((ControlFileData *)controlFile)->blcksz, \
.walSegmentSize = ((ControlFileData *)controlFile)->xlog_seg_size, \
Add validation for page checksum version in pg_control. This serves as an additional sanity check to be sure the pg_control format is as expected. The field is useful for being all the way at the end and being four bytes that can only have one of two values. Something more distinctive than 0 and 1 would be better, but this is what we have to work with. Convert PgControl.pageChecksum to unsigned int and rename to PgControl.pageChecksumVersion and make all downstream changes required for the new datatype.
2024-03-10 15:50:10 +13:00
.pageChecksumVersion = ((ControlFileData *)controlFile)->data_checksum_version, \
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
}; \
}
#endif
Retry reads of pg_control until checksum is valid. On certain file systems (e.g. ext4) pg_control may appear torn if there is a concurrent write while reading the file. To prevent an invalid read, retry until the checksum matches the control data. Special handling is required for the pg-version-force feature since the offset of the checksum is not known. In this case, scan from the default position to the end of the data looking for a checksum match. This is a bit imprecise, but better than nothing, and the chance of a random collision in the control data seems very remote considering the ratio of data size (< 512 bytes) to checksum size (4 bytes). This was discovered and a possible solution proposed for PostgreSQL in [1]. The proposed solution may work for backup, but pgBackRest needs to be able to read pg_control reliably outside of backup. So no matter what fix is adopted for PostgreSQL, pgBackRest need retries. Further adjustment may be required as the PostgreSQL fix evolves. [1] https://www.postgresql.org/message-id/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de
2023-09-10 09:47:49 -04:00
/***********************************************************************************************************************************
Get control crc offset
***********************************************************************************************************************************/
#if PG_VERSION > PG_VERSION_MAX
Remove support for PostgreSQL 9.3. Per our policy to support five EOL versions of PostgreSQL, 9.3 is no longer supported by pgBackRest. Remove all logic associated with 9.3 and update the tests.
2023-11-09 12:59:12 -03:00
#elif PG_VERSION >= PG_VERSION_94
Retry reads of pg_control until checksum is valid. On certain file systems (e.g. ext4) pg_control may appear torn if there is a concurrent write while reading the file. To prevent an invalid read, retry until the checksum matches the control data. Special handling is required for the pg-version-force feature since the offset of the checksum is not known. In this case, scan from the default position to the end of the data looking for a checksum match. This is a bit imprecise, but better than nothing, and the chance of a random collision in the control data seems very remote considering the ratio of data size (< 512 bytes) to checksum size (4 bytes). This was discovered and a possible solution proposed for PostgreSQL in [1]. The proposed solution may work for backup, but pgBackRest needs to be able to read pg_control reliably outside of backup. So no matter what fix is adopted for PostgreSQL, pgBackRest need retries. Further adjustment may be required as the PostgreSQL fix evolves. [1] https://www.postgresql.org/message-id/20221123014224.xisi44byq3cf5psi%40awork3.anarazel.de
2023-09-10 09:47:49 -04:00
#define PG_INTERFACE_CONTROL_CRC_OFFSET(version) \
static size_t \
pgInterfaceControlCrcOffset##version(void) \
{ \
return offsetof(ControlFileData, crc); \
}
#endif
Prevent invalid recovery when backup_label removed. If backup_label is removed from a restored backup then PostgreSQL will instead use checkpoint information from pg_control to attempt (what is thinks is) crash recovery. This will nearly always result in a corrupt cluster because the checkpoint will not be from the beginning of the backup, and even if it is, the end point will not be specified, which could lead to recovery stopping too early. To prevent this, invalidate the checkpoint LSN in pg_control on restore. If backup_label is removed then recovery will still fail because PostgreSQL will not be able to find the invalid checkpoint. The LSN of the checkpoint is not logged but it will be visible in pg_controldata output as 0/DEAD. This value is invalid because PostgreSQL always skips the first WAL segment when initializing a cluster.
2024-03-10 17:08:42 +13:00
/***********************************************************************************************************************************
Invalidate control checkpoint. PostgreSQL skips the first segment so any LSN in that segment is invalid.
***********************************************************************************************************************************/
#if PG_VERSION > PG_VERSION_MAX
#elif PG_VERSION >= PG_VERSION_93
#define PG_INTERFACE_CONTROL_CHECKPOINT_INVALIDATE(version) \
static void \
pgInterfaceControlCheckpointInvalidate##version(unsigned char *const controlFile) \
{ \
((ControlFileData *)controlFile)->checkPoint = PG_CONTROL_CHECKPOINT_INVALID; \
}
#endif
Remove most references to PostgreSQL control and catalog versions. The control and catalog versions were stored a variety of places in the optimistic hope that they would be useful. In fact they never were. We can't remove them from the backup.info and backup.manifest files due to backwards compatibility concerns, but we can at least avoid loading and storing them in C structures. Add functions to the PostgreSQL interface which will return the control and catalog versions for any supported version of PostgreSQL to allow backwards compatibility for backup.info and backup.manifest. These functions will be useful in other ways, e.g. generating the tablespace identifier in PostgreSQL >= 9.0.
2019-09-07 18:04:39 -04:00
/***********************************************************************************************************************************
Get the control version
***********************************************************************************************************************************/
#if PG_VERSION > PG_VERSION_MAX
Remove support for PostgreSQL 9.3. Per our policy to support five EOL versions of PostgreSQL, 9.3 is no longer supported by pgBackRest. Remove all logic associated with 9.3 and update the tests.
2023-11-09 12:59:12 -03:00
#elif PG_VERSION >= PG_VERSION_94
Remove most references to PostgreSQL control and catalog versions. The control and catalog versions were stored a variety of places in the optimistic hope that they would be useful. In fact they never were. We can't remove them from the backup.info and backup.manifest files due to backwards compatibility concerns, but we can at least avoid loading and storing them in C structures. Add functions to the PostgreSQL interface which will return the control and catalog versions for any supported version of PostgreSQL to allow backwards compatibility for backup.info and backup.manifest. These functions will be useful in other ways, e.g. generating the tablespace identifier in PostgreSQL >= 9.0.
2019-09-07 18:04:39 -04:00
#define PG_INTERFACE_CONTROL_VERSION(version) \
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
static uint32_t \
Remove most references to PostgreSQL control and catalog versions. The control and catalog versions were stored a variety of places in the optimistic hope that they would be useful. In fact they never were. We can't remove them from the backup.info and backup.manifest files due to backwards compatibility concerns, but we can at least avoid loading and storing them in C structures. Add functions to the PostgreSQL interface which will return the control and catalog versions for any supported version of PostgreSQL to allow backwards compatibility for backup.info and backup.manifest. These functions will be useful in other ways, e.g. generating the tablespace identifier in PostgreSQL >= 9.0.
2019-09-07 18:04:39 -04:00
pgInterfaceControlVersion##version(void) \
{ \
return PG_CONTROL_VERSION; \
}
#endif
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
/***********************************************************************************************************************************
Determine if the supplied WAL is for this version of PostgreSQL
***********************************************************************************************************************************/
#if PG_VERSION > PG_VERSION_MAX
Remove support for PostgreSQL 9.3. Per our policy to support five EOL versions of PostgreSQL, 9.3 is no longer supported by pgBackRest. Remove all logic associated with 9.3 and update the tests.
2023-11-09 12:59:12 -03:00
#elif PG_VERSION >= PG_VERSION_94
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
#define PG_INTERFACE_WAL_IS(version) \
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
static bool \
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
pgInterfaceWalIs##version(const unsigned char *walFile) \
{ \
ASSERT(walFile != NULL); \
\
return ((XLogPageHeaderData *)walFile)->xlp_magic == XLOG_PAGE_MAGIC; \
}
#endif
/***********************************************************************************************************************************
Read the version specific WAL header into a general data structure
***********************************************************************************************************************************/
#if PG_VERSION > PG_VERSION_MAX
Remove support for PostgreSQL 9.3. Per our policy to support five EOL versions of PostgreSQL, 9.3 is no longer supported by pgBackRest. Remove all logic associated with 9.3 and update the tests.
2023-11-09 12:59:12 -03:00
#elif PG_VERSION >= PG_VERSION_94
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
#define PG_INTERFACE_WAL(version) \
Automatically create PostgreSQL version interfaces. Maintaining the version interfaces was complicated by the fact that each interface needed to be in separate compilation unit to avoid type conflicts. This also meant that various build/test files needed to be updated to add the new interfaces. Solve these problems by auto-generating all the interfaces into a single file. This is made possible by parsing defines and types out of the header files and creating macros to rename the types. At the end of the version interface everything is undef'd. Another benefit is that the auto-generated interfaces can be static and included directly into postgres/interface.c. Since some code generation is now always required for tests, change --no-gen to --min-gen in test.pl. It would also make sense to auto-generate the version defines in postgres/version.h, but that will be left for a future commit.
2022-06-06 13:52:56 -04:00
static PgWal \
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
pgInterfaceWal##version(const unsigned char *walFile) \
{ \
ASSERT(walFile != NULL); \
\
return (PgWal) \
{ \
.systemId = ((XLogLongPageHeaderData *)walFile)->xlp_sysid, \
Read segment size from WAL headers. This allows validation of the WAL segment size for PostgreSQL versions <= 10.
2020-07-09 17:32:36 -04:00
.size = ((XLogLongPageHeaderData *)walFile)->xlp_seg_size, \
Refactor PostgreSQL interface to remove most code duplication. Having a copy per version worked well until it was time to add new features or modify existing functions. Then it was necessary to modify every version and try to keep them all in sync. Consolidate all the PostgreSQL types into a single file using #if for type versions. Many types do not change or change infrequently so this cuts down on duplication. In addition, it is far easier to see what has changed when a new version is added. Use macros to write the interface functions. There is still duplication here since some changes require a new copy of the macro, but it is far less than before.
2019-03-21 21:11:36 +04:00
}; \
}
#endif
Reference in New Issue Copy Permalink