Re: thinko in basic_archive.c

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: thinko in basic_archive.c
Date: 2022-10-17 02:44:40
Message-ID: Y0zBmKQjuWJN5WIp@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 15, 2022 at 02:10:26PM -0700, Nathan Bossart wrote:
> On Sat, Oct 15, 2022 at 10:19:05AM +0530, Bharath Rupireddy wrote:
>> Can you please help me understand how name collisions can happen with
>> temp file names including WAL file name, timestamp to millisecond
>> scale, and PID? Having the timestamp is enough to provide a non-unique
>> temp file name when PID wraparound occurs, right? Am I missing
>> something here?
>
> Outside of contrived cases involving multiple servers, inaccurate clocks,
> PID reuse, etc., it seems unlikely.

With a name based on a PID in a world where pid_max can be larger than
the default and a timestamp, I would say even more unlikely than what
you are implying with unlikely ;p

> I think the right way to do this would be to add handling for leftover
> files in the sigsetjmp() block and a shutdown callback (which just sets up
> a before_shmem_exit callback). While this should ensure those files are
> cleaned up after an ERROR or FATAL, crashes and unlink() failures could
> still leave files behind. We'd probably also need to avoid cleaning up the
> temp file if copy_file() fails because it already exists, as we won't know
> if it's actually ours. Overall, I suspect it'd be more trouble than it's
> worth.

Agreed. My opinion is that we should keep basic_archive as
minimalistic as we can: short still useful. It does not have to be
perfect, just to fit with what we want it to show, as a reference.

Anyway, the maths were wrong, so I have applied the patch of upthread,
with an extra pair of parenthesis, a comment where epoch is declared
to tell that it is in milliseconds, and a comment in basic_archive's
Makefile to mention the reason why we have NO_INSTALLCHECK.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2022-10-17 02:47:43 Re: Unnecessary lateral dependencies implied by PHVs
Previous Message Michael Paquier 2022-10-17 02:41:39 Re: [PATCH] comment fixes for delayChkptFlags