пн, 1 мая 2023 г. в 10:33, Michael Paquier <michael@paquier.xyz>:
> So, from what I read, what you basically mean is a sequence like that:
> 1) create unlogged table.
> 2) drop it.
If we talk about the script provided by Egor, the table is being deleted,
because the transaction that tried to create it aborts.
> 3) Stop the server in immediate mode before the next checkpoint has
> the time to finish cleaning up the main fork still lying around. At
> this point the server has the truncated main fork, but not the init
> fork as it has already been removed.
> 4) Restart server, recovery begins.
> 5) ResetUnloggedRelations(UNLOGGED_RELATION_CLEANUP) happens, sees
> only what looks like a main fork, thinks there is nothing to do
> because there is no init fork.
> 6) Begin WAL redo,
> 7) Replay the record that created the init fork.
> 8) Finish recovery.
> 9) ResetUnloggedRelations(UNLOGGED_RELATION_INIT) sees both the init
> fork and the main fork. We would do a copy_dir() from the init file
> to the main fork, that fails on EEXIST.
That's right.
> Between points 7 and 8, there is something I am not really following,
> though. The deletion of all the forks of an unlogged table should be
> replayed as well until we reach consistency, no? At redo, the cleanup
> of the forks is done when the COMMIT record of the transaction that
> dropped the table is replayed, rather than delayed at checkpoint as a
> sync request. Hence, the init fork previously created should not
> exist to begin with, no? Am I missing something?
Recovery replays all the WAL records until the last one present. If the server
was stopped immediately, there could be some records, that represent operations
of the transaction, which commit or abort record wasn't flushed at the moment
of the stop. As I understand, recovery works well for operations on tuples,
since in their headers transaction IDs are stored and it could be figured out
whether given transaction was committed or not. So when we replay for example
insert, tuples are inserted, but they won't be visible, if we don't replay
commit. But the same doesn't work for operations on files. If a file was
created during replay, it's still just a file. In our case, we expect it to
be deleted by abort, but abort record wasn't flushed, so the file is present.
As I see now, the problem of operations on files is more than just about this
particular case. So my fix is not the right solution, and we should rather
consider Kyotaro's patch.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/