Hi!
Thank you for detailed explanations.
Respectfully,
Mikhail Litsarev,
Postgres Professional: https://postgrespro.com
Hi!
I felt you might have missed attaching the test patches added at [1].
Well, the tests were written for the initial proposal which (after
Michael's review and advices) has been fixed and updated. The original
tests became not relevant actually. That is why I dropped them.
This change is
Hi,
Fix an error in the patch.
Respectfully,
Mikhail Litsarev,
Postgres Professional: https://postgrespro.com
From d96d322e9c146e35ef1a5c3168109d3b059585f7 Mon Sep 17 00:00:00 2001
From: Mikhail Litsarev
Date: Fri, 10 Jan 2025 21:23:02 +0300
Subject: [PATCH v6 1/2] Replace recovery boolean fla
Hi!
Rebased the patch.
Respectfully,
Mikhail Litsarev,
Postgres Professional: https://postgrespro.comFrom 67b190ce15f8ba7480ba1691b804b27f96fd5540 Mon Sep 17 00:00:00 2001
From: Mikhail Litsarev
Date: Fri, 10 Jan 2025 21:23:02 +0300
Subject: [PATCH v5 1/2] Replace recovery boolean flags with a
What does this patch give on aglobal scale? Does it save much memory or
increase performance? How many times?
This patch makes the code semantically more correct and we don't lose
anything. It is obviously not about performance or memory optimisation.
This will only reduce the size of the
$P
// Mutex should be last field, as this field isn't copied to dump file
Updated.
2) You didn't take into account the upgrade. Saved in Postgres with
this byte and try to load in version without this byte.
The PGSS_DUMP_FILE format is defined by PGSS_FILE_HEADER magic number
(the first four byte
Hi!
Currently in pg_stat_statements save/load routines the whole pgssEntry
entity data are written/read with its last field
slock_t mutex;
which is actually not used then.
This small patch fixes this issue. Hope, it will be useful.
Respectfully,
Mikhail Litsarev,
Postgres Professional
Hi!
Michael, sorry for such a long time to deliver next version of the patch
from my side.
In this version I have fixed all your propositions, hopefully correct.
There is one point that I would like to emphasize, namely
Shouldn't STANDBY_MODE be only used in the local flag, as well as an
ARCH
Hi!
Michael,
I have fixed the patches according to your comments.
merge both local variables into a single bits32 store?
This is done in v3-0001-Standby-mode-requested.patch
Then this could be used with a function that returns a
text[] array with all the states retrieved?
Placed this in the
simple there are already too many of them. Perhaps we should begin
tracking all that as a set of bitmasks, then plug in the tracked state
in shmem for consumption in some SQL function.
Hi!
Michael, Tristan
as a first step I have introduced the `SharedRecoveryDataFlags` bitmask
instead of thre
On 2024-Apr-16, Michael Paquier wrote:
there are already too many of them. Perhaps we should begin
tracking all that as a set of bitmasks, then plug in the tracked state
in shmem for consumption in some SQL function.
Yes, it sounds reasonable.
Let me implement some initial draft and come back
Hi,
At present time, an existing pg_is_in_recovery() method is not enough
to distinguish a server being in point in time recovery (PITR) mode and
an ordinary replica
because it returns true in both cases.
That is why pg_is_standby_requested() function introduced in attached
patch might help.
12 matches
Mail list logo
