pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feed From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Rémi Zara <remi_zara@mac.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Date: Mon, 24 Feb 2020 09:44:29 -0500
Message-ID: <16353.1582555469@sss.pgh.pa.us> (raw )
In-Reply-To: <CA+hUKGJeL9XP8p5c4fGoAgPU9ktuxpiCt6An4N9ytO=qSh9WgA@mail.gmail.com >
References: <E1izCmM-0005pV-Co@gemulon.postgresql.org >
<20200220072435.GM2288@paquier.xyz >
<CA+hUKG+yGQDPdwcH5euDb_pE7OcnbrvGDLoOi2JMaCwj4G+ttg@mail.gmail.com >
<08364CCB-07F5-423E-8CE0-ABF0195C4CA2@mac.com >
<17106.1582224047@sss.pgh.pa.us >
<19710.1582227844@sss.pgh.pa.us >
<20263.1582228617@sss.pgh.pa.us >
<CA+hUKGLh5NSUhPmipF+3n2-y_ncuVWu3DSg7vKhvY2HwxEBiNQ@mail.gmail.com >
<26174.1582236314@sss.pgh.pa.us >
<6610.1582242943@sss.pgh.pa.us >
<18091.1582259407@sss.pgh.pa.us >
<6230.1582494552@sss.pgh.pa.us >
<27649.1582500247@sss.pgh.pa.us >
<CA+hUKGJ5+5qWtLGhq-HXJ1UUF2rOtmrCo1rtb+F_-UHTRmdmGg@mail.gmail.com >
<CA+hUKGJeL9XP8p5c4fGoAgPU9ktuxpiCt6An4N9ytO=qSh9WgA@mail.gmail.com >
Thomas Munro <thomas.munro@gmail.com> writes:
> I suppose there may be users who have set ulimit -n high enough to
> support an FDW workload that connects to very many hosts, who will now
> need to set max_files_per_process higher to avoid the new error now
> that we're doing this accounting. That doesn't seem to be a problem
> in itself, but I wonder if the error message should make it clearer
> that it's our limit they hit here.
I struggled with the wording of that message, actually. The patch
proposes
+ ereport(ERROR,
+ (errcode(ERRCODE_SQLCLIENT_UNABLE_TO_ESTABLISH_SQLCONNECTION),
+ errmsg("could not connect to server \"%s\"",
+ server->servername),
+ errdetail("There are too many open files.")));
I wanted to say "The server has too many open files." but in context
it would seem to be talking about the remote server, so I'm not sure
how to fix that.
We could also consider a HINT, along the lines of "Raise the server's
max_files_per_process and/or \"ulimit -n\" limits." This again has
the ambiguity about which server, and it also seems dangerously
platform-specific.
regards, tom lane
view thread (36+ messages) latest in thread
Message-ID: <16353.1582555469@sss.pgh.pa.us>
Permalink: ../16353.1582555469@sss.pgh.pa.us/
Also on: postgresql.org/message-id/16353.1582555469@sss.pgh.pa.us
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, remi_zara@mac.com, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
In-Reply-To: <16353.1582555469@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox