Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tflxE-004xIF-Nw for pgsql-bugs@arkaria.postgresql.org; Wed, 05 Feb 2025 20:25:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tflxD-000eI9-MQ for pgsql-bugs@arkaria.postgresql.org; Wed, 05 Feb 2025 20:24:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tflxD-000eI0-DK for pgsql-bugs@lists.postgresql.org; Wed, 05 Feb 2025 20:24:59 +0000 Received: from seahorse.cherry.relay.mailchannels.net ([23.83.223.161]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tflxA-003NPH-2G for pgsql-bugs@lists.postgresql.org; Wed, 05 Feb 2025 20:24:58 +0000 X-Sender-Id: hostingeremail|x-authuser|david@pgbackrest.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9F37B182C83 for ; Wed, 5 Feb 2025 20:24:55 +0000 (UTC) Received: from uk-fast-smtpout9.hostinger.io (trex-1.trex.outbound.svc.cluster.local [100.119.243.17]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id EC4CB182C08 for ; Wed, 5 Feb 2025 20:24:54 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1738787095; a=rsa-sha256; cv=none; b=o65HqYoW3BlGnP9wIPgtyg95JqtF1Bd6RoMNNONY5HcvH75gvPptiUj3LtdOv9R19RqKCe 0XEY/l4KnzBYV5wqEDbzqFspI0pSOfIuSukuXf9zEigZ/dNUWz1aaufeLrmMY2poH5S0qh XyoK3KwBnFu6mSCpEgbgk/zF7XlyEx2t5ZCmNvZmrnuOZ+S1hOI8lH6wh/uRUESKyOW67D wB6KNkOQXtEpx0aU5CLZfVLH2VjKBN8gWRpeCvyZ9o0a29AYLfqD7buCttTTLHgn16NLIm dlrrfh1GFezzIt1onDxfD1+KgxFevVuzOaG0+5UwzbTsZU/KSiqgPluYnRhWmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1738787095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=26JTsMyYJln1ueW+f43smf/QahI1Hf75osIAdiZlQqM=; b=qNTT3vWdnRf4V3Ex3fgDpf96ebqvJzrRILtdoVURR5ij0FpSNPQUZZLbuDMvJ6/USZRED6 DByjacRSMfmqw40USUKMoAQMV1ODi7yCYKsqMmP22KCXIHO1anhAFAGfNzniV29RU1p/RZ 3A4RRp2BUIay4KAqxIAH75IzBWyLhX3KC2xTjANVbjdZak/24NdlQ9z+luoEEVS2chUuq6 CG0KbIlN4CHHGKVQ0Ct123RNdlDCR51zra7uzyEMzdKnF2tPEuuQa6yh8ekrPxrgCvGwTw YnyFgvlus1UMUrBbcl/Wq29T1aQEv/nzUMBdEFsgIrs+Eh37Bnh5qhRO8wWZAg== ARC-Authentication-Results: i=1; rspamd-854f7f575d-hc7pr; auth=pass smtp.auth=hostingeremail smtp.mailfrom=david@pgbackrest.org X-Sender-Id: hostingeremail|x-authuser|david@pgbackrest.org X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authuser|david@pgbackrest.org X-MailChannels-Auth-Id: hostingeremail X-Slimy-Abiding: 0e7dc5156b0c36be_1738787095441_3835928514 X-MC-Loop-Signature: 1738787095441:3849745441 X-MC-Ingress-Time: 1738787095440 Received: from uk-fast-smtpout9.hostinger.io (uk-fast-smtpout9.hostinger.io [31.220.23.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.119.243.17 (trex/7.0.2); Wed, 05 Feb 2025 20:24:55 +0000 Message-ID: <43f0c3df-a23c-4159-9610-934d3dceb80c@pgbackrest.org> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgbackrest.org; s=hostingermail1; t=1738787093; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=26JTsMyYJln1ueW+f43smf/QahI1Hf75osIAdiZlQqM=; b=S6kMY5gFrEjMUtGlntlJAYN1YI+X+MyvXyTDPEd1VBAskrQzPyd/YNgNXKkImnPuaxxf7y RKSa37uvX+2DTOcrYV01fJ+Ij2LaQLTW9uZ+8NLe+OBQatEus0lsYgDTEGL8R6cxfGrQs0 2sxXFvzieCAe++taP8ebylPLCEO3584CoEeP7VUNNocqmbRANWwOPUlLbo9S/7xY2qzVjk 1wSsRgkfU3LlSijcQeSIfNjrrwNDehkv4520hnIqBF4p6wc0lQ8DxYDIlD/Q9J8z3o1wdV pjGv3BCa2PZ2EhLXK/qUP+oe4CFfkERtTO0dk0Os6fttRjBtbs91kZEZ8XnhfA== MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "pgsql-bugs@lists.postgresql.org" From: David Steele Subject: Bug in recovery of drop database? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 05 Feb 2025 20:24:52 +0000 (UTC) X-CM-Analysis: v=2.4 cv=FNtJxPos c=1 sm=1 tr=0 ts=67a3c915 a=QI4V7O93spudX6nQxgX90Q==:117 a=QI4V7O93spudX6nQxgX90Q==:17 a=IkcTkHD0fZMA:10 a=VWqXDu5GH_ec4yLlCVkA:9 a=QEXdDO2ut3YA:10 X-CM-Envelope: MS4xfJlmtcr3p2QFNMm9tCDAkFao9ReWR57788rkyk1MiYIBAFL4y7NKqOknR1ROPnJ3zz3eBV0UaQS/zlywBM9P07pFVCzlDO4bnPMd8FgCxHmj163//8IJ sXFe3jlxVYA/oAGizvs/Je1TS82LXMHm/2yBwQzkMXnWUTLLsVzcE5oRYoVm1LPShmxy8wQiVfGyt35YkK+RjfUyjy+g8LHaPFQ= X-AuthUser: david@pgbackrest.org List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk It appears that if recovery ends on a drop database command the database is only partially removed -- the files are removed but the entry in pg_database remains, leading to this error: psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL: cannot connect to invalid database "mytest" HINT: Use DROP DATABASE to drop invalid databases. Here's pg_database: $ test/pg/bin/psql postgres -c 'select oid, datname from pg_database order by oid'; oid | datname -------+----------- 1 | template1 4 | template0 5 | postgres 16384 | mytest (4 rows) And the base data dir: $ ls -lah test/data/base total 20K drwx------ 5 dev dialout 4.0K Feb 5 19:31 . drwx------ 19 dev dialout 4.0K Feb 5 19:31 .. drwx------ 2 dev dialout 4.0K Feb 5 19:30 1 drwx------ 2 dev dialout 4.0K Feb 5 19:30 4 drwx------ 2 dev dialout 4.0K Feb 5 19:32 5 Here is a full repro: test/pg/bin/pg_basebackup -c fast -X none -D test/backup/full -F plain test/pg/bin/createdb mytest test/pg/bin/psql mytest -t -c 'select now()' 2025-02-05 19:18:26.245167+00 test/pg/bin/dropdb mytest test/pg/bin/psql mytest psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL: database "mytest" does not exist test/pg/bin/pg_ctl -D test/data -w stop rm -rf test/data cp -rp test/backup/full test/data touch test/data/recovery.signal echo "restore_command = 'cp /home/dev/test/archive/%f %p'" >> test/data/postgresql.auto.conf echo "recovery_target_time = '2025-02-05 19:18:26.245167+00'" >> test/data/postgresql.auto.conf test/pg/bin/pg_ctl -D test/data -w start test/pg/bin/psql mytest -c 'select count(*) from pgbench_accounts' psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL: cannot connect to invalid database "mytest" HINT: Use DROP DATABASE to drop invalid databases. However, if I insert this command before the drop database: test/pg/bin/psql mytest -c 'create table test (id int)' Then recovery works fine since it is able to stop before the the drop database. This is an issue on HEAD as well as all current back branches. For completeness here is my configuration on this test system (though I have seen this issue in a variety of environments): wal_level = replica archive_mode = on archive_command = 'cp %p /home/dev/test/archive/%f' log_min_messages = debug1 max_wal_senders = 10 log_line_prefix = '%m %L ' autovacuum = off We have seen this several times now because a favorite test for users is to drop a database and see if they can recover it with PITR. PITR in a test database is always a bit dicey since little/no WAL activity means recovery doesn't have much to go on RE recovery targets, but at the least the database should be fully there or fully not there. Regards, -David