On Thu, Jul 17, 2025 at 2:30 PM Dean Rasheed wrote:
>
> BTW, my other motivation for doing this was to simplify the numeric
> code. Even if this had zero performance benefit, as long as it didn't
> make things any slower, I would argue that it's worth doing.
I gathered that was the main motivatio
On Fri, Jul 18, 2025, at 03:28, Tom Lane wrote:
> So I sympathize with concerns about how well the notification code
> scales, but I think you're going to have to do a ton more work than
> this to get to anything that would pass muster to get committed.
> In particular, I'd really want to see somet
On Thu, Jul 17, 2025 at 1:24 AM Dean Rasheed wrote:
>
> On Wed, 16 Jul 2025 at 10:02, John Naylor wrote:
>
> > Which queries were you testing?
>
> I used the following 2 queries:
>
> SELECT count(*), sum(x), avg(x)
> FROM generate_series(1::bigint, 1000::bigint) g(x);
>
> SELECT count(*), v
Hi,
On Tue, Jul 15, 2025 at 04:13:49PM +0200, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Jul 11, 2025 at 11:59:39AM -0400, Andres Freund wrote:
> > Hi,
> >
> > On 2025-07-10 08:21:56 +, Bertrand Drouvot wrote:
> > > - Let's define a list of "cheap" and a list of "expensive" wait events
> > >
On Fri, Jul 18, 2025 at 11:25 AM shveta malik wrote:
>
> Okay. I see your point. Yes, it was non-blocking earlier but it was
> not giving ERROR, it was just dumping in logilfe that primary is
> behind and thus slot-sync could not be done.
>
> If we continue using the non-blocking mode, there’s a
On Fri, Jul 18, 2025 at 10:52 AM Dilip Kumar wrote:
>
> On Fri, Jul 18, 2025 at 10:45 AM shveta malik wrote:
> >
> > On Fri, Jul 18, 2025 at 10:14 AM Dilip Kumar wrote:
> > >
> > > On Thu, Jul 17, 2025 at 9:34 AM shveta malik
> > > wrote:
> > > >
> > > > On Wed, Jul 16, 2025 at 3:47 PM Ajin Ch
On Fri, Jul 18, 2025 at 10:45 AM shveta malik wrote:
>
> On Fri, Jul 18, 2025 at 10:14 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 17, 2025 at 9:34 AM shveta malik wrote:
> > >
> > > On Wed, Jul 16, 2025 at 3:47 PM Ajin Cherian wrote:
> > > >
> > > > > I am not able to apply the patch to the late
On Fri, Jul 18, 2025 at 10:14 AM Dilip Kumar wrote:
>
> On Thu, Jul 17, 2025 at 9:34 AM shveta malik wrote:
> >
> > On Wed, Jul 16, 2025 at 3:47 PM Ajin Cherian wrote:
> > >
> > > > I am not able to apply the patch to the latest head or even to a week
> > > > back version. Can you please check a
On Thu, Jul 17, 2025 at 4:52 PM vignesh C wrote:
>
> On Wed, 16 Jul 2025 at 11:15, Dilip Kumar wrote:
> >
> > On Mon, Jul 14, 2025 at 10:03 AM vignesh C wrote:
> > >
> > > On Fri, 11 Jul 2025 at 14:26, shveta malik wrote:
> > > >
> > I have picked this up again for final review, started with 00
On Fri, 18 Jul 2025 at 14:25, Sami Imseih wrote:
> I’d argue we should not provide the ALTER option without the GUC, for
> more granular control.
If you mean the use_invisible_index GUC, then for transparency here,
I'm not in favour of that. I do understand that this might be useful
when trying t
On Thu, Jul 17, 2025 at 9:34 AM shveta malik wrote:
>
> On Wed, Jul 16, 2025 at 3:47 PM Ajin Cherian wrote:
> >
> > > I am not able to apply the patch to the latest head or even to a week
> > > back version. Can you please check and rebase?
> > >
> > > thanks
> > > Shveta
> >
> > Rebased.
> >
>
>
On Thursday, July 17, 2025, David G. Johnston
wrote:
> On Thursday, July 17, 2025, David Rowley wrote:
>
>>
>> I find it hard to imagine that there'd be many people
>>
> around that would benefit from a global
>> "always_use_this_number_of_parallel_workers" GUC.
>>
>
> Just to clarify, the globa
On Thursday, July 17, 2025, David Rowley wrote:
>
> I find it hard to imagine that there'd be many people
>
around that would benefit from a global
> "always_use_this_number_of_parallel_workers" GUC.
>
Just to clarify, the global value would be -1 usually. It would be another
crappy planner hin
On Fri, 18 Jul 2025 at 13:04, David G. Johnston
wrote:
> Have the planner produce two numbers.
>
> 1: This plan needs a minimum of N workers to make the parallelism worthwhile.
> Assume that is what we produce today.
> 2: A number representing how much this plan would benefit from the
> availa
On Fri, Jul 18, 2025 at 12:26 AM Masahiko Sawada wrote:
>
> On Thu, Jul 17, 2025 at 2:36 AM Amit Kapila wrote:
> >
> > What if we make DROP SUBSCRIPTION fail if it can lead to removal of
> > the last slot on publisher and allow DROP to succeed when the
> > subscription's drop_slot_force (a new su
On Thursday, July 17, 2025, Sami Imseih wrote:
>
> My concern with #1 is that when we one day do get query hints, we'll
>> be left with a bunch of redundant ways to influence planner behaviour.
>
>
I’d rather not stop accepting improvements of this sort until we get a
proper planner hint into cor
Greg Hennessy writes:
Hi,
>> On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote:
>>> workers, but there isn't an easy way to get more
>>> workers.
> On 7/16/25 11:01 PM, David Rowley wrote:
>>> Is "alter table ... set (parallel_workers=N);" not easy enough?
>
> It may be easy enough for one tabl
> My concern with #1 is that when we one day do get query hints, we'll
> be left with a bunch of redundant ways to influence planner behaviour.
The GUC is more than just a hint. It can serve as a hint, but it also offers
operational benefits. For example, if I mark an index as invisible and that
On Thu, Jul 17, 2025 at 4:44 PM shveta malik wrote:
>
> On Thu, Jul 17, 2025 at 9:56 AM Dilip Kumar wrote:
> >
> > I was just thinking about what are the most practical use cases where
> > a user would need multiple active writer nodes. Most applications
> > typically function well with a single
On Thursday, July 17, 2025, yexiu-glory wrote:
>
>
> On Thursday, July 17, 2025, yexiu-glory <*yexiu-gl...@qq.com
> *> wrote:
>
> I encountered a problem in PostgreSQL 16:
> In db1, there is a user table with fields id, name, phone, and createtime
> db2 replicates the user table from db1 through
On Wed, 16 Jul 2025 at 05:59, Robert Treat wrote:
> operational risk within the system. Similarly, the nature of the DDL
> change also requires that all sessions be impacted everywhere at once;
> there is no way to slowly roll the change to some segment of the
> database or some specific workload
Rishu Bagga writes:
> To explore this further, I’ve drafted a patch that introduces a new GUC:
> `publish_out_of_order_notifications`.
We have generally found that GUCs that change query semantics turn
out to be very regrettable choices. They break applications that
aren't expecting it, and the
On Thursday, July 17, 2025, David Rowley wrote:
>
>
> I suggest to Greg that he might want to come up with a method to make
> this configurable and a means to get something close to what we get
> today and default the setting to that. It would also be easier to
> follow any proposed algorithms wit
Hi,
I ran into a problem with one of our schema monitoring queries today, which
I ended up concluding to likely be caused by a combination of querying
pg_locks on a recurring basis (once every 10 minutes), and a customer
workload that used excessive predicate locks (> 100MB of total pg_locks
data)
Hi all,
There’s been some renewed attention on improving the performance of the
LISTEN/NOTIFY system, which historically hasn’t scaled well under high
notify frequency. Joel Jacobson recently shared some work on optimizing
the LISTEN path [1], and I wanted to follow up with a proposal focused on
t
In a discussion on Discord (in the PG #core-hacking channel,
which unfortunately is inaccessible to non-members), Andres
and Robert complained about the development/maintenance costs
of continuing to support 32-bit platforms. Here is a modest
proposal to reduce those costs without going so far as
On Fri, 18 Jul 2025 at 05:03, Andres Freund wrote:
> Right now we basically assume that the benefit of parallelism reduces
> substantially with every additional parallel worker, but for things like
> seqscans that's really not true. I've seen reasonably-close-to-linear
> scalability for parallel
Hello, Peter!
> FWIW _hash_readpage has a comment about a stashed LSN, so it seems as
> if this was barely missed by the work on hash indexes around 2017:
I think commit 22c5e735 [0] (Remove lsn from HashScanPosData) is the
thing you are looking for in relation to hash.
Best regards,
Mikhail.
On 2025/07/18 1:15, Álvaro Herrera wrote:
On 2025-Jul-18, Fujii Masao wrote:
The current patches add nearly identical notice_receiver functions
in multiple places such as libpqwalreceiver.c and elsewhere. To avoid
duplicating the same logic, could we define a shared notice receiver
function
On Thu, 2025-07-17 at 11:59 -0700, Jeff Davis wrote:
> On Thu, 2025-07-17 at 08:30 +0200, Laurenz Albe wrote:
> > I wasn't aware how Oracle handles case mapping, but it seems you
> > are right:
>
> How does it handle UPPER('ß')? If the result is 'ß', that means it's
> similar to the builtin C.UTF-
Committed after some further editorialization.
--
nathan
On 7/4/25 20:12, Tomas Vondra wrote:
> On 7/4/25 13:05, Jakub Wartak wrote:
>> ...
>>
>> 8. v1-0005 2x + /* if (numa_procs_interleave) */
>>
>>Ha! it's a TRAP! I've uncommented it because I wanted to try it out
>> without it (just by setting GUC off) , but "MyProc->sema" is NULL :
>>
>> 202
On Wed, Jul 16, 2025 at 1:12 AM Michael Paquier wrote:
> On Tue, Jul 15, 2025 at 09:19:50PM +0300, Alexander Korotkov wrote:
> > Thank you for your efforts on this subject. Actually, I was planning
> > to work on pushing this after the release freeze ends for v18. I'd
> > like to do this at leas
On Tue, Jul 15, 2025 at 12:54 AM Sutou Kouhei wrote:
>
> Hi,
>
> In <20250714.173803.865595983884510428@clear-code.com>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 14 Jul 2025 17:38:03 +0900 (JST),
> Sutou Kouhei wrote:
>
> >> I've reviewed the 0
On Mon, Jun 30, 2025 at 9:41 AM Masahiko Sawada wrote:
>
> I've rebased the patches to the current HEAD.
Hi Sawada-san,
I've started reviewing this. I initially meant to review the eager
scan part, but I think it would be easier to do that if it were in a
separate patch on top of the rest of the
On Tue, Jul 15, 2025 at 5:37 AM Andres Freund wrote:
>
> Hi,
>
> On 2025-07-14 03:28:16 +0900, Masahiko Sawada wrote:
> > I've reviewed the 0001 and 0002 patches. The API implemented in the
> > 0002 patch looks good to me, but I'm concerned about the capsulation
> > of copy state data. With the v4
On Mon, Jul 14, 2025 at 3:49 AM Daniil Davydov <3daniss...@gmail.com> wrote:
>
>
> > ---
> > + nlaunched_workers = pvs->pcxt->nworkers_launched; /* remember this
> > value */
> > DestroyParallelContext(pvs->pcxt);
> > +
> > + /* Release all launched (i.e. reserved) parallel autovacuum work
On Thu, Jul 17, 2025 at 2:26 PM Peter Geoghegan wrote:
> The loop has an early check for this (for non-itemDead entries) here:
>
> /* Quickly skip over items never ItemDead-set by btgettuple */
> if (!kitem->itemDead)
> continue;
>
> I really doubt that this matters
I
On Thu, 2025-07-17 at 08:30 +0200, Laurenz Albe wrote:
> I wasn't aware how Oracle handles case mapping, but it seems you
> are right:
How does it handle UPPER('ß')? If the result is 'ß', that means it's
similar to the builtin C.UTF-8. If the result is 'SS', that means it's
similar to PG_UNICODE_F
On Wed, Jul 16, 2025 at 1:26 PM Nathan Bossart wrote:
>
> On Tue, Jul 15, 2025 at 04:14:44PM +0100, Dean Rasheed wrote:
> > On Tue, 15 Jul 2025 at 04:17, Robert Treat wrote:
> >> On Mon, Jul 14, 2025 at 3:22 PM David G. Johnston
> >> > The pg_overexplain extends EXPLAIN with new options that prov
On Thu, Jul 17, 2025 at 2:36 AM Amit Kapila wrote:
>
> What if we make DROP SUBSCRIPTION fail if it can lead to removal of
> the last slot on publisher and allow DROP to succeed when the
> subscription's drop_slot_force (a new subscription option) is set?
> Now, users can still be allowed to Drop
On Tue, Jul 15, 2025 at 10:55 PM shveta malik wrote:
>
> On Tue, Jul 15, 2025 at 10:37 PM Masahiko Sawada
> wrote:
> >
> > I've attached updated patches that implement the idea we've discussed.
> > The patches still need to be polished but the implemented ideas seem
> > good. Feedback is very we
On Thu, 2025-07-17 at 12:58 -0400, Tom Lane wrote:
> Cool, done that way.
Thanks!
Yours,
Laurenz Albe
On Fri, Jul 11, 2025, at 2:52 PM, Andres Freund wrote:
Hi,
On 2025-07-11 13:26:53 -0400, Greg Burd wrote:
In conversations [1] recently about considering how best to adapt the
code
to become NUMA-aware Andres commented, "FWIW, I've started to wonder
if we
shouldn't just get rid of the freelis
> On 30 Jun 2025, at 15:58, Andrey Borodin wrote:
>
> page_collect_tuples() holds a lock on the buffer while examining tuples
> visibility, having InterruptHoldoffCount > 0. Tuple visibility check might
> need WAL to go on, we have to wait until some next MX be filled in.
> Which might need
Kwangwon Seo writes:
> Using the PostgreSQL code coverage report, I found that tests for
> comparisons between date and timestamp[tz] are missing. Some of them have
> only partial coverage.
> Attached patch will cover following functions:
> ...
I'm really not very excited about adding regression
On Wed, Jul 16, 2025 at 5:27 PM Mircea Cadariu wrote:
> Does the above change mean it will have to do more work in the loop?
> Whereas before it visited strictly killed, it now has to go through all
> of them?
Yes, that's true. Any item that the scan returns from the so->currPos
page needs to be
> >> this for better tracking. By adding a CachedPlanSource::cplan link, we
> >> can establish a connection to the entire PlanCache entry instead of only
> >> CachedPlan within a queryDesc and, consequently, make it accessible from
> >> the executor. This would give an access to statistics on costs
Hi,
On Thu, 17 Jul 2025 at 11:19, Dave Page wrote:
>
> On Thu, 17 Jul 2025 at 09:01, Nazir Bilal Yavuz wrote:
>>
>> x64:
>>
>> * I downloaded Dave Page's Windows gettext artifact from [2]. I am
>> able to configure Postgres with nls being enabled but then compilation
>> failed with:
>> ```
>> [3
On Fri, Jul 11, 2025 at 3:58 AM Amit Kapila wrote:
>
> On Thu, Jul 10, 2025 at 6:46 PM Masahiko Sawada wrote:
> >
> > On Wed, Jul 9, 2025 at 9:09 PM Amit Kapila wrote:
> >
> > >
> > > > I think that even with retain_conflict_info = off, there is probably a
> > > > point at which the subscriber c
On 2025-Jul-15, jian he wrote:
> we should let:
> dumpConstraint handles dumping separate "NOT VALID" domain constraints along
> with their comments.
> dumpDomain: handles dumping "inlined" valid (not separate) domain constraints
> together with their comments.
Hmm, okay, but not-null constraints
Hi,
On 2025-07-17 15:01:55 +1200, David Rowley wrote:
> On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote:
> > workers, but there isn't an easy way to get more
> > workers.
>
> Is "alter table ... set (parallel_workers=N);" not easy enough?
I don't think that's a great approach, as that basical
Laurenz Albe writes:
> On Wed, 2025-07-16 at 15:36 -0400, Tom Lane wrote:
>> ... So it seems attractive to stick with the
>> original thought of making PQport substitute the correct value
>> for an empty string. PQport *does* know the correct value of
>> DEF_PGPORT_STR, so it'd be pretty nearly
On Wed, Jul 16, 2025 at 4:35 PM Andres Freund wrote:
> Why do we care about not hitting the socket? We always operate the socket in
> non-blocking mode anyway?
IIUC, that would change pqReadData() from a bounded read to an
unbounded one. Then we have to somehow protect against a server that
can s
On 7/16/25 11:01 PM, David Rowley wrote:
> Is "alter table ... set (parallel_workers=N);" not easy enough?
No opinions on the merit of the patch, but it's not as easy as better
default behavior, right? That is, the important questions are whether
the proposed behavior is better, and whether the c
On Thu, 2025-07-17 at 19:41 +0800, yexiu-glory wrote:
> I encountered a problem in PostgreSQL 16:
> In db1, there is a user table with fields id, name, phone, and createtime
> db2 replicates the user table from db1 through logical replication,
> specifying the fields as id, name, and createtime
>
On 2025-Jul-18, Fujii Masao wrote:
> The current patches add nearly identical notice_receiver functions
> in multiple places such as libpqwalreceiver.c and elsewhere. To avoid
> duplicating the same logic, could we define a shared notice receiver
> function in a common file, like libpq-be-fe-helpe
On 2025-07-17 Th 7:11 AM, Álvaro Herrera wrote:
On 2025-Jul-17, Mahendra Singh Thalor wrote:
To pg_restore, we are giving a dump of pg_dumpall which has a
global.dat file and we have drop commands in the global.dat file so
when we are using 'globals-only', we are dropping databases as we have
On Thursday, July 17, 2025, yexiu-glory wrote:
> I encountered a problem in PostgreSQL 16:
> In db1, there is a user table with fields id, name, phone, and createtime
> db2 replicates the user table from db1 through logical replication,
> specifying the fields as id, name, and createtime
> Then,
On 2025/07/17 23:34, Fujii Masao wrote:
The attached v5 version patch
has the changes for the same.
Thanks for updating the patches!
The current patches add nearly identical notice_receiver functions
in multiple places such as libpqwalreceiver.c and elsewhere. To avoid
duplicating the same
I encountered a problem in PostgreSQL 16:
In db1, there is a user table with fields id, name, phone, and createtime
db2 replicates the user table from db1 through logical replication, specifying
the fields as id, name, and createtime
Then, in db1, perform the following operation: alter table user
On Wed, Jul 16, 2025 at 10:47:03PM +0100, Dean Rasheed wrote:
> LGTM.
Committed. I ended up leaving out the note about needing to be a superuser
to use LOAD, mostly because I found myself spending way too much time
justifying it in the commit message.
--
nathan
Hi,
After studying proarray and lmgr more closely, I have found several
critical issues in the two patches and underestimated their complexity
and subtlety. Sorry for posting immature patches that may have created
noise.
I now realize that making lock acquisition— (void) LockAcquire(&tag,
ShareLo
On 2025/07/17 17:05, vignesh C wrote:
On Thu, 17 Jul 2025 at 11:18, Álvaro Herrera wrote:
Hi,
Shouldn't we be using a notice receiver rather than a notice processor?
I saw the following comment in code regarding PQsetNoticeProcessor
should be deprecated:
/*
* The default notice message
Hi,
On Thu, Jul 17, 2025 at 09:50:12AM +0900, Michael Paquier wrote:
> On Wed, Jul 16, 2025 at 11:41:09AM +, Bertrand Drouvot wrote:
>
> > As a way to prevent this to occur we might want to add extra input file(s)
> > parameter to generate-wait_event_types.pl (as proposed in [1]).
> >
> > [1
Hi all,
On 07.07.2025 11:17, Evgeny Voropaev wrote:
Do-side:
1. Having page ABC with several tuples.
2. Starting to perform insertion of new tuple
2.1. In the case of an inappropriate xid_base, trying to fit base
2.1.1 Freezing and pruning tuples without further repairing
fragmentation.
On Mon, Jul 7, 2025 at 3:27 PM Noah Misch wrote:
> Let's get rid of pg_dump's need to sort by OID, apart from catalog corruption
> scenarios.
+1. I had at one point believed that sorting by OID was a good way to
make dumps stable, but this disproves that theory. Sorting by logical
properties of t
Thanks Álvaro for the feedback.
On Thu, 17 Jul 2025 at 16:41, Álvaro Herrera
wrote:
>
> On 2025-Jul-17, Mahendra Singh Thalor wrote:
>
> > To pg_restore, we are giving a dump of pg_dumpall which has a
> > global.dat file and we have drop commands in the global.dat file so
> > when we are using 'g
On Fri, Jun 20, 2025 at 9:30 PM Amit Langote wrote:
> On Thu, May 22, 2025 at 5:12 PM Amit Langote wrote:
> > I have pushed out the revert now.
> >
> > Note that I’ve only reverted the changes related to deferring locks on
> > prunable partitions. I’m planning to leave the preparatory commits
> >
Hi Nathan,
> > Make sense. Here is the corrected patch.
>
> I trimmed this down some more while trying to keep the coverage the same.
LGTM except for a slight issue with double semicolons at
test_binaryheap.c:160. Here is the updated patch.
From 43718022ac914be9e4345597586e7b5225a14e06 Mon Sep 17
On 2025-Jul-17, zkbp712 wrote:
> Alternative (optional) syntax idea:
>
> INSERT INTO dosage (medication_id, amount, date)
> GENERATE RANGE (5, 3, '2025-04-01', '2025-04-30');
Here's a simple way to achieve this:
INSERT INTO dosage(medication_id, amount, date)
SELECT 5, 3, g
FROM generate_seri
Dear MySQL/PostgreSQL Development Teams,
My nameis T-RegExr (Tyrannosaurus RegExr), and I am a developer working
extensively withtime-series data such as medication dosages and other daily
records.
I would liketo propose a feature enhancement to simplify the insertion of
multiple rowsover a co
On Fri, Jul 11, 2025 at 7:01 PM Eduard Stefes wrote:
>
> On Wed, 2025-07-09 at 13:53 +0700, John Naylor wrote:
> > v3 still has direct-call and runtime-check paths. Let's keep only
> > USE_S390X_CRC32C_WITH_RUNTIME_CHECK and discard the direct call
> > configure checks. Once that's done I'll take
On Thu, Jul 17, 2025 at 9:56 AM Dilip Kumar wrote:
>
> On Fri, Jul 11, 2025 at 4:28 PM Amit Kapila wrote:
> >
> > On Thu, Jul 10, 2025 at 6:46 PM Masahiko Sawada
> > wrote:
> > >
> > > On Wed, Jul 9, 2025 at 9:09 PM Amit Kapila
> > > wrote:
> > >
> > > >
> > > > > I think that even with retai
On 2025-Jul-17, Mahendra Singh Thalor wrote:
> To pg_restore, we are giving a dump of pg_dumpall which has a
> global.dat file and we have drop commands in the global.dat file so
> when we are using 'globals-only', we are dropping databases as we have
> DROP commands.
> As of now, we don't have an
On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote:
workers, but there isn't an easy way to get more
workers.
On 7/16/25 11:01 PM, David Rowley wrote:
Is "alter table ... set (parallel_workers=N);" not easy enough?
It may be easy enough for one table, but that won't work for joins as
far as
Attaching the correct patch.
Sorry, I attached the wrong patch in my last email.
On Thu, 17 Jul 2025 at 15:46, Mahendra Singh Thalor wrote:
>
> Thanks Noah for the feedback.
>
> On Wed, 16 Jul 2025 at 05:50, Noah Misch wrote:
> >
> > On Thu, Jul 10, 2025 at 12:21:03AM +0530, Mahendra Singh Tha
Thanks Noah for the feedback.
On Wed, 16 Jul 2025 at 05:50, Noah Misch wrote:
>
> On Thu, Jul 10, 2025 at 12:21:03AM +0530, Mahendra Singh Thalor wrote:
> > On Wed, 9 Jul 2025 at 02:58, Noah Misch wrote:
> > > On Fri, Apr 04, 2025 at 04:11:05PM -0400, Andrew Dunstan wrote:
> > > > Thanks. I have
On Wed, Jul 16, 2025 at 8:51 AM cca5507 wrote:
>
> Hi,
>
> The v1-0002 in [1] will call ReportBackgroundWorkerExit() which will send
> SIGUSR1 to 'bgw_notify_pid', but it may already exit in HandleChildCrash(),
> is this ok?
>
Shall ReportBackgroundWorkerExit() be skipped for 'crashed' backgrou
On Thu, Jul 17, 2025 at 3:06 PM Amit Kapila wrote:
>
> On Wed, Jun 18, 2025 at 3:23 PM shveta malik wrote:
> >
> > On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jun 10, 2025 at 02:00:55PM -0700, Masahiko Sawada wrote:
> > > > > > > > > 0001 patch
On Wed, Jun 18, 2025 at 3:23 PM shveta malik wrote:
>
> On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Tue, Jun 10, 2025 at 02:00:55PM -0700, Masahiko Sawada wrote:
> > > > > > > > 0001 patch allows us to create a logical slot without WAL
> > > > > > > > reserva
Hi,
On Wed, 16 Jul 2025 at 18:24, Jacob Champion
wrote:
>
> On Wed, Jul 16, 2025 at 4:12 AM Nazir Bilal Yavuz wrote:
> > > For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We
> > > can rename it as a 'Meson Auto Feature Detection' but that is a bit
> > > longer. Do you have any
Hi,
On Wed, 16 Jul 2025 at 19:02, Andres Freund wrote:
>
> Hi,
>
> On 2025-07-16 14:12:22 +0300, Nazir Bilal Yavuz wrote:
> > On Fri, 11 Jul 2025 at 14:00, Nazir Bilal Yavuz wrote:
> > > On Thu, 10 Jul 2025 at 20:12, Jacob Champion
> > > wrote:
> > > >
> > > > On Thu, Jul 10, 2025 at 2:59 AM Na
Hi
On Thu, 17 Jul 2025 at 09:01, Nazir Bilal Yavuz wrote:
> Hi,
>
> On Thu, 10 Jul 2025 at 07:34, Thomas Munro wrote:
> >
> > On Thu, Jul 10, 2025 at 3:45 PM Thomas Munro
> wrote:
> > > [03:28:24.318] Program msgfmt found: NO
> >
> > Correction, that ^ is the reason it's not reached on the MSV
On Thu, 17 Jul 2025 at 11:18, Álvaro Herrera wrote:
>
> Hi,
>
> Shouldn't we be using a notice receiver rather than a notice processor?
I saw the following comment in code regarding PQsetNoticeProcessor
should be deprecated:
/*
* The default notice message receiver just gets the standard notice
Hi,
On Thu, 10 Jul 2025 at 07:34, Thomas Munro wrote:
>
> On Thu, Jul 10, 2025 at 3:45 PM Thomas Munro wrote:
> > [03:28:24.318] Program msgfmt found: NO
>
> Correction, that ^ is the reason it's not reached on the MSVC task,
> while -Dnls=disabled is the reason for the MinGW task. But the
> co
On 17/7/2025 00:58, Sami Imseih wrote:
this for better tracking. By adding a CachedPlanSource::cplan link, we
can establish a connection to the entire PlanCache entry instead of only
CachedPlan within a queryDesc and, consequently, make it accessible from
the executor. This would give an access t
On Wed, Jul 16, 2025, at 02:20, Rishu Bagga wrote:
> If we are doing this optimization, why not maintain a list of backends
> for each channel, and only wake up those channels?
Thanks for a contributing a great idea, it actually turned out to work
really well in practice!
The attached new v4 of t
On Wed, 16 Jul 2025 at 19:23, Dean Rasheed wrote:
>
> On 64-bit Linux with gcc 14.2 and native int128 support disabled I got
> the following results:
>
> Query 1:
> HEAD: 1404.096 ms
> Patch: 992.818 ms
>
> Query 2:
> HEAD: 1498.949 ms
> Patch: 935.654 ms
>
BTW, my other motivation fo
89 matches
Mail list logo
