Re: Synchronizing slots from primary to standby

On Mon, Oct 2, 2023 at 4:29 PM Hayato Kuroda (Fujitsu) wrote: > > Dear Shveta, > > Thank you for updating the patch! > > I found another ERROR due to the slot removal. Is this a real issue? > > 1. applied add_sleep.txt, which emulated the case the tablesync worker stucked >and the primary

Re: Synchronizing slots from primary to standby

On Wed, Oct 4, 2023 at 9:56 AM shveta malik wrote: > > On Wed, Oct 4, 2023 at 5:36 AM Amit Kapila wrote: > > > > On Tue, Oct 3, 2023 at 9:27 PM shveta malik wrote: > > > > > > On Tue, Oct 3, 2023 at 7:56 PM Drouvot, Bertrand > > > wrote: > > > > > > > > Hi, > > > > > > > > On 10/3/23 12:54 PM,

Re: Synchronizing slots from primary to standby

On Wed, Oct 4, 2023 at 5:36 AM Amit Kapila wrote: > > On Tue, Oct 3, 2023 at 9:27 PM shveta malik wrote: > > > > On Tue, Oct 3, 2023 at 7:56 PM Drouvot, Bertrand > > wrote: > > > > > > Hi, > > > > > > On 10/3/23 12:54 PM, Amit Kapila wrote: > > > > On Mon, Oct 2, 2023 at 11:39 AM Drouvot,

Re: Making aggregate deserialization (and WAL receive) functions slightly faster

On Tue, Oct 03, 2023 at 06:02:10PM +1300, David Rowley wrote: > I know I said I'd drop this, but I was reminded of it again today. I > ended up adjusting the patch so that it no longer adds a helper > function to stringinfo.c and instead just manually assigns the > StringInfo.data field to point

Re: Synchronizing slots from primary to standby

Here are some review comments for v20-0002. == 1. GENERAL - errmsg/elog messages There are a a lot of minor problems and/or quirks across all the message texts. Here is a summary of some I found: ERROR errmsg("could not receive list of slots from the primary server: %s", errmsg("invalid

回复: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

> > This patch makes the filenames always 12 characters wide (for SLRUs that > > opt-in to the new naming). That's actually not enough for the full range > > that a 64 bit page number can represent. Should we make it 16 characters > > now, to avoid repeating the same mistake we made earlier? Or

Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector

On Tue, Oct 3, 2023 at 4:15 PM Karl O. Pinc wrote: > On Tue, 3 Oct 2023 14:51:31 -0700 > "David G. Johnston" wrote: > > Isn't the entire section about "deviating from the normal flow of the > code"? That's what makes me want "Exception" in the section title. > It is about how error handling

RE: [PoC] pg_upgrade: allow to upgrade publisher node

Dear Bharath, While checking more, I found some problems your PoC. 1. rm_is_record_decodable() returns true when WAL records are decodable. Based on that, should is_valid be false when the function is true? E.g., XLOG_HEAP_INSERT is accepted in the PoC. 2. XLOG_CHECKPOINT_SHUTDOWN and

Re: make add_paths_to_append_rel aware of startup cost

On Sun, 1 Oct 2023 at 21:26, Andy Fan wrote: >> But overall, I'm more inclined to just go with the more simple "add a >> cheap unordered startup append path if considering cheap startup >> plans" version. I see your latest patch does both. So, I'd suggest two >> patches as I do see the merit in

Re: Removing unneeded self joins

Hi! I think this is a neat optimization. On Tue, Sep 12, 2023 at 4:58 PM Andrey Lepikhov wrote: > On 5/7/2023 21:28, Andrey Lepikhov wrote: > > During the significant code revision in v.41 I lost some replacement > > operations. Here is the fix and extra tests to check this in the future. > >

Re: False "pg_serial": apparent wraparound” in logs

On Sun, Oct 01, 2023 at 09:43:21PM +0300, Heikki Linnakangas wrote: > I think the smallest fix here would be to change CheckPointPredicate() so > that if tailPage > headPage, pass headPage to SimpleLruTruncate() instead of > tailPage. Or perhaps it should go into the "The SLRU is no longer needed"

Re: Synchronizing slots from primary to standby

On Tue, Oct 3, 2023 at 9:27 PM shveta malik wrote: > > On Tue, Oct 3, 2023 at 7:56 PM Drouvot, Bertrand > wrote: > > > > Hi, > > > > On 10/3/23 12:54 PM, Amit Kapila wrote: > > > On Mon, Oct 2, 2023 at 11:39 AM Drouvot, Bertrand > > > wrote: > > >> > > >> On 9/29/23 1:33 PM, Amit Kapila wrote:

Re: pgstatindex vs. !indisready

On Sun, Oct 01, 2023 at 06:31:26PM -0700, Noah Misch wrote: > The !indisvalid index may be missing tuples, yes. In what way does that make > one of those four operations incorrect? Reminding myself of what these four do, it looks that you're right and that the state of indisvalid is not going to

Re: Index range search optimization

On Wed, Oct 4, 2023 at 12:59 AM Pavel Borisov wrote: > I've looked through the patch v8. I think it's good enough to be > pushed if Peter has no objections. Thank you, Pavel. I'll push this if there are no objections. -- Regards, Alexander Korotkov

Re: Add support for AT LOCAL

On Tue, Oct 03, 2023 at 02:10:48AM +0200, Vik Fearing wrote: > On 9/29/23 09:27, Michael Paquier wrote: >> As the deparsing code introduced by this patch is showing, this leads >> to a lot of extra complexity. And, actually, this can be quite >> expensive as well with these two layers of

Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

On Tue, Oct 03, 2023 at 07:02:11PM +0530, Bharath Rupireddy wrote: > On Tue, Oct 3, 2023 at 5:45 PM Drouvot, Bertrand > wrote: >> I did some research and BGWORKER_BYPASS_ALLOWCONN has been added in >> eed1ce72e1 and >> at that time the bgw_flags did already exist. >> >> In this the related

Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector

On Tue, 3 Oct 2023 14:51:31 -0700 "David G. Johnston" wrote: > 0001 - I would just call the section: > Capturing Command Results into Variables I like your wording a lot. Let's use it! > I would add commentary in there that it is only possible for > variables to take on single value at any

Re: Improve WALRead() to suck data directly from WAL buffers when possible

On Sat, 2023-01-14 at 12:34 -0800, Andres Freund wrote: > One benefit would be that it'd make it more realistic to use direct > IO for WAL > - for which I have seen significant performance benefits. But when we > afterwards have to re-read it from disk to replicate, it's less > clearly a win.

Re: Pre-proposal: unicode normalized text

On Tue, Oct 03, 2023 at 03:34:44PM -0700, Jeff Davis wrote: > On Tue, 2023-10-03 at 15:15 -0500, Nico Williams wrote: > > Ugh, My client is not displying 'a' correctly > > Ugh. Is that an argument in favor of normalization or against? Heheh, well, it's an argument in favor of more software

Re: Pre-proposal: unicode normalized text

On Mon, 2023-10-02 at 10:47 +0200, Peter Eisentraut wrote: > I think a better direction here would be to work toward making > nondeterministic collations usable on the global/database level and > then > encouraging users to use those. > > It's also not clear which way the performance tradeoffs

Re: Pre-proposal: unicode normalized text

On Tue, 2023-10-03 at 15:15 -0500, Nico Williams wrote: > Ugh, My client is not displying 'a' correctly Ugh. Is that an argument in favor of normalization or against? I've also noticed that some fonts render the same character a bit differently depending on the constituent code points. For

Re: Index range search optimization

Hi! On Fri, 29 Sept 2023 at 10:35, Alexander Korotkov wrote: > > Hi, Peter. > > On Fri, Sep 29, 2023 at 4:57 AM Peter Geoghegan wrote: > > On Fri, Sep 22, 2023 at 7:24 AM Alexander Korotkov > > wrote: > > > The thing is that NULLs could appear in the middle of matching values. > > > > > > #

Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector

On Tue, Oct 3, 2023 at 10:56 AM Karl O. Pinc wrote: > On Mon, 2 Oct 2023 15:18:32 -0500 > "Karl O. Pinc" wrote: > > Version 7 > > 0001 - I would just call the section: Capturing Command Results into Variables I would add commentary in there that it is only possible for variables to take on

Re: Allow deleting enumerated values from an existing enumerated data type

Matthias van de Meent writes: > I don't quite get what the hard problem is that we haven't already > solved for other systems: > We already can add additional constraints to domains (e.g. VALUE::int > <> 4), which (according to docs) scan existing data columns for > violations. That's "solved"

Re: Allow deleting enumerated values from an existing enumerated data type

On Tue, 3 Oct 2023 at 22:49, Tom Lane wrote: > > Andrew Dunstan writes: > > On 2023-09-28 Th 14:46, Tom Lane wrote: > >> We went through all these points years ago when the enum feature > >> was first developed, as I recall. Nobody thought that the ability > >> to remove an enum value was worth

Re: Allow deleting enumerated values from an existing enumerated data type

Andrew Dunstan writes: > On 2023-09-28 Th 14:46, Tom Lane wrote: >> We went through all these points years ago when the enum feature >> was first developed, as I recall. Nobody thought that the ability >> to remove an enum value was worth the amount of complexity it'd >> entail. > That's quite

Re: Pre-proposal: unicode normalized text

On Tue, Oct 03, 2023 at 12:15:10PM -0700, Jeff Davis wrote: > On Mon, 2023-10-02 at 15:27 -0500, Nico Williams wrote: > > I think you misunderstand Unicode normalization and equivalence.  > > There is no standard Unicode `normalize()` that would cause the > > above equality predicate to be true. 

Re: Annoying build warnings from latest Apple toolchain

I wrote: > Assuming that this problem is restricted to initdb, which I think > is true, probably the best fix is to cause the initdb link *only* > to link libpgcommon before libpq. Every other non-backend program > is interested in libpq's encoding IDs if it cares at all. The more I thought

Re: Pre-proposal: unicode normalized text

On Mon, 2023-10-02 at 16:06 -0400, Robert Haas wrote: > It seems to me that this overlooks one of the major points of Jeff's > proposal, which is that we don't reject text input that contains > unassigned code points. That decision turns out to be really painful. Yeah, because we lose

Re: [DOCS] HOT - correct claim about indexes not referencing old line pointers

On Mon, Oct 2, 2023 at 2:55 PM Robert Haas wrote: > > On Sat, Sep 30, 2023 at 1:05 AM Peter Geoghegan wrote: > > > This is why I discovered it: it says "indexes do not reference their > > > page item identifiers", which is manifestly not true when talking > > > about the root item, and in fact

Re: Pre-proposal: unicode normalized text

On Mon, 2023-10-02 at 15:27 -0500, Nico Williams wrote: > I think you misunderstand Unicode normalization and equivalence.  > There > is no standard Unicode `normalize()` that would cause the above > equality > predicate to be true.  If you normalize to NFD (normal form > decomposed) > then a

Re: RFC: Logging plan of the running query

On Thu, Sep 7, 2023 at 2:09 AM torikoshia wrote: > > On 2023-09-06 11:17, James Coleman wrote: > > >> > I've never been able to reproduce it (haven't tested the new version, > >> > but v28 at least) on my M1 Mac; where I've reproduced it is on Debian > >> > (first buster and now bullseye). > >> >

Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector

On Mon, 2 Oct 2023 15:18:32 -0500 "Karl O. Pinc" wrote: Version 7 Added: v7-0016-Predicate-locks-are-held-per-cluster-not-per-data.patch > > > On Mon, 25 Sep 2023 23:37:44 -0500 > > > "Karl O. Pinc" wrote: > > > > > > > > On Mon, 25 Sep 2023 17:55:59 -0500 > > > > > "Karl O. Pinc"

Re: On login trigger: take three

Hi, Robert! On Tue, Oct 3, 2023 at 5:21 PM Robert Haas wrote: > On Tue, Oct 3, 2023 at 9:43 AM Daniel Gustafsson wrote: > > That's exactly what happens, the patch is using BuildEventTriggerCache() to > > build the hash for EVT which is then checked for login triggers. This is > > clearly the

Re: Annoying build warnings from latest Apple toolchain

I wrote: > Andres Freund writes: >> On 2023-09-29 12:14:40 -0400, Tom Lane wrote: >>> Therefore, I think the prudent thing to do in the back branches is use the >>> patch I posted before, to suppress the duplicate -l switches only on macOS. >>> In HEAD, I propose we simplify life by doing it

Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written}

On Fri, Sep 15, 2023 at 12:34 PM Melanie Plageman wrote: > On Fri, Sep 15, 2023 at 9:24 AM Nazir Bilal Yavuz wrote: > > I found that pgBufferUsage.blk_{read|write}_time are zero although there > > are pgBufferUsage.local_blks_{read|written} > > Yes, good catch. This is a bug. I will note that

Re: Synchronizing slots from primary to standby

On Tue, Oct 3, 2023 at 7:56 PM Drouvot, Bertrand wrote: > > Hi, > > On 10/3/23 12:54 PM, Amit Kapila wrote: > > On Mon, Oct 2, 2023 at 11:39 AM Drouvot, Bertrand > > wrote: > >> > >> On 9/29/23 1:33 PM, Amit Kapila wrote: > >>> On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand > >>> wrote: >

Re: Remove IndexInfo.ii_OpclassOptions field

On 30.08.23 02:51, Michael Paquier wrote: On Tue, Aug 29, 2023 at 10:51:10AM +0200, Peter Eisentraut wrote: At a glance, however, I think my patch is (a) not related, and (b) if it were, it would probably *help*, because the change is to not allocate any long-lived structures that no one needs

Re: Allow deleting enumerated values from an existing enumerated data type

On 10/3/23 17:44, Tom Lane wrote: Vik Fearing writes: On 10/2/23 20:07, Dagfinn Ilmari Mannsåker wrote: FWIW I'm +1 on this patch, Thanks. and with Tom on dropping the "yet". To me it makes it sound like we intend to implement it soon (fsvo). I am not fundamentally opposed to it,

Re: Allow deleting enumerated values from an existing enumerated data type

Vik Fearing writes: > On 10/2/23 20:07, Dagfinn Ilmari Mannsåker wrote: >> FWIW I'm +1 on this patch, > Thanks. >> and with Tom on dropping the "yet". To me it >> makes it sound like we intend to implement it soon (fsvo). > I am not fundamentally opposed to it, nor to any other wordsmithing

Re: trying again to get incremental backup

On Fri, Sep 1, 2023 at 10:30 AM Robert Haas wrote: > > No objections to 0001/0002. > > Cool. Nobody else objected either, so I went ahead and committed those. I'll rebase the rest of the patches on top of the latest master and repost, hopefully after addressing some of the other review comments

Re: Synchronizing slots from primary to standby

Hi, On 10/3/23 12:54 PM, Amit Kapila wrote: On Mon, Oct 2, 2023 at 11:39 AM Drouvot, Bertrand wrote: On 9/29/23 1:33 PM, Amit Kapila wrote: On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand wrote: - probably open corner cases like: what if a standby is down? would that mean that

Re: On login trigger: take three

On Tue, Oct 3, 2023 at 9:43 AM Daniel Gustafsson wrote: > That's exactly what happens, the patch is using BuildEventTriggerCache() to > build the hash for EVT which is then checked for login triggers. This is > clearly the bottleneck and there needs to be a fast-path. There used to be a > cache

Re: Modernize const handling with readline

Peter Eisentraut writes: > The comment > /* On some platforms, readline is declared as readline(char *) */ > is obsolete. The casting away of const can be removed. +1, that's surely not of interest on anything we still support. regards, tom lane

Re: CHECK Constraint Deferrable

On Monday, October 2, 2023, Andreas Joseph Krogh wrote: > På fredag 07. juli 2023 kl. 13:50:44, skrev Dilip Kumar < > dilipbal...@gmail.com>: > > On Wed, Jul 5, 2023 at 3:08 PM Himanshu Upadhyaya > wrote: > > > > Hi, > > > > Currently, there is no support for CHECK constraint DEFERRABLE in a >

Re: On login trigger: take three

> On 2 Oct 2023, at 20:10, Robert Haas wrote: > > Sorry to have gone dark on this for a long time after having been > asked for my input back in March. I'm not having a great time trying > to keep up with email, and the threads getting split up makes it a lot > worse for me. Not a problem,

Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

On Tue, Oct 3, 2023 at 5:45 PM Drouvot, Bertrand wrote: > > > While I like the idea of the flag to skip login checks for bg workers, > > I don't quite like the APIs being changes InitializeSessionUserId and > > InitPostgres (adding a new input parameter), > > BackgroundWorkerInitializeConnection

Re: remaining sql/json patches

On Mon, Oct 2, 2023 at 2:26 PM Amit Langote wrote: > On Mon, Oct 2, 2023 at 1:24 PM Amit Langote wrote: > > Pushed this 30 min ago (no email on -committers yet!) and am looking > > at the following llvm crash reported by buildfarm animal pogona [1]: > > > > #4 0x7f5bceb673d5 in

Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning

On Fri, Sep 29, 2023 at 8:36 AM Amit Langote wrote: > IOW, something > like the following would have sufficed: > > @@ -1735,6 +1735,10 @@ build_child_join_sjinfo(PlannerInfo *root, > SpecialJoinInfo *parent_sjinfo, > /* > * free_child_sjinfo_members > * Free memory consumed by members of

Re: bgwriter doesn't flush WAL stats

Hi, On Mon, 2 Oct 2023 at 13:08, Heikki Linnakangas wrote: > > The first patch, to flush the bgwriter's WAL stats to the stats > collector, seems like a straightforward bug fix, so committed and > backpatched that. Thank you! > > I didn't look at the second patch. Thanks for the push! Actual

Re: New WAL record to detect the checkpoint redo location

On Wed, Sep 20, 2023 at 4:20 PM Robert Haas wrote: > Here are some patches. Here are some updated patches. Following some off-list conversation with Andres, I restructured 0003 to put the common case first and use likely(), and I fixed the brown-paper-bag noted by Amit. I then turned my

Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

Hi, On 10/3/23 11:21 AM, Bharath Rupireddy wrote: On Mon, Oct 2, 2023 at 4:58 PM Drouvot, Bertrand wrote: On 9/29/23 8:19 AM, Michael Paquier wrote: On Thu, Sep 28, 2023 at 02:37:02PM +0200, Drouvot, Bertrand wrote: This patch allows the role provided in

Re: Add the ability to limit the amount of memory that can be allocated to backends.

On 29/9/2023 09:52, Andrei Lepikhov wrote: On 22/5/2023 22:59, reid.thomp...@crunchydata.com wrote: Attach patches updated to master. Pulled from patch 2 back to patch 1 a change that was also pertinent to patch 1. +1 to the idea, have doubts on the implementation. I have a question. I see

Re: Modernize const handling with readline

Hi, > The comment > > /* On some platforms, readline is declared as readline(char *) */ > > is obsolete. The casting away of const can be removed. > > The const in the readline() prototype was added in GNU readline 4.2, > released in 2001. BSD libedit has also had const in the prototype

Re: Synchronizing slots from primary to standby

On Mon, Oct 2, 2023 at 11:39 AM Drouvot, Bertrand wrote: > > On 9/29/23 1:33 PM, Amit Kapila wrote: > > On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand > > wrote: > >> > > > >> - probably open corner cases like: what if a standby is down? would that > >> mean > >> that synchronize_slot_names

Re: Skip collecting decoded changes of already-aborted transactions

On Mon, 3 Jul 2023 at 07:16, Masahiko Sawada wrote: > > On Fri, Jun 23, 2023 at 12:39 PM Dilip Kumar wrote: > > > > On Fri, Jun 9, 2023 at 10:47 AM Masahiko Sawada > > wrote: > > > > > > Hi, > > > > > > In logical decoding, we don't need to collect decoded changes of > > > aborted

Modernize const handling with readline

The comment /* On some platforms, readline is declared as readline(char *) */ is obsolete. The casting away of const can be removed. The const in the readline() prototype was added in GNU readline 4.2, released in 2001. BSD libedit has also had const in the prototype since at least

Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Tue, Oct 3, 2023 at 9:58 AM Bharath Rupireddy wrote: > > On Fri, Sep 29, 2023 at 5:27 PM Hayato Kuroda (Fujitsu) > wrote: > > > > Yeah, the approach enforces developers to check the decodability. > > But the benefit seems smaller than required efforts for it because the > > function > >

Re: Improvements in pg_dump/pg_restore toc format and performances

On Tue, 19 Sept 2023 at 15:46, Pierre Ducroquet wrote: > > On Monday, September 18, 2023 11:54:42 PM CEST Nathan Bossart wrote: > > On Mon, Sep 18, 2023 at 02:52:47PM -0700, Nathan Bossart wrote: > > > On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote: > > >> I ended up writing

Re: [PGDOCS] Inconsistent linkends to "monitoring" views.

On Tue, Oct 3, 2023 at 6:30 PM Michael Paquier wrote: > > On Tue, Oct 03, 2023 at 01:11:15PM +1100, Peter Smith wrote: > > I noticed one or two "monitoring" links and linkends that are slightly > > inconsistent from all the others. > > - > + > > Is that really worth bothering for the

RE: [PoC] pg_upgrade: allow to upgrade publisher node

Dear Bharath, > I'm attaching 0002 patch (on top of v45) which implements the new > decodable callback approach that I have in mind. IMO, this new > approach is extensible, better than the current approach (hard-coding > of certain WAL records that may be generated during pg_upgrade) taken > by

Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written}

Hi, On Fri, 15 Sept 2023 at 16:30, Melanie Plageman wrote: > > Yes, good catch. This is a bug. I will note that at least in 15 and > likely before, pgBufferUsage.local_blks_written is incremented for > local buffers but pgBufferUsage.blk_write_time is only added to for > shared buffers (in

Re: Doc: Minor update for enable_partitionwise_aggregate

On Sun, Oct 1, 2023 at 7:38 AM Andy Atkinson wrote: > > Hello. While reading the docs for the enable_partitionwise_aggregate > parameter on the Query Planning page, I thought the description had a small > mistake that could be improved. > > The current wording is: "which allows grouping or

Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag

On Mon, Oct 2, 2023 at 4:58 PM Drouvot, Bertrand wrote: > > On 9/29/23 8:19 AM, Michael Paquier wrote: > > On Thu, Sep 28, 2023 at 02:37:02PM +0200, Drouvot, Bertrand wrote: > >> This patch allows the role provided in > >> BackgroundWorkerInitializeConnection() > >> and

Re: pg*.dll and *.pdb files in psqlODBC have no version numbers

Mark Hill writes: > I posted this question to > pgsql-gene...@lists.postgrsql.org > last week but on one has responded so posting here now. > A colleague noticed that the following files in the psqlODBC MSI for Windows > have no version numbers: > ...

Re: CHECK Constraint Deferrable

On Tue, Sep 19, 2023 at 4:14 PM Dean Rasheed wrote: > > I think we should be able to defer one constraint like in the case of > > foreign key constraint > > > > Agreed. It should be possible to have a mix of deferred and immediate > constraint checks. In the example, the tbl_chk_1 is set

Re: [PATCH] Fix memory leak in memoize for numeric key

On Tue, 3 Oct 2023 at 19:38, Orlov Aleksej wrote: > I found a query which consumes a lot of memory and triggers OOM killer. > Memory leak occurs in memoize node for numeric key. Thanks for the analysis and the patch. > I've attached memoize_memory_leak_numeric_key.patch to address this. Yeah,

Re: [PGDOCS] Inconsistent linkends to "monitoring" views.

On Tue, Oct 03, 2023 at 01:11:15PM +1100, Peter Smith wrote: > I noticed one or two "monitoring" links and linkends that are slightly > inconsistent from all the others. - + Is that really worth bothering for the internal link references? This can create extra backpatching conflicts. --

Re: Trigger violates foreign key constraint

On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote: > This is by design: triggers operate at a lower level than > foreign keys, so an ill-conceived trigger can break an FK constraint. > That's documented somewhere, though maybe not visibly enough. Not having found any documentation, I propose the

Re: Incorrect handling of OOM in WAL replay leading to data loss

On Tue, Sep 26, 2023 at 03:48:07PM +0900, Michael Paquier wrote: > By the way, anything that I am proposing here cannot be backpatched > because of the infrastructure changes required in walreader.c, so I am > going to create a second thread with something that could be > backpatched (yeah, likely

Re: pg16: XX000: could not find pathkey item to sort

On Tue, 3 Oct 2023 at 09:11, David Rowley wrote: > I'm concerned that this patch will be too much overhead when creating > paths when a PathKey's EquivalenceClass has a large number of members > from partitioned tables. I just tried out the patch to see how much it affects the performance of the

Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()

On Mon, Oct 02, 2023 at 10:22:06AM +0200, Jakub Wartak wrote: > I've attached v4 that covers your suggestions. Hmm. I was looking at all that and pondered quite a bit about the addition of the restriction when starting up the server, particularly why there would be any need to include it in the

Re: Invalidate the subscription worker in cases where a user loses their superuser status

On Tue, Oct 3, 2023 at 5:42 PM vignesh C wrote: > > Thanks for the comments, the attached v6 version patch has the changes > for the same. > v6 LGTM. == Kind Regards, Peter Smith. Fujitsu Australia

Re: Invalidate the subscription worker in cases where a user loses their superuser status

On Tue, 3 Oct 2023 at 06:09, Peter Smith wrote: > > Some review comments for v5. > > == > src/backend/catalog/pg_subscription.c > > 1. GetSubscription - comment > > + /* Get superuser for subscription owner */ > + sub->ownersuperuser = superuser_arg(sub->owner); > + > > The comment doesn't

Re: Fail hard if xlogreader.c fails on out-of-memory

On Thu, Sep 28, 2023 at 09:36:37AM +0900, Michael Paquier wrote: > If none, I propose to apply the patch to switch to palloc() instead of > palloc_extended(NO_OOM) in this code around the beginning of next > week, down to 12. Done down to 12 as of 6b18b3fe2c2f, then. -- Michael signature.asc

Re: Differences between = ANY and IN?

Great, thanks for the guidance!

Re: pg_stat_statements and "IN" conditions

I've also tried the patch and I see the same results as Jakub, which make sense to me. I did have issues getting it to apply, though: `git am` complains about a conflict, though patch itself was able to apply it.

Re: CHECK Constraint Deferrable

On Thu, Sep 14, 2023 at 9:57 AM vignesh C wrote: > 2) I was not sure, if the error message change was intentional: > 2a) > In Head: > CREATE FOREIGN TABLE t9(a int CHECK(a<>0) DEFERRABLE) SERVER s1; > ERROR: misplaced DEFERRABLE clause > LINE 1: CREATE FOREIGN TABLE t9(a int CHECK(a<>0)