whether to unlink the existing state.tmp file in SaveSlotToPath

Sergei Kornilov <sk@zsrv.org>

From: Sergei Kornilov <sk@zsrv.org>

To: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>

Date: 2023-09-05T10:38:46Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Remove state.tmp when failing to save a replication slot
- c878d9808420 13.23 landed
- f57f2760e665 14.20 landed
- 0adf424b490b 15.15 landed
- bfdd1a12d2d9 16.11 landed
- 42348839d8b7 17.7 landed
- 9a6ea00ac8c0 18.1 landed
- 912af1c7e9c9 19 (unreleased) landed

Hello
I encountered a very lucky logical decoding error on the publisher:

2023-09-05 09:58:38.955 UTC 28316 melkij@postgres from [local] [vxid:3/0 txid:0] [START_REPLICATION] LOG:  starting logical decoding for slot "pubsub"
2023-09-05 09:58:38.955 UTC 28316 melkij@postgres from [local] [vxid:3/0 txid:0] [START_REPLICATION] DETAIL:  Streaming transactions committing after 0/16AD5F8, reading WAL from 0/16AD5F8.
2023-09-05 09:58:38.955 UTC 28316 melkij@postgres from [local] [vxid:3/0 txid:0] [START_REPLICATION] STATEMENT:  START_REPLICATION SLOT "pubsub" LOGICAL 0/16AD5F8 (proto_version '4', origin 'any', publication_names '"testpub"')
2023-09-05 09:58:38.956 UTC 28316 melkij@postgres from [local] [vxid:3/0 txid:0] [START_REPLICATION] LOG:  logical decoding found consistent point at 0/16AD5F8
2023-09-05 09:58:38.956 UTC 28316 melkij@postgres from [local] [vxid:3/0 txid:0] [START_REPLICATION] DETAIL:  There are no running transactions.
2023-09-05 09:58:38.956 UTC 28316 melkij@postgres from [local] [vxid:3/0 txid:0] [START_REPLICATION] STATEMENT:  START_REPLICATION SLOT "pubsub" LOGICAL 0/16AD5F8 (proto_version '4', origin 'any', publication_names '"testpub"')
2023-09-05 09:58:39.187 UTC 28316 melkij@postgres from [local] [vxid:3/0 txid:0] [START_REPLICATION] ERROR:  could not create file "pg_replslot/pubsub/state.tmp": File exists

As I found out, the disk with the database ran out of space, but it was so lucky that postgresql did not go into crash recovery. Doubly lucky that logical walsender was able to create state.tmp, but could not write the contents and got "ERROR: could not write to file "pg_replslot/pubsub/state.tmp": No space left on device". The empty state.tmp remained on disk. When the problem with free disk space was solved, the publication remained inoperative. To fix it, one need to restart the database (RestoreSlotFromDisk always deletes state.tmp) or delete state.tmp manually.

Maybe in SaveSlotToPath (src/backend/replication/slot.c) it's also worth deleting state.tmp if it already exists? All operations are performed under LWLock and there should be no parallel access.

PS: I reproduced the error on HEAD by adding pg_usleep to SaveSlotToPath before writing to file. At this time, I filled up the virtual disk.

regards, Sergei