r can lead to
> > inconsistent behavior during switchovers. On the first switchover, the
> > new standby logs an error: "Exiting from slot synchronization because
> > a slot with the same name already exists on the standby." But during
> > a double switchover, this err
On 8/9/2025 12:32, Adrien Nayrat wrote:
On 9/8/25 12:05 PM, Andrei Lepikhov wrote:
On 8/9/2025 11:47, Ashutosh Bapat wrote:
On Mon, Sep 8, 2025 at 4:01 AM Vivek Gadge wrote:
It reminds me of these threads :
Yes, partially. Actively using foreign tables and touching cheaper
partitions first i
On 08/09/2025 17:35, Tom Lane wrote:
"David G. Johnston" writes:
On Monday, September 8, 2025, Matheus Alcantara
wrote:
On this step it will search the .control
file on paths at extension_control_path in order and it will use the
first one that it finds and based on the .control file found
Hi Sophie,
Thanks for the fix. We do have a lot of applications that use ctid to
update/delete rows for performance considerations.
> On Sep 8, 2025, at 17:15, David Rowley wrote:
>
> On Mon, 8 Sept 2025 at 18:57, Sophie Alpert wrote:
>> I'm actually digging in more now and if I'm reading th
On Mon, Sep 8, 2025 at 6:33 PM Nitin Motiani wrote:
>
> Hi Hackers,
>
> I'd like to propose a patch to allow accepting connections post recovery
> without waiting for the removal of old xlog files.
As another idea, could crash recovery avoid waiting for the end-of-recovery
checkpoint itself to f
Hi David,
On 08.09.2025 17:36, David Geier wrote:
Do you think anything else needs changes in the patch?
From an architectural perspective, I think the patch is already in good
shape. However, I have some suggestions regarding code style:
1. I would move McvHashEntry, McvHashContext, he ne
xiting from slot synchronization because
> a slot with the same name already exists on the standby." But during
> a double switchover, this error does not occur.
>
> Upon re-evaluating this, it seems more appropriate to clear the synced
> flag after promotion, as the flag d
On Mon, Sep 8, 2025 at 3:03 PM Nitin Motiani wrote:
>
> I'd like to propose a patch to allow accepting connections post recovery
> without waiting for the removal of old xlog files.
>
> Why : We have seen instances where the crash recovery takes very long (tens
> of minutes to hours) if a large
On Thu, Jun 5, 2025 at 6:09 PM Nitin Motiani wrote:
>
> Hi,
>
> Apologies for the delay on this thread.
>
> On Mon, Apr 28, 2025 at 1:52 PM Nitin Motiani wrote:
> >
> > Thanks for the feedback, Thomas.
> >
> > > Do I understand correctly that
> > > the problem you encountered is in some other tes
On Mon, 8 Sept 2025 at 12:05, Chao Li wrote:
>
>
>
> On Sep 8, 2025, at 14:00, vignesh C wrote:
>
>
>
> 1 - 0001
> ```
> diff --git a/src/test/regress/sql/sequence.sql
> b/src/test/regress/sql/sequence.sql
> index 2c220b60749..c8adddbfa31 100644
> --- a/src/test/regress/sql/sequence.sql
> +++ b/
On Mon, Sep 8, 2025 at 11:22 PM Masahiko Sawada wrote:
>
> On Fri, Sep 5, 2025 at 9:12 PM Amit Kapila wrote:
> >
> > On Sat, Sep 6, 2025 at 3:58 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Sep 2, 2025 at 5:12 AM Shlok Kyal
> > > wrote:
> > > >
> > > >
> > > > I tested the behaviour with
On Mon, Sep 8, 2025 at 3:03 PM Nitin Motiani wrote:
>
> Hi Hackers,
>
> I'd like to propose a patch to allow accepting connections post recovery
> without waiting for the removal of old xlog files.
>
> Why : We have seen instances where the crash recovery takes very long (tens
> of minutes to ho
On Tue, Sep 09, 2025 at 11:58:51AM +0800, 邱宇航 wrote:
>> Oops. When redo XLOG_CHECKPOINT_SHUTDOWN, smgrdestroyall should also be
>> called, since the startup may not exit on standby.
>>
>> The patch is updated.
True that the situation sucks for the startup process, bloating its
memory. That's har
On Tuesday, September 9, 2025 1:30 PM Amit Kapila
wrote:
>
> On Mon, Sep 8, 2025 at 2:56 PM Alexander Kukushkin
> wrote:
> >
> > Recently we also hit this problem.
> >
> > I think in a current state check_synchronized_standby_slots() and
> validate_sync_standby_slots() functions are not very us
Dear Team,
With reference to the conversation ongoing in message ID :
c562dc2a-6e36-46f3-a5ea-cd42eebd7118, I am writing to express my interest
in contributing to the ongoing work on fixing the bug related to Adding
skip scan (including MDAM style range skip scan) to nbtree.
I tried to replicate
On Tue, Aug 26, 2025 at 4:34 PM Nishant Sharma <
nishant.sha...@enterprisedb.com> wrote:
> On Mon, Aug 25, 2025 at 8:59 PM jian he
> wrote:
>
>> On Mon, Aug 25, 2025 at 3:52 PM Nishant Sharma
>> wrote:
>> >
>> >
>> > Experiment 1:-
>> > SQL File : PG_Exp_1.sql
>> >
>> > Actual Output : PG_Exp_1.
On Mon, Sep 8, 2025 at 10:36 PM Álvaro Herrera wrote:
>
> On 2025-Sep-04, Dilip Kumar wrote:
>
> > What's the complain, Srinath complained that if you try to LOAD
> > '$libdir/foo' explicitly then it should load this from $libdir path
> > and it will indeed do so because it will directly call
> >
On Fri, Sep 05, 2025 at 10:40:46AM +0100, Dean Rasheed wrote:
> Alternatively, why not just impose the upper bound at the call sites
> if needed, so there may be no need for these functions at all. For
> example, looking at nodeHash.c, it would seem much more logical to
> have ExecChooseHashTableSi
On Thu, Sep 4, 2025 at 6:00 PM jian he wrote:
> in _tocEntryRestorePass
> if we do
>
> if ((strcmp(te->desc, "COMMENT") == 0 ||
> strcmp(te->desc, "SECURITY LABEL") == 0) &&
> strncmp(te->tag, "EVENT TRIGGER ", 14) == 0)
> return RESTORE_PASS_POST_ACL;
>
> then Restore
> 2025年8月26日 11:59，Jingtang Zhang 写道：
>
> Hi~
>
>> I purpose a patch which calls smgrdestroyall() when redo each
>> XLOG_CHECKPOINT_ONLINE, so that it can keep the same frequency of calling
>> smgrdestroyall() as background processes on primary. I don't call it for
>> XLOG_CHECKPOINT_SHUTDOWN be
On Mon, Sep 08, 2025 at 09:20:14PM -0500, Sami Imseih wrote:
> The following will fail the assert since padding is needed for the
> new Oid member.
>
> @@ -53,6 +53,7 @@ typedef struct PgStat_HashKey
> {
> PgStat_Kind kind; /* statistics entry kind */
> Oid
On Mon, Sep 08, 2025 at 02:47:26PM -0500, Sami Imseih wrote:
> I think v2 is fine because it is perfectly fine for a normal backend
> (EXEC_BACKEND) to call this function as long as it's processing the
> startup hook. The goal is to prevent it from being called outside of the
> startup hook.
I tho
On Mon, Sep 8, 2025 at 10:56 PM Robert Haas wrote:
> On Mon, Sep 8, 2025 at 5:51 AM Richard Guo wrote:
> > BTW, I'm wondering if we can take outer join relids into account in
> > assert_join_preserves_scan_rtis(), which could make the check more
> > useful. A joinrel's relids consists of three p
On Tue, Sep 9, 2025 at 1:59 PM Thomas Munro wrote:
> (3) even though it should
> win for Jeff's test case by skipping workers entirely if an initial
> RWF_NOWAIT attempt succeeds, you could presumably change some
> parameters and make it lose
... not to mention that with v19 patches even that eff
> > I'd just add a comment mentioning that any padding bytes should be avoided.
>
> Agreed on this part.
>
> I am wondering also about the addition of a static assertion as well,
> as it seems that this thread and the opinions on it point to such an
> addition having value, and requiring valgrind t
overheads for
io_method=worker/sync with a primed page cache, and that seems to have
some fundamental issues: (1) AFAIK the plan is to drop io_method=sync
soon, it's only a temporary be-more-like-v17 mitigation in case of
unforeseen problems or in case we decided not to launch with worker by
def
On Mon, 2025-09-08 at 15:14 -0500, Nathan Bossart wrote:
> I think we need to do something similar for numeric.c.
Good catch. Patch LGTM.
Regards,
Jeff Davis
On Mon, Sep 08, 2025 at 12:08:12PM -0400, Andres Freund wrote:
> On 2025-09-08 10:25:13 +0900, Michael Paquier wrote:
>> Another idea would be to make sure that the sizeof() of the structure
>> matches with the sum of the sizeof() for the individual fields in it.
>> That's cumbersome to rely on, st
On Mon, Sep 08, 2025 at 09:37:39AM -0400, Robert Treat wrote:
> Thanks for your work on this. For those who may not be aware, Sami did
> implement a version of this in pg_hint_plan{1}, so that is helpful. I think
> it may be worth revisiting this in core, but perhaps once we seen this new
> impleme
Hi Joel, Arseniy, Matheus, thanks for taking a look. I’ve attached an
updated patch and rebased on the latest commits that fixes the
correctness issues.
On Fri, Sep 5, 2025 at 2:38 AM Joel Jacobson wrote:
> What's the definition of the test table?
It’s just a one column integer table defined as
32 +
src/include/storage/bufpage.h | 1 +
src/tools/pgindent/typedefs.list | 1 +
7 files changed, 269 insertions(+), 11 deletions(-)
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 90f36a04c19..ade83adca59 100644
--- a/src/backen
On 2025-Sep-08, jian he wrote:
> set pg_attribute.attnotnull to true for not-valid not-null is still
> useful for INSERT/UPDATE.
> set pg_attribute.attnotnull to true for not-enforced not-null
> constraints doesn't have real benefits, IMHO.
Yeah, you might be right about this actually. What we w
On Mon, Sep 8, 2025 at 3:14 PM Melanie Plageman
wrote:
> I noticed that in that thread they decided to use errmsg_internal()
> instead of errmsg() for a few different reasons -- one of which was
> that the situation is not supposed to happen/cannot happen -- which I
> don't really understand. It i
On Mon, 2025-09-08 at 17:02 -0400, Andres Freund wrote:
> I forgot an addendum: In fact, if there were a sufficiently cheap way
> to avoid
> using AIO when data is in the page cache, I'm fairly sure we'd want
> to use
> that. However, there is not, from what I know (both fincore() and
> RWF_NOWAIT
> I quickly put together a patch for the stuff we've discussed in this
> thread. WDYT?
>
> --
> nathan
I still think we need to mention EXEC_BACKEND somehow.
The way it's done in [0], it says "On Windows (and anywhere else
where EXEC_BACKEND is defined)"
So we do have precedent of mentioning EXE
Hi,
On 2025-09-08 16:45:52 -0400, Andres Freund wrote:
> On 2025-09-08 12:08:10 -0700, Jeff Davis wrote:
> > On Mon, 2025-09-08 at 14:39 +1200, Thomas Munro wrote:
> > > Some raw thoughts on this topic, and how we got here: This type of
> > > extreme workload, namely not doing any physical I/O, j
> On Mon, Sep 08, 2025 at 02:47:26PM -0500, Sami Imseih wrote:
> > I think v2 is fine because it is perfectly fine for a normal backend
> > (EXEC_BACKEND) to call this function as long as it's processing the
> > startup hook. The goal is to prevent it from being called outside of the
> > startup ho
Hi,
On 2025-09-08 12:08:10 -0700, Jeff Davis wrote:
> On Mon, 2025-09-08 at 14:39 +1200, Thomas Munro wrote:
> > Some raw thoughts on this topic, and how we got here: This type of
> > extreme workload, namely not doing any physical I/O, just copying the
> > same data from the kernel page cache to
On Wed, Aug 27, 2025 at 2:30 PM Masahiko Sawada wrote:
>
> On Tue, Aug 26, 2025 at 8:55 AM Melanie Plageman
> wrote:
>
> > If you do parallel worker setup below heap_vacuum_rel(), then how are
> > you supposed to use those workers to do non-heap table vacuuming?
>
> IIUC non-heap tables can call
On Mon, Sep 8, 2025 at 4:21 PM Richard Guo wrote:
>
> On Sun, Sep 7, 2025 at 8:12 PM Junwang Zhao wrote:
> > While reading this thread, I found that it uses *Relids* to collect NOT NULL
> > attribute numbers, I think this might be an oversight, since ISTM that
> > Relids is used to represent the
Reviewing 0003:
+ /*
+* If we're only adding already frozen rows to a
previously empty
+* page, mark it as all-frozen and update the
visibility map. We're
+* already holding a pin on the vmbuffer.
+*/
els
On Mon, Sep 08, 2025 at 01:43:45PM -0400, Andres Freund wrote:
> On 2025-09-05 16:07:09 -0700, Jeff Davis wrote:
>> On Fri, 2025-09-05 at 13:25 -0700, Jeff Davis wrote:
>>> As an aside, I'm building with meson using -Dc_args="-msse4.2 -Wtype-
>>> limits -Werror=missing-braces". But I notice that th
On Thu, Sep 04, 2025 at 08:35:13PM -0500, Nathan Bossart wrote:
> On Thu, Sep 04, 2025 at 04:12:09PM -0500, Sami Imseih wrote:
>>> Yeah, I think modeling this after commit 4f2400c is a reasonable thing to
>>> explore.
>>
>> Here it is as described above.
>
> Thanks. This looks like the right ide
> On Thu, Sep 04, 2025 at 08:35:13PM -0500, Nathan Bossart wrote:
> > On Thu, Sep 04, 2025 at 04:12:09PM -0500, Sami Imseih wrote:
> >>> Yeah, I think modeling this after commit 4f2400c is a reasonable thing to
> >>> explore.
> >>
> >> Here it is as described above.
> >
> > Thanks. This looks like
On Mon, Sep 8, 2025 at 2:54 PM Robert Haas wrote:
>
> Commit fd6ec93bf890314ac694dc8a7f3c45702ecc1bbd and other previous
> work has established the principle that when an error is potentially
> reachable in case of on-disk corruption, but is not expected to be
> reached otherwise, ERRCODE_DATA_COR
> I'm not sure I understand the compatibility fallout. Like, who would be
angry if we did that?
>From my very first message:
> Breaking change in setups with ignored "passfile" (edge-case, not likely)
So unless I am missing something this only affects people who ran into a
permission issue, left
On 08.09.2025 13:35, Ilia Evdokimov wrote:
Based on these results, I’d prefer the hash lookup implementation, so
I think it makes sense to improve your patch further and bring it into
good shape. Shall I take care of that, or would you prefer to do it
yourself?
I realized I mistakenly cop
On Mon, Sep 8, 2025 at 11:44 AM Melanie Plageman
wrote:
> I pushed this, so rebased v10 is attached. I've added one new patch:
> 0002 adds ERRCODE_DATA_CORRUPTED to the existing log messages about
> VM/data corruption in vacuum. Andrey Borodin earlier suggested this,
> and I had neglected to incl
Hi,
On Tue, Aug 12, 2025 at 8:40 PM SATYANARAYANA NARLAPURAM
wrote:
>
> I couldn't find a previous discussion on a new GUC to globally enable or
> disable logical subscription workers at the instance level. So starting a new
> thread on this.
>
> In multi-region or high-availability setups, a p
On Mon, Sep 8, 2025 at 12:41 PM Robert Haas wrote:
>
> On Fri, Sep 5, 2025 at 6:20 PM Melanie Plageman
> wrote:
> > yikes, you are right about the "reason" member. Attached 0002 removes
> > it, and I'll go ahead and fix it in the back branches too.
>
> I think changing this in the back-branches i
> On Sep 5, 2025, at 2:43 PM, Nathan Bossart wrote:
>
> On Fri, Sep 05, 2025 at 10:48:21AM -0400, Burd, Greg wrote:
>> I looked at both radix tree and binary heap and how they use random sets when
>> testing. Binary heap uses it to create different random sets of numbers to
>> use across multi
On Mon, Sep 8, 2025 at 10:46 AM Tom Lane wrote:
> > Changing the warning to an error wouldn't bother me a great deal, but
> > we'd probably need more than just you voting for that alternative to
> > justify overturning longstanding behavior.
>
> Agreed.
I think I'm starting to lean in the directi
On Sun, Sep 7, 2025 at 12:03 PM Zsolt Parragi wrote:
>
> Hello Hackers,
Thank you for the report!
> While working on an OAuth validator for PG18 I noticed that currently
> the client code doesn't work when using Google as the OAuth provider.
Yep, this came up a couple of times previously [1, 2
On Fri, Sep 5, 2025 at 9:12 PM Amit Kapila wrote:
>
> On Sat, Sep 6, 2025 at 3:58 AM Masahiko Sawada wrote:
> >
> > On Tue, Sep 2, 2025 at 5:12 AM Shlok Kyal wrote:
> > >
> > >
> > > I tested the behaviour with HEAD and with Patch. And I confirmed the
> > > change in behaviour between HEAD and P
On Fri, Sep 5, 2025 at 8:50 PM Amit Kapila wrote:
>
> On Thu, Sep 4, 2025 at 1:24 AM Masahiko Sawada wrote:
> >
> > On Tue, Sep 2, 2025 at 4:35 AM Amit Kapila wrote:
> > >
> > > On Fri, Aug 29, 2025 at 9:38 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > I've attached the updated patch.
> > >
Hi,
On 2025-09-05 16:07:09 -0700, Jeff Davis wrote:
> On Fri, 2025-09-05 at 13:25 -0700, Jeff Davis wrote:
> > As an aside, I'm building with meson using -Dc_args="-msse4.2 -Wtype-
> > limits -Werror=missing-braces". But I notice that the meson build
> > doesn't seem to use -funroll-loops or -ftre
> Then why didn't you specified PARALLEL UNSAFE as well?
You are correct, I missed marking the function as PARALLEL UNSAFE.
I’ve attached a revised patch with the correct annotation.
> BTW, yesterday a new thread started with the same requirement [1]. It
> uses a slightly different way to define
On 8/9/2025 11:47, Ashutosh Bapat wrote:
On Mon, Sep 8, 2025 at 4:01 AM Vivek Gadge wrote:
Looking forward to your guidance.
Thank you
Can you please describe how the query performance is affected because
of the order in which partitions are scanned?
I guess they mentioned that the Postgres
On 2025-Sep-04, Dilip Kumar wrote:
> What's the complain, Srinath complained that if you try to LOAD
> '$libdir/foo' explicitly then it should load this from $libdir path
> and it will indeed do so because it will directly call
> expand_dynamic_library_name() and in this function if there is '/' i
> Did you run a full installcheck under valgrind to have more confidence
> that this is the only code path where we care about the padding of the
> passed-in values for the hash lookups?
I did and could not reproduce "Use of uninitialised value..." on HEAD.
I will mention that it's not a simple r
On Fri, Sep 5, 2025 at 6:20 PM Melanie Plageman
wrote:
> yikes, you are right about the "reason" member. Attached 0002 removes
> it, and I'll go ahead and fix it in the back branches too.
I think changing this in the back-branches is a super-bad idea. If you
want, you can add a comment in the bac
Hi Aleksander,
> Thanks for reporting this. Did you investigate whether Meson also has
> this issue? Fixing anything for Autotools arguably has low priority
> since we are going to get rid of it in the near future, but Meson is
> another matter.
Thanks for the reply. Yes, I tested with Meson and c
Hi,
On 29/08/2025 19:27, Sami Imseih wrote:
Thoughts on v8?
I tried v8 with the Java file in the original email and it works (I
don't see the wrong query in the logs).
Small fix needed in the test descriptions: used to logged -> used to log.
Only question is if we should avoid the extra po
Hi,
On 2025-09-08 10:25:13 +0900, Michael Paquier wrote:
> On Sat, Sep 06, 2025 at 10:35:58AM +0900, Michael Paquier wrote:
> > One idea would be, for example, that keys used with simplehash should
> > never have any padding at all, and we could force a check in the shape
> > of a static assertion
On Mon, Sep 8, 2025 at 6:26 PM Alexander Kukushkin wrote:
>
> Hi,
>
>
> On Sun, 7 Sept 2025 at 10:15, Fabrice Chapuis wrote:
>>
>> Thanks for your reply Zhijie,
>>
>> I understand that the error invalid value for parameter will be diplayed in
>> case of bad value for the GUC synchronized_standb
On Mon, Sep 8, 2025 at 11:20 AM Paul Ohlhauser
wrote:
> And I propose one or more of the following solutions:
> - 1. Make the warning clearer by stating that passfile is ignored (B)
> - 2. Change the warning to be an error (A,B)
> - 3. Allow group permissions (C)
> - 4. Just warn, don't ignore (A,
> Would it address your concern if we reworded that error message to be
> more clear that the file is going to be ignored? I think that proposal
> would have a better chance of success than this one.
Yes, that would improve it a bit. I already suggested this in my very first
message.
To reiterate:
On Sep 1, 2025, at 09:12, David E. Wheeler wrote:
>> Also, I think we can also have a configuration option for animal owners to
>> toggle ABI change status on or off, thoughts?
>
> Mabye? Might be worth waiting to see how much of an issue it is. If there is
> a failure a then a fix, it should
On Fri Sep 5, 2025 at 11:22 AM -03, Pierrick wrote:
> If the same extension is in two different paths mentioned in
> extension_control_path,
> it is impossible to install the version of the last one.
>
> postgres=# show extension_control_path ;
> extension_control_path
Hi!
On 08.09.2025 15:45, Ilia Evdokimov wrote:
> I reran the benchmark on a clean cluster and collected the top slowest
> JOB queries — now the effect is clearly visible.
>
> Merge (sum of all JOB queries)
> ==
> default_statistics_target | Planner Speedup (×) | Planner Before (ms
On Mon, Sep 8, 2025 at 5:51 AM Richard Guo wrote:
> > Plain (not-outer) joins will never be included in a relid set in the
> > first place.
>
> Exactly. Non-outer joins wouldn't cause Vars to become null, so we
> never include them in the joinrel's relids.
OK. I didn't understand what the rules
On Mon, Sep 8, 2025 at 1:15 PM Shayon Mukherjee wrote:
> Hello Hackers,
>
> Looks like there may not be enough interest to port any functionality into
> core. So, just noting that I have withdrawn the patch from CommitFest[1].
> Thank you for the good discussions and leanings.
>
> Thanks for your
Hi Emmanuel,
> Hi hackers, I've found a bug that causes PostgreSQL to crash during startup
> when built with ThreadSanitizer (-fsanitize=thread).
>
> [...]
Thanks for reporting this. Did you investigate whether Meson also has
this issue? Fixing anything for Autotools arguably has low priority
si
On 08.09.2025 13:08, David Geier wrote:
Hi Ilia!
On 05.09.2025 16:03, David Geier wrote:
I propose an optimization: when the column datatype supports
ordering(i.e., has < and >), we can sort both MCV lists and apply
mege-style algorithm to detect matches. This reduces runtime from
O(N^2) to O(
For example, when a query runs on a partitioned table, PostgreSQL scans
partitions in the order they were created or attached to the parent table.
In our case (monthly partitions from January through September), this means
that queries looking for recent data (e.g., September) may experience
additi
On Monday, September 8, 2025 3:13 PM Amit Kapila
wrote:
>
> On Fri, Sep 5, 2025 at 5:03 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Here are v2 patches which addressed above comments.
> >
>
> I have pushed the first patch. I find that the test can't reliably fail
> without a fix.
> Can you pleas
On Thu, Sep 4, 2025 at 8:00 PM Álvaro Herrera wrote:
>
> > @@ -9937,9 +9962,9 @@ ATAddCheckNNConstraint(List **wqueue,
> > AlteredTableInfo *tab, Relation rel,
> >* If adding a valid not-null constraint, set the
> > pg_attribute flag
> >* and tell phase 3 to verif
Hi Ilia!
> I have read all the previous messages - and yes, you are right. I don’t
> know why I didn’t consider using a hash table approach initially. Your
> idea makes a lot of sense.
Your solution would be beneficial on top, for cases where the data type
is not hashable. But I think that's over
On 08.09.2025 12:45, Ilia Evdokimov wrote:
>
> I realized I mistakenly copied the wrong results for the hash-map
> version in my previous draft. Sorry about that. Here are the correct
> benchmark results:
>
> Merge
>
> default_statistics_target | Planner Speedup (×) | Planner Before (ms) |
> Pla
> On 8 Sep 2025, at 11:46, Zsolt Parragi wrote:
>
>> AFAICT adding this would not violate the RFC but it is "NOT RECOMMENDED".
>
> I didn't test Okta yet, but it worked with all other providers I tried
> so far. I try to verify this with Okta and modify it if it doesn't
> work
Great, thanks!
>
On Mon, Sep 8, 2025 at 3:06 AM Tom Lane wrote:
>
> Coverity is not happy with commit a850be2fe:
>
> /srv/coverity/git/pgsql-git/postgresql/src/backend/replication/logical/worker.c:
> 3276 in FindDeletedTupleInLocalRel()
> 3270 * maybe_advance_nonremovable_xid() for
On 9/8/25 12:05 PM, Andrei Lepikhov wrote:
On 8/9/2025 11:47, Ashutosh Bapat wrote:
On Mon, Sep 8, 2025 at 4:01 AM Vivek Gadge wrote:
Looking forward to your guidance.
Thank you
Can you please describe how the query performance is affected because
of the order in which partitions are scann
On Mon, Sep 8, 2025 at 4:01 AM Vivek Gadge wrote:
>
> Hi Team,
>
> We are currently experiencing performance issues related to partition
> scanning on a heavily used table in our PostgreSQL v17.6 database.
>
> The table is partitioned monthly (e.g., transactions_jan25,
> transactions_feb25, …, t
> AFAICT adding this would not violate the RFC but it is "NOT RECOMMENDED".
I didn't test Okta yet, but it worked with all other providers I tried
so far. I try to verify this with Okta and modify it if it doesn't
work, but I think this isn't clear in the RFCs:
RFC 8628 states that "The authoriza
On Sat, Sep 6, 2025 at 10:33 AM Dilip Kumar wrote:
> On Wed, Aug 13, 2025 at 4:17 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Here is the initial POC patch for this idea.
> >
> >
> > If no parallel apply worker is available, the leader will apply the
> > transaction
> > independently.
>
> This type
Hi,
On Sun, 7 Sept 2025 at 10:15, Fabrice Chapuis
wrote:
> Thanks for your reply Zhijie,
>
> I understand that the error invalid value for parameter will be diplayed
> in case of bad value for the GUC synchronized_standby_slots or if a
> standby node configured is not up and running.
> But the
On Mon, 8 Sept 2025 at 18:57, Sophie Alpert wrote:
> I'm actually digging in more now and if I'm reading the code correctly,
> EvalPlanQualStart calls ExecInitNode to create an entirely separate PlanState
> tree for EPQ so I'm unsure if any of the state is carried over to the Recheck
> calls?
> On 8 Sep 2025, at 12:20, Dean Rasheed wrote:
>
> However, even if those issues were addressed, my feeling is that this
> is too specialised to be considered for inclusion in core. The fact
> that it exists in Scipy and not a core python module is a hint at
> that. There are a lot of other Sc
On Mon, Sep 8, 2025 at 11:39 AM Richard Guo wrote:
> On Sun, Sep 7, 2025 at 8:26 PM Alexander Korotkov
> wrote:
> > Great, thank you for catching this. The diff of costs is attached. I
> > see the costs now are better or within the fuzz factor.
>
> Will have a review by the end of this commitf
Thanks for taking a look.
On Sun, Sep 7, 2025 at 9:51 PM, David Rowley wrote:
> I agree that this is a bug and we should fix it. The behaviour should
> match what you'd get if you ran it with "SET enable_tidscan = 0;".
I've confirmed that my new tests already pass on current master if `SET
e
On Sun, Sep 7, 2025 at 8:26 PM Alexander Korotkov wrote:
> Great, thank you for catching this. The diff of costs is attached. I
> see the costs now are better or within the fuzz factor.
Will have a review by the end of this commitfest.
- Richard
Hi,
On Fri, 6 Jun 2025 at 08:30, Peter Eisentraut wrote:
>
> On 05.06.25 12:42, Thomas Munro wrote:
> > I think on your C11 thread I might have been confused about that,
> > since there was an implication that 2019 might support ,
> > but it looks like 2019 added language stuff while 2022 added t
On Sun, Sep 7, 2025 at 8:12 PM Junwang Zhao wrote:
> While reading this thread, I found that it uses *Relids* to collect NOT NULL
> attribute numbers, I think this might be an oversight, since ISTM that
> Relids is used to represent the index of the relation in the range table.
Nice catch; it's b
Hello,
On 05.09.25 23:06, Tom Lane wrote:
> I remain unsure which way I like better. The NULL approach has the
> advantage of not foreclosing use of empty-string list elements, which
> we might want someday even if there's no obvious value today. (And
> for the same reason, it's less of a behavi
On Sat, Sep 06, 2025 at 10:01:24AM +0900, Michael Paquier wrote:
> A last thing that I was not able to spend much time on is how much it
> is possible to mess up with the shared memory state. If it is worse
> than I suspected initially, where an OOM in a first session can cause
> crashes because o
On Sun, 31 Aug 2025 at 13:30, Florents Tselai wrote:
>
> Hi hackers,
>
> In my analytics work, I frequently conduct extensive correlation discovery.
> i.e., given a list of columns, run corr(X, Y) over different pairs and see
> what pairs score high.
> Standard Postgres as-is offers the well-know
In the previous email I attached a git diff not a proper patch file, I
added the correct attachment to this email.
On Sun, Sep 7, 2025 at 8:02 PM Zsolt Parragi wrote:
>
> Hello Hackers,
>
> While working on an OAuth validator for PG18 I noticed that currently
> the client code doesn't work when
> On Sep 8, 2025, at 14:00, vignesh C wrote:
>>
>>
>> 1 - 0001
>> ```
>> diff --git a/src/test/regress/sql/sequence.sql
>> b/src/test/regress/sql/sequence.sql
>> index 2c220b60749..c8adddbfa31 100644
>> --- a/src/test/regress/sql/sequence.sql
>> +++ b/src/test/regress/sql/sequence.sql
>> @@ -
On Sun, Sep 7, 2025 at 1:42 PM Alastair Turner wrote:
>
> Hi Dilip
>
> Thanks for working on this, I think it will make conflict detection a lot
> more useful.
Thanks for the suggestions, please find my reply inline.
> On Sat, 6 Sept 2025, 10:38 Dilip Kumar, wrote:
>>
>> While working on the p
On Wed, May 21, 2025 at 7:29 PM Robert Haas wrote:
>
> On Tue, May 20, 2025 at 2:45 PM Tomas Vondra wrote:
> I have a sense - possibly an incorrect one - that the core of the
> problem here is that the planner considers lots of very similar
> alternatives. A hypothetical feature that showed the
1 - 100 of 20748 matches
Mail list logo
