On 2019-May-13, Robert Haas wrote:
> I think I see what Alvaro is talking about, or at least I think I see
> *a* possible problem based on his remarks.
>
> Suppose we create an unlogged table and then crash. The main fork
> makes it to disk, and the init fork does not. Before WAL replay, we
> remove any main forks that have init forks, but because the init fork
> was lost, that does not happen. Recovery recreates the init fork.
> After WAL replay, we try to copy_file() each _init fork to the
> corresponding main fork. That fails, because copy_file() expects to be
> able to create the target file, and here it can't do that because it
> already exists.
... right, that seems to be it.
> If that's the scenario, I'm not sure the smgrimmedsync() call is
> sufficient. Suppose we log_smgrcreate() but then crash before
> smgrimmedsync()... seems like we'd need to do them in the other order,
> or else maybe just pass a flag to copy_file() telling it not to be so
> picky.
Well, if we do modify copy_file and thus we don't think the deletion
step serves any purpose, why not just get rid of the deletion step
entirely?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services