How to move a 11.4 cluster to another Linux host, but empty?
Hello, I've a 11.4 cluster on a Linux host with 3 production database, all below /data/postgresql11.4/ (i.e. the cluster itself is /data/postgresql11.4/data) fully configured an running fine. I want to move it "cold" (i.e. when it is shutdown) by tar to another host, BUT without the database (due to PII and GDPR relevant data). Between the source and target host there is no network. Of course I could, after moving all the PostgreSQL software (all is below a top level directory /usr/local/sisis-pap/pgsql, compiled by me) and setup the cluster from scratch on the other host, but I wanted to have it all in one shoot by tar. Is there a way to exclude the databases from the move by tar, or by some sophisticated pg_* command? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: How to move a 11.4 cluster to another Linux host, but empty?
Hi Matthias, > On 01. May, 2020, at 10:10, Matthias Apitz wrote: > > > Hello, > > I've a 11.4 cluster on a Linux host with 3 production database, all > below /data/postgresql11.4/ (i.e. the cluster itself is > /data/postgresql11.4/data) fully configured an running fine. I want to > move it "cold" (i.e. when it is shutdown) by tar to another host, BUT > without the database (due to PII and GDPR relevant data). Between the > source and target host there is no network. > > Of course I could, after moving all the PostgreSQL software (all is below a > top > level directory /usr/local/sisis-pap/pgsql, compiled by me) and setup the > cluster from scratch on the other host, but I wanted to have it all in one > shoot by tar. > > Is there a way to exclude the databases from the move by tar, or by some > sophisticated pg_* command? > > Thanks > > matthias you may have a look at the tar man page. tar in Linux has the --exclude=PATTERN option. You may specify the PGDATA directory there. Alternatively you may specify each directory inside the software directory without explicitly specifying subdirectories to include: tar cvf postgresql11.4.tar /data/postgresql11.4/bin /data/postgresql11.4/share ... Also, why do you have the PGDATA directory inside the software home directory? That makes no sense and only leads to problems when updating or, in your case, moving. We use: /data/postgres/xx.x <= with xx.x as PostgreSQL version /data// <= as PGDATA This way, we never have any trouble doing something with the software or database cluster independently from each other. Hope, this helps. Cheers, Paul
Re: How to move a 11.4 cluster to another Linux host, but empty?
Hi Paul, El día viernes, mayo 01, 2020 a las 10:23:37a. m. +0200, Paul Förster escribió: > > you may have a look at the tar man page. tar in Linux has the > --exclude=PATTERN option. I do know the man page(s) of tar ant the --exclude=PATTERN. > You may specify the PGDATA directory there. This is, what I wanted to know: that the cluster can be moved without the PGDATA dir and still works fine. > Also, why do you have the PGDATA directory inside the software home > directory? That makes no sense and only leads to problems when updating or, > in your case, moving. > I don't. The software is below /usr/local/sisis-pap/pgsql and the cluster is below /data/postgres11.4/data. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: How to move a 11.4 cluster to another Linux host, but empty?
Hi Matthias, > On 01. May, 2020, at 10:31, Matthias Apitz wrote: > > I don't. The software is below > > /usr/local/sisis-pap/pgsql > > and the cluster is below > > /data/postgres11.4/data. in this case, all you'd have to do is: tar cvf software.tar /usr/local/sisis-pap/pgsql to only copy the software. You don't even need to stop the database cluster for this because nothing is ever changed inside the software tree by a running database cluster. Changes are only done in PGDATA. Cheers, Paul
Re: pg_stat_statements : how to catch non successfully finished statements ?
Tom Lane-2 wrote > legrand legrand < > legrand_legrand@ > > writes: >> Tom Lane-2 wrote >>> The hard part here is that you have to be really careful what you do in >>> a PG_CATCH block, because the only thing you know for sure about the >>> backend's state is that it's not good. Catalog fetches are right out, >>> and anything that might itself throw an error had best be avoided as >>> well. (Which, among other things, means that examining executor state >>> would be a bad idea, and I'm not even sure you'd want to traverse the >>> plan >>> tree.) >>> I'm not convinced that it's practical for pg_stat_statements to make a >>> new >>> shared hashtable entry under those constraints. But figuring out how to >>> minimize the risks around that is the stumbling block, not lack of a >>> hook. > >> As far as I have been testing this with *cancelled* queries (Cancel, >> pg_cancel_backend(), statement_timeout, ...), I haven't found any >> problem. >> Would limiting the PG_CATCH block to thoses *cancelled* queries >> and *no other error*, be an alternate solution ? > > I do not see that that would make one iota of difference to the risk that > the executor state tree is inconsistent at the instant the error is > thrown. You can't test your way to the conclusion that it's safe, either > (much less that it'd remain safe); your test cases surely haven't hit > every CHECK_FOR_INTERRUPTS call in the backend. > > regards, tom lane new try: Considering that executor state tree is limited to QueryDesc->estate, that would mean that rows processed can not be trusted, but that queryid, buffers and *duration* (that is the more important one) can still be used ? Knowing that shared hashtable entries are now (in pg13) created during planning time. There is no need to create a new one for execution error: just update counters (current ones or new columns like "errors" , "total_error_time", ... added to pg_stat_statements view). Is that better ? Regards PAscal -- Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
How to use pg_waldump?
Im using pgBackRest for incremental backups which, as far as I understand, use the WAL. These backups are relatively large, so I wanted to take a look at my WAL. I understand pg_waldump is the tool for this. However, I struggle with its usage. The --help output suggests all command line parameters are optional, but running it like that yields "pg_waldump: no arguments specified". So I tried "pg_waldump -z" which yields "pg_waldump: FATAL: could not find any WAL file". Ok, so apparently it doesn't know the location of the WAL files. I then tried "pg_waldump -p /var/lib/postgresql/11/main/pg_wal". Now I get "pg_waldump: no start WAL location given". And this is where I'm stuck. I don't know any WAL location. I don't even know how far back my WAL goes, that's one thing I want to find out, among other things. On https://www.postgresql.org/docs/11/pgwaldump.html it says about "--start": > WAL location at which to start reading. The default is to start reading the first valid log record found in the earliest file found. If that's the default, why does it ask me for a WAL location? What do I need to do?
Re: How to use pg_waldump?
Hi André, > On 01. May, 2020, at 12:47, André Hänsel wrote: > > I知 using pgBackRest for incremental backups which, as far as I understand, > use the WAL. These backups are relatively large, so I wanted to take a look > at my WAL. I understand pg_waldump is the tool for this. > > However, I struggle with its usage. > > The --help output suggests all command line parameters are optional, but > running it like that yields "pg_waldump: no arguments specified". So I tried > "pg_waldump -z" which yields "pg_waldump: FATAL: could not find any WAL > file". Ok, so apparently it doesn't know the location of the WAL files. I > then tried "pg_waldump -p /var/lib/postgresql/11/main/pg_wal". > > Now I get "pg_waldump: no start WAL location given". And this is where I'm > stuck. I don't know any WAL location. I don't even know how far back my WAL > goes, that's one thing I want to find out, among other things. > > On https://www.postgresql.org/docs/11/pgwaldump.html it says about > "--start": >> WAL location at which to start reading. The default is to start reading > the first valid log record found in the earliest file found. > > If that's the default, why does it ask me for a WAL location? > > What do I need to do? try: pg_waldump -p /var/lib/postgresql/11/main/pg_wal [] where is the name of the WAL file to start and (optionally) is the WAL file to stop. It reads and shows all information of the WAL files in this range. Hope, this helps. Cheers, Paul
RE: How to use pg_waldump?
Paul Förster wrote: > try: > > pg_waldump -p /var/lib/postgresql/11/main/pg_wal [] > > where is the name of the WAL file to start and (optionally) > is the WAL file to stop. It reads and shows all information of the > WAL files in this range. Picking a random WAL file and running the command gives me: pg_waldump: FATAL: could not find a valid record after 2F/6C00
Re: How to use pg_waldump?
Hi André, > On 01. May, 2020, at 14:33, André Hänsel wrote: > > Picking a random WAL file and running the command gives me: > > pg_waldump: FATAL: could not find a valid record after 2F/6C00 maybe try with another WAL file or files? Works for me... postgres@weasel:~$ pg_waldump -p /data/wal 004F000B0072 004F000B0074 rmgr: XLOGlen (rec/tot):114/ 114, tx: 0, lsn: B/E428, prev B/E20001C0, desc: CHECKPOINT_SHUTDOWN redo B/E428; tli 79; prev tli 79; fpw true; xid 0:6641; oid 37940; multi 1; offset 0; oldest xid 561 in DB 16400; oldest multi 1 in DB 16401; oldest/newest commit timestamp xid: 0/0; oldest running xid 0; shutdown rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E4A0, prev B/E428, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E4D8, prev B/E4A0, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: XLOGlen (rec/tot):114/ 114, tx: 0, lsn: B/E4000110, prev B/E4D8, desc: CHECKPOINT_ONLINE redo B/E4D8; tli 79; prev tli 79; fpw true; xid 0:6641; oid 37940; multi 1; offset 0; oldest xid 561 in DB 16400; oldest multi 1 in DB 16401; oldest/newest commit timestamp xid: 0/0; oldest running xid 6641; online rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E4000188, prev B/E4000110, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: XLOGlen (rec/tot): 24/24, tx: 0, lsn: B/E40001C0, prev B/E4000188, desc: SWITCH rmgr: XLOGlen (rec/tot):114/ 114, tx: 0, lsn: B/E628, prev B/E40001C0, desc: CHECKPOINT_SHUTDOWN redo B/E628; tli 79; prev tli 79; fpw true; xid 0:6641; oid 37940; multi 1; offset 0; oldest xid 561 in DB 16400; oldest multi 1 in DB 16401; oldest/newest commit timestamp xid: 0/0; oldest running xid 0; shutdown rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E6A0, prev B/E628, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E6D8, prev B/E6A0, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: XLOGlen (rec/tot):114/ 114, tx: 0, lsn: B/E6000110, prev B/E6D8, desc: CHECKPOINT_ONLINE redo B/E6D8; tli 79; prev tli 79; fpw true; xid 0:6641; oid 37940; multi 1; offset 0; oldest xid 561 in DB 16400; oldest multi 1 in DB 16401; oldest/newest commit timestamp xid: 0/0; oldest running xid 6641; online rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E6000188, prev B/E6000110, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: XLOGlen (rec/tot): 24/24, tx: 0, lsn: B/E60001C0, prev B/E6000188, desc: SWITCH rmgr: XLOGlen (rec/tot):114/ 114, tx: 0, lsn: B/E828, prev B/E60001C0, desc: CHECKPOINT_SHUTDOWN redo B/E828; tli 79; prev tli 79; fpw true; xid 0:6641; oid 37940; multi 1; offset 0; oldest xid 561 in DB 16400; oldest multi 1 in DB 16401; oldest/newest commit timestamp xid: 0/0; oldest running xid 0; shutdown rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E8A0, prev B/E828, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E8D8, prev B/E8A0, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: XLOGlen (rec/tot):114/ 114, tx: 0, lsn: B/E8000110, prev B/E8D8, desc: CHECKPOINT_ONLINE redo B/E8D8; tli 79; prev tli 79; fpw true; xid 0:6641; oid 37940; multi 1; offset 0; oldest xid 561 in DB 16400; oldest multi 1 in DB 16401; oldest/newest commit timestamp xid: 0/0; oldest running xid 6641; online rmgr: Standby len (rec/tot): 50/50, tx: 0, lsn: B/E8000188, prev B/E8000110, desc: RUNNING_XACTS nextXid 6641 latestCompletedXid 6640 oldestRunningXid 6641 rmgr: XLOGlen (rec/tot): 24/24, tx: 0, lsn: B/E80001C0, prev B/E8000188, desc: SWITCH Cheers, Paul
RE: How to use pg_waldump?
Paul Förster wrote: > maybe try with another WAL file or files? > > Works for me... Ok, I tried it with all the files in the pg_wal directory and it worked with one: the first one (lexicographically/hex).
Re: How to use pg_waldump?
Hi André, > On 01. May, 2020, at 15:46, André Hänsel wrote: > > Ok, I tried it with all the files in the pg_wal directory and it worked with > one: the first one (lexicographically/hex). strange. Bug? I don't know. What is your PostgreSQL version? Mine is 12.2 compiled from source on the machine it runs on. Cheers, Paul
RE: How to use pg_waldump?
Paul Förster wrote: > strange. Bug? I don't know. > > What is your PostgreSQL version? Mine is 12.2 compiled from source on the > machine it runs on. 11.7-2.pgdg18
Re: How to use pg_waldump?
Hi André, > On 01. May, 2020, at 16:03, André Hänsel wrote: > > 11.7-2.pgdg18 is this Ubuntu? A pre-packaged version? I use openSUSE as a dedicated server and, as said, compiled on that machine. Did you try an 11.7 compiled from source on that machine? I always recommend this. :-) Cheers, Paul
Re: Pgbackrest restore options
On 4/17/20 2:38 AM, Konireddy Rajashekar wrote: Doubt regarding the backrest restore options, is there any way to ensure the backups are good as expected, instead of restoring the whole cluster or database is there any other possibility to ensure it by restoring a single file? or any other such mechanism Currently there is no command to verify a backup without restoring it. However, we are planning a verify command in the near future -- most likely within the next few releases. Regards, -- -David da...@pgmasters.net
Checking for Presence of Required Libraries Fails during PostgreSQL Upgrade
I'm trying to upgrade my PostgreSQL form 10.2 to 11.7 (and eventually to 12.x), when I run: /usr/pgsql-11/bin/pg_upgrade --old-bindir=/usr/pgsql-10/bin/ --new-bindir=/usr/pgsql-11/bin/ --old-datadir=/var/lib/pgsql/10/data --new-datadir=/var/lib/pgsql/11/data --check I get: Checking for presence of required libraries fatal Your installation references loadable libraries that are missing from the new installation. You can add these libraries to the new installation, or remove the functions using them from the old installation. A list of problem libraries is in the file: loadable_libraries.txt" my loadable_libraries.txt file shows: could not load library "myfunc": ERROR: could not access file "myfunc": No such file or directory could not load library "randomness": ERROR: could not access file "randomness": No such file or directory could not load library "seal_diff_cpp": ERROR: could not access file "seal_diff_cpp": No such file or directory could not load library "seal_mean_cxx": ERROR: could not access file "seal_mean_cxx": No such file or directory could not load library "seal_mean_cxx_v2": ERROR: could not access file "seal_mean_cxx_v2": No such file or directory could not load library "seal_variance_cxx": ERROR: could not access file "seal_variance_cxx": No such file or directory could not load library "seal_diff_benchmark": ERROR: could not access file "seal_diff_benchmark": No such file or Directory Running: SELECT proname, probin, pronamespace FROM pg_proc WHERE probin IS NOT NULL AND pronamespace = 2200 Results in: | proname | probin | pronamespace | bytea_size| randomness | 2200 | sum_of_numbers | myfunc | 2200 | seal_diff_cpp| seal_diff_cpp | 2200 | seal_mean_cxx_v2| seal_mean_cxx_v2| 2200 | seal_variance_cxx | seal_variance_cxx | 2200 | seal_diff_benchmark | seal_diff_benchmark | 2200 | seal_mean_cxx | seal_mean_cxx | 2200 All the 7 problematic libraries (.so) are manually created c extension functions. I can't just move them to /usr/pgsql-11/lib/ because they we compiled with PostgresSQL10 and not 11. How can I resolve this issue? How can I delete them properly if porting them to 11 is a painful process? Deleting them directly form /usr/pgsql-10/lib/ doesn't help. -- Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Re: Checking for Presence of Required Libraries Fails during PostgreSQL Upgrade
On 5/1/20 3:03 PM, TalGloz wrote: I'm trying to upgrade my PostgreSQL form 10.2 to 11.7 (and eventually to 12.x), when I run: /usr/pgsql-11/bin/pg_upgrade --old-bindir=/usr/pgsql-10/bin/ --new-bindir=/usr/pgsql-11/bin/ --old-datadir=/var/lib/pgsql/10/data --new-datadir=/var/lib/pgsql/11/data --check I get: Checking for presence of required libraries fatal Your installation references loadable libraries that are missing from the new installation. You can add these libraries to the new installation, or remove the functions using them from the old installation. A list of problem libraries is in the file: loadable_libraries.txt" my loadable_libraries.txt file shows: could not load library "myfunc": ERROR: could not access file "myfunc": No such file or directory could not load library "randomness": ERROR: could not access file "randomness": No such file or directory could not load library "seal_diff_cpp": ERROR: could not access file "seal_diff_cpp": No such file or directory could not load library "seal_mean_cxx": ERROR: could not access file "seal_mean_cxx": No such file or directory could not load library "seal_mean_cxx_v2": ERROR: could not access file "seal_mean_cxx_v2": No such file or directory could not load library "seal_variance_cxx": ERROR: could not access file "seal_variance_cxx": No such file or directory could not load library "seal_diff_benchmark": ERROR: could not access file "seal_diff_benchmark": No such file or Directory Running: SELECT proname, probin, pronamespace FROM pg_proc WHERE probin IS NOT NULL AND pronamespace = 2200 Results in: | proname | probin | pronamespace | bytea_size| randomness | 2200 | sum_of_numbers | myfunc | 2200 | seal_diff_cpp| seal_diff_cpp | 2200 | seal_mean_cxx_v2| seal_mean_cxx_v2| 2200 | seal_variance_cxx | seal_variance_cxx | 2200 | seal_diff_benchmark | seal_diff_benchmark | 2200 | seal_mean_cxx | seal_mean_cxx | 2200 All the 7 problematic libraries (.so) are manually created c extension functions. I can't just move them to /usr/pgsql-11/lib/ because they we compiled with PostgresSQL10 and not 11. Why not compile them against 11? Then follow step 5) here: https://www.postgresql.org/docs/12/pgupgrade.html How can I resolve this issue? How can I delete them properly if porting them to 11 is a painful process? Deleting them directly form /usr/pgsql-10/lib/ doesn't help. If there are objects in the 10 database that depend on the libraries then I imagine deleting them won't help. -- Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html -- Adrian Klaver adrian.kla...@aklaver.com
Re: Checking for Presence of Required Libraries Fails during PostgreSQL Upgrade
On Fri, May 1, 2020 at 03:03:36PM -0700, TalGloz wrote: > I'm trying to upgrade my PostgreSQL form 10.2 to 11.7 (and eventually to > 12.x), when I run: FYI, you can go from PG 10 to 12 directly, without doing PG 11. --- > > /usr/pgsql-11/bin/pg_upgrade --old-bindir=/usr/pgsql-10/bin/ > --new-bindir=/usr/pgsql-11/bin/ --old-datadir=/var/lib/pgsql/10/data > --new-datadir=/var/lib/pgsql/11/data --check > > I get: > > Checking for presence of required libraries fatal > Your installation references loadable libraries that are missing from the > new installation. You can add these libraries to the new installation, > or remove the functions using them from the old installation. A list of > problem libraries is in the file: > loadable_libraries.txt" > > my loadable_libraries.txt file shows: > > could not load library "myfunc": ERROR: could not access file "myfunc": No > such file or directory > could not load library "randomness": ERROR: could not access file > "randomness": No such file or directory > could not load library "seal_diff_cpp": ERROR: could not access file > "seal_diff_cpp": No such file or directory > could not load library "seal_mean_cxx": ERROR: could not access file > "seal_mean_cxx": No such file or directory > could not load library "seal_mean_cxx_v2": ERROR: could not access file > "seal_mean_cxx_v2": No such file or directory > could not load library "seal_variance_cxx": ERROR: could not access file > "seal_variance_cxx": No such file or directory > could not load library "seal_diff_benchmark": ERROR: could not access file > "seal_diff_benchmark": No such file or Directory > > Running: > SELECT proname, probin, pronamespace > FROM pg_proc > WHERE probin IS NOT NULL AND pronamespace = 2200 > > Results in: > > | proname | probin | pronamespace > | bytea_size| randomness | 2200 > | sum_of_numbers | myfunc | 2200 > | seal_diff_cpp| seal_diff_cpp | 2200 > | seal_mean_cxx_v2| seal_mean_cxx_v2| 2200 > | seal_variance_cxx | seal_variance_cxx | 2200 > | seal_diff_benchmark | seal_diff_benchmark | 2200 > | seal_mean_cxx | seal_mean_cxx | 2200 > > All the 7 problematic libraries (.so) are manually created c extension > functions. I can't just move them to /usr/pgsql-11/lib/ because they we > compiled with PostgresSQL10 and not 11. > > How can I resolve this issue? How can I delete them properly if porting them > to 11 is a painful process? Deleting them directly form /usr/pgsql-10/lib/ > doesn't help. > > > > -- > Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html > > -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Re: Checking for Presence of Required Libraries Fails during PostgreSQL Upgrade
Adrian Klaver-4 wrote > Why not compile them against 11? > > Then follow step 5) here: > > https://www.postgresql.org/docs/12/pgupgrade.html Step 5 doesn’t actually say how to compile them during the upgrade process it just gives a warning about not to use "CREATE EXTENSION my_lib" because this won't effect the target version. Do you mean that I'll have to compile them manually to my target PostgreSQL Version? -- Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Re: Checking for Presence of Required Libraries Fails during PostgreSQL Upgrade
On 5/1/20 3:39 PM, TalGloz wrote: Adrian Klaver-4 wrote Why not compile them against 11? Then follow step 5) here: https://www.postgresql.org/docs/12/pgupgrade.html Step 5 doesn’t actually say how to compile them during the upgrade process it just gives a warning about not to use "CREATE EXTENSION my_lib" because this won't effect the target version. Do you mean that I'll have to compile them manually to my target PostgreSQL Version? You haven't said how you installed the various versions of Postgres in the first place. Bottom line is that the libraries that existed in the old version need to exist on the new version. If they where not included as part of the install process them they need to be manually created/added. -- Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html -- Adrian Klaver adrian.kla...@aklaver.com
Re: How to use pg_waldump?
On 2020-May-01, André Hänsel wrote: > Paul Förster wrote: > > > maybe try with another WAL file or files? > > > > Works for me... > > Ok, I tried it with all the files in the pg_wal directory and it > worked with one: the first one (lexicographically/hex). The other files have not yet been written, so pg_waldump cannot read them. If you can find out what was the name of the file that it had before the recycling, you can rename (a copy of) the file to that, and then pg_waldump will be able to read it. (You can try brute-forcing the search for the correct file name). If you have an archive_command-generated archive of WALs, or pg_receivewal, those files should all be readable by pg_waldump. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
