Andrew Dunstan <and...@dunslane.net> writes:
> On 07/26/2015 11:00 AM, Andres Freund wrote:
>> On 2015-07-26 10:56:05 -0400, Tom Lane wrote:
>>> I'm inclined to reduce the WARNING to LOG
>> Hm, that doesn't seem like a very nice solution, given that LOG is even
>> more likely to end up in the server log.
>>> and/or skip it altogether if the error is ESRCH.
>> Combined with a comment why we're ignoring that case that'd work for me.
> +1 for this. if the process is gone we shouldn't really have a problem,
> should we?
The only real reason for printing anything here is the possibility that
the shared lock table is sufficiently corrupted that we think there's
an autovacuum process blocking us when there isn't. However, I don't
see any particular reason to think that this is more probable than any
other bad consequence of corrupted shmem, so I don't feel a need to be
in the user's face with a WARNING. The evidence so far is that the
race condition is real, but I don't recall anyone ever reporting this
in a context where we'd suspect actual shmem corruption.
I do, however, think it might be reasonable to LOG the failure given
that we LOG'd the action. Is nobody else on board with downgrading
both ereports to DEBUG?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
