On 24/7/2025 17:05, Tom Lane wrote:
> Andrei Lepikhov writes:
>> I see you have chosen a variant with a new enum instead of a pointer to
>> a plan cache entry. I wonder if you could write the arguments
>> supporting this choice?
>
> Pointing to a plan cache entry would often mean that the data
> s
On Wed, Jul 23, 2025 at 12:53 PM Zhijie Hou (Fujitsu)
wrote:
>
> Thanks for pushing. I have rebased the remaining patches.
>
+ * This function performs a full table scan instead of using indexes because
+ * index scans could miss deleted tuples if an index has been re-indexed or
+ * re-created du
On Tue, Jul 22, 2025 at 11:44 PM shveta malik wrote:
>
> On Tue, Jul 22, 2025 at 5:03 AM Masahiko Sawada wrote:
> >
> > Yes, I agree. The main patch focuses on the part where we
> > automatically change the effective WAL level upon the logical slot
> > creation and deletion (and potentially remov
On Fri, 2025-07-25 at 10:23 +0530, vignesh C wrote:
> Some patches marked as "Waiting on Author" were not updated to "Needs
> Review" after they posted a new version, so I haven't returned all of
> them. For the ones that are still open, I’ve sent a private email to
> the respective authors. Let’s
On Thu, 24 Jul 2025 at 22:28, Álvaro Herrera wrote:
>
> On 2025-Jul-24, Laurenz Albe wrote:
>
> > I just happened to look into https://commitfest.postgresql.org/52/
> > and saw plenty of "Active patches" there.
> >
> > I guess that's a consequence of the new rule established in [1].
>
> I don't kn
Hi Andrew,
On Fri, Jul 25, 2025 at 1:56 AM Andrew Dunstan wrote:
>
> Some years ago I gave a talk about $subject, but somehow it dropped off
> my radar. Now I'm looking at it again. The idea is to have a function
> (or set of functions) that would allow the user to get the DDL for any
> database
On Fri, Jul 25, 2025 at 9:23 AM Tom Lane wrote:
>
> Dilip Kumar writes:
> > OTOH, we can have a common function and pass object type as parameter
> > i.e. select pg_get_ddl('table', 'mytable'), with this the same
> > function can be extended for different object types.
>
> And you'll work regclas
On Wed, 23 Jul 2025 at 14:07, Peter Smith wrote:
> On Tue, Jul 22, 2025 at 8:12 PM Japin Li wrote:
> ...
>> 1.
>> I encountered another crash while checking VCI's internal relations.
>>
>> rm -rf demo
>> initdb -D demo
>> cat > shared_preload_libraries = 'vci'
>> max_w
Dilip Kumar writes:
> OTOH, we can have a common function and pass object type as parameter
> i.e. select pg_get_ddl('table', 'mytable'), with this the same
> function can be extended for different object types.
And you'll work regclass/regtype/etc into that how? AFAICS the
only way would involv
On Fri, Jul 25, 2025 at 3:06 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > I have been trying to think
> > of a reasonable interface for a single function, where we would pass in,
> > say, a catalog oid plus an object oid, and maybe some optional extra
> > arguments. That seems a bit fra
Hi,
The v2-0001 LGTM!
--
Regards,
ChangAo Chen
On Mon, Jul 21, 2025 at 09:40:02AM -0400, Robert Haas wrote:
> On Fri, Jul 18, 2025 at 3:17 PM Noah Misch wrote:
> > +* Sort by encoding, per pg_collation_name_enc_nsp_index.
> > Wherever
> > +* this changes dump order, restoring the dump fails
> > anyway. CREAT
On Thu, Jul 24, 2025 at 6:46 PM shveta malik wrote:
> Sounds reasonable.
> Thinking out loud, when cleaning up after a backend or background
> worker crash, process_pm_child_exit() is invoked, which subsequently
> calls both CleanupBackend() and HandleChildCrash(). After the cleanup
> completes, p
On Thu, Jul 24, 2025 at 07:38:46AM +, Bertrand Drouvot wrote:
> On Thu, Jul 24, 2025 at 09:34:45AM +0900, Michael Paquier wrote:
>> These numbers mean that we have enough room for 7 more builtins kinds,
>
> 11 for builtins kinds? (from 13 to 23)
>
> 9 for custom kinds including experimental? (
On Thu, Jul 24, 2025 at 01:14:47PM -0500, Sami Imseih wrote:
>> Sami Imseih writes:
That is not to say that I think 719dcf3c4 was a good idea: it looks
rather useless from here. It seems to me that the right place to
accumulate these sorts of stats is in CachedPlanSources, and I do
On Thu, Jul 24, 2025 at 7:52 PM Tomas Vondra wrote:
> Yeah, I forgot about that. Should be fixed in the v2. Admittedly I don't
> know that much about nbtree internals, so this is mostly copy pasting
> from verify_nbtree.
As long as the scan only moves to the right (never the left), and as
long as
On Fri, Jul 25, 2025 at 01:25:48AM +0200, Jim Jones wrote:
> On 24.07.25 21:23, Tom Lane wrote:
>> However, when testing on RHEL8 with libxml2 2.9.7, indeed
>> I get "Huge input lookup" with our current code but no
>> failure with f68d6aabb7e2^.
>>
>> The way I interpret these results is that in ol
On 7/24/25 16:40, Peter Geoghegan wrote:
> On Thu, Jul 24, 2025 at 7:19 AM Tomas Vondra wrote:
>> I got a bit bored yesterday, so I gave this a try and whipped up a patch
>> that adds two pgstattuple functins that I think could be useful for
>> analyzing index metrics that matter for prefetching.
On 24.07.25 21:23, Tom Lane wrote:
> Oh, wait ... the plot thickens! The above statement is true
> when testing on my Mac with libxml2 2.13.8 from MacPorts.
> With either HEAD or f68d6aabb7e2^, I get errors similar to
> what Erik just showed:
>
> ERROR: invalid XML content
> DETAIL: line 1: R
On Wed, Jul 2, 2025 at 06:23:52PM +0200, Daniel Gustafsson wrote:
> > On 2 Jul 2025, at 04:51, Steve Chavez wrote:
>
> > While updating an extension to support 18beta1, I stumbled on the removal
> > of `pg_attribute_noreturn()` in favor of `pg_noreturn`, which wasn't
> > mentioned in the relea
On Thu, Jul 24, 2025 at 09:56:00AM -0500, Nathan Bossart wrote:
> On Thu, Jul 24, 2025 at 03:50:17PM +0800, Julien Rouhaud wrote:
> > I was reading the visibility map code and noticed that
> > visibilitymap_get_status() wasn't updated in a892234f830e AFAICS (Cc Robert
> > and
> > Sawada-san) to re
On Wed, Jul 23, 2025, at 09:42, Joel Jacobson wrote:
> Great work in this thread. I'll try to help, definitively benchmarking,
> but will also try to load the new design into my brain, to get the
> correct mental model of it, so I can hopefully help with code review as
> well.
First, my apologies
On Thu, Jul 24, 2025 at 2:18 PM Jean-Christophe Arnu wrote:
> Could we perhaps improve the documentation by stating that return codes over
> 125 or (at least) 128 will lead to the server not starting?
>
> This may help people better understand the behaviour of the restore_command
> and quickly s
On Thu, 24 Jul 2025 at 16:49, Álvaro Herrera wrote:
> Hello,
>
> Since this is a whole new symbol, I'd rather you use the term WAL rather
> than Xlog ...
>
Fair enough
Dave
On Thu, 24 Jul 2025 at 17:05, Jacob Champion <
jacob.champ...@enterprisedb.com> wrote:
> On Thu, Jul 24, 2025 at 12:04 PM Dave Cramer wrote:
> > Patch attached
>
> +/* Replication Protocol sent by the primary */
> +
> +#define PqMsg_XlogData 'w'
> +#define PqMsg_PrimaryKeepAlive
Andrew Dunstan writes:
> I have been trying to think
> of a reasonable interface for a single function, where we would pass in,
> say, a catalog oid plus an object oid, and maybe some optional extra
> arguments. That seems a bit fragile, though. The alternative is that we
> have a separat
Hi,
I thought it might be interesting to revive this thread because the
improvements i saw from Thomas’s work, and even just simple prefetching of
bucket headers for the probe phase in-memory (to see the effect of
prefetching), are still showing nice improvements. Here are some results
for simple
Dear hackers,
We encountered an issue with restore_command when using scp on a v16
version. When SCP cannot connect to a host, it returns a return code of 255
(I won't discuss the decision to use such a return code). The return code of
the restore_command is tested at [1] by calling wait_result_is
On Thu, 2025-07-24 at 18:58 +0200, Álvaro Herrera wrote:
> On 2025-Jul-24, Laurenz Albe wrote:
>
> > I just happened to look into https://commitfest.postgresql.org/52/
> > and saw plenty of "Active patches" there.
>
> I *think* we should close the Waiting-on-author ones as Returned with
> Feedbac
On Thu, Jul 24, 2025 at 12:04 PM Dave Cramer wrote:
> Patch attached
+/* Replication Protocol sent by the primary */
+
+#define PqMsg_XlogData 'w'
+#define PqMsg_PrimaryKeepAlive 'k'
+#define PqMsg_PrimaryStatusUpdate 's'
+
+
+/* Replication Protocol sent by the standby */
+
+
On Wed, Jul 23, 2025, at 04:44, Thomas Munro wrote:
> On Wed, Jul 23, 2025 at 1:39 PM Joel Jacobson wrote:
>> In their patch, in asyn.c's SignalBackends(), they do
>> SendInterrupt(INTERRUPT_ASYNC_NOTIFY, procno) instead of
>> SendProcSignal(pid, PROCSIG_NOTIFY_INTERRUPT, procnos[i]). They don't
>
On Thu, 24 Jul 2025 at 21:46, Matheus Alcantara
wrote:
>
> On Thu Jul 24, 2025 at 5:26 PM -03, Andrew Dunstan wrote:
> > Some years ago I gave a talk about $subject, but somehow it dropped off
> > my radar. Now I'm looking at it again. The idea is to have a function
> > (or set of functions) that
Hello,
Since this is a whole new symbol, I'd rather you use the term WAL rather than
Xlog ...
--
Álvaro Herrera
On Thu Jul 24, 2025 at 5:26 PM -03, Andrew Dunstan wrote:
> Some years ago I gave a talk about $subject, but somehow it dropped off
> my radar. Now I'm looking at it again. The idea is to have a function
> (or set of functions) that would allow the user to get the DDL for any
> database object.
On 2025-07-21 Mo 8:53 PM, Noah Misch wrote:
I suspect this is going to end with a structured dump like we use on the
pg_dump (per-database) side. It's not an accident that v17 pg_restore doesn't
lex text files to do its job. pg_dumpall deals with a more-limited set of
statements than pg_dump
On Thu, 24 Jul 2025 at 16:26, Andrew Dunstan wrote:
> Some years ago I gave a talk about $subject, but somehow it dropped off
> my radar. Now I'm looking at it again. The idea is to have a function
> (or set of functions) that would allow the user to get the DDL for any
> database object. Obvious
Some years ago I gave a talk about $subject, but somehow it dropped off
my radar. Now I'm looking at it again. The idea is to have a function
(or set of functions) that would allow the user to get the DDL for any
database object. Obviously we already have some functions for things
like views an
I wrote:
> BTW, further testing shows that the same failure occurs at
> f68d6aabb7e2^. So AFAICS, the answer as to why the behavior
> changed there is that it didn't.
Oh, wait ... the plot thickens! The above statement is true
when testing on my Mac with libxml2 2.13.8 from MacPorts.
With either
كل ما تحتاج معرفته حول شهادة الأبوة بالمغرب
يمكنك تحميل الطلب من خلال الرابط المباشر
https://www.targir.com/2025/04/blog-post_14.html
معلومات شاملة لاستخراج شهادة الأبوة والإجراءات القانونية المرتبطة بها
ما هي شهادة الأبوة في المغرب؟
شهادة الأبوة وثيقة قانونية تصدر بناءً على حكم قضا
On Thu, Jul 24, 2025 at 12:48 PM Tomas Vondra wrote:
> I was thinking about this a bit more, and I think the CustomScan join
> essentially has to construct it's own info how to build the tuple, most
> likely in PlanCustomPath, because once setrefs.c does it's thing it's
> way too late for that I t
On Thu, 24 Jul 2025 at 05:34, Dave Cramer wrote:
>
>
>
> On Wed, 23 Jul 2025 at 11:40, Nathan Bossart
> wrote:
>
>> Committed. I noticed that there are several characters with no match in
>> protocol.h. It might be worth adding those.
>>
>> In walsender.c:
>>
>> 1537: pq_sendbyte(ctx
On 2025-07-24 05:12 +0200, Michael Paquier wrote:
> Switching back to the previous code, where we rely on
> xmlParseBalancedChunkMemory() fixes the issue. A quick POC is
> attached. It fails one case in check-world with SERIALIZE because I
> am not sure it is possible to pass down some options th
Michael Paquier writes:
>>> A customer has reported a regression with the parsing of rather large
>>> XML data, introduced by the set of backpatches done with f68d6aabb7e2
>>> & friends.
BTW, further testing shows that the same failure occurs at
f68d6aabb7e2^. So AFAICS, the answer as to why the
On 2025-07-24 20:10 +0200, Tom Lane wrote:
> The supplied test case hides important details in the error message.
> If you get rid of the exception block so that the error is reported
> in full, what you see is
>
> regression=# CREATE TEMP TABLE xmldata (id BIGINT PRIMARY KEY, message XML );
> CRE
Hi David
Thank you so much for the review! I have addressed the comments in the
attached v7 patch.
> 1. In cost_tidrangescan() you're dividing the total costs by the
> number of workers yet the comment is claiming that's CPU cost. I think
> this needs to follow the lead of cost_seqscan() and s
On Tue, Jul 22, 2025 at 11:17:42AM +0900, Michael Paquier wrote:
> On Mon, Jul 21, 2025 at 09:06:59PM -0500, Nathan Bossart wrote:
>> On Tue, Jul 22, 2025 at 10:37:05AM +0900, Michael Paquier wrote:
>>> This would not choke as long as the old cluster is at least at v10,
>>> but well why not.
>>
>>
On 24/07/2025 17:20, Damien Clochard wrote:
Le 21.07.2025 21:06, Greg Sabino Mullane a écrit :
Damien, maybe we can let the time ones go? Tom and I are not big fans
of those, and nobody else has stepped up to defend them.
Here's a second version with the following changes
- update tests
> One option might be to use a local hash table, keyed the same way as the
> shared pgss hash (excluding dbid), to handle cases where a backend has
> more than one active cached plan. Then at ExecutorEnd, the local entry could
> be looked up and passed to pgss_store. Not sure if this is worth the e
> Sami Imseih writes:
> >> That is not to say that I think 719dcf3c4 was a good idea: it looks
> >> rather useless from here. It seems to me that the right place to
> >> accumulate these sorts of stats is in CachedPlanSources, and I don't
> >> see how this helps. What likely *would* help is some
Robert Haas writes:
> Since Peter Eisentraut's commit
> 473a575e05979b4dbb28b3f2544f4ec8f184ce65 on January 25 of this year,
> attempting to set synchronous_standby_names to a value that doesn't
> parse results in a generic and uninformative error message:
Oops.
> Apparently, our tests do not ex
On Wed, 2025-07-23 at 19:11 -0700, Jeff Davis wrote:
> The patch feels a bit over-engineered, but I'd like to know what you
> think. It would be great if you could test/debug the windows NLS-
> enabled paths.
Let me explain how it ended up looking over-engineered, and perhaps
someone has a simpler
I wrote:
> Michael Paquier writes:
>> A customer has reported a regression with the parsing of rather large
>> XML data, introduced by the set of backpatches done with f68d6aabb7e2
>> & friends.
> Bleah.
The supplied test case hides important details in the error message.
If you get rid of the e
On Wed, Jul 9, 2025 at 2:51 PM Mahendra Singh Thalor wrote:
> > This drops all databases:
> >
> > pg_dumpall --clean -Fd -f /tmp/dump
> > pg_restore -d template1 --globals-only /tmp/dump
> >
> > That didn't match my expectations given this help text:
> >
> > $ pg_restore --help|grep global
> > -
Since Peter Eisentraut's commit
473a575e05979b4dbb28b3f2544f4ec8f184ce65 on January 25 of this year,
attempting to set synchronous_standby_names to a value that doesn't
parse results in a generic and uninformative error message:
[robert.haas ~]$ postgres -c synchronous_standby_names='"foo'
2025-07
On Thu, Jul 17, 2025 at 03:46:41PM +0530, Mahendra Singh Thalor wrote:
> 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
On Thu, Jul 24, 2025 at 7:03 AM Fabrice Chapuis wrote:
> After upgrading from Postgres version 14 to Postgres version 17, I noticed
> that some "grantor" roles (admin_role) disappear when exporting all roles
> with grants
>
> /usr/pgsql-17/bin/pg_dumpall --globals-only --quote-all-identifiers
Sami Imseih writes:
>> That is not to say that I think 719dcf3c4 was a good idea: it looks
>> rather useless from here. It seems to me that the right place to
>> accumulate these sorts of stats is in CachedPlanSources, and I don't
>> see how this helps. What likely *would* help is some hooks in
Aidar Imamov writes:
> Recently, while working with hash tables in dynahash.c, I noticed
> something weird.
> When a hash table is already created in shared memory, and the another
> process
> calls hash_create attempting to attach to it, it seems like the
> HASH_FIXED_SIZE
> flag gets lost.
Y
On 2025-Jul-24, Laurenz Albe wrote:
> I just happened to look into https://commitfest.postgresql.org/52/
> and saw plenty of "Active patches" there.
>
> I guess that's a consequence of the new rule established in [1].
I don't know about the rest of it, but I moved all the entries in the
"Bug Fix
> Andrei Lepikhov writes:
> > I see you have chosen a variant with a new enum instead of a pointer to
> > a plan cache entry. I wonder if you could write the arguments
> > supporting this choice?
>
> Pointing to a plan cache entry would often mean that the data
> structure as a whole is circular (
On 7/24/25 15:57, Robert Haas wrote:
> On Thu, Jul 24, 2025 at 9:04 AM Tomas Vondra wrote:
>> With this patch, my custom join can simply do
>>
>> econtext->ecxt_outertuple = outer;
>> econtext->ecxt_innertuple = inner;
>>
>> return ExecProject(node->js.ps.ps_ProjInfo);
>>
>> and it wor
Hi hackers,
Recently, while working with hash tables in dynahash.c, I noticed
something weird.
When a hash table is already created in shared memory, and the another
process
calls hash_create attempting to attach to it, it seems like the
HASH_FIXED_SIZE
flag gets lost.
For example, if you st
Le 21.07.2025 21:06, Greg Sabino Mullane a écrit :
Damien, maybe we can let the time ones go? Tom and I are not big fans
of those, and nobody else has stepped up to defend them.
Sure !
Here's a second version with the following changes
- remove time and timetz variants
- disallow infinity bo
Andrei Lepikhov writes:
> I see you have chosen a variant with a new enum instead of a pointer to
> a plan cache entry. I wonder if you could write the arguments
> supporting this choice?
Pointing to a plan cache entry would often mean that the data
structure as a whole is circular (since a plan
I just happened to look into https://commitfest.postgresql.org/52/
and saw plenty of "Active patches" there.
I guess that's a consequence of the new rule established in [1].
Are they supposed to stay like that? Should they be closed?
If yes, "Returned with Feedback"? Or some new state "Abandoned
On Thu, Jul 24, 2025 at 03:50:17PM +0800, Julien Rouhaud wrote:
> I was reading the visibility map code and noticed that
> visibilitymap_get_status() wasn't updated in a892234f830e AFAICS (Cc Robert
> and
> Sawada-san) to return an empty set of flags rather than false in one code
> path,
> so sim
On Thu, Jul 24, 2025 at 7:19 AM Tomas Vondra wrote:
> I got a bit bored yesterday, so I gave this a try and whipped up a patch
> that adds two pgstattuple functins that I think could be useful for
> analyzing index metrics that matter for prefetching.
This seems quite useful.
I notice that you'r
On Thu, Jul 24, 2025 at 7:52 AM Bertrand Drouvot
wrote:
> Well, the idea was more: as we speak about "wait" events then it would make
> sense to add their duration. And then, to have meaningful data to interpret
> the
> durations then it would make sense to add the counters. So that one could
>
On Thu, Jul 24, 2025 at 11:54:10AM +0200, Álvaro Herrera wrote:
> Yeah, thanks for taking a look. That duplication is just me being dumb.
> Here's a version without that. The only thing that needed to change was
> changing "CLUSTER opt_verbose" to "CLUSTER VERBOSE" so that the
> unadorned CLUSTER
Hi,
Thanks for the update! I tried v5 and it returns the expected results on
my laptop, same as before.
Just two further remarks for your consideration.
+
+ number of OS memory page for this buffer
+
Let's capitalize the first letter here.
+-- Check that the functions
On 24/07/2025 15:44, jian he wrote:
just want to confirm my understanding of ``[ FORMAT ]``.
SELECT CAST('2022-13-32' AS DATE FORMAT '-MM-DD' DEFAULT NULL ON
CONVERSION ERROR);
will return NULL.
because ``SELECT to_date('2022-13-32', '-MM-DD');``
will error out, so the above query wi
On 24/07/2025 03:22, jian he wrote:
+SELECT CAST('a' as int DEFAULT sum(1) ON CONVERSION ERROR); --error
+SELECT CAST('a' as int DEFAULT sum(1) over() ON CONVERSION ERROR); --error
This seems like an arbitrary restriction. Can you explain why this is
necessary? Those same expressions are a
On Thu, Jul 24, 2025 at 9:04 AM Tomas Vondra wrote:
> With this patch, my custom join can simply do
>
> econtext->ecxt_outertuple = outer;
> econtext->ecxt_innertuple = inner;
>
> return ExecProject(node->js.ps.ps_ProjInfo);
>
> and it works.
This doesn't seem like the right approach
On Tue, Jul 22, 2025 at 8:26 PM Vik Fearing wrote:
>
>
> On 22/07/2025 12:19, jian he wrote:
> > On Tue, Jul 22, 2025 at 2:45 PM Vik Fearing
> > wrote:
> >> It was accepted into the standard after 2023 was released. I am the
> >> author of this change in the standard, so feel free to ask me any
Hi,
I've been experimenting with executor nodes inspired by papers on
executor robustness (think "Algorithms that don't explode if an estimate
is off."). And I decided to use the CustomScan API, because it seemed
like an ideal solution for my experiments - convenient, isolated, easy
to try on othe
On 24/7/2025 09:03, Michael Paquier wrote:
> On Wed, Jul 23, 2025 at 12:15:06PM +0900, Michael Paquier wrote:
>> A small thing that would be cleaner is to split the patch into two
>> parts: one for the in-core backend addition and a second for PGSS.
>> Code paths are different, so it's simple to do
On Wed, Jul 23, 2025 at 8:01 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > Dear Ajin,
> >
> > Thanks for the patch. Firstly let me confirm my understanding. While
> > altering the
> > subscription, locks are acquired with below ordering:
> >
>
> I forgot to confirm one point. For which branch should be
Hi,
Thank you for working on this!
On Wed, 23 Jul 2025 at 22:00, Tom Lane wrote:
>
> I'm disinclined to put in a huge amount of effort looking for the
> worst case. We established long ago that we weren't going to
> optimize for 32-bit anymore. So as long as this doesn't completely
> tank perf
Hi,
On Wed, Jul 23, 2025 at 11:38:07AM -0400, Robert Haas wrote:
> On Tue, Jul 22, 2025 at 8:24 AM Bertrand Drouvot
> wrote:
> > So based on the cycles metric I think it looks pretty safe to implement for
> > the
> > whole majority of classes.
>
> I'm not convinced that this is either cheap eno
On Thu, 24 Jul 2025 at 16:49, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Michael,
>
> Sorry for the late reply.
>
> > So, what you are doing here is changing the behavior of the check in
> > recoveryStopsAfter(), with the addition of one exit path based on
> > EndRecPtr if recovery_target_inclusive i
Hi,
On Tue, Jul 22, 2025 at 10:07:30AM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-07-22 12:24:46 +, Bertrand Drouvot wrote:
> > Anyway, let's forget about eBPF, I ran another experiment by counting the
> > cycles
> > with:
> >
> > static inline uint64_t rdtsc(void) {
> > uint32_t lo,
On 7/23/25 02:37, Tomas Vondra wrote:
> ...
>
>>> Thanks. I wonder how difficult would it be to add something like this to
>>> pgstattuple. I mean, it shouldn't be difficult to look at leaf pages and
>>> count distinct blocks, right? Seems quite useful.
>>
>> I agree that that would be quite usefu
Dear Michael,
Sorry for the late reply.
> So, what you are doing here is changing the behavior of the check in
> recoveryStopsAfter(), with the addition of one exit path based on
> EndRecPtr if recovery_target_inclusive is false, to leave a bit
> earlier in case if we don't have a follow-up recor
Hi,
After upgrading from Postgres version 14 to Postgres version 17, I noticed
that some "grantor" roles (admin_role) disappear when exporting all roles
with grants
/usr/pgsql-17/bin/pg_dumpall --globals-only --quote-all-identifiers
--binary-upgrade --no-sync -f /var/lib/pgsql/roles_bin.sql
Con
On 24.07.25 03:14, David Rowley wrote:
So, I think that means we can adjust the meson build scripts to pass
/std:c11 when building in MSVC. The attached patch does this and
defines a pg_builtin_constant() macro and adjusts ereport_domain() to
use it.
Please review my patch at
https://www.postg
On Wed, Jul 23, 2025 at 4:54 AM Tom Lane wrote:
>
> Corey Huinker writes:
> > I'm interested in this feature, specifically whether the optimizer uses the
> > index in situations where the expression is used rather than the virtual
> > column name.
>
> Hmm, I kinda think we should not do this. Th
Hi,
On Tue, 22 Jul 2025 at 03:56, Michael Paquier wrote:
>
> On Mon, Jul 21, 2025 at 11:53:00AM +0300, Nazir Bilal Yavuz wrote:
> > I realized that we actually don't trim the file, we do the opposite;
> > read the file from both ends. Sorry for not realizing earlier. I will
> > update the remaini
Hello,
On 2025-Jul-23, Andres Freund wrote:
> On 2025-07-23 19:59:52 +0200, Álvaro Herrera wrote:
> > ... so using the same set of productions, I can rewrite the current
> > CLUSTER rule in this way and it won't be a problem for the REPACK
> > changes.
>
> But it comes at the price of henceforth
On Thu, Jul 24, 2025 at 2:39 PM Fujii Masao wrote:
>
> On Thu, Jul 17, 2025 at 6:58 PM shveta malik wrote:
> >
> > 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_pi
On Wed, 23 Jul 2025 at 11:40, Nathan Bossart
wrote:
> Committed. I noticed that there are several characters with no match in
> protocol.h. It might be worth adding those.
>
> In walsender.c:
>
> 1537: pq_sendbyte(ctx->out, 'w');
> 2353: case 'r':
> 2357:
On Wed, Jun 11, 2025 at 5:26 PM Andrey Rudometov
wrote:
>
> Good day, hackers.
>
> Reading through changes committed in master, I noticed that after
> CleanupBackend/CleanupBackroundworker refactor background workers will fail to
> start again after postgres' restart with restart_after_crash = on.
On Thu, Jul 17, 2025 at 6:58 PM shveta malik wrote:
>
> 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?
>
On Tue, Jul 22, 2025 at 11:30 AM Patrick Stählin wrote:
>
> Hi!
>
> On 4/7/25 11:27 PM, Tomas Vondra wrote:
> >
> > I've pushed all three parts of v29, with some additional corrections
> > (picked lower OIDs, bumped catversion, fixed commit messages).
>
> While building the PG18 beta1/2 packages I
Hi,
I was reading the visibility map code and noticed that
visibilitymap_get_status() wasn't updated in a892234f830e AFAICS (Cc Robert and
Sawada-san) to return an empty set of flags rather than false in one code path,
so simple patch attached. Both have the same value so that likely explains why
Dear Vignesh,
Thanks for working the project. Here are my comments only for 0001 and 0002.
Sorry if my points have already been discussed, this thread is too huge to
catchup for me :-(.
01.
Do we have to document the function and open to users? Previously it was not.
Another example is pg_get_pu
Hi,
On Thu, Jul 24, 2025 at 09:34:45AM +0900, Michael Paquier wrote:
> On Wed, Jul 23, 2025 at 12:00:55PM -0400, Andres Freund wrote:
> > On 2025-07-23 09:54:12 +0900, Michael Paquier wrote:
> >> Noted. I was wondering originally if the threshold for the builtin
> >> and custom kinds should be lo
On Wed, Jul 23, 2025 at 12:15:06PM +0900, Michael Paquier wrote:
> A small thing that would be cleaner is to split the patch into two
> parts: one for the in-core backend addition and a second for PGSS.
> Code paths are different, so it's simple to do.
I have been looking at the backend part of th
97 matches
Mail list logo
