From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: abstract Unix-domain sockets |
Date: | 2020-11-23 13:50:41 |
Message-ID: | 5d2dc07b-1495-ae79-9034-8f45e7e7ca80@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-11-20 18:23, David G. Johnston wrote:
> If there is dead code there is an underlying problem to
> address/discover, not just removing the dead code. In this case are we
> saying that a new server won’t ever fail to start because the socket
> file exists but instead will just clobber the file with its own?
Yes. (In practice, there will be an error with respect to the lock file
before you even get to that question, but that is different code elsewhere.)
> Because given that error, and a server process that failed to clean up
> after itself, the correction to take would indeed seem to be to manually
> remove the file as the hint says. IOW, fix the code, not the message?
I don't understand that.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-11-23 14:41:03 | Re: [PoC] Non-volatile WAL buffer |
Previous Message | Daniil Zakhlystov | 2020-11-23 13:44:51 | Re: libpq compression |