Re: meson: Specify -Wformat as a common warning flag for extensions

Hi, Could someone take a look at this? Patch is attached in the original e-mail: https://www.postgresql.org/message-id/20240122.141139.931086145628347157.kou%40clear-code.com Thanks, -- kou In <20240122.141139.931086145628347157@clear-code.com> "meson: Specify -Wformat as a common

Re: locked reads for atomics

On Tue, Nov 28, 2023 at 2:30 AM Nathan Bossart wrote: > > Here's a v2 of the patch set in which I've attempted to address all > feedback. I've also added a pg_write_membarrier_u* pair of functions that There's some immediate use for reads/writes with barrier semantics -

Re: Speeding up COPY TO for uuids and arrays

On Thu, Feb 22, 2024 at 08:16:09AM +0100, Laurenz Albe wrote: > I'm attaching the remaining patch for the Juli commitfest, if you > don't get inspired before that. There are good chances that I get inspired some time next week. We'll see ;) -- Michael signature.asc Description: PGP signature

Re: Add lookup table for replication slot invalidation causes

On Thu, Feb 22, 2024 at 12:26 PM Michael Paquier wrote: > > On Thu, Feb 22, 2024 at 05:30:08PM +1100, Peter Smith wrote: > > Oops. Perhaps I meant more like below -- in any case, the point was > > the same -- to ensure RS_INVAL_NONE is what returns if something > > unexpected happens. > > You are

Re: Speeding up COPY TO for uuids and arrays

On Thu, 2024-02-22 at 10:34 +0900, Michael Paquier wrote: > This part is done as of 011d60c4352c. I did not evaluate the rest > yet. Thanks! I'm attaching the remaining patch for the Juli commitfest, if you don't get inspired before that. Yours, Laurenz Albe From

Re: POC: GROUP BY optimization

On 22/2/2024 13:35, Richard Guo wrote: The avg() function on integer argument is commonly used in aggregates.sql.  I don't think this is an issue.  See the first test query in aggregates.sql. Make sense > it should be parallel to the test cases for utilize the ordering of > index

Re: Add lookup table for replication slot invalidation causes

On Thu, Feb 22, 2024 at 05:30:08PM +1100, Peter Smith wrote: > Oops. Perhaps I meant more like below -- in any case, the point was > the same -- to ensure RS_INVAL_NONE is what returns if something > unexpected happens. You are right that this could be a bit confusing, even if we should never

Re: Synchronizing slots from primary to standby

On Thu, Feb 22, 2024 at 10:31 AM shveta malik wrote: > > Please find patch001 attached. There is a CFBot failure in patch002. > The test added there needs some adjustment. We will rebase and post > rest of the patches once we fix that issue. > There was a recent commit 801792e to improve error

Re: Make COPY format extendable: Extract COPY TO format implementations

On Thu, Feb 15, 2024 at 03:34:21PM +0900, Sutou Kouhei wrote: > It seems that it improves performance a bit but my > environment isn't suitable for benchmark. So they may not > be valid numbers. I was comparing what you have here, and what's been attached by Andres at [1] and the top of the

Re: Why is pq_begintypsend so slow?

Hi, In <20240219195351.5vy7cdl3wxia6...@awork3.anarazel.de> "Re: Why is pq_begintypsend so slow?" on Mon, 19 Feb 2024 11:53:51 -0800, Andres Freund wrote: >> I don't have a strong opinion how to implement this >> optimization as I said above. It seems that you like your >> approach. So I

Re: POC: GROUP BY optimization

On Thu, Feb 22, 2024 at 12:18 PM Andrei Lepikhov wrote: > On 22/2/2024 09:09, Richard Guo wrote: > > I looked through the v2 patch and have two comments. > > > > * The test case under "Check we don't pick aggregate path key instead of > > grouping path key" does not have EXPLAIN to show the

Re: Add lookup table for replication slot invalidation causes

On Thu, Feb 22, 2024 at 5:19 PM Peter Smith wrote: > > Hi, Sorry for the late comment but isn't the pushed logic now > different to what it was there before? > > IIUC previously (in a non-debug build) if the specified > conflict_reason was not found, it returned RS_INVAL_NONE -- now it > seems to

Re: Add lookup table for replication slot invalidation causes

Hi, Sorry for the late comment but isn't the pushed logic now different to what it was there before? IIUC previously (in a non-debug build) if the specified conflict_reason was not found, it returned RS_INVAL_NONE -- now it seems to return whatever enum happens to be last. How about something

Re: About a recently-added message

At Thu, 22 Feb 2024 10:51:07 +0530, Amit Kapila wrote in > > Do you think some additional tests for the rest of the messages are > > worth the trouble? > > > > We have discussed this during development and didn't find it worth > adding tests for all misconfigured parameters. However, in the

Re: About a recently-added message

On Thu, Feb 22, 2024 at 6:16 AM Kyotaro Horiguchi wrote: > > At Thu, 22 Feb 2024 09:36:43 +0900 (JST), Kyotaro Horiguchi > wrote in > > Yes, I'm happy with all of the changes. The proposed patch appears to > > cover all instances related to slotsync.c, and it looks fine to > > me. Thanks! > >

Re: Synchronizing slots from primary to standby

On Wed, Feb 21, 2024 at 5:19 PM Amit Kapila wrote: > > A few minor comments: Thanks for the feedback. > = > 1. > +/* > + * Is stopSignaled set in SlotSyncCtx? > + */ > +bool > +IsStopSignaledSet(void) > +{ > + bool signaled; > + > + SpinLockAcquire(>mutex); > + signaled =

Re: LogwrtResult contended spinlock

On Thu, Feb 22, 2024 at 1:54 AM Jeff Davis wrote: > On Wed, 2024-02-21 at 20:00 +0530, Bharath Rupireddy wrote: > > The local copy of LogwrtResult is so frequently used in the backends, > > if we were to replace it with atomic accesses, won't the atomic reads > > be costly and start showing up in

Re: Unlinking Parallel Hash Join inner batch files sooner

On 22/2/2024 06:42, Thomas Munro wrote: On Wed, Feb 21, 2024 at 7:34 PM Andrei Lepikhov wrote: I see in [1] that the reporter mentioned a delay between the error message in parallel HashJoin and the return control back from PSQL. Your patch might reduce this delay. Also, I have the same

Re: DSA_ALLOC_NO_OOM doesn't work

On Thu, Feb 22, 2024 at 12:49 AM Heikki Linnakangas wrote: > That's fair, I can see those reasons. Nevertheless, I do think it was a > bad tradeoff. A little bit of repetition would be better here, or we can > extract the common parts to smaller functions. > > I came up with the attached: > >

Re: POC: GROUP BY optimization

On 22/2/2024 09:09, Richard Guo wrote: On Wed, Feb 21, 2024 at 6:20 PM Alexander Korotkov > wrote: Hi, Richard! > What do you think about the revisions for the test cases? I've rebased your patch upthread.  Did some minor beautifications. > *

Re: RFC: Logging plan of the running query

On Thu, Feb 22, 2024 at 6:25 AM James Coleman wrote: > > > > ...I think the current approach is just plain dead, because of this > > issue. We can't take an approach that creates an unbounded number of > > unclear reentrancy issues and then insert hacks one by one to cure > > them (or hack around

Re: Documentation to upgrade logical replication cluster

Here are some minor comments for patch v8-0001. == doc/src/sgml/glossary.sgml 1. + + + A set of publisher and subscriber instances with publisher instance + replicating changes to the subscriber instance. + + /with publisher instance/with the publisher instance/ ~~~

Re: Injection points: some tools to wait and wake

On Wed, Feb 21, 2024 at 11:50:21AM +, Bertrand Drouvot wrote: > I think the approach is fine and the hardcoded value is "large" enough (it > would > be surprising, at least to me, to write a test that would need more than 32 > waiters). This could use less. I've never used more than 3 of

Re: Add LSN <-> time conversion functionality

Thanks so much for reviewing! On Fri, Feb 16, 2024 at 3:41 PM Tomas Vondra wrote: > > When I first read this, I immediately started wondering if this might > use the commit timestamp stuff we already have. Because for each commit > we already store the LSN and commit timestamp, right? But I'm

Re: POC: GROUP BY optimization

On Wed, Feb 21, 2024 at 6:20 PM Alexander Korotkov wrote: > Hi, Richard! > > > What do you think about the revisions for the test cases? > > I've rebased your patch upthread. Did some minor beautifications. > > > * The table 'btg' is inserted with 1 tuples, which seems a bit > > expensive

Re: Speeding up COPY TO for uuids and arrays

On Wed, Feb 21, 2024 at 02:29:05PM +0900, Michael Paquier wrote: > That's very good, so I'd like to apply this part. Let me know if > there are any objections. This part is done as of 011d60c4352c. I did not evaluate the rest yet. -- Michael signature.asc Description: PGP signature

Re: Test to dump and restore objects left behind by regression

On Wed, Feb 21, 2024 at 12:18:45PM +0530, Ashutosh Bapat wrote: > Even with 1 and 2 the test is useful to detect dump/restore anomalies. > I think we should improve 3, but I don't have a good and simpler > solution. I didn't find any way to compare two given clusters in our > TAP test framework.

Re: RFC: Logging plan of the running query

On Mon, Feb 19, 2024 at 11:53 PM Robert Haas wrote: > > On Fri, Feb 16, 2024 at 12:29 AM Andres Freund wrote: > > If we went with something like tht approach, I think we'd have to do > > something > > like redirecting node->ExecProcNode to a wrapper, presumably from within a > > CFI. That

Re: About a recently-added message

At Thu, 22 Feb 2024 09:36:43 +0900 (JST), Kyotaro Horiguchi wrote in > Yes, I'm happy with all of the changes. The proposed patch appears to > cover all instances related to slotsync.c, and it looks fine to > me. Thanks! I'd like to raise another potential issue outside the patch. The patch

Re: About a recently-added message

At Wed, 21 Feb 2024 14:57:42 +0530, Amit Kapila wrote in > On Tue, Feb 20, 2024 at 3:21 PM shveta malik wrote: > > > > okay, attached v2 patch with changed error msgs and double quotes > > around logical. > > > > Horiguchi-San, does this address all your concerns related to > translation with

Re: Patch: Add parse_type Function

On Feb 21, 2024, at 17:19, Erik Wienhold wrote: > Thanks David! LGTM. Thanks. Anyone else? Or is it ready for committer? Best, David

Re: DSA_ALLOC_NO_OOM doesn't work

On 22/02/2024 01:03, Thomas Munro wrote: On Thu, Feb 22, 2024 at 10:30 AM Thomas Munro wrote: collisions arbitrarily far apart (just decide how many bits to use). . o O ( Perhaps if you also allocated slots using a FIFO freelist, instead of the current linear search for the first free slot,

Re: Add lookup table for replication slot invalidation causes

On Wed, Feb 21, 2024 at 12:50:00PM +0530, Bharath Rupireddy wrote: > Please see the attached v3 patch. Seems globally OK, so applied. I've simplified a bit the comments, painted some extra const, and kept variable name as conflict_reason as the other routines of slot.h use "name" already to

Re: Experiments with Postgres and SSL

On Wed, 10 Jan 2024 at 09:31, Heikki Linnakangas wrote: > > Some more comments on this: > > 1. It feels weird that the combination of "gssencmode=require > sslnegotiation=direct" combination is forbidden. Sure, the ssl > negotiation will never happen with gssencmode=require, so the >

Re: Unlinking Parallel Hash Join inner batch files sooner

On Wed, Feb 21, 2024 at 7:34 PM Andrei Lepikhov wrote: > I see in [1] that the reporter mentioned a delay between the error > message in parallel HashJoin and the return control back from PSQL. Your > patch might reduce this delay. > Also, I have the same complaint from users who processed

RE: Psql meta-command conninfo+

Hi! (v19) Adjusted the description of each column in the documentation as promised. I used the existing documentation as a basis for each SQL function used, as well as for functions and views related to SSL and GSSAPI (documentation). If you can validate, I appreciate it. Regards, Maiquel

Re: DSA_ALLOC_NO_OOM doesn't work

On Thu, Feb 22, 2024 at 10:30 AM Thomas Munro wrote: > collisions arbitrarily far apart (just decide how many bits to use). . o O ( Perhaps if you also allocated slots using a FIFO freelist, instead of the current linear search for the first free slot, you could maximise the time before a slot

Discover PostgreSQL's Graph Power with Apache AGE!

Hello PostgreSQL Community, Excited to share how Apache AGE enhances PostgreSQL with smooth graph features! Handles complex data, and supports SQL and Cypher. Join our awesome community, check tutorials, and let's dive into those data projects! More info.: Apache AGE GitHub

Re: Patch: Add parse_type Function

On 2024-02-21 22:49 +0100, David E. Wheeler wrote: > On Feb 21, 2024, at 16:43, Erik Wienhold wrote: > > > The docs still state that to_regtypemod() has a named parameter, which > > is not the case per pg_proc.dat. > > Bah, I cleaned it up before but somehow put it back. Thanks for the > catch.

Re: Patch: Add parse_type Function

On Feb 21, 2024, at 16:43, Erik Wienhold wrote: > The docs still state that to_regtypemod() has a named parameter, which > is not the case per pg_proc.dat. Bah, I cleaned it up before but somehow put it back. Thanks for the catch. Fixed. Best, David

Re: Patch: Add parse_type Function

On 2024-02-21 17:51 +0100, David E. Wheeler wrote: > On Feb 21, 2024, at 11:18, Erik Wienhold wrote: > > > Thanks. But it's an applefile again, not a patch :P > > Let’s try that again. Thanks. > +to_regtypemod ( type > text ) The docs still state that to_regtypemod() has a named

Re: DSA_ALLOC_NO_OOM doesn't work

On Thu, Feb 22, 2024 at 8:19 AM Heikki Linnakangas wrote: > - Separate dsm_handle, used by backend code to interact with the high > level interface in dsm.c, from dsm_impl_handle, which is used to > interact with the low-level functions in dsm_impl.c. This gets rid of > the convention in dsm.c of

Re: [PATCH] Exponential backoff for auth_delay

Hi, Thanks for the patch. I took a closer look at v3, so let me share some review comments. Please push back if you happen to disagree with some of it, some of this is going to be more a matter of personal preference. 1) I think it's a bit weird to have two options specifying amount of time,

Re: margay fails assertion in stats/dsa/dsm code

On Sat, Jul 2, 2022 at 11:10 AM Thomas Munro wrote: > On Sat, Jul 2, 2022 at 1:15 AM Robert Haas wrote: > > Changing the default on certain platforms to 'posix' or 'sysv' > > according to what works best on that platform seems reasonable to me. > > Ok, I'm going to make that change in 15 +

Re: WIP Incremental JSON Parser

On Wed, Feb 21, 2024 at 6:50 AM Jacob Champion wrote: > On Tue, Feb 20, 2024 at 9:32 PM Andrew Dunstan wrote: > > *sigh* That's weird. I wonder why you can reproduce it and I can't. Can > > you give me details of the build? OS, compiler, path to source, build > > setup etc.? Anything that might

Re: LogwrtResult contended spinlock

On Wed, 2024-02-21 at 20:00 +0530, Bharath Rupireddy wrote: > The local copy of LogwrtResult is so frequently used in the backends, > if we were to replace it with atomic accesses, won't the atomic reads > be costly and start showing up in perf profiles? I don't see exactly where the extra cost

RE: Popcount optimization using AVX512

Hi, I am encountering a problem that I don't think I understand. I cannot get the MSVC build to link in CI. I added 2 files to the build, but the linker is complaining about the original pg_bitutils.c file is missing (specifically symbol 'pg_popcount'). To my knowledge my changes did not

Re: bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445)

On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote: > > On the face of it, the simplest fix is to tweak is_simple_union_all() > to prevent UNION ALL subquery pullup for MERGE, forcing a > subquery-scan plan. A quick test shows that that fixes the reported > issue. > > However, that leaves the

Re: to_regtype() Raises Error

On Feb 21, 2024, at 11:54 AM, David Wheeler wrote: > Merged this change into the [to_regtypemod > patch](https://commitfest.postgresql.org/47/4807/), which has exactly the > same issue. > > The new status of this patch is: Needs review Bah, withdrawn. D

Re: to_regtype() Raises Error

Merged this change into the [to_regtypemod patch](https://commitfest.postgresql.org/47/4807/), which has exactly the same issue. The new status of this patch is: Needs review

Re: Patch: Add parse_type Function

On Feb 21, 2024, at 11:18, Erik Wienhold wrote: > Thanks. But it's an applefile again, not a patch :P WTF. I still have that feature disabled. Oh, I think I deleted the file after dragged it into Mail but before sending, because it’s empty everywhere I look. 臘‍♂️ Let’s try that again.

Re: Patch: Add parse_type Function

On 2024-02-21 16:14 +0100, David E. Wheeler wrote: > > V8 attached. Thanks. But it's an applefile again, not a patch :P -- Erik

Re: When extended query protocol ends?

Vladimir Sitnikov writes: >> Would performance suffer that much? > I have not benchmarked it much, however, the driver sends "autosave" > queries once (savepoint) or twice(savepoint+release) for every > user-provided query. > If we use extended queries (parse+bind+exec) for every savepoint, that

Re: When extended query protocol ends?

>Would performance suffer that much? I have not benchmarked it much, however, the driver sends "autosave" queries once (savepoint) or twice(savepoint+release) for every user-provided query. If we use extended queries (parse+bind+exec) for every savepoint, that would result in 3 or 6 messages

Re: When extended query protocol ends?

On Wed, 21 Feb 2024 at 16:35, Vladimir Sitnikov wrote: > We can't send complete parse-bind-execute commands for every "savepoint" call > as it would hurt performance. Would performance suffer that much? I'd expect the simple and extended protocol to have roughly the same overhead for simple

Re: When extended query protocol ends?

>Is it possible for the JDBC >driver to issue a Sync message before sending SAVEPOINT in simple >query protocol? Apparently, sending an extra message would increase the overhead of the protocol, thus reducing the efficiency of the application. What is the benefit of sending extra Sync?

Re: Patch: Add parse_type Function

On Feb 20, 2024, at 21:09, Erik Wienhold wrote: > The references are printed as "???" right now. Can be fixed with > xreflabel="format_type" and xreflabel="to_regtype" on those > elements. Thanks. > The docs show parameter name "type" but pg_proc.data does not define > proargnames. So the

Re: POC: GROUP BY optimization

Hi! Another issue on test introduced in 0452b461bc405. I think it may be unstable in some circumstances. For example, if we'll try to use different BLCKSZ. See, I've made a little change in the number of tuples to be inserted: $ git diff diff --git a/src/test/regress/sql/aggregates.sql

Improve readability by using designated initializers when possible

Usage of designated initializers came up in: https://www.postgresql.org/message-id/flat/ZdWXhAt9Tz4d-lut%40paquier.xyz#9dc17e604e58569ad35643672bf74acc This converts all arrays that I could find that could clearly benefit from this without any other code changes being necessary. There were a few

Re: WIP Incremental JSON Parser

On Tue, Feb 20, 2024 at 9:32 PM Andrew Dunstan wrote: > *sigh* That's weird. I wonder why you can reproduce it and I can't. Can > you give me details of the build? OS, compiler, path to source, build > setup etc.? Anything that might be remotely relevant. Sure: - guest VM running in UTM (QEMU

Re: Introduce XID age and inactive timeout based replication slot invalidation

On Wed, Feb 21, 2024 at 5:55 PM Bertrand Drouvot wrote: > > > As far as the 0001 patch is concerned, it reports the > > invalidation_reason as long as slot_contents.data.invalidated != > > RS_INVAL_NONE. I think this is okay. > > > > Thoughts? > > Yeah, looking at the code I agree that looks ok.

Re: LogwrtResult contended spinlock

On Sat, Feb 17, 2024 at 2:24 AM Jeff Davis wrote: > > Though it looks like we can remove the non-shared LogwrtResult > entirely. Andres expressed some concern here: > > https://www.postgresql.org/message-id/20210130020211.rtu5ir3dpjrbi...@alap3.anarazel.de > > But then seemed to favor removing it

Re: Shared detoast Datum proposal

I see your reply when I started to write a more high level document. Thanks for the step by step help! Tomas Vondra writes: > On 2/20/24 19:38, Andy Fan wrote: >> >> ... >> >>> I think it should be done the other >>> way around, i.e. the patch should introduce the main feature first >>>

Re: Shared detoast Datum proposal

On 2/20/24 19:38, Andy Fan wrote: > > ... > >> I think it should be done the other >> way around, i.e. the patch should introduce the main feature first >> (using the traditional Bitmapset), and then add Bitset on top of that. >> That way we could easily measure the impact and see if it's useful.

Re: Introduce XID age and inactive timeout based replication slot invalidation

Hi, On Wed, Feb 21, 2024 at 10:55:00AM +0530, Bharath Rupireddy wrote: > On Tue, Feb 20, 2024 at 12:05 PM Bharath Rupireddy > wrote: > > > >> [...] and was able to produce something like: > > > > > > postgres=# select > > > slot_name,slot_type,active,active_pid,wal_status,invalidation_reason

Re: 'Shutdown <= SmartShutdown' check while launching processes in postmaster.

On Wed, Feb 21, 2024 at 3:38 PM shveta malik wrote: > > > Children that are stopped by the "if (pmState == PM_STOP_BACKENDS)" > > stanza in PostmasterStateMachine should not be allowed to start > > again later if we are trying to shut down. (But "smart" shutdown > > doesn't enforce that, since

Re: Injection points: some tools to wait and wake

Hi, On Wed, Feb 21, 2024 at 04:46:00PM +0900, Michael Paquier wrote: > On Wed, Feb 21, 2024 at 07:08:03AM +0900, Michael Paquier wrote: > > Well, both you and Andrey are asking for it now, so let's do it. The > > implementation is simple: > > - Store in InjectionPointSharedState an array of

Re: Synchronizing slots from primary to standby

On Wed, Feb 21, 2024 at 12:15 PM shveta malik wrote: > > > Thanks for the feedback. I have addressed it in v93. > A few minor comments: = 1. +/* + * Is stopSignaled set in SlotSyncCtx? + */ +bool +IsStopSignaledSet(void) +{ + bool signaled; + + SpinLockAcquire(>mutex); + signaled

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Hi! > How do you suppose this would work differently from a long-lived > normal snapshot, which is how it works right now? Difference in the ability to take new visibility snapshot periodically during the second phase with rechecking visibility of tuple according to the "reference" snapshot

Re: A problem about partitionwise join

On Tue, Aug 2, 2022 at 4:24 AM Jacob Champion wrote: > Once you think you've built up some community support and the patchset > is ready for review, you (or any interested party) can resurrect the > patch entry by visiting > > https://commitfest.postgresql.org/38/2266/ > > and changing the

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

On Wed, 21 Feb 2024 at 09:35, Michail Nikolaev wrote: > > One more idea - is just forbid HOT prune while the second phase is > running. It is not possible anyway currently because of snapshot held. > > Possible enhancements: > * we may apply restriction only to particular tables > * we may apply

Re: Reduce useless changes before reassembly during logical replication

Hi Jie, > Most importantly, if we filter out unpublished relationship-related > changes after > constructing the changes but before queuing the changes into a transaction, > will it reduce the workload of logical decoding and avoid disk or memory > growth > as much as possible? Thanks for the

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

On Wed, 21 Feb 2024 at 00:33, Michail Nikolaev wrote: > > Hello! > > I think the best way for this to work would be an index method that > > exclusively stores TIDs, and of which we can quickly determine new > > tuples, too. I was thinking about something like GIN's format, but > > using

Re: BRIN integer overflow

> On 21 Feb 2024, at 06:40, Oleg Tselebrovskiy > wrote: > Function bringetbitmap that is used in BRIN's IndexAmRoutine should return an > int64 value, but the actual return value is int, since totalpages is int and > totalpages * 10 is also int. This could lead to integer overflow (totalpages

Re: POC: GROUP BY optimization

Hi, Richard! > What do you think about the revisions for the test cases? I've rebased your patch upthread. Did some minor beautifications. > * The table 'btg' is inserted with 1 tuples, which seems a bit > expensive for a test. I don't think we need such a big table to test > what we

Re: 'Shutdown <= SmartShutdown' check while launching processes in postmaster.

On Wed, Feb 21, 2024 at 10:01 AM Tom Lane wrote: > > shveta malik writes: > > I would like to know that why we have 'Shutdown <= SmartShutdown' > > check before launching few processes (WalReceiver, WalSummarizer, > > AutoVacuum worker) while rest of the processes (BGWriter, WalWriter, > >

Re: logical decoding and replication of sequences, take 2

On Wed, Feb 21, 2024 at 2:52 PM Robert Haas wrote: > > On Wed, Feb 21, 2024 at 2:43 PM Dilip Kumar wrote: > > So the problem is that we might consider the transaction change as > > non-transaction and mark this flag as true. > > But it's not "might" right? It's absolutely 100% certain that we

Re: About a recently-added message

On Tue, Feb 20, 2024 at 3:21 PM shveta malik wrote: > > okay, attached v2 patch with changed error msgs and double quotes > around logical. > Horiguchi-San, does this address all your concerns related to translation with these new messages? -- With Regards, Amit Kapila.

Re: logical decoding and replication of sequences, take 2

On Wed, Feb 21, 2024 at 2:43 PM Dilip Kumar wrote: > So the problem is that we might consider the transaction change as > non-transaction and mark this flag as true. But it's not "might" right? It's absolutely 100% certain that we will consider that transaction's changes as non-transactional ...

Re: logical decoding and replication of sequences, take 2

On Wed, Feb 21, 2024 at 1:24 PM Robert Haas wrote: > > On Wed, Feb 21, 2024 at 1:06 PM Dilip Kumar wrote: > > > But I am wondering why this flag is always set to true in > > > DecodeTXNNeedSkip() irrespective of the commit or abort. Because the > > > aborted transactions are not supposed to be

Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

One more idea - is just forbid HOT prune while the second phase is running. It is not possible anyway currently because of snapshot held. Possible enhancements: * we may apply restriction only to particular tables * we may apply restrictions only to part of the tables (not yet scanned by R/CICs).

Re: POC: GROUP BY optimization

On Fri, Feb 2, 2024 at 12:40 PM Andrei Lepikhov wrote: > On 2/2/2024 11:06, Richard Guo wrote: > > > > On Fri, Feb 2, 2024 at 11:32 AM Richard Guo > > wrote: > > > > On Fri, Feb 2, 2024 at 10:02 AM Tom Lane > > wrote: > > > >

Re: Injection points: some tools to wait and wake

Hi, On Wed, Feb 21, 2024 at 07:08:03AM +0900, Michael Paquier wrote: > On Tue, Feb 20, 2024 at 03:55:08PM +, Bertrand Drouvot wrote: > > +PG_FUNCTION_INFO_V1(injection_points_wake); > > +Datum > > +injection_points_wake(PG_FUNCTION_ARGS) > > +{ > > > > I think that This function will wake up

Re: Catalog domain not-null constraints

wandering around the function AlterDomainNotNull, the following code can fix the previous undesired behavior. seems pretty simple, am I missing something? based on v3-0001-Add-tests-for-domain-related-information-schema-v.patch and v3-0002-Catalog-domain-not-null-constraints.patch diff --git

Re: Removing unneeded self joins

On 21/2/2024 14:26, Richard Guo wrote: This patch also includes some cosmetic tweaks for SJE test cases.  It does not change the test cases using catalog tables though.  I think that should be a seperate patch. Thanks for this catch, it is really messy thing, keeping aside the question why we