On Sun, Oct 26, 2025, at 05:11, Chao Li wrote:
> I figured out a way to resolve the race condition for alt3:
>
> * add an awakening flag for every listener, this flag is only set by
> listeners
> * add an advisory pos for every listener, similar to alt1
> * if a listener is awaken, notify only upd
> On Oct 23, 2025, at 18:02, Arseniy Mukhin
> wrote:
>
> Hi,
>
> On Thu, Oct 23, 2025 at 11:17 AM Chao Li wrote:
>>
>>
>>
>>> On Oct 21, 2025, at 00:43, Arseniy Mukhin
>>> wrote:
>>>
>>>
>>> I managed to reproduce the race with v20-alt3. I tried to write a TAP
>>> test reproducing the
On Sat, 25 Oct 2025 at 04:08, Nathan Bossart wrote:
> Here is an updated patch based on the latest discussion.
Thanks. I've just had a look at it. A few comments and questions.
1) The subtraction here looks back to front:
+ xid_age = TransactionIdIsNormal(relfrozenxid) ? relfrozenxid - recentXi
> On 25 Oct 2025, at 04:31, Masahiko Sawada wrote:>
> Or providing
> 'uuid_encode(uuid, format text) -> text' and 'uuid_decode(text, format
> text) -> uuid' might make sense too, but I'm not sure.
> On Saturday 25 October 2025 at 09:07:39 pm GMT+3, Andrey Borodin
> wrote:
> I like the idea, so I
Hi Phil, Hi Jian
On 23/10/2025 00:27, Philip Alger wrote:
> It might be advantageous to show a `trigger name cannot be schema
> qualified` error to the user. Therefore, I added the check and the tests
> on v8 attached.
>
> postgres=# SELECT pg_get_trigger_ddl('main_table', 'public.modified_a');
>
> On 25 Oct 2025, at 04:31, Masahiko Sawada wrote:
>
> Or providing
> 'uuid_encode(uuid, format text) -> text' and 'uuid_decode(text, format
> text) -> uuid' might make sense too, but I'm not sure.
I like the idea, so I drafted a prototype for discussion.
Though I do not see what else methods
On Sat, Oct 25, 2025, at 15:08, Arseniy Mukhin wrote:
> I reimplemented the test in 0002 as an isolation test and added the
> commit message. PFA the new version.
I've rebased the patches so they can be applied on top of v12:
- v12-vacuum_notify_queue_cleanup-without-code-dup.txt
- v12-vacuum_noti
On 2024-Sep-26, Florents Tselai wrote:
> Attached an idea.
> The A/B example may be wordy / redundant,
Yeah, it seems a little wordy to me, how about something like the
attached?
> but the -e note on the distinction between installing binaries / creating
> an extension I think it's important.
H
Alexander Lakhin writes:
> 25.10.2025 00:31, Tom Lane wrote:
>> The other side of that coin is that no other LLVM-using animal is
>> showing similar instability.
> My collection [2] contains also reports from other animals: petalura,
> desmoxytes, dragonet.
Hmm ... but none of those are running
Hello Tom and Andres,
25.10.2025 00:31, Tom Lane wrote:
Sure, we'd need to change our docs about the oldest supported LLVM
version if we go that way.
I wonder if we should just write these off as "probably an LLVM bug".
As I wrote upthread, I could not reproduce the issue with the same old
L
Hello, everyone!
Andres, added you in CC because I am referring to your words in
personal conversation.
Amit, I asked Andres about that situation and Andres said it is a bug
if we execute DirtySnapshot without holding a real one.
And this is how it is done in RelationFindReplTupleByIndex and
Rela
On 2025-Oct-23, Tom Lane wrote:
> I think that rhinoceros is the only BF member testing with
> --with-selinux.
As I recall, there is/was one other animal doing it, but I don't
remember which one it is.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Rebased again.
From 69c2d56899f8729dc1d1476f10da50d879f177d9 Mon Sep 17 00:00:00 2001
From: nkey
Date: Sat, 23 Nov 2024 13:25:11 +0100
Subject: [PATCH v13 1/2] This patch introduces new injection points and TAP
tests to reproduce and verify conflict detection issues that arise during
SNAPSHOT_DI
On Sat, 25 Oct 2025 at 18:59, Bykov Ivan wrote:
>
> In GetNewMultiXactId() this code may lead to error
>
> ---
>
> ExtendMultiXactOffset(MultiXactState->nextMXact + 1);
>
> ---
>
> If MultiXactState->nextMXact = MaxMultiXactId (0x)
>
> we will not extend MultiXactOffset as we should
>
> --
I noticed that this patch has gone largely unreviewed, but it needs
rebase due to the GUC changes, so here it is again.
Thanks
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
>From ee2f93145dbbf0354e167b42078b74d7a0666882 Mon Sep 17 00:00:00 2001
From: Alexander
In GetNewMultiXactId() this code may lead to error
---
ExtendMultiXactOffset(MultiXactState->nextMXact + 1);
---
If MultiXactState->nextMXact = MaxMultiXactId (0x)
we will not extend MultiXactOffset as we should
---
ExtendMultiXactOffset(0);
MultiXactIdToOffsetEntry(0)
multi % MU
On Sat, Oct 25, 2025 at 3:33 AM Matheus Alcantara
wrote:
>
> On Fri Oct 24, 2025 at 4:36 AM -03, Arseniy Mukhin wrote:
> >> I would expect to add 002_aborted_tx_notifies.pl in a separate patch
> >> since it's not related to this bug fix.
> >>
> >> ---
> >> +# Test checks that listeners do not rece
On Fri, 24 Oct 2025 at 20:30, Dean Rasheed wrote:
>
> On Fri, 24 Oct 2025 at 15:23, Andres Freund wrote:
> >
> > FWIW, there are a few interesting messages on the host of my buildfarm
> > animal:
> >
> > Aug 19 02:05:31 andres-postgres-buildfarm-v6 kernel: traps:
> > test_int128[1678696] trap d
> On Oct 25, 2025, at 12:38, Florents Tselai wrote:
>
>
Overall LGTM. Just one comment:
```
+ /* current search_path, or "?" if not
reported by the server */
+ case 'S':
+ strlcpy(bu
19 matches
Mail list logo
