| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_plan_advice |
| Date: | 2026-03-19 17:02:18 |
| Message-ID: | 1301986.1773939738@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... Anyway, the question here is not about
> such a generic mechanism, but about whether somebody wants to argue
> for sticking a limit of 100 on feedback messages on the theory that
> log spam is bad, or whether it's fine as-is either because (a) the
> likelihood of a significant number of people hitting that limit is
> thought to be too low to worry about or (b) the likelihood of someone
> wanting all of those messages (e.g. for machine-parsing) is thought to
> be high enough that a limit is actually worse than no limit.
FWIW, I'm inclined to think that people won't actually have this
turned on unless they want to see that output, and then they'll
probably want to see all of it. So I'm inclined to leave it as-is
for now. If field experience teaches differently, we can always
improve it later.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-19 17:08:15 | Re: [PATCH] Fix fd leak in pg_dump compression backends when dup()+fdopen() fails |
| Previous Message | Robert Haas | 2026-03-19 16:54:43 | Re: pg_plan_advice |