On Mon, Jan 31, 2022 at 04:57:13PM +0900, Michael Paquier wrote:
> On Tue, Jan 25, 2022 at 01:12:32PM +0900, Michael Paquier wrote:
>> Once you remove the requirement of a running server, we have basically
>> what has been recently implemented with postgres -C for
>> runtime-computed GUCs, because
On Tue, Jan 25, 2022 at 01:12:32PM +0900, Michael Paquier wrote:
> Once you remove the requirement of a running server, we have basically
> what has been recently implemented with postgres -C for
> runtime-computed GUCs, because we already go through a read of the
> control file to be able to print
On Mon, Jan 24, 2022 at 08:40:08PM +, Bossart, Nathan wrote:
> On 1/23/22, 7:31 PM, "Michael Paquier" wrote:
>> On Mon, Aug 16, 2021 at 06:12:54PM +, Bossart, Nathan wrote:
>>> I was looking at the --check switch for the postgres binary recently
>>> [0], and this sounds like something that
Thanks for taking a look!
On 1/23/22, 7:31 PM, "Michael Paquier" wrote:
> On Mon, Aug 16, 2021 at 06:12:54PM +, Bossart, Nathan wrote:
>> I was looking at the --check switch for the postgres binary recently
>> [0], and this sounds like something that might fit in nicely there.
>> In the attac
On Mon, Aug 16, 2021 at 06:12:54PM +, Bossart, Nathan wrote:
> I was looking at the --check switch for the postgres binary recently
> [0], and this sounds like something that might fit in nicely there.
> In the attached patch, --check will also check the control file if one
> exists.
This woul
On Wed, Mar 3, 2021 at 8:16 PM Tom Lane wrote:
>
> Vik Fearing writes:
> > On 3/3/21 6:35 PM, Peter Eisentraut wrote:
> >> If what you want to know is whether a given binary can run against a
> >> given data directory then CATALOG_VERSION_NO isn't the only thing you
> >> need to check. The full
Vik Fearing writes:
> On 3/3/21 6:35 PM, Peter Eisentraut wrote:
>> If what you want to know is whether a given binary can run against a
>> given data directory then CATALOG_VERSION_NO isn't the only thing you
>> need to check. The full truth of this is in ReadControlFile(). The
>> best way to g
On 3/3/21 6:35 PM, Peter Eisentraut wrote:
> On 22.02.21 08:00, Vik Fearing wrote:
>> On 2/22/21 3:24 AM, Andres Freund wrote:
>>> Imagine trying to run regular tests of HEAD, where the tests require a
>>> large database to be loaded. Re-loading the data for every [few] commits
>>> is prohibitively
On 22.02.21 08:00, Vik Fearing wrote:
On 2/22/21 3:24 AM, Andres Freund wrote:
Imagine trying to run regular tests of HEAD, where the tests require a
large database to be loaded. Re-loading the data for every [few] commits
is prohibitively time consuming, and even just running pg_upgrade is
pain
On 2/22/21 3:24 AM, Andres Freund wrote:
> Imagine trying to run regular tests of HEAD, where the tests require a
> large database to be loaded. Re-loading the data for every [few] commits
> is prohibitively time consuming, and even just running pg_upgrade is
> painful. So you'd like to re-use a "t
Hi,
On 2021-02-21 20:53:52 -0500, Tom Lane wrote:
> Andres Freund writes:
> >> If we're going to bother with providing a way
> >> to get this info, we should make it possible to ask the running server.
>
> > In Vik's case there is no running server to ask, IIUC.
>
> Hm. If you're about to init
Andres Freund writes:
> On 2021-02-21 19:54:01 -0500, Tom Lane wrote:
>> FWIW, I think asking pg_config about this is a guaranteed way of having
>> version-skew-like bugs.
> Could you elaborate a bit?
How do you know that the pg_config you found has anything to do with the
server you're connecte
Hi,
On 2021-02-21 19:54:01 -0500, Tom Lane wrote:
> Vik Fearing writes:
> > On 2/22/21 12:48 AM, Andres Freund wrote:
> >> Seems roughly reasonable. Although I wonder if we rather should make it
> >> something more generic than just catversion? E.g. a wal page magic bump
> >> will also require a
Vik Fearing writes:
> On 2/22/21 12:48 AM, Andres Freund wrote:
>> Seems roughly reasonable. Although I wonder if we rather should make it
>> something more generic than just catversion? E.g. a wal page magic bump
>> will also require a dump/restore or pg_upgrade, but won't be detected by
>> just
On Sun, Feb 21, 2021, at 8:15 PM, Vik Fearing wrote:
> and a second patch that adds a read-only guc to get at it on the SQL
> level using SHOW catalog_version; or similar. I need that because I
> also do a dump of pg_settings and I would like for it to appear there.
The catalog version number is a
On 2/22/21 12:48 AM, Andres Freund wrote:
> Hi,
>
> On 2021-02-22 00:15:20 +0100, Vik Fearing wrote:
>> I do some very regular testing on HEAD and my scripts need to know if
>> the catalog version has changed to determine if it needs to pg_restore
>> or if a basebackup is okay. In order to get it
Hi,
On 2021-02-22 00:15:20 +0100, Vik Fearing wrote:
> I do some very regular testing on HEAD and my scripts need to know if
> the catalog version has changed to determine if it needs to pg_restore
> or if a basebackup is okay. In order to get it, I have to do this:
>
>
> # Get the catalog vers
Hello.
I do some very regular testing on HEAD and my scripts need to know if
the catalog version has changed to determine if it needs to pg_restore
or if a basebackup is okay. In order to get it, I have to do this:
# Get the catalog version (there is no better way to do this)
tmp=$(mktemp --dir
18 matches
Mail list logo
