Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

Hi Yugo On 26.05.25 18:39, Yugo Nagata wrote: > I can see the error when two concurrent transactions issue > "alter function f() immutable". I might have missed something in my last tests... I could now reproduce the behaviour you mentioned. I've tested v2 and it works as described. CREATE OR R

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

Hello Yugo, 31.03.2025 14:22, Yugo Nagata wrote: I found that multiple sessions concurrently execute CREATE OR REPLACE FUNCTION for a same function, the error "tuple concurrently updated" is raised. This is an internal error output by elog, also the message is not user-friendly. I also found th

Re: Replication slot is not able to sync up

On Mon, May 26, 2025 at 12:02 PM shveta malik wrote: > > Agree that log messages need improvement. Please find the patch > attached for the same. I also intend to update the docs in this area > for users to understand this feature better, and will work on that > soon. > PFA the patch with doc cha

Re: Avoiding memory leak when compilation of a function fails

út 27. 5. 2025 v 7:27 odesílatel Amul Sul napsal: > On Tue, May 27, 2025 at 4:23 AM Tom Lane wrote: > > > > Back in [1], Andres complained that repeated attempts to create > > an invalid plpgsql function (one that fails initial compilation) > > leak memory, for example > > > > DO $do$ > > BEGIN

Re: Avoiding memory leak when compilation of a function fails

On Tue, May 27, 2025 at 4:23 AM Tom Lane wrote: > > Back in [1], Andres complained that repeated attempts to create > an invalid plpgsql function (one that fails initial compilation) > leak memory, for example > > DO $do$ > BEGIN > FOR i IN 1 .. 10 LOOP > BEGIN > CREATE OR REPLACE

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

On Mon, May 26, 2025 at 10:36 PM Alexander Korotkov wrote: > > On Mon, May 26, 2025 at 2:43 PM Amit Kapila wrote: > > > > On Mon, May 26, 2025 at 3:52 PM Vitaly Davydov > > wrote: > > > OTOH, if we don't want to adjust physical > > slot machinery, it seems saving the logical slots to disk immed

Re: Standardize the definition of the subtype field of AlterDomainStmt

On Tue, May 27, 2025 at 11:06:46AM +0800, Quan Zongliang wrote: > I noticed that the subtype of AlterDomainStmt is directly using constants in > the code. It is not conducive to the maintenance and reading of the code. > Based on the definition of AlterTableType, use "AD_" as the prefix. Define > s

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

On Tue, 27 May 2025 10:03:58 +0800 jian he wrote: > On Tue, May 27, 2025 at 1:35 AM Yugo Nagata wrote: > > > > > + /* Lock the function so nobody else can do anything with it. */ > > > + LockDatabaseObject(ProcedureRelationId, oldproc->oid, 0, > > > AccessExclusiveLock); > > > + > > > + /* > >

Re: doc: Make logical replication examples executable in bulk and legal sgml.

On Fri, May 23, 2025 at 10:52 AM David G. Johnston wrote: > > On Thursday, May 22, 2025, Amit Kapila wrote: >> >> On Sat, May 3, 2025 at 9:33 PM David G. Johnston >> wrote: >> > >> > While responding to a "our documentation is buggy" complaint I got annoyed >> > in my attempt to reproduce the b

Standardize the definition of the subtype field of AlterDomainStmt

I noticed that the subtype of AlterDomainStmt is directly using constants in the code. It is not conducive to the maintenance and reading of the code. Based on the definition of AlterTableType, use "AD_" as the prefix. Define several macros to replace the original characters. The subtype of Alt

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

On Tue, May 27, 2025 at 1:35 AM Yugo Nagata wrote: > > > + /* Lock the function so nobody else can do anything with it. */ > > + LockDatabaseObject(ProcedureRelationId, oldproc->oid, 0, > > AccessExclusiveLock); > > + > > + /* > > + * It is possible that by the time we acquire the lock on functio

Re: queryId constant squashing does not support prepared statements

On Sat, May 24, 2025 at 09:35:24AM -0500, Sami Imseih wrote: > 2. If we have 1 or more squashed lists, then we can't guarantee > the $n parameter as was supplied by the user and we simply rename > the $n starting from 1. > > therefore, a user supplied query like this: > ``` > select where $5 in ($

Re: Persist injection points across server restarts

On Mon, May 26, 2025 at 01:17:46PM +0530, Rahila Syed wrote: > 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.org/

Re: Retiring some encodings?

On Mon, May 26, 2025 at 06:54:49PM +0200, Daniel Gustafsson wrote: > Agreed, it seems very unappealing to remove something so important to such a > large userbase. Agreed that the so-said "state" level requirement would be a non-starter. -- Michael signature.asc Description: PGP signature

Re: Add AioUringCompletion in wait_event_names.txt and a safeguard in generate-wait_event_types.pl

On Mon, May 26, 2025 at 07:49:34AM +, Bertrand Drouvot wrote: > c325a7633fcb forgot to add AioUringCompletion in wait_event_names.txt: please > find attached v1-0001 fixing it (please double check the wait event > description > as I'm not that familiar with io_uring). +AioUringCompletion "Wai

Re: Automatically sizing the IO worker pool

BTW I would like to push 0001 and 0002 to master/18. They are are not behaviour changes, they just fix up a bunch of inconsistent (0001) and misleading (0002) variable naming and comments to reflect reality (in AIO v1 the postmaster used to assign those I/O worker numbers, now the postmaster has i

Avoiding memory leak when compilation of a function fails

Back in [1], Andres complained that repeated attempts to create an invalid plpgsql function (one that fails initial compilation) leak memory, for example DO $do$ BEGIN FOR i IN 1 .. 10 LOOP BEGIN CREATE OR REPLACE FUNCTION foo() RETURNS VOID LANGUAGE plpgsql AS $f$BEGIN fra

Re: PG 18 release notes draft committed

Hi, There seems to be some unexpected ">" here: "E.1.3.7.3. Logical Replication Applications>" == Kind Regards, Peter Smith. Fujitsu Australia

Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

On May 25, 2025, at 00:16, Florents Tselai wrote: > The most important problem in jsonpath_scan.l now is the fact that I broke > the alphabetical ordering of keywords in v2 , > and you followed that too. Oh. They have been organized by length; I didn’t notice they were also alphabetical. > Bu

Re: SQL:2011 application time

On Sun, May 25, 2025 at 10:57 PM Peter Eisentraut wrote: > Here we added a gist support function that we internally refer to by the > symbol GIST_STRATNUM_PROC. This translated from "well-known" strategy > numbers to opfamily-specific strategy numbers. However, we later > changed this to fit int

Re: Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait

Hi Fujii, Thanks for the review. > Just an idea: how about calling pgstat_report_wait_start() and _end() around pg_usleep(), similar to what WaitExceedsMaxStandbyDelay() does? I was thinking about this as well, but the question is what do we report the wait event here as? The one that makes sens

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

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, the point is that a rogue regular user *can* use this pattern to become

Re: Fixing memory leaks in postgres_fdw

Here's a v4 that is actually more or less feature-complete: it removes no-longer-needed complexity such as PG_TRY blocks. I've checked that Valgrind shows no leaks in the postgres_fdw and dblink tests after applying this on top of my other patch series. 0001 is like the previous version except tha

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

On Fri, 23 May 2025 10:37:42 +0800 jian he wrote: > On Thu, May 22, 2025 at 10:25 AM jian he wrote: > > > hi. > earlier, i didn't check patch 0002. > > i think in AlterFunction add > /* Lock the function so nobody else can do anything with it. */ > LockDatabaseObject(ProcedureRelationId

Re: Amcheck verification of GiST and GIN

Hello Tomas, On Mon, May 26, 2025 at 1:27 PM Tomas Vondra wrote: > > Hello Arseniy, > > I finally got time to look at this more closely, and do some testing. Thank you for looking into this. > Are there any cases when the current code incorrectly reports corruption > for a valid index? So far

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

Hi, On Thu, 22 May 2025 10:25:58 +0800 jian he wrote: Thank you for looking into it. > + /* Lock the function so nobody else can do anything with it. */ > + LockDatabaseObject(ProcedureRelationId, oldproc->oid, 0, > AccessExclusiveLock); > + > + /* > + * It is possible that by the time we acq

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

On Mon, May 26, 2025 at 2:43 PM Amit Kapila wrote: > > On Mon, May 26, 2025 at 3:52 PM Vitaly Davydov > wrote: > > > > Dear Alexander, Amit, All > > > > > Amit wrote: > > > > Is my understanding correct that we need 0001 because > > > > PhysicalConfirmReceivedLocation() doesn't save the slot to

Re: Retiring some encodings?

> On 26 May 2025, at 18:07, Andrew Dunstan wrote: > On 2025-05-24 Sa 8:58 PM, DEVOPS_WwIT wrote: >> The GB18030 encoding standard is a mandatory Chinese character encoding >> standard required by regulations. Software sold and used in China must >> support GB18030, with its latest version being

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

On Tue, 20 May 2025 17:30:35 +0200 Jim Jones wrote: > I just briefly tested this patch and it seems to work as expected for > CREATE OF REPLACE FUNCTION: Thank you for reviewing the patch! > I did the same for ALTER FUNCTION but I was unable to reproduce the > error your reported. Could you pr

Re: Retiring some encodings?

On 2025-05-24 Sa 8:58 PM, DEVOPS_WwIT wrote: Hi Michael Yeah, that's a good point. I would also question what's the benefit in using GB18030 over UTF-8, though. An obvious one I can see is because legacy applications never get updated. The GB18030 encoding standard is a mandatory Chinese c

Re: Differential code coverage between 16 and HEAD

Hi, On Mon, 26 May 2025 at 16:40, Álvaro Herrera wrote: > > Hi > > I updated our coverage building server from bullseye to bookworm today. > That got us from lcov 1.14 to ... 1.16. Disappointing! But lcov 2.0, > with support for differential report, is just around the corner, so I > thought I c

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

Dear Amit, > OTOH, if we don't want to adjust physical > slot machinery, it seems saving the logical slots to disk immediately > when its restart_lsn is updated is a waste of effort after your patch, > no? If so, why are we okay with that? I agree, that saving logical slots at advance is a possib

Re: Feature Suggestion: Make synchronous_commit a table level property

Hi Chris and Andy, Thanks for your comments. @Chris I see your point in regards to unlogged tables. While this statement might be true in a world withou

Re: PG 18 release notes draft committed

On 5/23/25 09:47, Bruce Momjian wrote: On Fri, May 23, 2025 at 09:54:54AM +0200, Álvaro Herrera wrote: I also think that showing an XML-ish format of a commit message is unhelpful, not to mention hard to read. Showing a few actual examples would be better. Agreed, but the XML came from Joe Co

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

On Mon, May 26, 2025 at 4:56 PM Feike Steenbergen wrote: > > > > On Sat, 24 May 2025 at 15:43, jian he wrote: > > sorry, I am not fully sure what this means. a minimum sql reproducer would > > be > > great. > > The initial email contains a fully self-contained example of a regular user > becomin

Re: Differential code coverage between 16 and HEAD

Hi I updated our coverage building server from bullseye to bookworm today. That got us from lcov 1.14 to ... 1.16. Disappointing! But lcov 2.0, with support for differential report, is just around the corner, so I thought I could spend some time figuring out how to make it generate those reports

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

On Mon, May 26, 2025 at 9:49 AM Amit Kapila wrote: > > On Sat, May 24, 2025 at 6:59 PM Alexander Korotkov > wrote: > > > > Hi, Amit! > > > > Thank you for your attention to this patchset! > > > > On Sat, May 24, 2025 at 2:15 PM Amit Kapila wrote: > > > On Sat, May 24, 2025 at 4:08 PM Alexander

Re: MERGE issues around inheritance

Dean Rasheed 于2025年5月26日周一 18:41写道： > On Mon, 26 May 2025 at 07:46, Tender Wang wrote: > > > > Hi Dean, > > > > "it is possible for the parent to be excluded from the > > plan and so all of the entries in the resultRelInfo array may be for > > different relations than rootResultRelInfo." > > >

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

On Mon, May 26, 2025 at 3:52 PM Vitaly Davydov wrote: > > Dear Alexander, Amit, All > > > Amit wrote: > > > Is my understanding correct that we need 0001 because > > > PhysicalConfirmReceivedLocation() doesn't save the slot to disk after > > > changing the slot's restart_lsn? > > > > Yes. Also, e

Re: Better HINT message for "unexpected data beyond EOF"

On Fri, Apr 4, 2025 at 12:55 PM Jakub Wartak wrote: Hi [..] > OK, so attached is a small patch to eradicate this HINT: CI tested, > verified using original reproducer, registered in cf app. v2 attached, rebased and tested. -J. v2-0001-Remove-HINT-message-for-unexpected-data-beyond-EO.patch Des

Re: Fix a minor typo in jit/README

> On 26 May 2025, at 08:44, Yugo Nagata wrote: > -additionally an index is over these is stored to > +additionally an index over these is stored to Fixed, thanks! -- Daniel Gustafsson

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

Hi Andy, Thanks for the reply. As suggested, I tried using CTE which seems to solve the case. This is the updated plan:     QUERY PLAN   

Re: Allow table AMs to define their own reloptions

On Sat, Mar 29, 2025 at 08:46:01AM +0100, Julien Tachoires wrote: > On Sun, Mar 02, 2025 at 02:23:54PM +0100, Julien Tachoires wrote: > > On Sun, Mar 02, 2025 at 09:56:41AM +0100, Julien Tachoires wrote: > > > With the help of the new TAM routine 'relation_options', table access > > > methods can

Re: MERGE issues around inheritance

On Mon, 26 May 2025 at 10:39, Tender Wang wrote: > > jian he 于2025年5月26日周一 17:30写道： >> >> + Relation rootRelation = rootRelInfo->ri_RelationDesc; >> + Relation firstResultRel = mtstate->resultRelInfo[0].ri_RelationDesc; >> + int firstVarno = mtstate->resultRelInfo[0].ri_RangeTableIndex; >> >> fir

Re: MERGE issues around inheritance

On Mon, 26 May 2025 at 07:46, Tender Wang wrote: > > Hi Dean, > > "it is possible for the parent to be excluded from the > plan and so all of the entries in the resultRelInfo array may be for > different relations than rootResultRelInfo." > > I didn't fully understand the above sentence. Can you

Re: MERGE issues around inheritance

On Mon, 26 May 2025 at 10:30, jian he wrote: > > + Relation rootRelation = rootRelInfo->ri_RelationDesc; > + Relation firstResultRel = mtstate->resultRelInfo[0].ri_RelationDesc; > + int firstVarno = mtstate->resultRelInfo[0].ri_RangeTableIndex; > > firstResultRel may equal (==) to rootRelation, >

Re: Random subscription 021_twophase test failure on kestrel

On Mon, 26 May 2025 at 13:59, Michael Paquier wrote: > > On Sat, May 24, 2025 at 11:27:05AM +0530, Amit Kapila wrote: > > On Sat, May 24, 2025 at 6:07 AM Michael Paquier wrote: > >> Yes, agreed that your suggested fix looks sensible with an extra check > >> for pg_prepared_xacts on the subscriber

Re: Amcheck verification of GiST and GIN

Hello Arseniy, I finally got time to look at this more closely, and do some testing. Are there any cases when the current code incorrectly reports corruption for a valid index? So far I've been unable to find such case. Or am I wrong? It seems to me all the proposed changes are "tightening" the

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

Dear Alexander, Amit, All > Amit wrote: > > Is my understanding correct that we need 0001 because > > PhysicalConfirmReceivedLocation() doesn't save the slot to disk after > > changing the slot's restart_lsn? > > Yes. Also, even if it would save slot to the disk, there is still > race condition t

Re: MERGE issues around inheritance

On Mon, May 26, 2025 at 4:11 AM Dean Rasheed wrote: > > On Sun, 25 May 2025 at 13:41, Dean Rasheed wrote: > > > > 2. ExecInitModifyTable() does not initialize the WCO lists or > RETURNING list for rootResultRelInfo, so those never get executed. > > As it happens, it is possible to construct cases

Re: MERGE issues around inheritance

jian he 于2025年5月26日周一 17:30写道： > On Mon, May 26, 2025 at 4:11 AM Dean Rasheed > wrote: > > > > On Sun, 25 May 2025 at 13:41, Dean Rasheed > wrote: > > > > > > > 2. ExecInitModifyTable() does not initialize the WCO lists or > > RETURNING list for rootResultRelInfo, so those never get executed. >

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

On Sat, 24 May 2025 at 15:43, jian he wrote: > sorry, I am not fully sure what this means. a minimum sql reproducer would be > great. The initial email contains a fully self-contained example of a regular user becoming a superuser. The only thing the superuser had to do was SELECT * FROM unt

Re: Random subscription 021_twophase test failure on kestrel

On Sat, May 24, 2025 at 11:27:05AM +0530, Amit Kapila wrote: > On Sat, May 24, 2025 at 6:07 AM Michael Paquier wrote: >> Yes, agreed that your suggested fix looks sensible with an extra check >> for pg_prepared_xacts on the subscriber side that can be useful for >> debugging. > > +1. Applied dow

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

2025/05/21 12:54 Fujii Masao :On Mon, May 19, 2025 at 5:18 PM Masahiro Ikeda wrote: > > Thanks for your work and feedback! > > I've updated the patches and added regular regression tests for > both pg_prewarm and amcheck. Thanks for updating the patches! Regarding the 0001 patch: +CR

Add AioUringCompletion in wait_event_names.txt and a safeguard in generate-wait_event_types.pl

Hi hackers, c325a7633fcb forgot to add AioUringCompletion in wait_event_names.txt: please find attached v1-0001 fixing it (please double check the wait event description as I'm not that familiar with io_uring). 042a66291 also missed it for LWTRANCHE_MEMORY_CONTEXT_REPORTING_PROC and LWTRANCHE_MEM

Re: Persist injection points across server restarts

Hi, > This is v19 work, so I am adding that to the next commit fest. > > Rebased, to fix a conflict I've introduced with a different commit. > > Thank you for the rebased patches. I reviewed the code and have a few comments for your consideration. It appears that Github CI is reporting failures

Re: Automatically sizing the IO worker pool

On Sun, May 25, 2025 at 7:20 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Sun, Apr 13, 2025 at 04:59:54AM GMT, Thomas Munro wrote: > > It's hard to know how to set io_workers=3. If it's too small, > > io_method=worker's small submission queue overflows and it silently > > falls back to s

Re: MERGE issues around inheritance

Dean Rasheed 于2025年5月26日周一 04:10写道： > On Sun, 25 May 2025 at 13:41, Dean Rasheed > wrote: > > > > On Sun, 25 May 2025 at 13:06, Tender Wang wrote: > > > > > > For a partitioned table, we must pass rootResultRelInfo to > ExecInsert(). I added the check before calling ExecInsert() > > > If it is

RE: Conflict detection for update_deleted in logical replication

On Fri, May 23, 2025 at 11:51 PM Xuneng Zhou wrote: > Thanks for the effort on the patches. I did a quick look on them before > diving into the logic and discussion. Below are a few minor typos found in > version 31. Thanks for the comments! I have fixed these typos in latest version. Best Regar

RE: Conflict detection for update_deleted in logical replication

On Fri, May 23, 2025 at 2:45 PM shveta malik wrote: > > Thanks you for v31 patch-set. Please find few comments on patch001: Thanks for the comments. > > 1) > > wait_for_local_flush: > > + if (data->last_recv_time && > + TimestampDifferenceExceeds(data->flushpos_update_time, > +data->last

Re: JIT works only partially with meson build?

On Mon, 26 May 2025 at 18:08, Yugo Nagata wrote: > While building PostgreSQL 17 on Windows, I noticed bitcode files (.bc) are not > generated with meson. Does this means that "inlining" of JIT doesn't > work when PostgreSQL is build with meson? Yes. I believe [1] aims to fix this. David [1] ht

RE: Conflict detection for update_deleted in logical replication

On Sat, May 24, 2025 at 6:28 PM Dilip Kumar wrote: > > On Sat, May 24, 2025 at 11:00 AM Amit Kapila > wrote: > > > > On Sat, May 24, 2025 at 10:29 AM Dilip Kumar > wrote: > > > > > > On Sat, May 24, 2025 at 10:04 AM Dilip Kumar > wrote: > > > > > > > > On Fri, May 23, 2025 at 9:21 PM Xuneng Zh

RE: Conflict detection for update_deleted in logical replication

On Sun, May 25, 2025 at 4:36 PM Dilip Kumar wrote: > > On Sat, May 24, 2025 at 4:46 PM Amit Kapila > wrote: > > > > This sounds reasonable to me. Let us see what others think. > > > > I was looking into the for getting the transaction status from > publisher, what I would assume this patch shou