On 2018-08-10 22:57:57 +0200, Tomas Vondra wrote:
>
>
> On 08/09/2018 07:47 PM, Alvaro Herrera wrote:
> > On 2018-Aug-09, Tomas Vondra wrote:
> >
> >> I suppose there are reasons why it's done this way, and admittedly the test
> >> that happens to trigger this is a bit extreme (essentially running pgbench
> >> concurrently with 'vacuum full pg_class' in a loop). I'm not sure it's
> >> extreme enough to deem it not an issue, because people using many temporary
> >> tables often deal with bloat by doing frequent vacuum full on catalogs.
> >
> > Actually, it seems to me that ApplyLogicalMappingFile is just leaking
> > the file descriptor for no good reason. There's a different
> > OpenTransientFile call in ReorderBufferRestoreChanges that is not
> > intended to be closed immediately, but the other one seems a plain bug,
> > easy enough to fix.
> >
>
> Indeed. Adding a CloseTransientFile to ApplyLogicalMappingFile solves
> the issue with hitting maxAllocatedDecs. Barring objections I'll commit
> this shortly.
Yea, that's clearly a bug. I've not seen a patch, so I can't quite
formally sign off, but it seems fairly obvious.
> But while running the tests on this machine, I repeatedly got pgbench
> failures like this:
>
> client 2 aborted in command 0 of script 0; ERROR: could not read block
> 3 in file "base/16384/24573": read only 0 of 8192 bytes
>
> That kinda reminds me the issues we're observing on some buildfarm
> machines, I wonder if it's the same thing.
Oooh, that's interesting! What's the precise recipe that gets you there?
Greetings,
Andres Freund
