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
c1805134b370f0c5c54c40a2df8978599328784f
pgbackrest/src/postgres/interface/version.intern.h

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

134 lines
10 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.0/9.1/9.2. Our new policy is to support ten versions of PostgreSQL, the five supported releases and the last five EOL releases. As of PostgreSQL 15, that means 9.0/9.1/9.2 are no longer supported by pgBackRest. Remove all logic associated with 9.0/9.1/9.2 and update the tests. Document the new support policy. Update InfoPg to read/write control versions for the history in backup.info, since we can no longer rely on the mappings being available. In theory this could have been an issue after removing 8.3/8.4 if anybody was using a version that old.
2022-12-20 12:20:47 +07:00
#elif PG_VERSION >= PG_VERSION_93
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
#elif PG_VERSION >= PG_VERSION_93
#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, \
.pageChecksum = ((ControlFileData *)controlFile)->data_checksum_version != 0, \
}; \
}
#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.0/9.1/9.2. Our new policy is to support ten versions of PostgreSQL, the five supported releases and the last five EOL releases. As of PostgreSQL 15, that means 9.0/9.1/9.2 are no longer supported by pgBackRest. Remove all logic associated with 9.0/9.1/9.2 and update the tests. Document the new support policy. Update InfoPg to read/write control versions for the history in backup.info, since we can no longer rely on the mappings being available. In theory this could have been an issue after removing 8.3/8.4 if anybody was using a version that old.
2022-12-20 12:20:47 +07:00
#elif PG_VERSION >= PG_VERSION_93
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.0/9.1/9.2. Our new policy is to support ten versions of PostgreSQL, the five supported releases and the last five EOL releases. As of PostgreSQL 15, that means 9.0/9.1/9.2 are no longer supported by pgBackRest. Remove all logic associated with 9.0/9.1/9.2 and update the tests. Document the new support policy. Update InfoPg to read/write control versions for the history in backup.info, since we can no longer rely on the mappings being available. In theory this could have been an issue after removing 8.3/8.4 if anybody was using a version that old.
2022-12-20 12:20:47 +07:00
#elif PG_VERSION >= PG_VERSION_93
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.0/9.1/9.2. Our new policy is to support ten versions of PostgreSQL, the five supported releases and the last five EOL releases. As of PostgreSQL 15, that means 9.0/9.1/9.2 are no longer supported by pgBackRest. Remove all logic associated with 9.0/9.1/9.2 and update the tests. Document the new support policy. Update InfoPg to read/write control versions for the history in backup.info, since we can no longer rely on the mappings being available. In theory this could have been an issue after removing 8.3/8.4 if anybody was using a version that old.
2022-12-20 12:20:47 +07:00
#elif PG_VERSION >= PG_VERSION_93
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