> > [...]
> > - LWLockInitialize(&dsm->lck,
> > LWLockNewTrancheId("test_dsm_registry"));
> > + LWLockInitialize(&dsm->lck, LWLockNewTrancheId((char *) arg));
> > dsm->val = 0;
> > [...]
> >
> > instead of creating a new test? For the other GetNamedDSMSegment calls,
> > I'll pa
Hi,
> It's strange to see this thread go on about messing with the Perl script
> because we're too afraid of pg_bsd_indent. Maybe we should take
> ownership of that code -- improve its own indentation to our
> conventions, add comments, rename unclear variables, and so on until we
> have somethin
On Fri, Dec 12, 2025 at 02:56:39PM -0600, Sami Imseih wrote:
> fair point. In that case why don't we just keep:
>
> [...]
> - LWLockInitialize(&dsm->lck, LWLockNewTrancheId("test_dsm_registry"));
> + LWLockInitialize(&dsm->lck, LWLockNewTrancheId((char *) arg));
> dsm->val = 0;
> fair point. In that case why don't we just keep:
I did something similar, but using a simple pointer comparison instead
of strings, to avoid a warning about discarding const qualifiers.
What do you think about this version?
+void *sample_arg_ptr = &tdr_dsm;
+
static void
-init_tdr_dsm(void *p
> On Fri, Dec 12, 2025 at 12:48:52PM -0600, Sami Imseih wrote:
> > As far as testing, I did not think it's worth it since in the cases out
> > there now a NULL void * will result in an error when calling
> > LWLockNewTrancheId.
>
> I think we should pass NULL to all the existing in-tree calls to
>
On 12/12/2025 2:01 PM, Tom Lane wrote:
> Bryan Green writes:
>> On 12/11/2025 8:43 AM, Peter Eisentraut wrote:
>>> I wonder, this change that gettext did with the locale naming, does that
>>> also affect what guidance we need to provide to users about how to
>>> configure locale names? For exampl
Hi everyone,
On Tue, Dec 09, 2025 at 04:40:19PM +0300, Bilal Yavuz wrote:
> Hi,
>
> On Sat, 6 Dec 2025 at 10:55, Bilal Yavuz wrote:
> >
> > Hi,
> >
> > On Sat, 6 Dec 2025 at 04:40, Manni Wood wrote:
> > > Hello, all.
> > >
> > > Andrew, I tried your suggestion of just reading the first chunk of
On Fri, 2025-12-05 at 16:01 +0100, Peter Eisentraut wrote:
> v11-0003-Fix-inconsistency-between-ltree_strncasecmp-and-.patch
>
> The function comment reads "Check if b has a prefix of a." -- Is that
> the same as "Check if a is a prefix of b."? The latter might be
> clearer.
Yes, fixed.
Note: I
Bryan Green writes:
> On 12/11/2025 8:43 AM, Peter Eisentraut wrote:
>> I wonder, this change that gettext did with the locale naming, does that
>> also affect what guidance we need to provide to users about how to
>> configure locale names? For example, on a Unix-ish system, a user can
>> do som
I wrote:
> Peter Eisentraut writes:
>> I wonder how other gettext-using projects handle this on Solaris.
> I suspect that the answer for most non-Solaris-specific projects has
> been "use GNU gettext".
I poked into that and it seems a lot messier than I hoped. At least
on OpenIndiana, what's ac
CCing Jonathan Katz and Nathan Bossart as they had been sounding boards for
me when I started designing this feature.
> Returning in the FDW_IMPORT_STATS_OK case isn't 100% correct; if the
> foreign table is an inheritance parent, we would fail to do inherited
> stats.
>
Perhaps I'm not understa
On Fri, Dec 12, 2025 at 12:48:52PM -0600, Sami Imseih wrote:
> As far as testing, I did not think it's worth it since in the cases out
> there now a NULL void * will result in an error when calling
> LWLockNewTrancheId.
I think we should pass NULL to all the existing in-tree calls to
GetNamedDSMSe
Hi,
On 2025-12-12 14:21:47 -0500, Greg Burd wrote:
>
> On Fri, Dec 12, 2025, at 11:03 AM, Nathan Bossart wrote:
> > +/*
> > + * _InterlockedExchange() generates a full memory barrier (or release
> > + * semantics that ensures all prior memory operations are visible to
> > + * other cores before t
On Fri, Dec 12, 2025, at 11:03 AM, Nathan Bossart wrote:
> +/*
> + * _InterlockedExchange() generates a full memory barrier (or release
> + * semantics that ensures all prior memory operations are visible to
> + * other cores before the lock is released.
> + */
> +#define S_UNLOCK(lock) (Interloc
On Fri, Dec 12, 2025 at 10:59:53AM +0800, Chao Li wrote:
> I just reviewed the patch. My comments are mainly in 0001, and a few nits
> on 0003. For 0002, the code change is quite straightforward, I am not
> sure the value bumping to has been discussed.
Thanks!
> Where "(MaxTransactionId >> 1)” ha
>
>
> A kind reminder, I don’t see my comments are addressed:
>
>
My apologies. Will get into the next rev.
> My trivial example for it would be persistent statistics: when I want
> to collect some information, save it to disk before shutdown, and on
> the next startup, I want to load the previous state before continuing
> collecting. pg_track_optimizer seems to do this. There are also
> definitely other
Nathan Bossart writes:
> Yeah, I tried to find a bug in it recently and could do little more than
> trial-and-error in the areas that seemed vaguely close (with no success).
> I'm generally critical of efforts to rewrite things from scratch, but this
> might be a case where it's the better option.
On Fri, Dec 12, 2025 at 9:36 AM Robert Haas wrote:
> At least for me, setting pg_plan_advice.advice to any of these strings
> does not provoke a crash. What I discovered after a bit of
> experimentation is that you get the crash if you (a) set the string to
> something like this and then (b) run a
Peter Eisentraut writes:
> On 28.08.24 20:50, Peter Eisentraut wrote:
>> I suggest that the simplification of the xlocale.h configure tests could
>> be committed separately. This would also be useful independent of this,
>> and it's a sizeable chunk of this patch.
> To keep this moving along a
On Thu, Dec 11, 2025 at 4:24 PM Noah Misch wrote:
>
> On Thu, Dec 04, 2025 at 04:19:02PM -0800, Noah Misch wrote:
> > Thanks for the review.
>
> > The attached version doesn't need a comprehensive re-review, but I'd
> > particularly value hearing about any places where you find it's reducing
> > c
On Thu, Dec 11, 2025 at 8:11 PM Jacob Champion
wrote:
> Sure! (They'll need to be golfed down.) Here are three entries that
> hit the crash, each on its own line:
>
> > join_order(qoe((nested_l
> > oindex_scanp_plain))se(nested_loop_plain)nested_loo/_pseq_scanlain)
> > join_order(qoe((nested_loop
On Fri, Dec 12, 2025 at 11:17:01AM -0500, Tom Lane wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
>> It's strange to see this thread go on about messing with the Perl script
>> because we're too afraid of pg_bsd_indent. Maybe we should take
>> ownership of that code -- improve its own indentati
On Fri, 12 Dec 2025 at 19:10, tushar wrote:
>
>
>
> On Thu, Dec 11, 2025 at 9:39 PM Mahendra Singh Thalor
> wrote:
>>
>>
>>
>> Here, in our case, as the cluster already has a role with the current
>> user in restore, we are reporting error "pg_restore: error: could not
>> execute query: ERROR:
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> It's strange to see this thread go on about messing with the Perl script
> because we're too afraid of pg_bsd_indent. Maybe we should take
> ownership of that code -- improve its own indentation to our
> conventions, add comments, rename unclear variables
On Fri, Dec 12, 2025 at 07:10:24AM +, Zsolt Parragi wrote:
>> GetNamedDSA and GetNamedDSHash do not have a need for a callback,
>> because there isn't custom initialization logic that can be applied there.
>
> The use case for GetNamedDSHash is:
I'm going to stay focused on the GetNamedDSMSeg
On Thu, Dec 11, 2025 at 05:17:30PM -0600, Sami Imseih wrote:
>> If the initialization callback function needed the name, it could be
>> provided via the "void *" callback argument, right? I'm not following why
>> we need to provide it separately.
>
> While it's true it can be passed as extra data
+/*
+ * _InterlockedExchange() generates a full memory barrier (or release
+ * semantics that ensures all prior memory operations are visible to
+ * other cores before the lock is released.
+ */
+#define S_UNLOCK(lock) (InterlockedExchange(lock, 0))
This seems to change the implementation from
It's strange to see this thread go on about messing with the Perl script
because we're too afraid of pg_bsd_indent. Maybe we should take
ownership of that code -- improve its own indentation to our
conventions, add comments, rename unclear variables, and so on until we
have something we can work w
On Fri, Dec 12, 2025, at 7:52 AM, Akshay Joshi wrote:
> On Thu, Dec 11, 2025 at 7:29 PM Euler Taveira wrote:
>>
> Is there any way to obtain the default values directly from the source
> code itself, or do I need to refer to the documentation? If we rely on
> the documentation and compare against
Hi,
On Thu, Dec 11, 2025 at 09:51:49AM -0800, Jacob Champion wrote:
> On Wed, Dec 10, 2025 at 11:22 PM Bertrand Drouvot
> wrote:
> > Let me try to focus on functions that really
> > deserve the change. I could look at function names that contain "copy" or
> > "cmp",
> > functions that are used f
Hi,
I would like to propose a patch that improves the handling of table
inheritance
hierarchies when adding tables to publications for logical replication.
Problem:
Currently, when attempting to add a parent table to a publication using,
the operation fails
with an error if any of the inherited c
On Fri, Dec 12, 2025 at 6:59 AM Corey Huinker wrote:
> Rebase, no changes.
Thanks for rebasing! I reviewed the changes made to the core:
@@ -196,13 +196,56 @@ analyze_rel(Oid relid, RangeVar *relation,
{
/*
* For a foreign table, call the FDW's hook function to see whether
Hi,
On Fri, Dec 12, 2025 at 4:45 PM Xuneng Zhou wrote:
>
> Hi Noah,
>
> On Fri, Dec 12, 2025 at 1:05 PM Noah Misch wrote:
> >
> > On Fri, Dec 12, 2025 at 12:51:00PM +0800, Xuneng Zhou wrote:
> > > Bug #19093 [1] reported that pg_stat_wal_receiver.status = 'streaming'
> > > does not accurately re
On Thu, Nov 27, 2025 at 9:46 PM Etsuro Fujita wrote:
> On Sat, Nov 22, 2025 at 6:31 AM Corey Huinker wrote:
> >> Other initial comments:
> >>
> >> The commit message says:
> >>
> >> This is managed via two new options, fetch_stats and remote_analyze,
> >> both are available at the server
On Thu, Dec 11, 2025 at 9:39 PM Mahendra Singh Thalor
wrote:
>
>
> Here, in our case, as the cluster already has a role with the current
> user in restore, we are reporting error "pg_restore: error: could not
> execute query: ERROR: role "role" already exists" and after this
> error, restore is
On 2025-Nov-27, Peter Geoghegan wrote:
> On Thu, Nov 27, 2025 at 11:00 AM Álvaro Herrera wrote:
> index_elems is needed by ON CONFLICT so that the user can specify an
> operator class and/or a collation. This is probably hardly ever used,
> but it does have its place.
Right.
> > So what about
Thanks, for looking into this and for creating the patch.
> +1 for that approach. heap_lock_updated_tuple() actually does that check
> too, but not for the first tuple.
I think this will for sure fix the problem, however we are still
accessing completely unrelated tuples. It feels unsafe to acces
Hi Aleksander,
On 20/11/2025 16:56, Aleksander Alekseev wrote:
Thanks for the patch. Here are my two cents.
This is a follow-up on my earlier answers to your questions. Below is a
motivating example and a performance comparison with HEAD.
For database performance we want to ensure our worki
On Wed, Nov 26, 2025 at 3:03 PM Filip Janus wrote:
>
>
>
> -Filip-
>
>
> út 7. 10. 2025 v 16:54 odesílatel Andres Freund napsal:
>>
>> Hi,
>>
>> On 2025-10-07 15:03:29 +0200, Philipp Marek wrote:
>> > > Have you tried to verify that this doesn't cause performance regressions
>> > > in
>> > >
On 24/11/2025 11:55, Alexander Borisov wrote:
Hey guys, any news?
I finally got around to look at this, thanks for your patience!
v6-0001-Moving-Perl-functions-Sparse-Array-to-a-common-mo.patch
+1, this makes the existing code more readable, even without the rest of
the patches. Thanks for
Would client side revalidation allow re-authentication while a
long-running query is in progress? Or would it kick out a connection
because it can't reauthenticate after some grace period? A strict OIDC
setup might use 5 or 10 minute access tokens, where this is a
realistic issue.
> Online checks
> On 11 Dec 2025, at 18:47, Jacob Champion
> wrote:
> On Mon, Nov 24, 2025 at 6:53 AM Daniel Gustafsson wrote:
>> The attached incorporates your tests, fixes them to make them pass. The
>> culprit seemed to be a combination of a bug in the code (the verify callback
>> need to be defined in the
Hi Nathan,
> [...]
> I think we should also figure out what we want to do for things like this:
>
>
> **
> - This file contains routines that can be bound to a Postgres backend and
> - called by the backend in the pro
Hello
I implemented a simple patch based on the above suggestion
(PGOAUTHDEBUG=UNSAFE:http...). I did not update the documentation yet,
let's see what everyone thinks about it before that, and I also have
some concerns/questions.
I added the new functions into a common source file which gets
incl
Hi Daniel,
>
> Thanks for the patch, below are a few comments and suggestions. As I was
> reviewing I tweaked the below and have attached the comments as changes in
> 0003.
>
Thank you for the improvements.
All your changes look good to me. I have incorporated those in the v44
patch.
> +*
On Thu, Dec 11, 2025 at 7:29 PM Euler Taveira wrote:
>
> On Thu, Nov 20, 2025, at 6:18 AM, Akshay Joshi wrote:
> >
> > Implemented in the suggested solution. Attached is the v5 patch for review.
> >
>
> I reviewed your patch and have some suggestions for this patch.
>
> * You shouldn't include th
Hi,
Currently, XLogFindNextRecord errormsg is ignored and callers will only
output a generic 'could not find a valid record' message without details.
Additionally, invalid page header won't go through XLogReadRecord, leaving
the error in state->errormsg_buf.
This patch propagates XLogFindNextReco
> On 12 Dec 2025, at 11:27, Heikki Linnakangas wrote:
> If we're going to bother changing this at all, let's consider reusing the
> buffer. So instead of initStringInfo()+pfree on every tuple, allocate it once
> and use resetStringInfo().
+1
--
Daniel Gustafsson
On 12/12/2025 11:48, Michael Paquier wrote:
On Fri, Dec 12, 2025 at 09:00:08AM +, Bertrand Drouvot wrote:
On Fri, Dec 12, 2025 at 04:50:09PM +0800, Chao Li wrote:
where CStringGetTextDatum() has made a copy of buf.data and assigned to
value[4], however buf.data is never free-ed.
I did not
Hi,
On Fri, Dec 12, 2025 at 06:48:09PM +0900, Michael Paquier wrote:
> On Fri, Dec 12, 2025 at 09:00:08AM +, Bertrand Drouvot wrote:
> > On Fri, Dec 12, 2025 at 04:50:09PM +0800, Chao Li wrote:
> >> where CStringGetTextDatum() has made a copy of buf.data and assigned to
> >> value[4], however
On 2025-Dec-12, Mihail Nikalayeu wrote:
> Hello, Álvaro!
>
> On Thu, Dec 11, 2025 at 10:36 PM Álvaro Herrera wrote:
> > I just saw a failure in CI for an unrelated patch
>
> I'll try to dive deeper tomorrow to find a fix, but it feels like we
> are doing something wrong here.
Hmm, this is a go
Hello,
These patches look good to me.
On 2025-Dec-11, Jacob Champion wrote:
> Oh, those catch logic errors in the parsing engine. v3-0002 removes
> those from the translation files as well.
Sounds good.
> On Thu, Nov 27, 2025 at 10:24 AM Álvaro Herrera wrote:
> > There's also the strings in C
On Fri, Dec 12, 2025 at 3:04 PM Amit Kapila wrote:
>
> On Thu, Dec 11, 2025 at 7:49 PM Dilip Kumar wrote:
> >
> > I was considering the interdependence between the subscription and the
> > conflict log table (CLT). IMHO, it would be logical to establish the
> > subscription as dependent on the CL
On Thu, Dec 11, 2025 at 11:43:27AM -0500, Tom Lane wrote:
> And before that, you'd have to get consensus that sizeof(*var) *is*
> the preferred style. I for one don't like it a bit. IMO what it
> mostly accomplishes is to remove a cue as to what we are allocating.
> I don't agree that it removes
> On Dec 10, 2025, at 18:20, Tomas Vondra wrote:
>
> I can confirm v2 makes it work for planning all 99 TPC-DS queries, i.e.
> there are no more crashes during EXPLAIN.
Thanks a lot for testing this — much appreciated.
> It's also tricky as plan choices depend on GUCs like random_page_cost,
>
On Fri, Dec 12, 2025 at 09:00:08AM +, Bertrand Drouvot wrote:
> On Fri, Dec 12, 2025 at 04:50:09PM +0800, Chao Li wrote:
>> where CStringGetTextDatum() has made a copy of buf.data and assigned to
>> value[4], however buf.data is never free-ed.
>
> I did not look in details but I think that we
Hi,
Sorry for the late response. Thank you for your reviewing and testing the
patch.
On Mon, Dec 8, 2025 at 6:56 AM torikoshia
wrote:
> On 2025-11-28 18:22, Rahila Syed wrote:
>
> Hi,
>
> > I'm attaching the updated patches, which primarily include cleanup and
> > have been rebased
> > followi
On Fri, Dec 12, 2025 at 11:58:54AM +0900, Michael Paquier wrote:
> FWIW, I have begun putting my hands on your patch, editing it at some
> degree. I am not sure that I will be able to finish that today, but
> I'm working towards getting something done.
Well, I have been able to do enough progress
On Thu, Dec 11, 2025 at 7:49 PM Dilip Kumar wrote:
>
> I was considering the interdependence between the subscription and the
> conflict log table (CLT). IMHO, it would be logical to establish the
> subscription as dependent on the CLT. This way, if someone attempts to
> drop the CLT, the system w
Hi,
On Thu, 11 Dec 2025 at 20:49, Andres Freund wrote:
>
> Hi,
>
> On 2025-12-11 11:45:01 -0600, Bryan Green wrote:
> > On 12/11/2025 10:05 AM, Andres Freund wrote:
> > > On 2025-12-11 15:43:36 +0100, Peter Eisentraut wrote:
> > >> On 10.12.25 01:45, Bryan Green wrote:
> > >>> The attached patch
Hi,
On Fri, Dec 12, 2025 at 04:50:09PM +0800, Chao Li wrote:
> Hi Hackers,
>
> While reading the code of pageinspect, I just found a memory leak
> in gist_page_items():
>
> ```
>values[4] = CStringGetTextDatum(buf.data);
>nulls[4] = false;
> ```
>
> where CStringGetTextDatum() has made
On 11/12/2025 22:05, Alvaro Herrera wrote:
On 2025-Dec-11, Heikki Linnakangas wrote:
That's a great question and I've been wondering about it myself. It goes all
the way to the initial commit where multixacts were introduced, and I don't
see any particular reason for it even back then. Even in
Hi Hackers,
While reading the code of pageinspect, I just found a memory leak
in gist_page_items():
```
values[4] = CStringGetTextDatum(buf.data);
nulls[4] = false;
```
where CStringGetTextDatum() has made a copy of buf.data and assigned to
value[4], however buf.data is never free-ed. This
Hi,
On Thu, Dec 11, 2025 at 11:43:27AM -0500, Tom Lane wrote:
> Andres Freund writes:
> > I tend to agree that what you propose is the better style, but I seriously
> > doubt that
>
> > a) changing over everything at once is worth the backpatch hazard and review
> >pain
> > b) that to judge
Hi Noah,
On Fri, Dec 12, 2025 at 1:05 PM Noah Misch wrote:
>
> On Fri, Dec 12, 2025 at 12:51:00PM +0800, Xuneng Zhou wrote:
> > Bug #19093 [1] reported that pg_stat_wal_receiver.status = 'streaming'
> > does not accurately reflect streaming health. In that discussion,
> > Noah noted that even be
Hi,
On Thu, Dec 11, 2025 at 05:56:13PM +0100, Álvaro Herrera wrote:
> I have my part of blame for having committed the mass change to
> XLogRecPtrIsValid in a2b02293bc65. I'm starting to regret that now.
After reflecting on this one, I do agree that this one was probably not worth
the mass chang
Hi,
On Thu, Dec 11, 2025 at 10:39:55AM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-12-11 13:27:56 +, Bertrand Drouvot wrote:
> > - 0002 is a very large patch. I think that it provides added value as
> > mentioned
> > above but I'm not sure it is worth the noise. Anyway it is done, so shari
68 matches
Mail list logo
