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
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
> and can't
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://blog.hagan
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.
>
> Also. In future how do i
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 for PITR
Hi,
Thanks for the quick response.
Regarding your questions,
*Why did you do that?*
This is our requirement and we are restoring this on another
instance(destination instance) where are the 'max_connection' value should
be less than that of the source instance(150 in our case).
On Fri, Aug 4, 2023
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 wa
On 1/9/23 11:23, Torsten Förtsch wrote:
On Mon, Jan 9, 2023 at 10:59 AM Adrien Nayrat
mailto:[email protected]>> 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 th
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_current() WHERE
(pg_last_committed_x
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
Many thanks for the explanation, Tom and Greg. That all makes sense.
Cheers
Huan
There actually is a third backstop if no other session ever connects to
that temp schema and cleans them out.
Eventually autovacuum notices that they would need a vacuum "to prevent
wraparound". It can't actually did the vacuum on temp tables but if there's
no session attached to the temp schema i
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 those
> temp table
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 o
From: Huan Ruan
Sent: Wednesday, April 20, 2022 2:18 PM
To: [email protected]
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 that
are vi
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 think there's
no
Hello.I'm not sure which replications issues you have, and I never used
Wall-E before, but I get some issues with PotgreSql 10 and Barman.
Try starting the primary server at first, when it finish to recovery
this should start as primary, if not then go to the postgresql data
directory and rename th
Hi Jeff,
You mean that ? Is this correct ?
hot_stanby = on to be sure it plays WAL and stays in standby mode ?
1. Stop Postgres
2. Restore Local basebackup (untar, un gzip)
3. Create (recovery.conf) standby_mode + hot_standby on (postgresql.conf)
4. Start Postgres
5. Wait to see in log "database
On Thu, Feb 8, 2018 at 5:07 AM, Sébastien Boutté 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 like to resync multiple times my local
> database:
>
19 matches
Mail list logo
