On Sat, 20 Jan 2024 at 08:39, Michael Paquier wrote:
>
> On Sat, Jan 20, 2024 at 07:59:22AM +0530, vignesh C wrote:
> > I'm seeing that there has been no activity in this thread for more
> > than 8 months, I'm planning to close this in the current commitfest
> > unless someone is planning to take
On Sat, Jan 20, 2024 at 07:59:22AM +0530, vignesh C wrote:
> I'm seeing that there has been no activity in this thread for more
> than 8 months, I'm planning to close this in the current commitfest
> unless someone is planning to take it forward.
Thanks, that seems right to me.
I have been lookin
On Wed, 10 May 2023 at 06:07, Justin Pryzby wrote:
>
> On Wed, Mar 29, 2023 at 11:03:59PM -0500, Justin Pryzby wrote:
> > On Wed, Jul 13, 2022 at 04:49:00PM -0700, Andres Freund wrote:
> > > On 2022-07-14 08:46:02 +0900, Michael Paquier wrote:
> > > > On Wed, Jul 13, 2022 at 12:30:00PM -0500, Just
On Wed, Mar 29, 2023 at 11:03:59PM -0500, Justin Pryzby wrote:
> On Wed, Jul 13, 2022 at 04:49:00PM -0700, Andres Freund wrote:
> > On 2022-07-14 08:46:02 +0900, Michael Paquier wrote:
> > > On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > > > How did you make this list ? Was it
On Wed, Jul 13, 2022 at 04:49:00PM -0700, Andres Freund wrote:
> On 2022-07-14 08:46:02 +0900, Michael Paquier wrote:
> > On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > > How did you make this list ? Was it by excluding things that failed for
> > > you ?
> > >
> > > cfbot is
@cfbot: re-rebased again
>From e1f0940e7682052b2ec9d58c361f56630aa1742e Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 19 Jul 2022 08:31:56 -0500
Subject: [PATCH 1/2] pg_settings_get_flags(): add DEFAULT_COMPILE and
DEFAULT_INITDB ..
for settings which vary by ./configure or platform or
On Tue, Oct 25, 2022 at 9:05 AM Justin Pryzby wrote:
>
> On Mon, Sep 26, 2022 at 05:29:58PM +0900, Kyotaro Horiguchi wrote:
> > At Sat, 17 Sep 2022 23:53:07 -0500, Justin Pryzby
> > wrote in
...
> Rebased the patch.
>
> I also split the flag into DEFAULTS_COMPILE and DEFAULTS_INITDB, since
> th
On Mon, Sep 26, 2022 at 05:29:58PM +0900, Kyotaro Horiguchi wrote:
> At Sat, 17 Sep 2022 23:53:07 -0500, Justin Pryzby
> wrote in
> > This is an alternative implementation, which still relies on adding the
> > GUC_DYNAMIC, flag but doesn't require adding a new, sql-accessible
> > function to con
At Fri, 21 Oct 2022 11:58:15 +1100, Peter Smith wrote
in
> Hi, I was hoping to use this patch in my other thread [1], but your
> latest attachment is reported broken in cfbot [2]. Please rebase it.
Ouch. I haven't reach here. I'll do that next Monday.
regards.
--
Kyotaro Horiguchi
NTT Open S
Hi, I was hoping to use this patch in my other thread [1], but your
latest attachment is reported broken in cfbot [2]. Please rebase it.
--
[1] GUC C var sanity check -
https://www.postgresql.org/message-id/CAHut%2BPs91wgaE9P7JORnK_dGq7zPB56WLDJwLNCLgGXxqrh9%3DQ%40mail.gmail.com
[2] cfbot fai
At Sat, 17 Sep 2022 23:53:07 -0500, Justin Pryzby wrote
in
> This is an alternative implementation, which still relies on adding the
> GUC_DYNAMIC, flag but doesn't require adding a new, sql-accessible
> function to convert the GUC to a pretty/human display value.
Thanks!
I'm not sure shared_b
This is an alternative implementation, which still relies on adding the
GUC_DYNAMIC, flag but doesn't require adding a new, sql-accessible
function to convert the GUC to a pretty/human display value.
>From 25ee6d6ed23ff273e622551fd033c8d086953fe5 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date:
Hi,
Checking if you're planning to work on this patch still ?
On Thu, Jul 28, 2022 at 05:27:34PM -0500, Justin Pryzby wrote:
> Note that this can currently exposes internal elog() errors to users:
>
> postgres=# select pg_normalize_config_value('log_min_messages','abc');
> WARNING: invalid valu
Note that this can currently exposes internal elog() errors to users:
postgres=# select pg_normalize_config_value('log_min_messages','abc');
WARNING: invalid value for parameter "log_min_messages": "abc"
HINT: Available values: debug5, debug4, debug3, debug2, debug1, info, notice,
warning, erro
On Tue, Jul 19, 2022 at 03:04:27PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 13 Jul 2022 18:54:45 -0500, Justin Pryzby
> wrote in
> > On Thu, Jul 14, 2022 at 08:46:02AM +0900, Michael Paquier wrote:
> > > On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > > > How did you make thi
At Wed, 13 Jul 2022 18:54:45 -0500, Justin Pryzby wrote
in
> On Thu, Jul 14, 2022 at 08:46:02AM +0900, Michael Paquier wrote:
> > On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > > How did you make this list ? Was it by excluding things that failed for
> > > you ?
Yes. I did
On Thu, Jul 14, 2022 at 08:46:02AM +0900, Michael Paquier wrote:
> On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > How did you make this list ? Was it by excluding things that failed for
> > you ?
> >
> > cfbot is currently failing due to io_concurrency on windows.
> > I think
Hi,
On 2022-07-14 08:46:02 +0900, Michael Paquier wrote:
> On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > How did you make this list ? Was it by excluding things that failed for
> > you ?
> >
> > cfbot is currently failing due to io_concurrency on windows.
> > I think there
On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> How did you make this list ? Was it by excluding things that failed for you ?
>
> cfbot is currently failing due to io_concurrency on windows.
> I think there are more GUC which should be included here.
>
> http://cfbot.cputube.org
> +# The following parameters are defaultly set with
> +# environment-dependent values at run-time which may not match the
> +# default values written in the sample config file.
> +my %ignore_parameters =
> + map { $_ => 1 } (
> + 'data_directory',
> + 'hba_file',
> + 'ident_fil
Thanks!
At Wed, 22 Jun 2022 16:07:10 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-06-17 09:43:58 +0900, Kyotaro Horiguchi wrote:
> > +/*
> > + * Convert value to unitless value according to the specified GUC variable
> > + */
> > +Datum
> > +pg_config_unitless_value(PG_FUNCTION_ARGS)
> > +{
Hi,
On 2022-06-17 09:43:58 +0900, Kyotaro Horiguchi wrote:
> +/*
> + * Convert value to unitless value according to the specified GUC variable
> + */
> +Datum
> +pg_config_unitless_value(PG_FUNCTION_ARGS)
> +{
> + char *name = "";
> + char *value = "";
> + struct config_generic *re
At Thu, 16 Jun 2022 08:23:07 -0500, Justin Pryzby wrote
in
> On Thu, Jun 16, 2022 at 05:19:46PM +0900, Kyotaro Horiguchi wrote:
> > At Sat, 11 Jun 2022 09:41:37 -0500, Justin Pryzby
> > wrote in
> > > Note that this gives:
> > >
> > > guc.c:7573:9: warning: ‘dst’ may be used uninitialized in
On Thu, Jun 16, 2022 at 05:19:46PM +0900, Kyotaro Horiguchi wrote:
> At Sat, 11 Jun 2022 09:41:37 -0500, Justin Pryzby
> wrote in
> > Note that this gives:
> >
> > guc.c:7573:9: warning: ‘dst’ may be used uninitialized in this function
> > [-Wmaybe-uninitialized]
>
> Mmm. I don't have an idea
At Thu, 16 Jun 2022 12:07:03 +0900, Michael Paquier wrote
in
> On Sat, Jun 11, 2022 at 09:41:37AM -0500, Justin Pryzby wrote:
> > Note that this gives:
> >
> > guc.c:7573:9: warning: ‘dst’ may be used uninitialized in this function
> > [-Wmaybe-uninitialized]
> >
> > with gcc version 9.2.1 20
On Sat, Jun 11, 2022 at 09:41:37AM -0500, Justin Pryzby wrote:
> Note that this gives:
>
> guc.c:7573:9: warning: ‘dst’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>
> with gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
>
> I wonder whether you'd consider renaming p
On Mon, May 30, 2022 at 05:27:19PM +0900, Kyotaro Horiguchi wrote:
> At Sat, 28 May 2022 13:22:45 -0700, Andres Freund wrote
> in
> > Hi,
> >
> > On 2022-05-26 16:27:53 +0900, Kyotaro Horiguchi wrote:
> > > It could be in SQL, but *I* prefer to use perl for this, since it
> > > allows me to wri
At Sat, 28 May 2022 13:22:45 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-05-26 16:27:53 +0900, Kyotaro Horiguchi wrote:
> > It could be in SQL, but *I* prefer to use perl for this, since it
> > allows me to write a bit complex things (than simple string
> > comparison) simpler.
>
> I wonder
On Sat, May 28, 2022 at 01:14:09PM -0700, Andres Freund wrote:
> I pushed this bit too.
Thanks for taking care of that!
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2022-05-26 16:27:53 +0900, Kyotaro Horiguchi wrote:
> It could be in SQL, but *I* prefer to use perl for this, since it
> allows me to write a bit complex things (than simple string
> comparison) simpler.
I wonder if we shouldn't just expose a C function to do this, rather than
having a se
Hi,
On 2022-05-25 14:00:23 +0900, Michael Paquier wrote:
> On Tue, May 24, 2022 at 09:28:49PM -0700, Andres Freund wrote:
> > And done. Thanks Nathan!
>
> Shouldn't you also refresh pgstat_fetch_consistency in pgstat.c for
> consistency?
Yes. Now that the visible sheen of embarassment in my face
At Thu, 26 May 2022 13:00:45 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 25 May 2022 21:25:53 -0500, Justin Pryzby
> wrote in
> > And I think these should be updated it postgresql.conf to use the same unit
> > as
> > in current_setting().
> >
> > track_activity_query_size | 1kB
At Wed, 25 May 2022 21:25:53 -0500, Justin Pryzby wrote
in
> On Thu, May 26, 2022 at 11:10:18AM +0900, Kyotaro Horiguchi wrote:
> > Yeah, "boot_val" is appropreate here. And I noticed that pg_settings
> > has the "unit" field. I'll try using them.
>
> I wrote this in guc.sql, which seems prom
On Thu, May 26, 2022 at 11:10:18AM +0900, Kyotaro Horiguchi wrote:
> Yeah, "boot_val" is appropreate here. And I noticed that pg_settings
> has the "unit" field. I'll try using them.
I wrote this in guc.sql, which seems promising, but it needs to be rewritten in
check_guc.pl to access postgresql
At Thu, 26 May 2022 08:53:55 +0900, Michael Paquier wrote
in
> On Wed, May 25, 2022 at 04:12:07PM +0900, Kyotaro Horiguchi wrote:
> > (sigh..) As the result, no need to fix in this area for now, and I
> > don't think there's any generic and reliable way to detect
> > inconsistencies of guc varia
On Wed, May 25, 2022 at 04:12:07PM +0900, Kyotaro Horiguchi wrote:
> (sigh..) As the result, no need to fix in this area for now, and I
> don't think there's any generic and reliable way to detect
> inconsistencies of guc variable definitions.
Hmm. Making the automation test painless in terms of
At Wed, 25 May 2022 15:56:23 +0900 (JST), Kyotaro Horiguchi
wrote in
> The following results are not deeply confirmed yet.
>
> 13 apparent inconsistencies are found. These should be fixed.
>
> archive_command = "(disabled)" != ""
The "(disabled)" is the representation of "".
> bgwriter_flush
At Wed, 25 May 2022 14:00:23 +0900, Michael Paquier wrote
in
> On Tue, May 24, 2022 at 09:28:49PM -0700, Andres Freund wrote:
> > And done. Thanks Nathan!
>
> Shouldn't you also refresh pgstat_fetch_consistency in pgstat.c for
> consistency?
>
> > I wonder if we should make src/test/modules/te
On Tue, May 24, 2022 at 09:28:49PM -0700, Andres Freund wrote:
> And done. Thanks Nathan!
Shouldn't you also refresh pgstat_fetch_consistency in pgstat.c for
consistency?
> I wonder if we should make src/test/modules/test_misc/t/003_check_guc.pl
> detect this kind of thing?
That sounds like a go
On 2022-05-24 21:23:32 -0700, Andres Freund wrote:
> Will apply.
And done. Thanks Nathan!
Hi,
On 2022-05-25 13:11:40 +0900, Kyotaro Horiguchi wrote:
> At Tue, 24 May 2022 15:01:47 -0700, Nathan Bossart
> wrote in
> > In postgresql.conf.sample, stats_fetch_consistency is set to "none," but
> > the default appears to be "cache." Should these be consistent? I've
> > attached a patch
At Tue, 24 May 2022 15:01:47 -0700, Nathan Bossart
wrote in
> In postgresql.conf.sample, stats_fetch_consistency is set to "none," but
> the default appears to be "cache." Should these be consistent? I've
> attached a patch to change the entry in the sample.
Good catch:)
The base C variable
On Tue, May 24, 2022 at 03:01:47PM -0700, Nathan Bossart wrote:
> In postgresql.conf.sample, stats_fetch_consistency is set to "none," but
> the default appears to be "cache." Should these be consistent? I've
> attached a patch to change the entry in the sample.
Yes, postgresql.conf.sample shoul
In postgresql.conf.sample, stats_fetch_consistency is set to "none," but
the default appears to be "cache." Should these be consistent? I've
attached a patch to change the entry in the sample.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/backend/utils/misc/post
44 matches
Mail list logo
