Re: PITR

On Wed, Feb 14, 2024 at 1:39 PM Yongye Serkfem wrote: > I checked the Postgresql.conf file and can't find the > appropriate parameter to set the target time. > It is set inside the postgresql.conf file. Unless you have modified it, there is a section in there called "Recovery Target" which has

Re: PITR

On Wed, Feb 14, 2024 at 1:39 PM Yongye Serkfem wrote: > Hi, > I hope you are all doing well. I am trying to do PITR on Postgresql v12. > Now that the recovery.conf file is not available in this version, where > should I set the recovery_target_time? I checked the Postgresql.conf file

PITR

Hi, I hope you are all doing well. I am trying to do PITR on Postgresql v12. Now that the recovery.conf file is not available in this version, where should I set the recovery_target_time? I checked the Postgresql.conf file and can't find the appropriate parameter to set the target time. I'm

Re: PITR

Am 22.11.23 um 11:50 schrieb Ron Johnson: On Wed, Nov 22, 2023 at 3:12 AM Rajesh Kumar wrote: How do I do PITR. Backup strategy is weekly full backup and daily differential backup. Using pgbackrest. Also. In future how do i monitor time of drop commands. https

Re: PITR

On Wed, Nov 22, 2023 at 3:12 AM Rajesh Kumar wrote: > Hi > > A person dropped the table and don't know time of drop. > Revoke his permission to drop tables? > How do I do PITR. Backup strategy is weekly full backup and daily > differential backup. Using pgbackrest. > >

Re: PITR partial timing

Don't write your own PITR.  Use PgBackRest, barman, etc. On 10/16/23 12:08, Rama Krishnan wrote: Hi team, I  m testing PITR 1.if I am doing full recovery what ever the new tables were create will not be appear how to handle it 2. I have given my logs which time log I have to choose

PITR partial timing

Hi team, I m testing PITR 1.if I am doing full recovery what ever the new tables were create will not be appear how to handle it 2. I have given my logs which time log I have to choose for PITR partial recovery 2023-10-16 16:22:35 UTC [16561]: [13-1] user=postgres,db=postgresLOG: statement

Re: PITR based recovery failing due to difference in max_connections

, 2023 at 1:13 PM Ron wrote: > On 8/3/23 23:47, Kalit Inani wrote: > > Hi all, > During PITR based recovery of a postgres instance, we are getting the > following error - > '2023-06-21 23:52:52.232 PDT [24244] FATAL: hot standby is not possible > because max_connections = 150 is

Re: PITR based recovery failing due to difference in max_connections

On 8/3/23 23:47, Kalit Inani wrote: Hi all, During PITR based recovery of a postgres instance, we are getting the following error - '2023-06-21 23:52:52.232 PDT [24244] FATAL:  hot standby is not possible because max_connections = 150 is a lower setting than on the master server (its value

PITR based recovery failing due to difference in max_connections

Hi all, During PITR based recovery of a postgres instance, we are getting the following error - '2023-06-21 23:52:52.232 PDT [24244] FATAL: hot standby is not possible because max_connections = 150 is a lower setting than on the master server (its value was 500)' Here are the steps we

recovery_target_action = shutdown not working on PG11 during PITR restore

Hello! I'm attempting to restore a database (via pgbackrest) on PG11.20 and have the database shutdown when all of the WAL archives have finished applying. In my recovery.conf file I have recovery_target_action = 'shutdown' with an appropriate recovery target time and restore command setup.

Re: PITR and instance without any activity

On 1/9/23 11:23, Torsten Förtsch wrote: On Mon, Jan 9, 2023 at 10:59 AM Adrien Nayrat mailto:adrien.nay...@anayrat.info>> wrote: * We can't perform PITR on a cluster without any activity since 13 * It seems creating restore point doesn't record a timestamp in wal. I have a cr

Re: PITR and instance without any activity

On Mon, Jan 9, 2023 at 10:59 AM Adrien Nayrat wrote: > > * We can't perform PITR on a cluster without any activity since 13 > * It seems creating restore point doesn't record a timestamp in wal. > I have a cron job that runs this every 5 minutes: SELECT txid_cur

Re: PITR and instance without any activity

Hello, I bump this thread up, I hope to have more reaction :) TL;DR: * We can't perform PITR on a cluster without any activity since 13 * It seems creating restore point doesn't record a timestamp in wal. Thanks -- Adrien NAYRAT

PITR and instance without any activity

Hello, I came across a weird problem about PITR with a recovery_target_time and a cluster without any activity. The issue is quite simple, we just try to do a PITR by specifying a recovery_target_time after the backup. The main issue, is that there is no timestamp in the wal

Re: PITR and Temp Tables

Many thanks for the explanation, Tom and Greg. That all makes sense. Cheers Huan

Re: PITR and Temp Tables

gt; Let's say at T0 a database has N session based temp tables. They would > have > > corresponding records in the catalog tables like pg_class and > pg_attribute > > that are visible to other sessions. > > > At T1, I do a PITR to T0. That recovered database should not h

Re: PITR and Temp Tables

Huan Ruan writes: > Let's say at T0 a database has N session based temp tables. They would have > corresponding records in the catalog tables like pg_class and pg_attribute > that are visible to other sessions. > At T1, I do a PITR to T0. That recovered database should not have

Re: PITR and Temp Tables

Hi Patrick Thanks for your reply. > > > My guess is that temp table entries will still be in your catalog until > you do a VACUUM FULL of the pg_class / pg_attribute tables. > > But you should not care about these entries if these tables are vacuumed > at regular intervals. > What I observed in

RE: PITR and Temp Tables

From: Huan Ruan Sent: Wednesday, April 20, 2022 2:18 PM To: pgsql-general@lists.postgresql.org Subject: PITR and Temp Tables Hi All Let's say at T0 a database has N session based temp tables. They would have corresponding records in the catalog tables like pg_class and pg_attribute

PITR and Temp Tables

Hi All Let's say at T0 a database has N session based temp tables. They would have corresponding records in the catalog tables like pg_class and pg_attribute that are visible to other sessions. At T1, I do a PITR to T0. That recovered database should not have those temp tables because

Re: PITR for an only object in postgres

At Thu, 18 Mar 2021 17:12:49 -0400, aslı cokay wrote in > Hi all, > > Is there any way to get for example a table version of 5 minutes ago, or we > should PITR to 5 minutes ago, dump the table and restore with this dump ? If you want to revert the recent changes on the table, I t

PITR for an only object in postgres

Hi all, Is there any way to get for example a table version of 5 minutes ago, or we should PITR to 5 minutes ago, dump the table and restore with this dump ? Thanks.

Re: cannot promote after recovery for PITR

On Mon, Feb 22, 2021 at 3:42 PM Luca Ferrari wrote: > If, instead, I do pg_wal_replay_resume(), the server is promoted (of > course not at the PITR I want). > Am I missing something? Apparently I was missing caffeine and confused the usage of the functions. pg_wal_replay_resume w

cannot promote after recovery for PITR

checked that PGDATA/promote is there. If, instead, I do pg_wal_replay_resume(), the server is promoted (of course not at the PITR I want). Am I missing something? Thanks, Luca

Re: Need help with PITR for PostgreSQL 9.4.5

On Fri, Nov 6, 2020 at 2:34 PM Sri Linux wrote: > Could you please provide me the link to start new questions? > >> >>> Assuming you are using Gmail... https://business.tutsplus.com/tutorials/how-to-compose-and-send-your-first-email-with-gmail--cms-27678 David J.

Re: Need help with PITR for PostgreSQL 9.4.5

David Could you please provide me the link to start new questions? Thanks and Regards Sri On Fri, Nov 6, 2020 at 3:27 PM Sri Linux wrote: > Thank you very much David > > > > On Fri, Nov 6, 2020 at 2:11 PM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Friday, November 6,

Re: Need help with PITR for PostgreSQL 9.4.5

Thank you very much David On Fri, Nov 6, 2020 at 2:11 PM David G. Johnston wrote: > On Friday, November 6, 2020, Sri Linux wrote: > >> Hi All >> >> I have to start Postgres 9.4.5 vacuum for our production environment. Got >> interrupted with the Linux session, is there a way I can monitor if

Re: Need help with PITR for PostgreSQL 9.4.5

On Friday, November 6, 2020, Sri Linux wrote: > Hi All > > I have to start Postgres 9.4.5 vacuum for our production environment. Got > interrupted with the Linux session, is there a way I can monitor if the > vacuum is progressing while I reconnect to the Linux box? > >> >>> Please start new

Re: Need help with PITR for PostgreSQL 9.4.5

Hi All I have to start Postgres 9.4.5 vacuum for our production environment. Got interrupted with the Linux session, is there a way I can monitor if the vacuum is progressing while I reconnect to the Linux box? Thanks Sri On Thu, Jun 25, 2020 at 1:16 PM Sri Linux wrote: > Thanks for your

Re: Need help with PITR for PostgreSQL 9.4.5

Thanks for your support. I will try to restore and provide results shortly without restoring pg_xlog file Regards, Sri On Thu, Jun 25, 2020 at 1:09 PM Stephen Frost wrote: > Greetings, > > * Sri Linux (srilinu...@gmail.com) wrote: > > Please find the method used. Please recommend me if I have

Re: Need help with PITR for PostgreSQL 9.4.5

Greetings, * Sri Linux (srilinu...@gmail.com) wrote: > Please find the method used. Please recommend me if I have done > something wrong... Yes, you are using 'cp' which is *not* recommended for an archive command. > Performing a hot backup using pg_basebackup: > Create a new folder as the

Re: Need help with PITR for PostgreSQL 9.4.5

;LOG: WAL file is from different database >> system: WAL file database system identifier is 6840038030519879233, >> pg_control database system identifier is 6841285371464745049. >> > > You cannot PITR if the WAL doesn’t match the base backup for the cluster > you are try

Re: Need help with PITR for PostgreSQL 9.4.5

different database > system: WAL file database system identifier is 6840038030519879233, > pg_control database system identifier is 6841285371464745049. > You cannot PITR if the WAL doesn’t match the base backup for the cluster you are trying to restore. https://www.postgresql.org/docs/9.

Need help with PITR for PostgreSQL 9.4.5

Hi All, I am trying to do PINT backup and recovery for the standalone database which is not in a cluster. recovery.done is created, after restart database is having errors to start " < 2020-06-22 16:34:08.280 CDT >LOG: starting archive recovery < 2020-06-22 16:34:08.456 CDT >LOG: restored log

Re: Hot and PITR backups in same server

ot standby and PITR in same server the following steps are required: 1. Create base backup using pg_basebackup 2. Create copy of base backup for PITR 3. Start hot standby server using data directory created in p.1 4. Run pg_receiceval as background process to save wal files to backup created in p.

Re: Hot and PITR backups in same server

backups". > >Do I get it right that you want to copy a streaming replication > >standby server's data > directory to perform PITR? > > I want to copy only pg_wal directory contents from this. If so, what you need seems to be pg_receivewal, not a full-fledged server. > Af

Re: Hot and PITR backups in same server

Hi! This is confused or at least confusing. - "max_wal_size" of 5TB is clearly insane. - I don't understand what you mean by "Start backup server for hot standby backups". Do I get it right that you want to copy a streaming replication standby server's data directory to p

Re: Hot and PITR backups in same server

On Sun, 2020-05-17 at 17:41 +0300, Andrus wrote: > How to implement hot standby and PITR recovery possibility in same backup > server. > > Plan is: > > 1. Create base backup using > > pg_basebackup --checkpoint=fast --verbose --progress --write-recovery-conf -D

Hot and PITR backups in same server

Hi! How to implement hot standby and PITR recovery possibility in same backup server. Plan is: 1. Create base backup using pg_basebackup --checkpoint=fast --verbose --progress --write-recovery-conf -D /var/lib/postgresql/12/standby 2. Create backup copy of /var/lib/postgresql/12/standby

Re: Is there any tool that provides Physical Backup plus PITR for a single database ( Not the whole PG instance ) ?

Hello! pg_probackup can do that: https://postgrespro.github.io/pg_probackup/#pbk-partial-restore On 12/15/19 5:32 PM, Abraham, Danny wrote: I assume that this magic does not exist. Am I right ? -- Grigory Smolkin Postgres Professional: http://www.postgrespro.com The Russian Postgres

Re: Is there any tool that provides Physical Backup plus PITR for a single database ( Not the whole PG instance ) ?

cannot add anything to the above. Restoring one db using pgbackrest zeroes out all the other databases. (The inability to do PITR of a single database is a serious flaw in Postgres, but I don't think it can be solved.) -- Angular momentum makes the world go 'round.

Re: Is there any tool that provides Physical Backup plus PITR for a single database ( Not the whole PG instance ) ?

On 12/15/19 6:33 AM, Abraham, Danny wrote: I assume that this magic does not exist. Am I right ? Take a look at: https://pgbackrest.org/user-guide.html#restore/option-db-include and see it that meets your needs. I have never actually done it so I cannot add anything to the above. Thanks

Is there any tool that provides Physical Backup plus PITR for a single database ( Not the whole PG instance ) ?

I assume that this magic does not exist. Am I right ? Thanks Danny

Is there any tool that provides Physical Backup plus PITR for a single database ( Not the whole PG instance ) ?

I assume that this magic does not exist. Am I right ?

RE: Postgres Point in time Recovery (PITR),

sage- From: Andreas Kretschmer Sent: Friday, October 18, 2019 12:38 PM To: pgsql-general@lists.postgresql.org; Daulat Ram ; pgsql-general@lists.postgresql.org Subject: Re: Postgres Point in time Recovery (PITR), On 18 October 2019 07:59:21 CEST, Daulat Ram wrote: >Hello All, >Ca

Re: Postgres Point in time Recovery (PITR),

Hi > On 22/10/2019, at 4:14 AM, Adrian Klaver wrote: > > On 10/21/19 8:10 AM, Avinash Kumar wrote: >> Hi, >> On Mon, Oct 21, 2019 at 8:16 PM Alan Hodgson > > wrote: >>On Mon, 2019-10-21 at 16:40 +0530, Avinash Kumar wrote: >>> >>>We need to ensure that

Re: Postgres Point in time Recovery (PITR),

On Mon, Oct 21, 2019 at 8:47 PM Alan Hodgson wrote: > On Mon, 2019-10-21 at 20:40 +0530, Avinash Kumar wrote: > > can't he destroy the offline backups and your database ? > This is not a right justification to encouraging Offline Backups over > Online Backups. > If you are worried about storing

Re: Postgres Point in time Recovery (PITR),

On Mon, 2019-10-21 at 20:40 +0530, Avinash Kumar wrote: > can't he destroy the offline backups and your database ? > This is not a right justification to encouraging Offline Backups over > Online Backups. > If you are worried about storing your online backups through internet > on cloud (i do

Re: Postgres Point in time Recovery (PITR),

On 10/21/19 8:10 AM, Avinash Kumar wrote: Hi, On Mon, Oct 21, 2019 at 8:16 PM Alan Hodgson > wrote: On Mon, 2019-10-21 at 16:40 +0530, Avinash Kumar wrote: We need to ensure that we have safe backup locations, for example, push them to AWS S3 and

Re: Postgres Point in time Recovery (PITR),

Hi, On Mon, Oct 21, 2019 at 8:16 PM Alan Hodgson wrote: > On Mon, 2019-10-21 at 16:40 +0530, Avinash Kumar wrote: > > > We need to ensure that we have safe backup locations, for example, push > them to AWS S3 and forget about redundancy. > Why do you think only Offline Backups are reliable

Re: Postgres Point in time Recovery (PITR),

On Mon, 2019-10-21 at 16:40 +0530, Avinash Kumar wrote: > We need to ensure that we have safe backup locations, for example, > push them to AWS S3 and forget about redundancy. > Why do you think only Offline Backups are reliable today ? There have been examples of hackers gaining control of an

Re: Postgres Point in time Recovery (PITR),

s argument more often than I wish. Offline backups and data replication are nearly entirely orthogonal. Any form of instantaneous redundancy (RAID, instantaneous replication and so on) primary is a mitigation measure to protect data & availability against loss of infrastr

Re: Postgres Point in time Recovery (PITR),

replication are nearly entirely orthogonal. > > Any form of instantaneous redundancy (RAID, instantaneous replication > and so on) primary is a mitigation measure to protect data & > availability against loss of infrastructure. > > > Backups (preferably with PITR) also do th

Re: Postgres Point in time Recovery (PITR),

often than I wish. Offline backups and data replication are nearly entirely orthogonal. Any form of instantaneous redundancy (RAID, instantaneous replication and so on) primary is a mitigation measure to protect data & availability against loss of infrastructure. Backups (preferably with

Re: Postgres Point in time Recovery (PITR),

On Sat, Oct 19, 2019 at 7:46 PM Daulat Ram wrote: > One more questions is, how backups are useful if we have streaming > replication . As I know, we can promote the standby as primary in case of > disaster at primary side. Do we need to schedule backups if we have streaming > replication?

Re: Postgres Point in time Recovery (PITR),

visena.com>; Daulat Ram ; > pgsql-general@lists.postgresql.org > *Subject:* Re: Postgres Point in time Recovery (PITR), > > > > Hi Daulat, > > > > PITR entirely depends on what type of backups you choose. > Sometimes, to reduce the amount of downtime involved while

Re: Postgres Point in time Recovery (PITR),

On Fri, Oct 18, 2019 at 1:59 AM Daulat Ram wrote: > Hello All, > > Can you please share some ideas and scenarios how we can do the PITR in > case of disaster. > It depends on what you mean by "disaster". Usually I think that would mean your server (or entire d

RE: Postgres Point in time Recovery (PITR),

Kumar Sent: Friday, October 18, 2019 5:28 PM To: David Steele Cc: Luca Ferrari ; Andreas Joseph Krogh ; Daulat Ram ; pgsql-general@lists.postgresql.org Subject: Re: Postgres Point in time Recovery (PITR), Hi Daulat, PITR entirely depends on what type of backups you choose. Sometimes, to reduce

Re: Postgres Point in time Recovery (PITR),

Hi Daulat, PITR entirely depends on what type of backups you choose. Sometimes, to reduce the amount of downtime involved while restoring and recovering a backup, you may also use a additional delayed standby. You could use the PG built-in feature to delay the replication and fast-forward

Re: Postgres Point in time Recovery (PITR),

/recovery.conf INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started) INFO: restore command end: completed successfully (5113ms) pgBackRest also has a tutorial on PITR: https://pgbackrest.org/user-guide.html#pitr -- -David da...@pgmasters.net

Re: Postgres Point in time Recovery (PITR),

On Fri, Oct 18, 2019 at 10:30 AM Andreas Joseph Krogh wrote: > We use barman (https://www.pgbarman.org/) for continuous streaming backup and > I had to restore from it once, and it went like this: Just for the records, here's an example of restore with pgbackrest: % sudo -u postgres pgbackrest

Re: Postgres Point in time Recovery (PITR),

On 18 October 2019 07:59:21 CEST, Daulat Ram wrote: >Hello All, >Can you please share some ideas and scenarios how we can do the PITR in >case of disaster. > > >Thanks, Consider Barman. -- 2ndQuadrant - The PostgreSQL Support Company

Sv: Postgres Point in time Recovery (PITR),

På fredag 18. oktober 2019 kl. 07:59:21, skrev Daulat Ram < daulat@exponential.com <mailto:daulat@exponential.com>>: Hello All, Can you please share some ideas and scenarios how we can do the PITR in case of disaster. We use barman (https://www.pgbarman.org/ <https://w

Re: Postgres Point in time Recovery (PITR),

On Fri, Oct 18, 2019 at 7:59 AM Daulat Ram wrote: > Can you please share some ideas and scenarios how we can do the PITR in case > of disaster. In order to be able to do PITR you need: - a base backup of your database - WALs from the backup going on See <https://www.postgresql.or

Postgres Point in time Recovery (PITR),

Hello All, Can you please share some ideas and scenarios how we can do the PITR in case of disaster. Thanks,

Re: PITR based recovery in a primary/standby cluster setup

file. Regards On Tue, 2019-05-21 at 14:27 +0530, Abhijit Gharami wrote: > Hi, > > We have primary and standby PostgreSQL cluster setup and also we have > PITR enabled on it. To improve the recovery time we are thinking of > recovering the database to both primary and standby a

PITR based recovery in a primary/standby cluster setup

Hi, We have primary and standby PostgreSQL cluster setup and also we have PITR enabled on it. To improve the recovery time we are thinking of recovering the database to both primary and standby at the same time. These are the steps we are following: 1. Restore the base backup to the both

Re: Monitoring PITR recovery progress

On Wed, 2019-01-23 at 18:58 +0100, Ivan Voras wrote: > And, the actual question: how to monitor the WAL replay process? > Currently, the recovery.conf file is sitting there, with the database > running, but pg processes are idle, and pg_stat_activity doesn't list > anything which appears to be

Monitoring PITR recovery progress

Hello, I got a sort of POLA violation moment today - a colleague has restored a PITR archive up to a point in time, and when the developers looked at the data, it looked wrong - as it if wasn't from that particular time. Later, he told me he got an error trying to use pg_dump to extract

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

On Thu, 2018-10-11 at 19:53 +0200, Laurenz Albe wrote: > Indeed, your sentence > > > if , for example, it recovered to "A" at "o1", then > > the switched WAL(in case of stop-then-recover) or .partial > > corresponding WAL(in case of promote) is the last WAL of the > > timeline1 > > seems to

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

magodo wrote: > > How can you know how many WAL segments there are on timeline 1, and if > > there is one that extends past 2018-10-11 12:00:00 or not? > > This is the exact problem I want to figure out. My approach is as you said, > I will parse each archived WAL segment via `pg_xlogdump -r

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

magodo wrote: > On Thu, 2018-10-11 at 06:35 +0200, Laurenz Albe wrote: > > magodo wrote: > > > OK... Just take another example: > > > > > > A B > > > BASE-+-+--o1 (recover to > > > A) 1 > > > | | C > > >

parallel PITR for HA setup

Hello, I have a HA setup, a standby following a primary. At beginning, when I do PITR for it, I just recover the primary the first, then remake the standby by doing a basebackup against primary and restart the standby with recovery.conf properly. This works well, however, it takes long time

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

On Thu, 2018-10-11 at 06:35 +0200, Laurenz Albe wrote: > magodo wrote: > > OK... Just take another example: > > > > A B > > BASE-+-+--o1 (recover to > > A) 1 > > | | C > > +.|...+---o2 (regret,

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

magodo wrote: > OK... Just take another example: > > A B > BASE-+-+--o1 (recover to A) 1 > | | C > +.|...+---o2 (regret, recover to B) 2 >| | >

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

On Wed, 2018-10-10 at 18:21 +0200, Laurenz Albe wrote: > magodo wrote: > > > By default, recovery will stay on the timeline where it started. > > > If you want to go to timeline 2 or 3, you have to specify > > > recovery_target_timeline. > > > > > For me, the specified point corresponds to

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

magodo wrote: > > By default, recovery will stay on the timeline where it started. > > If you want to go to timeline 2 or 3, you have to specify > > recovery_target_timeline. > > > For me, the specified point corresponds to timeline 1, because at that > time, the timeline is 1 indeed (when there

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

On Wed, 2018-10-03 at 08:06 +0200, Laurenz Albe wrote: > magodo wrote: > > I read the document about recovery configuration, it says: > > [...] > > > Therefore, suppose I am going to recover to a point of some child > > timeline, to identify the point, I have to specify either > >

Re: pg9.6: PITR paused just after failover, need manual resume

On Wed, 2018-10-10 at 11:24 +0800, magodo wrote: > Hello, > > I'm figuring out how to do PITR on a HA setup for postgres 9.6. I > almost manage to do it, while I faced following issue: > > > [1. create basebackup] > > [2. insert 2 rows] > > on b

pg9.6: PITR paused just after failover, need manual resume

Hello, I'm figuring out how to do PITR on a HA setup for postgres 9.6. I almost manage to do it, while I faced following issue: [1. create basebackup] [2. insert 2 rows] on both primary and standby's pg_xlog 00010005 rmgr: Transaction len (rec/tot): 34/34, tx

Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

magodo wrote: > I read the document about recovery configuration, it says: [...] > Therefore, suppose I am going to recover to a point of some child > timeline, to identify the point, I have to specify either > recovery_target_name or recovery_target_time, and also specify the >

how to identify the timeline of specified recovery_target_time when do multiple PITR

wal history oN: point to do PITR If am at "o3", and I want to recover to "C", if I don't specify timeline ID, then i will ends up with state as "o1". Only if I specify timeline ID as "2", then I can get the state as I expect (as illustrated). Why

Re: Issue with PostgreSQL replication and PITR

Amee Sankhesara - Quipment India wrote: > We have setup replication and PITR on this PostgreSQL server and wal files > for replication and PITR we are storing on the another server which is > shared with primary and secondary server. > > For doing some OS migration activity for

Issue with PostgreSQL replication and PITR

[Quipment Logo] Hello, We have a windows(2016) setup for PostgreSQL(Version 9.6.5). We have setup replication and PITR on this PostgreSQL server and wal files for replication and PITR we are storing on the another server which is shared with primary and secondary server. For doing some OS

Re: Warning of .partial wal file in PITR and Replication Environment

areful as a disabled write caching would cause the data to go to the OS cache on Windows and not directly to disk. > Due to this it has stopped to take backup of PITR > > So we like to know how to clean up the ".partial" file from pg_xlog and run > PITR backup

Re: How to perform PITR when all of the logs won't fit on the drive

On Thu, 2018-03-01 at 17:28 -0500, Tony Sullivan wrote: Hello, I have a situation where something was deleted from a database that shouldn't have been so I am having to take a base backup and perform a point-in-time-recovery. The problem I have is that the decompressed WAL files will not fit on

How to perform PITR when all of the logs won't fit on the drive

Hello, I have a situation where something was deleted from a database that shouldn't have been so I am having to take a base backup and perform a point-in-time-recovery. The problem I have is that the decompressed WAL files will not fit on the drive of the machine I am trying to do the restore

Re: PITR Multiple recoveries

eb 8, 2018 at 5:11 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Thu, Feb 8, 2018 at 5:07 AM, Sébastien Boutté < > sebastien.bou...@gmail.com> wrote: > >> Hi all, >> >> I'm trying to make my server doing PITR backup, i follow the rules on >>

Re: PITR Multiple recoveries

On Thu, Feb 8, 2018 at 5:07 AM, Sébastien Boutté <sebastien.bou...@gmail.com > wrote: > Hi all, > > I'm trying to make my server doing PITR backup, i follow the rules on > https://www.postgresql.org/docs/9.5/static/continuous-archiving.html. > > On my local server, i would

PITR Multiple recoveries

Hi all, I'm trying to make my server doing PITR backup, i follow the rules on https://www.postgresql.org/docs/9.5/static/continuous-archiving.html. On my local server, i would like to resync multiple times my local database: What i'm doing : 1. Stop Postgres 2. Restore Local basebackup (untar