Re: pg_rewind just doesn't fsync *anything*?

On Thu, Mar 10, 2016 at 4:43 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> how come that the only comment in pg_rewind about fsyncing is '
> void
> close_target_file(void)
> {
> ...
> /* fsync? */
> }
>
> Isn't that a bit, uh, minimal for a utility that's likely to be used in
> failover scenarios?
>
> I think we might actually be "saved" due to
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2ce439f33
> because pg_rewind appears to leave the cluster in
>
> ControlFile_new.state = DB_IN_ARCHIVE_RECOVERY;
> updateControlFile(&ControlFile_new);

Yep, with minimum recovery target changed as well up to the LSN where
pg_rewind began.

> a state that StartupXLOG will treat as needing recovery:
>
> if (ControlFile->state != DB_SHUTDOWNED &&
> ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY)
> SyncDataDirectory();
>
> but that code went in after pg_rewind, so this certainly can't be an
> intentional save.
> I also don't think it's ok that you need to start the cluster to make it
> safe against a crash?

No, that's not acceptable. One is not obliged to use the rewound data
folder immediately, and my first intuition is that we had better
guarantee that an entry in the file map gets consistent on disk
immediately after being done operating on it. If we get a power loss
after pg_rewind is done we may lose data silently.

> I guess the easiest fix would be to shell out to initdb -s?

What do you mean? I am not sure what initdb has to do with that as we
have no need for it in pg_rewind.
--
Michael