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
27 matches
Mail list logo
