Re: src/test/recovery regression failure on bionic

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: src/test/recovery regression failure on bionic
Date: 2020-01-08 23:22:05
Message-ID: 20200108232205.vegvaao4t672iuy5@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Hi,

On 2020-01-08 17:31:06 -0500, Tom Lane wrote:
> (1) d20703805's test will clearly fall over if there are more than six
> FDs open in the postmaster when set_max_safe_fds is called, because it
> sets max_files_per_process = 26 while set_max_safe_fds requires at
> least 20 usable FDs to be available.

> (4) NetBSD 7.0's cron leaves three extra open FDs in processes that
> it spawns. I have not looked into why, but I have experimentally
> observed this. For example, lsof on a "sleep" launched from cron
> shows
>
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> sleep 7824 tgl cwd VDIR 0,0 512 795201 /home/tgl
> sleep 7824 tgl txt VREG 0,0 10431 1613152 /bin/sleep
> sleep 7824 tgl txt VREG 0,0 1616564 22726 /lib/libc.so.12.193.1
> sleep 7824 tgl txt VREG 0,0 55295 22747 /lib/libgcc_s.so.1.0
> sleep 7824 tgl txt VREG 0,0 187183 22762 /lib/libm.so.0.11
> sleep 7824 tgl txt VREG 0,0 92195 1499524 /libexec/ld.elf_so
> sleep 7824 tgl 0r PIPE 0xfffffe803131eb58 16384
> sleep 7824 tgl 1w PIPE 0xfffffe8007ec4a30 0 ->0xfffffe800cc0d2c0
> sleep 7824 tgl 2w PIPE 0xfffffe8007ec4a30 0 ->0xfffffe800cc0d2c0
> sleep 7824 tgl 7u unknown file system type: 0
> sleep 7824 tgl 8u unknown file system type: 0
> sleep 7824 tgl 9w PIPE 0xfffffe80036c4dc0 0
>
> while of course "sleep" launched by hand has only 0/1/2 open.

Is it worth having the test close superflous FDs? It'd not be hard to do
so via brute force (or even going through /proc/self/fd).

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2020-01-09 00:18:04 Re: src/test/recovery regression failure on bionic
Previous Message Tom Lane 2020-01-08 22:31:06 Re: src/test/recovery regression failure on bionic

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2020-01-08 23:55:37 Re: Recognizing superuser in pg_hba.conf
Previous Message Stephen Frost 2020-01-08 23:09:35 Re: Removing pg_pltemplate and creating "trustable" extensions