On 2018-09-11 12:26:44 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-09-11 12:18:59 -0400, Tom Lane wrote:
> >> Doesn't matter: startup would hit a lock conflict and cancel the pg_dump
> >> to get out of it, long before approaching locktable full.
>
> > Only if all that's happening in the same database, which is far from a
> > given.
>
> Well, there remains the fact that we've seen no field reports that seem
> to trace to failure-to-acquire-AEL since 9.6 came out. So arguing that
> this *could* be a probable scenario fails to comport with the available
> evidence.
True. But it seems like it'd be really hard to actually encounter any
problems due to the failing lock, especially in a way that is visible
enough to be reported. In most cases the missing AEL will let things
just continue to operate as normal, and in some cases you'll get errors
about not being able to access files. I have *zero* trust that we'd
actually see this kind of error reported.
It might even be that we've seen reports of this, but didn't attribute
the errors correctly. There were a few reports about standbys having
corruptly replayed truncations - and a truncation that happens
concurrently to buffer accesses (due to the missing AEL) could
e.g. explain that, by later then re-enlarging the relations due to a
non-purged dirty block.
> My inclination is to fix it as I've suggested and wait to see if there
> are field complaints before expending a whole lot of effort to create
> a better solution. In any case, I am not willing to create that better
> solution myself, and neither is Robert; are you?
On master I'd be ok with that, but on the backbranches that seems like
playing with user's setups.
Greetings,
Andres Freund