From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "pg_ctl: the PID file ... is empty" at end of make check |
Date: | 2018-11-28 14:30:21 |
Message-ID: | 32439.1543415421@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Wed, Nov 28, 2018 at 6:47 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Is it possible that unlink() on APFS is not atomic?
> I think you might be right.
> https://github.com/macdice/unlinktest
Bleah. But you can do better than ask whether it's a bug: you can
quote POSIX:
The unlink() function shall remove a link to a file. If path names a
symbolic link, unlink() shall remove the symbolic link named by path
and shall not affect any file or directory named by the contents of
the symbolic link. Otherwise, unlink() shall remove the link named by
the pathname pointed to by path and shall decrement the link count of
the file referenced by the link.
When the file's link count becomes 0 and no process has the file open,
the space occupied by the file shall be freed and the file shall no
longer be accessible. If one or more processes have the file open when
the last link is removed, the link shall be removed before unlink()
returns, but the removal of the file contents shall be postponed until
all references to the file are closed.
Not a lot of wiggle room there.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2018-11-28 14:31:57 | Re: Unnecessary asterisk in comment in postgres_fdw.c |
Previous Message | Konstantin Knizhnik | 2018-11-28 14:08:06 | Re: VOPS-2.0 |