RE: automatic restore point

From: "Yotsunaga, Naoki" <yotsunaga(dot)naoki(at)jp(dot)fujitsu(dot)com>
To: Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: automatic restore point
Date: 2018-08-31 08:14:44
Message-ID: 8E9126CB6CE2CD42962059AB0FBF7B0DC2592A@g01jpexmbkw23
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----Original Message-----
From: Yotsunaga, Naoki [mailto:yotsunaga(dot)naoki(at)jp(dot)fujitsu(dot)com]
Sent: Tuesday, June 26, 2018 10:18 AM
To: Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: automatic restore point

Hi, I attached a patch to output the LSN before execution to the server log when executing a specific command and accidentally erasing data.

A detailed background has been presented before.
In short explain: After the DBA's operation failure and erases the data, it is necessary to perform PITR immediately.
Since it is not possible to easily obtain information for doing the current PITR, I would like to solve it.

The specification has changed from the first proposal.
-Target command
DROP TABLE
TRUNCATE

-Setting file
postgresql.conf
log_recovery_points = on #default value is 'off'. When the switch is turned on, LSN is output to the server log when DROP TABLE, TRUNCATE is executed.

-How to use
1) When executing the above command, identify the command and recovery point that matches the resource indicating the operation failure from the server log.
ex) LOG: recovery_point_lsn: 0/201BB70
     STATEMENT: drop table test ;
2) Implement PostgreSQL document '25 .3.4.Recovering Using a Continuous Archive Backup.'
*Set "recovery_target_lsn = 'recovery_point_lsn'" at recovery.conf.

Although there was pointed out that the source becomes complicated in the past, we could add the function by adding about 20 steps.

What do you think about it? Do you think is it useful?
------
Naoki Yotsunaga

Attachment Content-Type Size
automatic_restore_point.patch application/octet-stream 3.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-08-31 08:18:26 Re: CREATE ROUTINE MAPPING
Previous Message Michael Banck 2018-08-31 08:11:07 Re: pg_verify_checksums and -fno-strict-aliasing