Here is a patch with the proposed wording.
From 7fce0073f8a53b3e9ba84fa10fbc7b8efef36e97 Mon Sep 17 00:00:00 2001
From: benoit
Date: Mon, 22 Aug 2022 12:00:46 +0200
Subject: [PATCH] basic_archive parameter visibility doc patch
Module parameters are only visible from the pg_settings view once
the
Nathan Bossart writes:
> On one hand, it seems like folks will commonly encounter this behavior
with this
> module, so this feels like a natural place for such a note.
Yes, I looked there first.
Would this addition to the pg_settings description be better ?
From 5346a8a0451e222e6592baacb994e6a0
Would this addition to the documentation be ok ? I hope the english is not
too broken ..
From 8ea8c21413eeac8fbd37527e64820cbdca3a5d7a Mon Sep 17 00:00:00 2001
From: benoit
Date: Mon, 22 Aug 2022 12:00:46 +0200
Subject: [PATCH] basic_archive parameter visibility doc patch
Module parameters are on
(Sorry for the spam Nathan)
With the list in CC and additional information :
The modified archive module parameters are visible in pg_file_settings.
They don't show up in \dconfig+, which I understand given the query used by
the
meta command, but I find a little confusing from an end user POV.
> I think the reason is that only the archiver process loads the library, so
> the GUC isn't registered at startup like you'd normally see with
> shared_preload_libraries. IIUC the server will still create a placeholder
> GUC during startup for custom parameters, which is why it shows up for SHOW
Hi,
I am not sure why, but I can't find "basic_archive.archive_directory" in
pg_settings the same way I would find for example :
"pg_stat_statements.max".
[local]:5656 benoit@postgres=# SELECT count(*) FROM pg_settings WHERE name
= 'basic_archive.archive_directory';
count
---
0
(1 row)
Hi,
(I work with Guillaume on this case.)
On Sun, Dec 12, 2021 at 8:34 AM Noah Misch wrote:
> That almost certainly means he's using a 32-bit binary with the default
> heap
> size. To use more heap on AIX, build 64-bit or override the heap size.
> For
> example, "env LDR_CNTRL=MAXDATA=0x80
Hello,
The wiki page [1] still mentions that : "On Windows the useful range (for
shared buffers) is 64MB to 512MB". The topic showed up in a pgtune
discussion [2].
Is it possible to remove this advice or add that since pg10 it no longer
holds true [3] ?
Benoit
[1] https://wiki.postgresql.org/wi
Hi,
The documentation describes how a return code > 125 on the restore_command
would prevent the server from starting [1] :
"
It is important that the command return nonzero exit status on failure. The
command *will* be called requesting files that are not present in the
archive; it must return n
