At 2020-10-28 18:29:30 -0700, and...@anarazel.de wrote:
>
> I think my gut feeling about this still is that it's not worth
> implementing something that doesn't work in postgresql.conf. The
> likelihood of ending up with something that makes it hard to to
> eventually implement proper postgresql.co
At 2021-01-03 19:54:38 -0800, p...@bowt.ie wrote:
>
> It just seems worth removing gratuitous inconsistencies,
> such as this one.
Agreed.
-- Abhijit
At 2020-08-20 22:19:49 +1200, dgrowle...@gmail.com wrote:
>
> I was just looking over the JIT code and noticed a few comment and
> documentation typos. The attached fixes them.
The first change does not seem to be correct:
-That this is done at query execution time, possibly even only in cases
-
At 2020-08-20 22:51:41 +1200, dgrowle...@gmail.com wrote:
>
> > +This is done at query execution time, possibly even only in cases where
> > +the relevant task is done a number of times, makes it JIT, rather than
> > +ahead-of-time (AOT). Given the way JIT compilation is used in PostgreSQL,
> > +th
At 2021-11-08 08:41:42 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:
>
> Could someone please explain to me, why compression is being
> considered unsafe / insecure?
https://en.wikipedia.org/wiki/CRIME
> Might the underlying reason be, that certain people have shown
> interest in my libpq/PQb
At 2021-11-08 10:10:55 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:
>
> > https://en.wikipedia.org/wiki/CRIME
>
> Well Abhijit, personally I don't see any connection between crime and
> compression.
Reading the page I linked to may help you make the connection. If not,
try any of the numerou
At 2018-04-09 15:42:35 +0200, tomas.von...@2ndquadrant.com wrote:
>
> On 04/09/2018 12:29 AM, Bruce Momjian wrote:
> >
> > An crazy idea would be to have a daemon that checks the logs and
> > stops Postgres when it seems something wrong.
> >
>
> That doesn't seem like a very practical way.
Not
At 2019-03-20 23:22:44 +0100, tomas.von...@2ndquadrant.com wrote:
>
> I don't really understand what issue are we trying to solve here.
>
> Can someone describe a scenario where this (name of the binary not
> clearly indicating it's related postgres) causes issues in practice?
> On my system, ther
At 2018-11-26 10:18:52 -0500, sfr...@snowman.net wrote:
>
> > This came originally to check that recovery.conf handles correctly
> > its recovery targets when multiple ones are defined with the last
> > one winning […]
>
> Ugh, no, I don't agree that this property makes sense to keep and
> since w
At 2018-03-05 14:42:14 +0900, mich...@paquier.xyz wrote:
>
> > - sinval is a signal invalidation, so it seems to me that "a" is
> > correct, not "an".
I guess it depends on whether you read it as "sin-val" or "ess-inval".
> diff --git a/src/backend/access/gin/ginvacuum.c
> b/src/backend/access/g
At 2024-01-12 17:52:27 +0100, alvhe...@alvh.no-ip.org wrote:
>
> I think this patch is mostly OK
(After the last few rounds of changes, it looks fine to me too.)
> Planning:
>Buffers: shared hit=120 read=30
>Memory: used=67944 bytes allocated=73728 bytes
> Planning Time: 0.892 ms
>
> […
At 2024-01-12 11:21:52 -0600, nathandboss...@gmail.com wrote:
>
> From: Nathan Bossart
> Date: Thu, 11 Jan 2024 21:55:25 -0600
> Subject: [PATCH v6 1/3] reorganize shared memory and lwlocks documentation
>
> ---
> doc/src/sgml/xfunc.sgml | 182 +---
> 1 file c
At 2024-01-04 08:30:36 +0100, mba...@gmx.net wrote:
>
> +typedef struct AuthConnRecord
> +{
> + charremote_host[NI_MAXHOST];
> + boolused;
> + double sleep_time; /* in milliseconds */
> +} AuthConnRecord;
Do we really need a "used" field her
At 2023-11-30 11:29:15 +0100, gabriele.bartol...@enterprisedb.com wrote:
>
> With the attached patch, I extend the partitioning capability to the
> pgbench_history table too.
>
> I have been thinking of adding an option to control this, but I preferred
> to ask in this list whether it really makes
At 2024-01-19 15:08:36 +0100, mba...@gmx.net wrote:
>
> I wonder whether maybe auth_delay.max_seconds should either be renamed
> to auth_delay.exponential_backoff_max_seconds (but then it is rather
> long) in order to make it clearer it only applies in that context or
> alternatively just apply to
At 2024-03-26 08:11:33 -0400, robertmh...@gmail.com wrote:
>
> On Mon, Mar 25, 2024 at 5:04 PM Bruce Momjian wrote:
> > > > Isn't "configuration" too generic a term for disabling ALTER SYSTEM?
> > >
> > > maybe "externally_managed_auto_config"
> >
> > How many people associate "auto" with ALTER SY
At 2023-09-27 10:37:45 -0300, ranier...@gmail.com wrote:
>
> Forgive my impulsiveness, anyone who loves perfect, well written code,
> would understand.
I actually find this characterisation offensive.
Being scrupulous about not grouping random drive-by changes together
with the primary change is
At 2022-02-02 10:55:53 -0500, robertmh...@gmail.com wrote:
>
> On Tue, Jan 18, 2022 at 1:55 PM Robert Haas wrote:
> > 0001 adds "server" and "blackhole" as backup targets. It now has some
> > tests. This might be more or less ready to ship, unless somebody else
> > sees a problem, or I find one.
>
At 2023-05-19 09:16:09 -0400, br...@momjian.us wrote:
>
> On Fri, May 19, 2023 at 09:07:26AM -0400, Stephen Frost wrote:
> >
> > > Why is the new PG 16 GUC called "gss_accept_deleg" and not
> > > "gss_accept_delegation"? The abbreviation here seems atypical.
> >
> > At the time it felt natural t
At 2023-05-20 23:21:57 -0400, t...@sss.pgh.pa.us wrote:
>
> Nathan Bossart writes:
> > On Sat, May 20, 2023 at 09:33:44PM -0400, Bruce Momjian wrote:
> >> With less then 48 hours to beta 1 packaging, I have made this change and
> >> adjusted internal variable to match.
>
> > The buildfarm and cfb
At 2023-05-22 09:42:44 -0400, t...@sss.pgh.pa.us wrote:
>
> Alvaro Herrera writes:
> > I noticed that the value that enables this feature at libpq client side
> > is 'enable'. However, for other Boolean settings like sslsni,
> > keepalives, requiressl, sslcompression, the value that enables featu
At 2023-05-22 09:42:44 -0400, t...@sss.pgh.pa.us wrote:
>
> Alvaro Herrera writes:
> > I noticed that the value that enables this feature at libpq client side
> > is 'enable'. However, for other Boolean settings like sslsni,
> > keepalives, requiressl, sslcompression, the value that enables featu
At 2018-12-17 11:52:03 -0500, t...@sss.pgh.pa.us wrote:
>
> While a dozen lines in pgstrsignal.c certainly are not worth worrying
> over, getting rid of the configure test for sys_siglist[] would save
> some cycles on every build. So I'm tempted to drop it. Thoughts?
Removing it makes sense to m
udgement about their status, real or mythical; however,
adding them to shared_preload_libraries is not advisable.
>From b7f262cf98be76215a9b9968c8800831874cf1d7 Mon Sep 17 00:00:00 2001
From: Abhijit Menon-Sen
Date: Sun, 27 Sep 2020 06:52:30 +0530
Subject: Accept "SET xyz += pqr" t
At 2020-10-20 10:53:04 -0700, and...@anarazel.de wrote:
>
> > postgres=# ALTER SYSTEM SET max_worker_processes += 4;
> > ALTER SYSTEM
>
> Much less clear that this is a good idea...
I agree it's less clear. I still think it might be useful in some cases
(such as the example with max_worke
At 2020-10-26 20:56:57 +0800, craig.rin...@enterprisedb.com wrote:
>
> $ ./build/src/interfaces/libpq/libpq.so
> VERSION_NUM: 14
> VERSION: PostgreSQL 14devel on x86_64-pc-linux-gnu, compiled by gcc (GCC)
> 10.2.1 20200723 (Red Hat 10.2.1-1), 64-bit
> CONFIGURE_ARGS: '--cache-file=config.cach
At 2018-05-18 20:27:57 -0400, sfr...@snowman.net wrote:
>
> I don't agree with the general notion that we can't have a function
> which handles the complicated bits about the kind of error because
> someone grep'ing the source for PANIC might have to do an additional
> lookup.
Or we could just nam
27 matches
Mail list logo
