On Wed, 8 Nov 2023 at 12:03, Tomas Vondra wrote:
>
> Hi,
>
> here's an updated patch, addressing the review comments, and reworking
> how the work is divided between the workers & leader etc.
Thanks!
> In general I'm quite happy with the current state, and I believe it's
> fairly close to be com
On 11/12/23 10:38, Matthias van de Meent wrote:
> On Wed, 8 Nov 2023 at 12:03, Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> here's an updated patch, addressing the review comments, and reworking
>> how the work is divided between the workers & leader etc.
>
> Thanks!
>
>> In general I'm quite happy
Greetings,
I am getting the following error
building on HEAD
Library crypto found: YES
Checking for function "CRYPTO_new_ex_data" with dependencies -lssl,
-lcrypto: NO
I have openssl 1.1.1 installed
Dave Cramer
Hi
> What are your thoughts on this version? It's not in a committable state
> as it
> needs a bit more comments here and there and a triplecheck that nothing was
> missed in changing this, but I prefer to get your thoughts before spending
> the
> extra time.
>
I think using pointer to exit fun
Hello,
Thanks for the feedback!
On 07/11/2023 09:23, Jelte Fennema-Nio wrote:
> But I think it's looking at the situation from the wrong direction.
[...] we should look at it as an addition to our current list of PQsend
functions for a new packet type. And none of those PQsend functions ever
On 2023-11-11 Sa 12:00, Alexander Lakhin wrote:
11.11.2023 18:18, Andrew Dunstan wrote:
Hmm, maybe we should be using File::Copy::move() instead of rename().
The docco for that says:
If possible, move() will simply rename the file. Otherwise, it
copies the file to the new
On Sun, 12 Nov 2023 at 07:57, Dave Cramer wrote:
> Greetings,
>
> I am getting the following error
> building on HEAD
>
> Library crypto found: YES
> Checking for function "CRYPTO_new_ex_data" with dependencies -lssl,
> -lcrypto: NO
>
So this is the error you get if you mix a 64 bit version of o
On Fri, 2023-10-20 at 16:24 +0800, jian he wrote:
> [new patch]
Thanks, that patch works as expected and passes regression tests.
Some comments about the code:
> --- a/src/backend/utils/adt/rangetypes.c
> +++ b/src/backend/utils/adt/rangetypes.c
> @@ -558,7 +570,6 @@ elem_contained_by_range(PG_F
On Sun, 2023-11-12 at 18:15 +0100, Laurenz Albe wrote:
> I adjusted your patch according to my comments; what do you think?
I have added the patch to the January commitfest, with Jian and Kim as authors.
I hope that is OK with you.
Yours,
Laurenz Albe
On 12-11-2023 20:20, Laurenz Albe wrote:
On Sun, 2023-11-12 at 18:15 +0100, Laurenz Albe wrote:
I adjusted your patch according to my comments; what do you think?
I have added the patch to the January commitfest, with Jian and Kim as authors.
I hope that is OK with you.
Sounds great to me. T
On 11/11/2023 14:00, Alexander Lakhin wrote:
10.11.2023 17:26, Heikki Linnakangas wrote:
I think that is surprising behavior from the DSA facility. When you make
allocations with dsa_allocate() or just call
dsa_get_address() on an existing dsa_pointer, you wouldn't expect the current
resource
On Mon, Nov 13, 2023 at 11:16 AM Heikki Linnakangas wrote:
> On 11/11/2023 14:00, Alexander Lakhin wrote:
> > 10.11.2023 17:26, Heikki Linnakangas wrote:
> >> I think that is surprising behavior from the DSA facility. When you make
> >> allocations with dsa_allocate() or just call
> >> dsa_get_ad
On Fri, Nov 10, 2023 at 07:59:43PM -0800, Andres Freund wrote:
> I think this needs to add tests "documenting" the changed behaviour and
> perhaps also for a few other edge cases. You could e.g. test
> SELECT * FROM pg_walfile_name_offset('0/0')
> which today returns bogus values, and which is i
On 09/11/2023 18:57, Tom Lane wrote:
After further thought I concluded that this area is worth spending
a little more code for. If we have input like '{foo"bar"}' or
'{"foo"bar}' or '{"foo""bar"}', what it most likely means is that
the user misunderstood the quoting rules. A message like "Unexp
Heikki Linnakangas writes:
> On 09/11/2023 18:57, Tom Lane wrote:
>> Barring objections, I think v12 is committable.
> Looks good to me. Just two little things caught my eye:
> 1.
> The function comments in ReadArrayDimensions and ReadArrayStr don't make
> it clear that these arrays need to be
On Thursday, November 9, 2023 6:54 PM shveta malik
wrote:
>
>
> PFA v32 patches which has below changes:
Thanks for updating the patch.
Here are few comments:
1.
Do we need to update the slot upgrade code in pg_upgrade to upgrade the slot's
failover
property as well ?
2.
The check for wal_
In PostgreSQL, when a backend process crashes, it can cause other backend
processes to also require a restart, primarily to ensure data consistency. I
understand that the correct approach is to analyze and identify the cause of
the crash and resolve it. However, it is also important to be able t
Trivial observation: these patches obviously introduce many instances
of words derived from "cancel", but they don't all conform to
established project decisions (cf 21f1e15a) about how to spell them.
We follow the common en-US usage: "canceled", "canceling" but
"cancellation". Blame Webstah et al
yuansong writes:
> In PostgreSQL, when a backend process crashes, it can cause other backend
> processes to also require a restart, primarily to ensure data consistency. I
> understand that the correct approach is to analyze and identify the cause of
> the crash and resolve it. However, it is a
On Sat, Nov 11, 2023 at 5:46 AM Michael Paquier wrote:
>
> On Fri, Nov 10, 2023 at 03:27:25PM +0530, Amit Kapila wrote:
> > I don't think this comment is correct because there won't be any apply
> > activity on the new cluster as after restoration subscriptions should
> > be disabled. On the old c
On Fri, Nov 10, 2023 at 9:17 AM Hayato Kuroda (Fujitsu)
wrote:
>
> > Next we should add some test codes. I will continue considering but please
> > post
> > anything
> > If you have idea.
>
> And I did, PSA the patch. This patch adds two parts in hash_index.sql.
>
> In the first part, the primary
On Mon, Nov 13, 2023 at 6:19 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, November 9, 2023 6:54 PM shveta malik
> wrote:
> >
> >
> > PFA v32 patches which has below changes:
>
> Thanks for updating the patch.
>
> Here are few comments:
>
>
> 2.
> The check for wal_level < WAL_LEVEL_LOGICAL.
>
On 2023-11-12 16:46, Michael Paquier wrote:
On Fri, Nov 10, 2023 at 01:15:50PM +0900, Michael Paquier wrote:
The comments added could be better grammatically, but basically LGTM.
I'll take care of that if there are no objections.
The documentation also needed a few tweaks (for DEFAULT and the
On Thu, Nov 9, 2023 at 8:56 AM Amit Kapila wrote:
>
> On Thu, Nov 9, 2023 at 8:11 AM Amit Kapila wrote:
> >
> > On Wed, Nov 8, 2023 at 8:09 PM Drouvot, Bertrand
> > wrote:
> > >
> > > > Unrelated to above, if there is a user slot on standby with the same
> > > > name which the slot-sync worker i
On Fri, Nov 10, 2023 at 02:55:19PM -0400, David Steele wrote:
> On 11/10/23 00:37, Michael Paquier wrote:
>> I've done a few more dozen runs, and still nothing. I am wondering
>> what this disturbance was.
>
> OK, hopefully it was just a blip.
Still nothing on this side. So that seems really li
On Mon, Nov 13, 2023 at 08:45:12AM +0530, Amit Kapila wrote:
> I think we can be specific about logical replication stuff. I have not
> done any study on autovacuum behavior related to this, so we can
> update about it separately if required.
Autovacuum, as far as I recall, could decide to do some
Hi.
v13 works fine. all tests passed. The code is very intuitive. played
with multi WHEN clauses, even with before/after row triggers, work as
expected.
I don't know when replace_outer_merging will be invoked. even set a
breakpoint on it. coverage shows replace_outer_merging only called
once.
sql
On Fri, Nov 10, 2023 at 08:38:21AM +0100, Peter Eisentraut wrote:
> How about this patch as a comprehensive solution?
> 8 files changed, 26 insertions(+), 339 deletions(-)
Thanks for the patch. The numbers are here, and the patch looks
sensible.
The contents of probes.h without --enable-trace a
On Thu, Nov 9, 2023 at 9:54 PM shveta malik wrote:
>
> PFA v32 patches which has below changes:
Testing with this patch, I see that if the failover enabled slot is
invalidated on the primary, then the corresponding synced slot is not
invalidated on the standby. Instead, I see that it continuously
Dear Amit,
Thanks for reviewing! PSA new version patch.
> > > Next we should add some test codes. I will continue considering but please
> post
> > > anything
> > > If you have idea.
> >
> > And I did, PSA the patch. This patch adds two parts in hash_index.sql.
> >
> > In the first part, the prim
On Fri, Nov 10, 2023 at 02:44:25PM -0600, Nathan Bossart wrote:
> On Tue, Nov 07, 2023 at 05:01:16PM +0900, Michael Paquier wrote:
>> +#ifdef USE_INJECTION_POINTS
>> +#define INJECTION_POINT_RUN(name) InjectionPointRun(name)
>> +#else
>> +#define INJECTION_POINT_RUN(name) ((void) name)
>> +#endif
>
On Sun, 2023-11-12 at 21:55 -0500, Tom Lane wrote:
> yuansong writes:
> > In PostgreSQL, when a backend process crashes, it can cause other backend
> > processes to also require a restart, primarily to ensure data consistency.
> > I understand that the correct approach is to analyze and identify t
On Mon, Nov 13, 2023 at 01:15:14PM +0900, torikoshia wrote:
> I assume you have already taken this into account, but I think we should add
> the same documentation to the below patch for pg_stat_reset_slru():
>
> https://www.postgresql.org/message-id/CALj2ACW4Fqc_m%2BOaavrOMEivZ5aBa24pVKvoXRTmuFEC
On Mon, Nov 13, 2023 at 11:02 AM Ajin Cherian wrote:
>
> On Thu, Nov 9, 2023 at 9:54 PM shveta malik wrote:
> >
> > PFA v32 patches which has below changes:
> Testing with this patch, I see that if the failover enabled slot is
> invalidated on the primary, then the corresponding synced slot is no
On 08.10.23 07:15, Thomas Munro wrote:
About your patch:
I think you should have a "check" function called from
check_new_cluster(). That check function can then also handle the "not
supported" case, and you don't need to handle that in
parseCommandLine(). I suggest following the clone example
35 matches
Mail list logo