Re: [PATCH] Proposal: Improvements to PDF stylesheet and table column widths

Thank you Kuroda-san. > To confirm, generated pdf with current setting is left slide, and it would > become like right side, is it correct? I prefer right one. Sorry for the lack of explanation. That's right, the version on the left is the previous version, and the version on the right has the pa

Re: queryId constant squashing does not support prepared statements

On Thu, May 29, 2025 at 11:30:12AM +0900, Michael Paquier wrote: > I still need to review the rest of the patch series.. The test additions done in v7-0002 look sensible here. --- In the following two queries the operator expressions (+) and (@) have --- different oppno, and will be given differe

Re: Proposal: Make cfbot fail on patches not created by "git format-patch"

On Thursday, May 29, 2025, Ashutosh Bapat wrote: > > On Fri, May 16, 2025 at 1:45 PM Jelte Fennema-Nio wrote: > >> On Fri, 16 May 2025 at 12:24, Jacob Champion >> wrote: >> > >> > On Fri, May 16, 2025 at 12:12 PM Tom Lane wrote: >> > > That outcome seems entirely horrible to me. If you want to

RE: [PATCH] Proposal: Improvements to PDF stylesheet and table column widths

Dear Saito-san, > Since my previous email included many changes and may have been > difficult to review, I would like to propose a much simpler change > this time. I feel this is a reasonable approach. If needed, you can create set of patches and can discuss from 0001. See [1]. > I suggest setti

Re: Proposal: Make cfbot fail on patches not created by "git format-patch"

On Fri, May 16, 2025 at 1:45 PM Jelte Fennema-Nio wrote: > On Fri, 16 May 2025 at 12:24, Jacob Champion > wrote: > > > > On Fri, May 16, 2025 at 12:12 PM Tom Lane wrote: > > > That outcome seems entirely horrible to me. If you want to flag the > lack > > > of a commit message somehow, fine, bu

Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

Hi Timur. On Thu, May 29, 2025 at 11:30 PM Timur Magomedov wrote: > > Hi Peter, > I've noticed there are changes in Postgres code v4 patch that rollback > the commit [1]. That commit optimizes TupleHashEntryData struct size > and amount of memory allocations which improves performance (see > disc

Re: Proposal: Job Scheduler

On Thu, May 29, 2025 at 6:17 PM Nikolay Samokhvalov wrote: > pg_cron is written in Go, and it's already present in most managed > Postgres platforms. Why not to bring it to Postgres core so we could then > use it to improve developer experience of dealing with partitioning? > I mean, in C, of co

Re: Expression push down from Join Node to below node.

Shubhankar Anand Kulkarni writes: Hi, > As seen, the expression got pushed down to respective foreign scan, reducing > the overall query time reduced > significantly, but there is an increase in the memory footprint. That's great on the query time improvement. When you say the memory footprin

Re: Proposal: Job Scheduler

On Thu, Jun 6, 2024 at 5:31 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Thu, Jun 06, 2024 at 12:53:38PM GMT, Alvaro Herrera wrote: > > On 2024-Jun-06, Dave Page wrote: > > > > > It's this kind of choice that means it's unlikely we'd include any one > > > option in PostgreSQL, much like

Re: Add comment explaining why queryid is int64 in pg_stat_statements

On Fri, 30 May 2025 at 11:35, Michael Paquier wrote: > Thanks, Nathan. Let's proceed with the change then. David, would you > prefer handling the patch you have written by yourself for the query > ID part? Yes. I'll look at that again shortly. David

Re: Add comment explaining why queryid is int64 in pg_stat_statements

On Thu, May 29, 2025 at 09:28:35AM -0500, Nathan Bossart wrote: > On Thu, May 29, 2025 at 01:53:07PM +0900, Michael Paquier wrote: >> Now, I don't really want to take a leap of faith without the RMT being >> OK with that now that we are in beta1. > > After reading through this thread and the lates

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Thu, May 29, 2025 at 02:15:22PM -0400, Tom Lane wrote: > Feike Steenbergen writes: > > pg_restore may have issues though, as it will run these functions > > for GENERATED STORED columns? > > pg_restore is already fairly exposed, as it will run tables' CHECK > constraints, index expressions, et

Re: Persist injection points across server restarts

On Thu, May 29, 2025 at 01:17:21PM +0530, Rahila Syed wrote: > After applying the v3-patches, I see failure like these: > macOS - Sonoma - Meson - Cirrus CI > > Windows - Server 2019, VS 2019 - Meson & ninja - Cirrus CI >

Re: Extended Statistics set/restore/clear functions.

On Mon, Mar 31, 2025 at 1:10 AM Corey Huinker wrote: > Just rebasing. > At pgconf.dev this year, the subject of changing the formats of pg_ndistinct and pg_depdentencies came up again. To recap: presently these datatypes have no working input function, but would need one for statistics import t

Re: Improve explicit cursor handling in pg_stat_statements

> > postgres_fdw, as an example, in which cursor name get reused > > for different queries. Notice below "c1" and "c2" is reused for different > > queries, so now what underlying sql is FETCH, i.e. FETCH 100 FROM c1 > > referring > > to? v2-0001 does not help us with the FETCH problem > > because

Re: Fixing memory leaks in postgres_fdw

On Thu, May 29, 2025 at 2:02 PM Tom Lane wrote: > > I wrote: > > Pushed v5-0001, and here are rebased versions of the other four > > patches, mostly so that the cfbot knows what is the patch-of-record. > > Finally, here's a minimalistic version of the original v1-0001 > patch that I think we could

Re: Fix slot synchronization with two_phase decoding enabled

On Thu, May 29, 2025 at 2:00 AM Nisha Moond wrote: > > On Wed, May 28, 2025 at 6:10 AM Masahiko Sawada wrote: > > > > On Sun, May 25, 2025 at 11:34 PM Nisha Moond > > wrote: > > > > > > to > > > On Fri, May 23, 2025 at 10:06 PM Masahiko Sawada > > > wrote: > > > > > > > > > > > > Here are re

Re: track generic and custom plans in pg_stat_statements

It turns out that 1722d5eb05d8e reverted 525392d5727f, which made CachedPlan available in QueryDesc and thus available to pgss_ExecutorEnd. So now we have to make CachedPlan available to QueryDesc as part of this change. The reason the patch was reverted is related to a memory leak [0] in the Buil

get speed help

On Thursday, May 29, 2025, Dias Thomas wrote: > Hi all, > if 2 records per second, add speed, 4 gb ram, 1 index, is it > faster than postgres? > > Why didn’t you just reply to the people who answered you on -general when you asked this same “question”? This is a list for discussing the de

Re: track generic and custom plans in pg_stat_statements

> It turns out that 1722d5eb05d8e reverted 525392d5727f, which > made CachedPlan available in QueryDesc and thus > available to pgss_ExecutorEnd. I also forgot to mention, the revert also removes the generic plan is_reused logic: ``` boolis_reused; /* is it a reused gener

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Thu, 29 May 2025 at 20:30, Tom Lane wrote: > > Matthias van de Meent writes: > > On Thu, 29 May 2025 at 15:44, Robert Haas wrote: > >> But so far - apart from this feature - we > >> have managed to avoid making it categorically unsafe for the superuser > >> to run "SELECT * FROM table" > > >

get speed help

Hi all, if 2 records per second, add speed, 4 gb ram, 1 index, is it faster than postgres?

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Thu, 29 May 2025 at 15:44, Robert Haas wrote: > But so far - apart from this feature - we > have managed to avoid making it categorically unsafe for the superuser > to run "SELECT * FROM table" With CREATE RULE [0], a table owner can redefine what happens during e.g. SELECT * FROM table. This

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

Matthias van de Meent writes: > On Thu, 29 May 2025 at 15:44, Robert Haas wrote: >> But so far - apart from this feature - we >> have managed to avoid making it categorically unsafe for the superuser >> to run "SELECT * FROM table" > With CREATE RULE [0], a table owner can redefine what happens

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

Feike Steenbergen writes: > pg_restore may have issues though, as it will run these functions > for GENERATED STORED columns? pg_restore is already fairly exposed, as it will run tables' CHECK constraints, index expressions, etc. I don't think GENERATED STORED makes that picture much worse. As

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Thu, 29 May 2025 at 15:43, Robert Haas wrote: > that would also imply, > for example, that there's no way to run a pg_dump without letting any > user on the system obtain superuser privileges. I checked, pg_dump seems safe, it doesn't extract the values, even when using --column-inserts. pg_r

Re: Fixing memory leaks in postgres_fdw

I wrote: > Pushed v5-0001, and here are rebased versions of the other four > patches, mostly so that the cfbot knows what is the patch-of-record. Finally, here's a minimalistic version of the original v1-0001 patch that I think we could safely apply to fix the DirectModify problem in the back bran

Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

On 2025/05/29 11:46, Masahiro Ikeda wrote: Thanks for your feedback. I've attached the updated patches. I've pushed the 0001 patch. Thanks! What do you think about adding new error messages specifically for partitioned indexes? If the target is a partitioned index, the error messages wou

Re: PG 18 release notes draft committed

On Thu, May 29, 2025 at 09:42:30AM -0400, Melanie Plageman wrote: > > > "Add an asynchronous I/O subsystem" > > > > > > I notice we don't call out any of the operations where users could > > > expect to see asynchronous IO be used. Some were enabled in 17 (like > > > sequential scans, analyze, and

Re: [PING] fallocate() causes btrfs to never compress postgresql files

On Wed, 28 May 2025, Tomas Vondra wrote: Isn't guaranteeing success of a write a general issue with compressed filesystem? Why is posix_fallocate() any special in this regard? Shouldn't the filesystem be defensive and assume the data is not compressible? Or maybe just return EOPNOTSUPP when in d

Re: Warning -Wclobbered in PG_TRY(...)

I wrote: > Really? I don't have a current C standard at hand, but POSIX-2024 [1] > claims to be aligned with the C standard for this, Ooops, forgot to attach the URL: [1] https://pubs.opengroup.org/onlinepubs/9799919799/ Go there and use the "keyword search" for "longjmp" --- they don't seem to

Re: Correcting freeze conflict horizon calculation

On Thu, May 29, 2025 at 10:57 AM Melanie Plageman wrote: > However, we calculate the snapshot conflict horizon for the > prune/freeze record in master/17 and the freeze record in 16 before > updating all-frozen and all-visible. That means the horizon may be too > aggressive if the page cannot actu

Re: Warning -Wclobbered in PG_TRY(...)

Maxim Orlov writes: > On Thu, 29 May 2025 at 14:14, Tom Lane wrote: >> -Wclobbered would be really useful if it worked --- but sadly, >> on practically all gcc and clang versions, those warnings have >> nearly nothing to do with reality. We typically ignore them. > Yes, in the vast majority of

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

"David G. Johnston" writes: > Just to make sure we are on the same page as to who IS supposed to be > "current_user" within these functions - it should be the table owner, right? If we could make that happen (ie, run the generated-column expressions as the table owner), it would likely be a suffi

Re: Fixing memory leaks in postgres_fdw

I wrote: > Yeah, it's not intended to be done in that order: the v5-0001 patch is > an independent thing. I anticipate I'll have to rebase the other > patches after I push v5-0001. Pushed v5-0001, and here are rebased versions of the other four patches, mostly so that the cfbot knows what is the

Correcting freeze conflict horizon calculation

Hi, I noticed while writing another patch that I think there might be an issue/oversight with how the snapshot conflict horizon is calculated for the prune/freeze WAL record in master/17 and the freeze WAL record in 16. In code to determine whether or not to freeze tuples on the page in phase I o

Re: Warning -Wclobbered in PG_TRY(...)

On Thu, 29 May 2025 at 14:14, Tom Lane wrote: > -Wclobbered would be really useful if it worked --- but sadly, > on practically all gcc and clang versions, those warnings have > nearly nothing to do with reality. We typically ignore them. Yes, in the vast majority of cases. But I believe this

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Thu, May 29, 2025 at 6:43 AM Robert Haas wrote: > > Point being: this > feature will need to be fixed in some way that avoids further > expanding the set of things that a superuser must not ever do for fear > of giving away their privileges accidentally, or else it will need to > be reverted.

POC: Carefully exposing information without authentication

Proposal: Allow a carefully curated selection of information to be shown without authentication. A common task for an HA system or a load balancer is to quickly determine which of your Postgres clusters is the primary, and which are the replicas. The canonical way to do this is to log in to each s

Re: Add comment explaining why queryid is int64 in pg_stat_statements

On Thu, May 29, 2025 at 01:53:07PM +0900, Michael Paquier wrote: > On Thu, May 22, 2025 at 01:01:14PM +0900, Michael Paquier wrote: >> I have added an open item about the plan ID part as it applies to v18, >> adding the RMT in CC to get an opinion. If we cannot get a consensus >> on all that, lett

Re: autoprewarm_dump_now

On Thu, May 29, 2025 at 9:21 AM Tom Lane wrote: > Is that solving a real-world problem? If it is, shouldn't we be > looking for a different approach that doesn't require such a huge > amount of memory? Upthread, Heikki said that this function currently fails with shared_buffers>409GB. While I'm

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Mon, May 26, 2025 at 10:52 AM Feike Steenbergen wrote: > On Mon, 26 May 2025 at 16:17, jian he wrote: > > calling exploit_generated.exploit by normal user or superuser the > > effects are different, > > that by definition is not IMMUTABLE. > > Yeah, i know this is *wrong* usage of IMMUTABLE, t

Re: PG 18 release notes draft committed

On Wed, May 28, 2025 at 10:49 PM Bruce Momjian wrote: > > On Wed, May 28, 2025 at 08:07:20PM -0400, Melanie Plageman wrote: > > Yes, I can now see it is two items so I have split it into two in the > attached, applied patch. In a separate commit I adjusted the docs for > log_connections to more c

Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

Hi Peter, I've noticed there are changes in Postgres code v4 patch that rollback the commit [1]. That commit optimizes TupleHashEntryData struct size and amount of memory allocations which improves performance (see discussion [2]). Can we use leave TupleHashEntryData as is and make new VCI-specific

Re: autoprewarm_dump_now

Daria Shanina writes: > I have made a patch, now we can allocate more than 1 GB of memory for the > autoprewarm_dump_now function. Is that solving a real-world problem? If it is, shouldn't we be looking for a different approach that doesn't require such a huge amount of memory?

Re: Fixing memory leaks in postgres_fdw

Matheus Alcantara writes: > The only point is that I've just tried to apply the v5-0001 on top of > the previous v4-000X patches and is raising an error: > git am v5-0001-Avoid-resource-leaks-when-a-dblink-connection-fai.patch > Applying: Avoid resource leaks when a dblink connection fails. > er

Re: autoprewarm_dump_now

Hello! I have made a patch, now we can allocate more than 1 GB of memory for the autoprewarm_dump_now function. Best regards, Daria Shanina пт, 4 апр. 2025 г. в 19:36, Robert Haas : > On Fri, Apr 4, 2025 at 12:17 PM Melanie Plageman > wrote: > > Unrelated to this problem, but I wondered why

Re: Fixing memory leaks in postgres_fdw

On 28/05/25 17:56, Tom Lane wrote: > I wrote: >> Having said that, the idea that this sequence is OOM-safe is pretty >> silly anyway, considering that createNewConnection does a pstrdup, >> and creates a new hashtable entry which might require enlarging the >> hashtable, and for that matter might e

Re: Foreign key validation failure in 18beta1

On Thu, May 29, 2025 at 5:57 PM jian he wrote: > > On Thu, May 29, 2025 at 8:12 PM Amul Sul wrote: > > > > > >> > [...] > > > The attached *draft* patch is based on your idea. > > > > > > The idea is that we only need to conditionally do > > > ``tab->constraints = lappend(tab->constraints, newcon

Re: Replication slot is not able to sync up

On Wed, May 28, 2025 at 12:15 AM Zhijie Hou (Fujitsu) wrote: > I think the SQL API was mainly intended for testing and debugging purposes > where controlled sync operations are useful. For production use, the slotsync > worker (with sync_replication_slots=on) is recommended because it > automatic

Re: Foreign key validation failure in 18beta1

On Thu, May 29, 2025 at 8:12 PM Amul Sul wrote: > > > >> > [...] > > The attached *draft* patch is based on your idea. > > > > The idea is that we only need to conditionally do > > ``tab->constraints = lappend(tab->constraints, newcon);`` within > > QueueFKConstraintValidation. > > but the catalog

Re: PG 18 release notes draft committed

On 5/29/25 07:53, Álvaro Herrera wrote: On 2025-May-28, Bruce Momjian wrote: Sure, we can just link to: https://www.postgresql.org/list/pgsql-committers/ and they can choose any recent commit. IMO this is useless, because there's no assurance that the "recent commit" they choose is

Re: Foreign key validation failure in 18beta1

On Thu, May 29, 2025 at 12:38 PM jian he wrote: > > On Wed, May 28, 2025 at 8:38 PM Tender Wang wrote: > > > > > > > > Alvaro Herrera 于2025年5月28日周三 20:26写道： > >> > >> On 2025-May-28, Tender Wang wrote: > >> > >> > [...] > The attached *draft* patch is based on your idea. > > The idea is that we

Re: PG 18 release notes draft committed

On 2025-May-28, Bruce Momjian wrote: > Sure, we can just link to: > > https://www.postgresql.org/list/pgsql-committers/ > > and they can choose any recent commit. IMO this is useless, because there's no assurance that the "recent commit" they choose is actually following good practices.

Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

On Tue, May 27, 2025 at 2:26 PM Amit Kapila wrote: > Yeah, we should be able to change ABI during beta, but I can't comment > on the idea of effective_restart_lsn without seeing the patch or a > detailed explanation of this idea. Could you, please, check the patch [1]. It implements this idea ex

Re: Amcheck verification of GiST and GIN

On Mon, May 26, 2025 at 7:28 PM Arseniy Mukhin wrote: > On Mon, May 26, 2025 at 1:27 PM Tomas Vondra wrote: > > Also, I've noticed that the TAP test passes even with some (most) of the > > verify_gin.c changes reverted. See the 0002 patch - this does not break > > the TAP test. Of course, that do

Re: [PATCH] Fix replica identity mismatch for partitioned tables with publish_via_partition_root

Hi, Thank you for the feedback. I would like to clarify that the current behavior does not break replication between PostgreSQL instances. The logical replication stream is still accepted by the subscriber, and the data is applied correctly. However, the protocol semantics are violated, which may

Re: Warning -Wclobbered in PG_TRY(...)

m.litsa...@postgrespro.ru writes: > Does it makes sense to add volatile attribute to the _do_rethrow or > should we just ignore that -Wclobbered warning? -Wclobbered would be really useful if it worked --- but sadly, on practically all gcc and clang versions, those warnings have nearly nothing to

Re: Correct documentation for protocol version

On Thu, 29 May 2025 at 06:18, Jelte Fennema-Nio wrote: > On Thu, 29 May 2025 at 00:29, Dave Cramer wrote: > > I found another place where the docs should be updated. The Changes > since Protocol 2.0 > > I think it makes sense to have a dedicated page like this that lists > any protocol changes t

Re: Correct documentation for protocol version

On Thu, 29 May 2025 at 00:29, Dave Cramer wrote: > I found another place where the docs should be updated. The Changes since > Protocol 2.0 I think it makes sense to have a dedicated page like this that lists any protocol changes that we do. But I think the current structure doesn't make much se

Re: Fix slot synchronization with two_phase decoding enabled

On Wed, May 28, 2025 at 6:10 AM Masahiko Sawada wrote: > > On Sun, May 25, 2025 at 11:34 PM Nisha Moond wrote: > > > > to > > On Fri, May 23, 2025 at 10:06 PM Masahiko Sawada > > wrote: > > > > > > > > > Here are review comments for v14 patch: > > > > > > > Thank you for the review. > > > > >

Re: Conflict detection for update_deleted in logical replication

On Tue, May 27, 2025 at 3:59 PM shveta malik wrote: > > On Mon, May 26, 2025 at 12:46 PM Zhijie Hou (Fujitsu) > wrote: > > > > Attaching the V32 patch set which addressed comments in [1]~[5]. > > Thanks for the patch, I am still reviewing the patches, please find > few trivial comments for patch0

Warning -Wclobbered in PG_TRY(...)

Hi, hackers! While building pg_duckdb extension with PostgreSQL 17.5 we found -Wclobbered warning from gcc with PG_TRY(): g++ -Wall -Wpointer-arith -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-

Re: Persist injection points across server restarts

Hi, Thank you for addressing the review comments. > It appears that Github CI is reporting failures with > > injection_points/002_data_persist > > failing across all OSes. > > I am not sure to see what you are referring to here, based on the > following reports: > https://commitfest.postgresql.or

Re: Replication slot is not able to sync up

On Wed, May 28, 2025 at 11:56 AM Masahiko Sawada wrote: > > > I didn't know it was intended for testing and debugging purposes so > clearilying it in the documentation would be a good idea. I have added the suggested docs in v3. thanks Shveta v3-0001-Improve-log-messages-and-docs-for-slotsync.

Re: Foreign key validation failure in 18beta1

On Wed, May 28, 2025 at 8:38 PM Tender Wang wrote: > > > > Alvaro Herrera 于2025年5月28日周三 20:26写道： >> >> On 2025-May-28, Tender Wang wrote: >> >> > I dided the codes, in QueueFKConstraintValidation(), we add three >> > newconstraint for the >> > fk rel, because the pk rel is partition table. >> >