Hi,
On Fri, Mar 07, 2025 at 12:09:35PM -0800, Masahiko Sawada wrote:
> Thank you for updating the patch. It looks mostly good to me. I've
> made some cosmetic changes and attached the updated version.
LGTM, thanks!
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Datab
Updated and rebase patches.
0001 is the same as v6-0002, but with proper ACL checks on schemas after
cache lookup
0002 attempts to replace all possible ERRORs in the restore/clear functions
with WARNINGs. This is done with an eye towards reducing the set of things
that could potentially cause an
Hi,
On Sat, Mar 08, 2025 at 10:57:38AM +0900, Michael Paquier wrote:
> On Fri, Mar 07, 2025 at 08:33:04AM +, Bertrand Drouvot wrote:
> > But when it's time to flush, then pgstat_backend_have_pending_cb() checks
> > for zeros in PendingBackendStats *without* any check on the backend type.
> >
On Sat, Mar 8, 2025 at 12:52 AM Hari Krishna Sunder
wrote:
> To improve the performance of pg_dump can we add a new sql function that
> can operate more efficiently than the pg_stats view? It could also take in
> an optional list of oids to filter on.
> This will help speed up the dump and restor
On Thu, Mar 06, 2025 at 10:33:52AM +, Bertrand Drouvot wrote:
> Indeed, there is no reason for pgstat_backend_have_pending_cb() to return
> true if
> pgstat_tracks_backend_bktype() is not satisfied.
>
> So it deserves a dedicated patch to fix this already existing issue:
> 0001 attached.
p
To improve the performance of pg_dump can we add a new sql function that
can operate more efficiently than the pg_stats view? It could also take in
an optional list of oids to filter on.
This will help speed up the dump and restore within pg18 and future
upgrades to higher pg versions.
Thanks
Hari
Dear Amit,
> Don't we need to call this invalidation function from
> InvalidateSystemCachesExtended()?
Hmm. I did not call relsync callback functions in
InvalidateSystemCachesExtended()
intentionally, but added now. Please see my analysis below and let me know how
you think.
In the first place,
On Thu, Mar 6, 2025 at 5:33 PM Peter Smith wrote:
>
> Some minor review comments for patch v10-0001.
>
> ==
> src/include/access/tableam.h
>
> 1.
> struct IndexInfo;
> +struct ParallelVacuumState;
> +struct ParallelContext;
> +struct ParallelWorkerContext;
> struct SampleScanState;
>
> Use a
Hi Tom,
> Well, no. That still allows the database owner to commandeer any
> non-superuser role. Even if we tightened "nosuperuser" to mean
> "not superuser and not any built-in role", I don't think it will fly.
Why would the predefined roles be taken into consideration here? The docs
on https:
Hi,
forget to add hackers to cc.
Xuneng Zhou 于2025年3月8日周六 12:10写道：
>
>
> Navneet Kumar 于2025年3月8日周六 02:09写道：
>
>>
>>
>>> This scenario fails
>>> 1. CREATE TABLE person (
>>> id INT GENERATED BY DEFAULT AS IDENTITY,
>>> first_name VARCHAR(50) NOT NULL,
>>> last_name VARCHAR(50) NOT
Hi,
jian he 于2025年3月6日周四 21:44写道：
> On Wed, Feb 26, 2025 at 3:01 PM ego alter wrote:
> >
> > Hi, I’ve had a chance to review the patch. As I am still getting
> familiar with executor part, questions and feedbacks could be relatively
> trivial.
> >
> > There are two minor issues i want to discu
Hi,
On Sun, Oct 27, 2024 at 12:05 PM Kirill Reshke wrote:
>
> On Wed, 14 Aug 2024 at 11:35, Steven Niu wrote:
> >
> > Junwang, Kirill,
> >
> > The split work has been done. I created a new patch for removing redundant
> > smgrclose() function as attached.
> > Please help review it.
> >
> > Than
>
> I tried to generalize that requirement to all of
> {schema|data|statistics} for consistency, but that resulted in 9
> options.
>
9 options that resolve to 3 boolean variables. It's not that hard.
And if we add a fourth option set, then we have 12 options. So it's O(3N),
not O(N^2).
People ha
>
>
> if you want everything --include=schema,data,statistics (presumably
> redundant with the default behavior)
> if you want schema only --include=schema
> if you want "everything except schema" --include=data,statistics
>
Until we add a fourth option, and then it becomes completely ambiguous as
On 2025-03-06 Th 9:17 AM, Shinoda, Noriyoshi (SXD Japan FSI) wrote:
Hi,
Thanks for developing the good feature.
I've attached a small patch for the documentation of the json_strip_nulls
function. The data type of the 'target' parameter is different between the
implementation and the documenta
Hello!
Several times in spell.c, we call strtol and then check the errno, but we
do not clear out errno = 0 before strtol, as is customary (and done
everywhere else in the codebase that I could find.) This could
hypothetically lead to us incorrectly logging an error.
Regards,
Jacob
v1-errno.pat
On Wed, 5 Mar 2025 at 19:19, Matthias van de Meent
wrote:
>
> On Wed, 5 Mar 2025 at 10:04, Heikki Linnakangas wrote:
> >
> > On 28/02/2025 03:53, Peter Geoghegan wrote:
> > > On Sat, Feb 8, 2025 at 8:47 AM Michail Nikolaev
> > > wrote:
> > >> Just some commit messages + few cleanups.
> > >
> > >
Hi,
Tom, CCed you since you have worked most on elog.c
On 2025-03-07 16:23:51 -0500, Andres Freund wrote:
> What about pg_io_handles?
While looking at the view I felt motivated to tackle the one FIXME in the
implementation of the view. Namely that the "error_desc" column wasn't
populated (the v
On Fri, Mar 07, 2025 at 08:33:04AM +, Bertrand Drouvot wrote:
> But when it's time to flush, then pgstat_backend_have_pending_cb() checks
> for zeros in PendingBackendStats *without* any check on the backend type.
>
> I think the issue is "masked" on HEAD because PendingBackendStats is
> proba
Hi,
I reviewed the discussions, and while most agreements focused on
changes to the toast pointer, the design I propose requires no
modifications to it. I’ve carefully considered the design choices made
previously, and I recognize Zstd’s clear advantages in compression
efficiency and performance o
> On 6 Mar 2025, at 12:05, Dave Page wrote:
>
> Further to my previous patch to update the licence preamble
> (https://www.postgresql.org/message-id/CA%2BOCxoy1Z05qDb1BfZZaVzT%3D6BrEW6u3wxprBkc7pewThJMoCA%40mail.gmail.com),
> the attached patch updates the history doc page to properly reflect t
On Wed, Mar 5, 2025 at 5:28 PM Nathan Bossart
wrote:
> On Wed, Mar 05, 2025 at 09:35:27AM -0600, Nathan Bossart wrote:
> > On Wed, Mar 05, 2025 at 01:52:40PM +0100, Magnus Hagander wrote:
> >> Another option that I think would also work is to just cut down the
> details
> >> to just "The --jobs o
On Thu, Mar 6, 2025 at 4:38 PM Robert Haas wrote:
>
> On Thu, Mar 6, 2025 at 4:27 PM Tom Lane wrote:
>
> > My point was that we can implement such a policy in a laissez-faire
> > way: if an older BF animal isn't causing us trouble then why mess
> > with it? Once we *do* recognize that it's causi
On Fri, Mar 7, 2025 at 1:52 PM Thomas Munro wrote:
> I believe I know exactly why: kqueues are considered readable (by
> poll/select/other kqueues) if there are any events queued[1]. Apple's
> EVFILT_TIMER implementation is doing that trick[2] where it leaves
> them queued, but filt_timerprocess(
Dear Amit, hackers,
> Yeah, this is a good improvement and the patch looks safe to me, so I
> pushed with minor changes in the comments.
Thanks! PSA rebased patch. While considering more about 0002, I found a
conceptual bug - when relsync cache could not be re-built when SQL interfaces
are
used.
On Thu, 6 Mar 2025 at 13:40, Burd, Greg wrote:
>
> > On Mar 5, 2025, at 6:39 PM, Matthias van de Meent
> > wrote:
> >
> > On Wed, 5 Mar 2025 at 18:21, Burd, Greg wrote:
> >> * augments IndexInfo only when needed for testing expressions and only once
> >
> > ExecExpressionIndexesUpdated seems to
On Fri, Mar 7, 2025 at 10:09 AM Bertrand Drouvot
wrote:
>
> Given that conn_timing.ready_for_use is only used here:
>
> + if (!reported_first_ready_for_query &&
> + (log_connections &
> LOG_CONNECTION_READY_FOR_USE) &&
> +
On Fri, Mar 7, 2025 at 2:17 PM Melanie Plageman
wrote:
> Yea, "auth_id" is too ambiguous for a GUC option. I went with
> "authorization" because it sounds a bit less like a stage while also
> being a recognizable word. It achieves symmetry -- though it doesn't
> match the prefix used in the logs.
Jelte Fennema-Nio wrote:
> As an example you can copy paste this tiny script:
>
> \startpipeline
> select pg_sleep(5) \bind \g
> \endpipeline
>
> And then it will show these "extra argument ... ignored" warnings
>
> \startpipeline: extra argument "select" ignored
> \startpipeline: extra
On Wed, Mar 5, 2025, at 03:32, Andreas Karlsson wrote:
> On 3/4/25 10:24 AM, Andreas Karlsson wrote:
>> Rebased the patch to add support for OLD.* and NEW.*.
>
> Apparently the CI did not like that version.
>
> Andreas
>
> Attachments:
> * v6-0001-Add-support-for-ON-CONFLICT-DO-SELECT-FOR.patch
+1
On Thu, Mar 6, 2025 at 9:13 PM Thomas Munro wrote:
> I don't see that behaviour on my Mac with a simple program, and that
> seems like it couldn't possibly be intended.
What version of macOS?
Just to make sure I'm not chasing ghosts, I've attached my test
program. Here are my CI results for runn
On Fri, Mar 7, 2025 at 4:53 PM Jacob Champion
wrote:
>
> If I add a hypothetical auth method in the future that authenticates,
> and then farms the authorization decision out to some slow-moving
> network machinery, would "authenticated" retroactively become a stage
> then? (OAuth almost does this
Thanks for the review!
On Fri, Mar 7, 2025 at 2:08 AM Fujii Masao wrote:
>
> With the patch, any unambiguous prefix of a valid boolean value,
> like 'y', is no longer accepted even though it's currently valid
> for boolean GUCs. I don’t have a strong opinion on whether
> we should maintain compat
On Fri, Mar 7, 2025 at 12:29 PM Melanie Plageman
wrote:
> This got me thinking more about the existing log connections messages
> and whether or not they are actually all "stages". The authenticated
> and authorized messages occur at nearly the same time in the
> connection establishment timeline.
On Sat, Mar 8, 2025 at 6:31 AM Jacob Champion
wrote:
> On Thu, Mar 6, 2025 at 9:13 PM Thomas Munro wrote:
> > I don't see that behaviour on my Mac with a simple program, and that
> > seems like it couldn't possibly be intended.
>
> What version of macOS?
>
> Just to make sure I'm not chasing ghos
On Fri, 2025-03-07 at 15:46 -0500, Robert Treat wrote:
> There might be some variability depending on the default behavior,
> but
> if we assume that default means "output everything"
The reason I posted this patch is that, depending on performance
characteristics in v18 and a decision to be made
Em sex., 7 de mar. de 2025 às 16:01, Álvaro Herrera
escreveu:
> On 2025-Mar-07, Álvaro Herrera wrote:
>
> > Anyway, my version of this is attached. It fixes the problems with your
> > patch, but not Orlov's fundamental bug.
>
> And of course I forgot to actually attach the patch. Good grief.
>
On Fri, 7 Mar 2025 at 17:42, Tom Lane wrote:
> Hm, don't you *want* a failure if the patch is already applied?
It's pretty common that in a larger patchset the first 1-2
small/trivial patches get committed before the rest. Having to then
send an additional email, resubmitting the rest of the patc
On Fri, Mar 07, 2025 at 02:38:47PM -0600, Nathan Bossart wrote:
> If that looks good, I'm planning to commit it.
And committed.
--
nathan
Hi,
On 2025-03-06 11:53:41 -0500, Andres Freund wrote:
> On 2025-03-06 10:33:33 -0500, Robert Haas wrote:
> > On Tue, Mar 4, 2025 at 2:00 PM Andres Freund wrote:
> > > - pg_stat_aios currently has the IO Handle flags as dedicated columns. Not
> > > sure that's great?
> >
> > I don't like the n
On Wed, 2025-03-05 at 20:43 -0600, Nathan Bossart wrote:
> I see. Do we provide any suggested next steps for users to assess
> the
> potentially-affected relations?
I don't know exactly where we should document it, but I've attached a
SQL file that demonstrates what can happen for a PG17->PG18 up
On Fri, Mar 7, 2025 at 1:41 PM Jeff Davis wrote:
>
> On Fri, 2025-03-07 at 12:41 -0500, Robert Treat wrote:
> > Ugh... this feels like a bit of the combinatorial explosion,
> > especially if we ever need to add another option.
>
> Not quite that bad, because ideally the yes/no/only would not be
>
On Fri, Mar 07, 2025 at 10:52:10AM -0600, Nathan Bossart wrote:
> Good enough for me. I'll commit/back-patch to v17 the attached soon.
On second thought, since the signal number is a signed integer, I think we
also ought to check that it's > 0. I'm running the attached patch through
the CI tests
Jeff Davis writes:
> Sounds good. I will commit something like the v2 patch then soon, and
> if we need a different condition we can change it later.
Sadly, this made things worse not better: crake is failing
cross-version-upgrade tests again [1], with dump diffs like
@@ -270836,8 +270836,8 @@
> Implementation of the new GUC progressive_explain_min_duration was done
> with
> timeouts. The timeout callback function is used to initialize the
> progressive
> explain.
>
> There is a catch to this implementation. In thread
> https://www.postgresql.org/message-id/flat/d68c3ae31672664876b22d2dc
On Fri, Mar 7, 2025 at 6:16 AM Bertrand Drouvot
wrote:
>
> On Thu, Mar 06, 2025 at 11:41:03AM -0500, Melanie Plageman wrote:
>
> > Well, I actually didn't want to call it "timings" because it implies
> > that we only measure the timings when it is specified. But we actually
> > get the timings unc
Steve Chavez writes:
> This is why I thought the database owner is the right role to allow evtrig
> creation since it won't need an explicit list of roles.
> How about requiring explicit non-superuser execution for the database owner
> evtrig? It would be like:
> CREATE EVENT TRIGGER name ... FOR
On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > >
> > > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > > While investigating a bug in the patch to get rid of WA
Hello
I find that this is still quite broken -- both the original, and your
patch. I have already complained about a fundamental bug in the
original in [1]. In addition to what I reported there, in the unpatched
code I noticed that we're wasting memory and CPU by comparing the
qualified table na
On Fri, Mar 7, 2025 at 2:42 AM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Fri, Mar 07, 2025 at 10:26:23AM +0530, Amit Kapila wrote:
> > On Fri, Mar 7, 2025 at 3:19 AM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Mar 5, 2025 at 4:05 AM Bertrand Drouvot
> > > wrote:
> > > >
> > > > Hi,
> > > >
> >
Hi,
On 2025-03-07 00:03:47 +0100, Tomas Vondra wrote:
> while running check-world on 64-bit arm (rpi5 with Debian 12.9), I got a
> couple reports like this:
>
> ==64550== Use of uninitialised value of size 8
> ==64550==at 0xA62FE0: wrapper_handler (pqsignal.c:107)
> ==64550==by 0x580BB9E7
Many thanks for the feedback.
> an attribute of the trigger and allow both superusers and non-superusers
to create them.
The above is the crux of the issue. Superuser evtrigs can target every role
but non-superusers evtrigs must apply only to a restricted set of roles to
avoid privilege escalatio
Hi Laurenz
On 18.06.24 18:49, Laurenz Albe wrote:
> I have attached a new version that leaves the parameter empty by default.
I've tested this patch and for the most part it works as intended. For
convenience, I wrote a small function to simulate the exceptions using a
given errcode:
CREATE OR
Em sex., 7 de mar. de 2025 às 15:54, Álvaro Herrera
escreveu:
> Hello
>
> I find that this is still quite broken -- both the original, and your
> patch. I have already complained about a fundamental bug in the
> original in [1]. In addition to what I reported there, in the unpatched
> code I no
On 2025-Mar-07, Álvaro Herrera wrote:
> Anyway, my version of this is attached. It fixes the problems with your
> patch, but not Orlov's fundamental bug.
And of course I forgot to actually attach the patch. Good grief.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseD
jian he writes:
> On Fri, Mar 7, 2025 at 11:05 AM Tom Lane wrote:
>> Do others agree Erik's version improves readability?
> i think so.
Pushed v4, then.
regards, tom lane
On Fri, 2025-03-07 at 12:41 -0500, Robert Treat wrote:
> Ugh... this feels like a bit of the combinatorial explosion,
> especially if we ever need to add another option.
Not quite that bad, because ideally the yes/no/only would not be
expanding as well. But I agree that it feels like a lot of opt
Jelte Fennema-Nio writes:
> On Fri, 7 Mar 2025 at 17:42, Tom Lane wrote:
>> Hm, don't you *want* a failure if the patch is already applied?
> It's pretty common that in a larger patchset the first 1-2
> small/trivial patches get committed before the rest. Having to then
> send an additional emai
On Fri, Mar 7, 2025 at 9:25 AM Andres Freund wrote:
> I should have clarified - there are a few that I think are ok, basically the
> places where we wrap syscalls, e.g. around the sendto, select and recvfrom in
> PerformRadiusTransaction().
Okay.
> OTOH that code is effectively completely broken
On 2024-Mar-25, Alexander Korotkov wrote:
> reindexdb: Add the index-level REINDEX with multiple jobs
>
> Straight-forward index-level REINDEX is not supported with multiple jobs as
> we cannot control the concurrent processing of multiple indexes depending on
> the same relation. Instead, we de
>
> This scenario fails
> 1. CREATE TABLE person (
> id INT GENERATED BY DEFAULT AS IDENTITY,
> first_name VARCHAR(50) NOT NULL,
> last_name VARCHAR(50) NOT NULL
> );
>
> 2. INSERT INTO person (first_name, last_name)
> VALUES ('first', 'last');
>
> 3. ALTER TABLE person
> ADD COLUMN ful
On Fri, Mar 7, 2025 at 7:46 PM Andres Freund wrote:
> On 2025-03-07 19:44:20 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 7:38 PM Andres Freund wrote:
> > > On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> > > > On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > > >
On Fri, Mar 7, 2025 at 7:38 PM Andres Freund wrote:
> On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > > What is the access pattern and the observed problems with it that made you
> > > look at the disassembly?
> >
> > Check this
On 2025-03-07 19:44:20 +0200, Alexander Korotkov wrote:
> On Fri, Mar 7, 2025 at 7:38 PM Andres Freund wrote:
> > On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> > > On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > > > What is the access pattern and the observed problems with it
Hi,
On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > What is the access pattern and the observed problems with it that made you
> > look at the disassembly?
>
> Check this code.
>
> l1: pg_atomic_write_u64(&XLogCtl->xlblocks[n
Hi,
On 2025-03-07 18:03:04 +0100, Tomas Vondra wrote:
> On 3/7/25 16:49, Andres Freund wrote:
> > Hi,
> >
> > On 2025-03-07 16:25:09 +0100, Tomas Vondra wrote:
> >> FWIW I keep running into this (and skink seems unhappy too). I ended up
> >> just adding a sleep(1), right before
> >>
> >> push(@se
On Thu, Mar 6, 2025 at 8:42 PM Jeff Davis wrote:
> On Thu, 2025-03-06 at 11:15 -0500, Robert Haas wrote:
> Patch attached. This patch does NOT change the default; stats are still
> opt-out. But it makes it easier for users to start specifying what they
> want or not explicitly, or to rely on the d
Hi,
On 2025-03-07 21:08:34 +0400, Pavel Borisov wrote:
> On Fri, 7 Mar 2025 at 20:40, Alexander Korotkov wrote:
> > Yes, there surely should be a memory barrier on another side. But
> > does __ATOMIC_SEQ_CST works as a barrier for the regular read/write
> > operations on the same side?
> Accordi
On Mon, Mar 3, 2025 at 3:24 PM Masahiko Sawada wrote:
>
> On Mon, Mar 3, 2025 at 1:28 AM Masahiko Sawada wrote:
> >
> > On Tue, Feb 25, 2025 at 4:49 PM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Feb 25, 2025 at 2:44 PM Melanie Plageman
> > > wrote:
> > > >
> > > > On Tue, Feb 25, 2025 at 5
On Thu, Mar 6, 2025 at 1:54 PM Robert Haas wrote:
> Hmm, it seems weird that you can't get a hold of that structure to me.
> Why can't you just go find it in the DSM?
Sorry, I was unclear.
One reason is that there isn't necessarily anything to find.
Certainly, when I try this out with a debugger
Robert Haas writes:
> Here's v6, doing it that way. I found that the simplest thing to do
> was just push the call to GetExplainExtensionId() inside
> Get/SetExplainExtensionState().
Fair enough.
> Tom, what do you think?
The header comments for explain_state.c could use a spellcheck.
I noticed
On Thu, Mar 06, 2025 at 04:10:10PM +0530, Ashutosh Sharma wrote:
> Attached is the v2 patch with the following updates:
>
> 1) Added detailed comments atop check_drop_role_dependency() to
> clarify role dependencies, addressing Nathan's comment.
Thanks!
> 2) Fixed a race condition where the depe
Hi,
On 2025-03-07 09:03:18 -0800, Jacob Champion wrote:
> On Fri, Mar 7, 2025 at 8:38 AM Andres Freund wrote:
> > FWIW, I continue to think that this is a misuse of wait events. We shouldn't
> > use them as a poor man's general purpose tracing framework.
>
> Well, okay. That's frustrating.
I sho
On Fri, Mar 7, 2025 at 7:15 PM Alexander Korotkov wrote:
>
> On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > > >
> > > > On 2025-03-07 17:47:08 +0200, Alexander Korotkov
On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > >
> > > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > > While investigating a bug in the patch to get rid of
WA
On Fri, Mar 7, 2025 at 11:24 AM Robert Treat wrote:
> everyday english/grammar; as an example, people would generally write
> "the dr. lasered the tumor" not "the dr. LASERed the tumor".
For the record, I wouldn't write either of those things if I wanted to
be certain of being understood. Using a
jian he writes:
> While looking at it, in build_attrmap_by_position
> I guess errmsg may be better than errmsg_internal
> since there are around 10 related error messages in
> src/pl/plpgsql/src/expected/plpgsql_record.out,
> so it's user visible.
No, you misunderstand how that works:
er
On Thu, Mar 6, 2025 at 2:12 PM Robert Haas wrote:
> Maybe show_sort_info() has some useful
> precedent, since that's also a bit of node-specific instrumentation,
> and it seems to know what to do about workers.
What do you think of the attached WIP patch, which does things this
way? Does this see
Hi, Alexander and Andres!
On Fri, 7 Mar 2025 at 20:40, Alexander Korotkov wrote:
>
> Hi, Andres.
>
> Thank you for reply.
>
> On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> >
> > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > While investigating a bug in the patch to get ri
Hi,
On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> >
> > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > While investigating a bug in the patch to get rid of WALBufMappingLock, I
> > > found that the surrounding pg_ato
On Fri, Mar 7, 2025 at 11:21 AM Tom Lane wrote:
> While I'm all for chipping away at what superuser privilege is
> needed for, we have to tread VERY carefully about chipping away
> at things that allow any outside-the-database access.
I agree, but I also don't want the security decisions that the
On Fri, Mar 7, 2025 at 8:38 AM Andres Freund wrote:
> FWIW, I continue to think that this is a misuse of wait events. We shouldn't
> use them as a poor man's general purpose tracing framework.
Well, okay. That's frustrating.
If I return to the original design, but replace all of the high-level
w
On 3/7/25 16:49, Andres Freund wrote:
> Hi,
>
> On 2025-03-07 16:25:09 +0100, Tomas Vondra wrote:
>> FWIW I keep running into this (and skink seems unhappy too). I ended up
>> just adding a sleep(1), right before
>>
>> push(@sessions, background_psql_as_user('regress_superuser'));
>>
>> and that m
While working with my New Options Engine patch
https://commitfest.postgresql.org/patch/4688/
I found out that I can detach a small portion of it as a separate
patch.
It has own value, even if big patch is never committed, and it would make
smoother further committing of big patch if we ever get t
On Fri, 2025-03-07 at 11:22 -0500, Andres Freund wrote:
> +1, this has been annoying me while testing.
IIRC, originally someone had questioned the need for options that
expressed what was already the default, but I can't find it right now.
Regardless, now the need is clear enough.
> Could we, ins
On Fri, Mar 07, 2025 at 11:41:38AM -0500, Andres Freund wrote:
> On 2025-03-07 10:36:35 -0600, Nathan Bossart wrote:
>> On Fri, Mar 07, 2025 at 11:32:28AM -0500, Andres Freund wrote:
>> > Is it possible that the signal number we're getting called for is above
>> > PG_NSIG? That'd explain why the so
Hi
I encountered an issue when trying to add a virtual column to an existing
table using the ALTER command. The operation fails even though the existing
data ensures that the virtual column's value will never be NULL. However,
if I define the same virtual column while creating the table and then
i
Jelte Fennema-Nio writes:
> On Fri, 7 Mar 2025 at 11:26, Andreas Karlsson wrote:
>> Out of curiosity: do you track which method works? I would expect
>> everything to be applied with either git am or patch which can be
>> applied with git apply making git apply technically unnecessary.
> I think
Hi,
On 2025-03-07 10:36:35 -0600, Nathan Bossart wrote:
> On Fri, Mar 07, 2025 at 11:32:28AM -0500, Andres Freund wrote:
> > Is it possible that the signal number we're getting called for is above
> > PG_NSIG? That'd explain why the source value is something fairly random?
> >
> > ISTM that we sh
Hi, Andres.
Thank you for reply.
On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
>
> On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > While investigating a bug in the patch to get rid of WALBufMappingLock, I
> > found that the surrounding pg_atomic_compare_exchange_u64() fixes the
Hi,
On 2025-03-06 15:39:44 -0800, Jacob Champion wrote:
> I've reattached the wait event patches, to get the cfbot back to where it was.
FWIW, I continue to think that this is a misuse of wait events. We shouldn't
use them as a poor man's general purpose tracing framework.
Greetings,
Andres Fre
On Fri, Mar 07, 2025 at 11:32:28AM -0500, Andres Freund wrote:
> Is it possible that the signal number we're getting called for is above
> PG_NSIG? That'd explain why the source value is something fairly random?
>
> ISTM that we should add an Assert() to wrapper_handler() that ensures that the
> s
Robert Haas writes:
> On Fri, Mar 7, 2025 at 9:37 AM Michael Banck wrote:
>> Also, I think there is case to be made that a cloud provider (or site
>> admin) would like to delegate the decision whether users with CREATE
>> rights on a particular database are allowed to install some extensions
>> o
Hello!
Last time, I forgot to attach the patches.
The problem still persists in the 17.3 release.
Solution One
The simplest way to fix the problem is to place the scalar field used in the
query ID calculation
between similar subnodes.
A patch for this solution is attached below
(00
hi.
It seems we don't have much info about "Patch Triage" in 2025.
but 2023, 2024 we do have.
like:
https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2024_Developer_Meeting#v17_Patch_Triage
and
https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2023_Developer_Meeting#v16_Patch_Triage
On Fri, Mar 7, 2025 at 9:11 AM Srirama Kucherlapati
wrote:
> Our team has identified couple of issues with the meson build on AIX,
> primarily focusing on the following areas:
>
> Symbol extraction and resolution in object files during binary creation.
> Dynamic runtime library path resolution in
Jelte Fennema-Nio writes:
> The reason why I walked back my comment was that cloud providers can
> simply choose which extensions they actually add to the image. If an
> extension is marked as not trusted by the author, then with this role
> they can still choose to add it without having to make c
On Mon, Feb 17, 2025 at 6:27 PM David G. Johnston
wrote:
>
> On Wed, Jan 15, 2025 at 10:38 PM Peter Smith wrote:
>>
>> On Thu, Jan 16, 2025 at 3:26 PM Tom Lane wrote:
>> >
>> > Peter Smith writes:
>> > > During some recent reviews, I came across some comments mentioning
>> > > "toast" ...
>> >
On Sun, Feb 23, 2025 at 3:41 PM Shayon Mukherjee wrote:
> I have rebased the patch on top of master (resolving some merge
> conflicts), along with the meson changes (thank you for that).
>
Rebased against the latest master and attaching the v13 patch.
Thank you
Shayon
v13-0001-Introduce-the-a
Hi,
On 2025-03-06 17:42:30 -0800, Jeff Davis wrote:
> At minimum, we would need to at least add the option "--with-
> statistics", because right now the only way to explicitly request stats
> is to say "--statistics-only".
+1, this has been annoying me while testing.
I did get confused for a whi
1 - 100 of 171 matches
Mail list logo
