2015-03-23 18:47:52 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_rewind.h
|
|
|
|
*
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2015-03-23 18:47:52 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef PG_REWIND_H
|
|
|
|
#define PG_REWIND_H
|
|
|
|
|
|
|
|
#include "access/timeline.h"
|
2019-09-30 17:57:35 +02:00
|
|
|
#include "common/logging.h"
|
2019-11-25 03:38:57 +01:00
|
|
|
#include "datapagemap.h"
|
2019-09-30 17:57:35 +02:00
|
|
|
#include "libpq-fe.h"
|
2015-03-23 18:47:52 +01:00
|
|
|
#include "storage/block.h"
|
Change internal RelFileNode references to RelFileNumber or RelFileLocator.
We have been using the term RelFileNode to refer to either (1) the
integer that is used to name the sequence of files for a certain relation
within the directory set aside for that tablespace/database combination;
or (2) that value plus the OIDs of the tablespace and database; or
occasionally (3) the whole series of files created for a relation
based on those values. Using the same name for more than one thing is
confusing.
Replace RelFileNode with RelFileNumber when we're talking about just the
single number, i.e. (1) from above, and with RelFileLocator when we're
talking about all the things that are needed to locate a relation's files
on disk, i.e. (2) from above. In the places where we refer to (3) as
a relfilenode, instead refer to "relation storage".
Since there is a ton of SQL code in the world that knows about
pg_class.relfilenode, don't change the name of that column, or of other
SQL-facing things that derive their name from it.
On the other hand, do adjust closely-related internal terminology. For
example, the structure member names dbNode and spcNode appear to be
derived from the fact that the structure itself was called RelFileNode,
so change those to dbOid and spcOid. Likewise, various variables with
names like rnode and relnode get renamed appropriately, according to
how they're being used in context.
Hopefully, this is clearer than before. It is also preparation for
future patches that intend to widen the relfilenumber fields from its
current width of 32 bits. Variables that store a relfilenumber are now
declared as type RelFileNumber rather than type Oid; right now, these
are the same, but that can now more easily be changed.
Dilip Kumar, per an idea from me. Reviewed also by Andres Freund.
I fixed some whitespace issues, changed a couple of words in a
comment, and made one other minor correction.
Discussion: http://postgr.es/m/CA+TgmoamOtXbVAQf9hWFzonUo6bhhjS6toZQd7HZ-pmojtAmag@mail.gmail.com
Discussion: http://postgr.es/m/CA+Tgmobp7+7kmi4gkq7Y+4AM9fTvL+O1oQ4-5gFTT+6Ng-dQ=g@mail.gmail.com
Discussion: http://postgr.es/m/CAFiTN-vTe79M8uDH1yprOU64MNFE+R3ODRuA+JWf27JbhY4hJw@mail.gmail.com
2022-07-06 17:39:09 +02:00
|
|
|
#include "storage/relfilelocator.h"
|
2015-03-23 18:47:52 +01:00
|
|
|
|
|
|
|
/* Configuration options */
|
|
|
|
extern char *datadir_target;
|
|
|
|
extern bool showprogress;
|
|
|
|
extern bool dry_run;
|
2020-11-04 09:38:39 +01:00
|
|
|
extern bool do_sync;
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
extern int WalSegSz;
|
2015-03-23 18:47:52 +01:00
|
|
|
|
2015-12-01 16:56:44 +01:00
|
|
|
/* Target history */
|
|
|
|
extern TimeLineHistoryEntry *targetHistory;
|
|
|
|
extern int targetNentries;
|
|
|
|
|
2019-05-14 19:11:23 +02:00
|
|
|
/* Progress counters */
|
|
|
|
extern uint64 fetch_size;
|
|
|
|
extern uint64 fetch_done;
|
|
|
|
|
2015-03-23 18:47:52 +01:00
|
|
|
/* in parsexlog.c */
|
|
|
|
extern void extractPageMap(const char *datadir, XLogRecPtr startpoint,
|
2020-04-01 03:57:03 +02:00
|
|
|
int tliIndex, XLogRecPtr endpoint,
|
|
|
|
const char *restoreCommand);
|
2015-03-23 18:47:52 +01:00
|
|
|
extern void findLastCheckpoint(const char *datadir, XLogRecPtr searchptr,
|
2015-12-01 16:56:44 +01:00
|
|
|
int tliIndex,
|
2015-03-23 18:47:52 +01:00
|
|
|
XLogRecPtr *lastchkptrec, TimeLineID *lastchkpttli,
|
2020-04-01 03:57:03 +02:00
|
|
|
XLogRecPtr *lastchkptredo,
|
|
|
|
const char *restoreCommand);
|
2015-03-23 18:47:52 +01:00
|
|
|
extern XLogRecPtr readOneRecord(const char *datadir, XLogRecPtr ptr,
|
2020-04-22 01:08:28 +02:00
|
|
|
int tliIndex, const char *restoreCommand);
|
2015-03-23 18:47:52 +01:00
|
|
|
|
2019-05-14 19:11:23 +02:00
|
|
|
/* in pg_rewind.c */
|
2020-08-17 08:27:29 +02:00
|
|
|
extern void progress_report(bool finished);
|
2019-05-14 19:11:23 +02:00
|
|
|
|
2015-03-23 18:47:52 +01:00
|
|
|
/* in timeline.c */
|
|
|
|
extern TimeLineHistoryEntry *rewind_parseTimeLineHistory(char *buffer,
|
2019-09-30 17:57:35 +02:00
|
|
|
TimeLineID targetTLI,
|
|
|
|
int *nentries);
|
2015-03-23 18:47:52 +01:00
|
|
|
|
|
|
|
#endif /* PG_REWIND_H */
|