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
logicaldecoding 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
transactionscommitting 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_REPLICATIONSLOT "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
decodingfound 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
norunning transactions.
2023-09-05 09:58:38.956 UTC 28316 melkij@postgres from [local] [vxid:3/0 txid:0] [START_REPLICATION] STATEMENT:
START_REPLICATIONSLOT "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
createfile "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
ondisk. When the problem with free disk space was solved, the publication remained inoperative. To fix it, one need to
restartthe 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
operationsare 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
upthe virtual disk.
regards, Sergei