Re: PITR on DROP DATABASE, deleting of the database directory despitethe recovery_target_time set before. - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: PITR on DROP DATABASE, deleting of the database directory despitethe recovery_target_time set before.
Date
Msg-id CAMsr+YGsh46i-muFB3Wm7d900q9Wgr5G+xsKd6h4488zy0_X8g@mail.gmail.com
Whole thread Raw
In response to PITR on DROP DATABASE, deleting of the database directory despite therecovery_target_time set before.  (Nicolas Lutic <n.lutic@loxodata.com>)
Responses Re: PITR on DROP DATABASE, deleting of the database directory despitethe recovery_target_time set before.  (Nicolas Lutic <n.lutic@loxodata.com>)
List pgsql-hackers
On Mon, 18 Nov 2019 at 18:48, Nicolas Lutic <n.lutic@loxodata.com> wrote:
Dear Hackers,

After a drop database

with FORCE?
 
, he tried to recover the data on the last inserted transaction by using the recovery_target_time.
The issue is the database is present in the system catalog but the directory was still deleted.
Here the technical information of the database
version 11
default  postgresql.conf except for this options
    wal_level = replica
    archive_mode = on
    archive_command = 'cp %p /tmp/wal_archive/%f '
    log_statement = 'all'
    log_min_messages = debug5

  
The following method was used 
  • create cluster
  • create database
  • create 1 table 
  • create 1 index on 1 column
  • insert 1 rows
  • backup with pg_base_backup
  • insert 2 rows
autocommit? 
    • drop database
    force?
     
    •     Change recovery behaviour in that case to prevent all xact operation to perform until COMMIT timestamp is checked against recovery_time bound (but it seems to be difficult as state https://www.postgresql.org/message-id/flat/20141125160629.GC21475%40msg.df7cb.de which also identifies the problem and tries to give some solutions.  Maybe another way, as a trivial guess (all apologises) is to buffer immediate xacts until we have the commit for each and apply the whole buffer xact once the timestamp known (and checked agains recovery_target_time value);

    If this only happens when a DB is dropped under load with force, I lean toward just documenting it as a corner case.

    --
     Craig Ringer                   http://www.2ndQuadrant.com/
     2ndQuadrant - PostgreSQL Solutions for the Enterprise

    pgsql-hackers by date:

    Previous
    From: Craig Ringer
    Date:
    Subject: Re: physical slot xmin dependency on logical slot?
    Next
    From: Peter Geoghegan
    Date:
    Subject: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.