Re: remove volatile qualifiers from pg_stat_statements

Hi, On Tue, Jul 30, 2024 at 01:24:54PM -0500, Nathan Bossart wrote: > While looking into converting pgssEntry->mutex to an LWLock (per a > suggestion elsewhere [0]), I noticed that pg_stat_statements uses > "volatile" quite liberally. IIUC we can remove these as of commit 0709b7e > (like commits

make pg_createsubscriber option names more consistent

I propose to rename the pg_createsubscriber option --socket-directory to --socketdir. This would make it match the equivalent option in pg_upgrade. (It even has the same short option '-s'.) pg_createsubscriber and pg_upgrade have a lot of common terminology and a similar operating mode, so it

Lack of possibility to specify CTAS TAM

I have noticed $subj while working with other unrelated patches. The question is, why there is no CREATE TABLE AS USING (some_access_method)? This feature looks straightforward, and lack of it is a bit of inconsistency from my point of view. Maybe there are some unobvious caveats with implemen

Re: Use pgBufferUsage for block reporting in analyze

On Tue, Jul 30, 2024 at 9:21 AM Anthonin Bonnefoy wrote: > A possible change would be to pass an inh flag when an acquirefunc is > called from acquire_inherited_sample_rows. The acquirefunc could then > use an alternative log format to append to logbuf. This way, we could > have a more compact for

Re: proposal: schema variables

st 31. 7. 2024 v 8:57 odesílatel Laurenz Albe napsal: > On Wed, 2024-07-31 at 08:41 +0200, Pavel Stehule wrote: > > Probably you didn't attach new files - the second patch is not complete. > Or you didn't make changes there? > > Hm. What is missing? > let.sgml, session_variable.c svariable_rece

Re: Lack of possibility to specify CTAS TAM

> On 31 Jul 2024, at 12:03, Kirill Reshke wrote: > > CREATE TABLE AS USING > (some_access_method) This looks in a line with usual CREATE TABLE. +1 for the feature. Currently we do not have so many TAMs, but I hope eventually we will have some. Best regards, Andrey Borodin.

Re: Lack of possibility to specify CTAS TAM

On Wednesday, July 31, 2024, Kirill Reshke wrote: > I have noticed $subj while working with other unrelated patches. > The question is, why there is no CREATE TABLE AS USING > (some_access_method)? The syntax is documented… CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TAB

Re: Lack of possibility to specify CTAS TAM

On Wed, 31 Jul 2024, 12:12 Andrey M. Borodin, wrote: > > Currently we do not have so many TAMs > Currently we do not have so many TAM in core. Outside core there is actually a quite a number of projects doing TAMs. Orioledb is one example. >

Re: Lack of possibility to specify CTAS TAM

On Wednesday, July 31, 2024, Kirill Reshke wrote: > > > The same storage specification feature can actually be supported for > CTAE (like CTAS but execute) and CREATE MATERIALIZED VIEW. > > On a related note, the description here seems outdated. https://www.postgresql.org/docs/current/runtime-co

Re: Logical Replication of sequences

Hi Vignesh, Here are my review comments for your latest 0730_2* patches. Patch v20240730_2-0001 looks good to me. Patch v20240730_2-0002 looks good to me. My comments for the v20240730_2-0003 patch are below: // GENERAL 1. Inconsistent terms I've noticed there are many variations of

Re: Lack of possibility to specify CTAS TAM

On Wednesday, July 31, 2024, David G. Johnston wrote: > On Wednesday, July 31, 2024, Kirill Reshke wrote: >> >> >> The same storage specification feature can actually be supported for >> CTAE (like CTAS but execute) and CREATE MATERIALIZED VIEW. >> >> > On a related note, the description here se

Re: Lack of possibility to specify CTAS TAM

On Wed, 31 Jul 2024 at 12:15, David G. Johnston wrote: > > On Wednesday, July 31, 2024, Kirill Reshke wrote: >> >> I have noticed $subj while working with other unrelated patches. >> The question is, why there is no CREATE TABLE AS USING >> (some_access_method)? > > > The syntax is documente

Re: Docs: Order of json aggregate functions

On Tue, 2024-07-23 at 11:45 +0200, Marlene Reiterer wrote: > Am Mo., 22. Juli 2024 um 15:19 Uhr schrieb Wolfgang Walther > : > > > > The order of json related aggregate functions in the docs is currently > > like this: > > > > [...] > > json_agg > > json_objectagg > > json_object_agg > > json_ob

psql client does not handle WSAEWOULDBLOCK on Windows

*Description:*The connection fails with a non-blocking socket error when using psql on Windows to connect to a PostgreSQL server with GSSAPI enabled. The error is because the socket error code is obtained by WSAGetLastError() instead of errno. This causes the value of errno to be incorrect when han

PG17beta2: SMGR: inconsistent type for nblocks

Hi, While working on rebasing the patches of Neon's fork onto the REL_17_STABLE branch, I noticed that the nblocks arguments of various smgr functions have inconsistent types: smgrzeroextend accepts `nblocks` as signed integer, as does the new signature for smgrprefetch, but the new vectorized ope

Re: Remove last traces of HPPA support

On 31/07/2024 08:52, Thomas Munro wrote: On Tue, Jul 30, 2024 at 9:50 AM Thomas Munro wrote: I guess we should also consider reimplementing the spinlock on the atomic API, but I can see that Andres is poking at spinlock code right now so I'll keep out of his way... Here is a first attempt at

RE: Remove duplicate table scan in logical apply worker and code refactoring

Dear Hou, Thanks for creating a patch! > When reviewing the code in logical/worker.c, I noticed that when applying a > cross-partition update action, it scans the old partition twice. > I am attaching the patch 0001 to remove this duplicate table scan. Just to clarify, you meant that FindReplTup

Re: Logical Replication of sequences

On Mon, Jun 10, 2024 at 5:00 PM vignesh C wrote: > > On Mon, 10 Jun 2024 at 12:24, Amul Sul wrote: > > > > > > > > On Sat, Jun 8, 2024 at 6:43 PM vignesh C wrote: > >> > >> On Wed, 5 Jun 2024 at 14:11, Amit Kapila wrote: > >> [...] > >> A new catalog table, pg_subscription_seq, has been introdu

RE: make pg_createsubscriber option names more consistent

Dear Peter, > I propose to rename the pg_createsubscriber option --socket-directory to > --socketdir. This would make it match the equivalent option in > pg_upgrade. (It even has the same short option '-s'.) > pg_createsubscriber and pg_upgrade have a lot of common terminology and > a similar op

Re: MAINTAIN privilege -- what do we need to un-revert it?

Hi, On Fri, 26 Jul 2024 16:47:23 -0700 Jeff Davis wrote: > Hello, > > Thank you for looking. > > On Fri, 2024-07-26 at 12:26 +0900, Yugo Nagata wrote: > > Since this commit, matviews are no longer handled in > > ExecCreateTableAs, so the > > following error message has not to consider material

Re: Proposal: Document ABI Compatibility

On 19.07.24 16:10, David E. Wheeler wrote: On Jun 27, 2024, at 18:07, David E. Wheeler wrote: Minor nit - misspelled “considerd" Thank you, Jeremy. V3 attached. Rebase on 5784a49 attached. I presume this topic needs quite a bit of review and consensus from the committers more generally.

Re: Logical Replication of sequences

On Sat, 20 Jul 2024 at 20:48, vignesh C wrote: > > On Fri, 12 Jul 2024 at 08:22, Peter Smith wrote: > > > > Hi Vignesh. Here are the rest of my comments for patch v20240705-0003. > > == > > > > 8. logicalrep_sequence_sync_worker_find > > > > +/* > > + * Walks the workers array and searches fo

Re: can we mark upper/lower/textlike functions leakproof?

On 2024-07-30 Tu 6:51 PM, David Rowley wrote: On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan wrote: Fast forward to now. The customer has found no observable ill effects of marking these functions leakproof. The would like to know if there is any reason why we can't mark them leakproof, so that

Re: Remove last traces of HPPA support

On Wed, Jul 31, 2024 at 8:47 PM Heikki Linnakangas wrote: > On 31/07/2024 08:52, Thomas Munro wrote: > The old __i386__ implementation of TAS() said: > > >* When this was last tested, we didn't have separate TAS() and > > TAS_SPIN() > >* macros. Nowadays it probably would be bett

Re: Conflict detection and logging in logical replication

On Wed, Jul 31, 2024 at 7:40 AM Zhijie Hou (Fujitsu) wrote: > > Here is the V8 patch set. It includes the following changes: > A few more comments: 1. I think in FindConflictTuple() the patch is locking the tuple so that after finding a conflict if there is a concurrent delete, it can retry to fi

The stats.sql test is failing sporadically in v14- on POWER7/AIX 7.1 buildfarm animals

Hello hackers, Yesterday, the buildfarm animal sungazer was benevolent enough to demonstrate a rare anomaly, related to old stats collector: test stats    ... FAILED   469155 ms  1 of 212 tests failed. --- /home/nm/farm/gcc6

RE: Remove duplicate table scan in logical apply worker and code refactoring

On Wednesday, July 31, 2024 5:07 PM Kuroda, Hayato/黒田 隼人 wrote: > > Dear Hou, > > > When reviewing the code in logical/worker.c, I noticed that when > > applying a cross-partition update action, it scans the old partition twice. > > I am attaching the patch 0001 to remove this duplicate table s

Re: refactor the CopyOneRowTo

Hi, hackers I'm sure this refactoring is useful because it's more readable when datum value is binary or not. However, I can see a little improvement. We can declare variable 'bytea *outputbytes' in 'else' because variable is used nowhere except this place. Regards, Ilia Evdokimov, Tanto

Re: can we mark upper/lower/textlike functions leakproof?

On 7/31/24 05:47, Andrew Dunstan wrote: On 2024-07-30 Tu 6:51 PM, David Rowley wrote: On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan wrote: Fast forward to now. The customer has found no observable ill effects of marking these functions leakproof. The would like to know if there is any reason why

Re: refactor the CopyOneRowTo

On Fri, Jul 5, 2024 at 12:26 AM jian he wrote: > > original CopyOneRowTo: > https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/commands/copyto.c#n922 > I change it to: > --- > if (!cstate->opts.binary) > { > foreach_int(attnum, cstate->attnumlist) > { > Datum value

Re: can we mark upper/lower/textlike functions leakproof?

On 2024-07-31 We 9:14 AM, Joe Conway wrote: On 7/31/24 05:47, Andrew Dunstan wrote: On 2024-07-30 Tu 6:51 PM, David Rowley wrote: On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan wrote: Fast forward to now. The customer has found no observable ill effects of marking these functions leakproof. T

Re: pg_upgrade failing for 200+ million Large Objects

On Mon, Jul 29, 2024 at 12:24 AM Tom Lane wrote: > So I'm forced to the conclusion that we'd better make the transaction > size adaptive as per Alexander's suggestion. > > In addition to the patches attached, I experimented with making > dumpTableSchema fold all the ALTER TABLE commands for a sing

Re: Fixing backslash dot for COPY FROM...CSV

Sutou Kouhei wrote: > BTW, here is a diff after pgindent: PFA a v5 with the cosmetic changes applied. > I also confirmed that the updated server and non-updated > psql compatibility problem (the end-of-data "\." is > inserted). It seems that it's difficult to solve without > introducing

Re: Assertion failure with summarize_wal enabled during pg_createsubscriber

On Mon, Jul 29, 2024 at 7:20 PM Robert Haas wrote: > On Fri, Jul 26, 2024 at 4:10 PM Alexander Korotkov > wrote: > > 0002 could also use pg_indent and pgperltidy. And I have couple other > > notes regarding 0002. > > As Tom said elsewhere, we don't have a practice of requiring perltidy > for ev

Re: Proposal: Document ABI Compatibility

On Jul 31, 2024, at 05:27, Peter Eisentraut wrote: > Well, nobody has protested against what we wrote, so I have committed it. Excellent, thank you! D

Re: make pg_createsubscriber option names more consistent

On Wed, Jul 31, 2024, at 4:02 AM, Peter Eisentraut wrote: > I propose to rename the pg_createsubscriber option --socket-directory to > --socketdir. This would make it match the equivalent option in > pg_upgrade. (It even has the same short option '-s'.) > pg_createsubscriber and pg_upgrade hav

Re: New compiler warnings in buildfarm

Peter Eisentraut writes: > On 30.07.24 18:19, Tom Lane wrote: >> Sometime in the last month or so, flaviventris's bleeding-edge >> version of gcc has started whining[1] about truncation of a >> string literal's implicit trailing '\0' in contexts like this: >> ../pgsql/src/backend/commands/copyto.c

Suggestions to overcome 'multixact "members" limit exceeded' in temporary tables

I've reached the limit of my understanding and attempts at correcting my code/use of temporary tables in the face of multixact members and have come to ask for your help! Here's a brief description of my software; Pool of N connection sessions, persistent for the duration of the program lifetime.

Re: improve performance of pg_dump with many sequences

Committed. -- nathan

Re: why there is not VACUUM FULL CONCURRENTLY?

Kirill Reshke wrote: > Also, I was thinking about pg_repack vs pg_squeeze being used for the > VACUUM FULL CONCURRENTLY feature, and I'm a bit suspicious about the > latter. > If I understand correctly, we essentially parse the whole WAL to > obtain info about one particular relation changes. Th

Re: Suggestions to overcome 'multixact "members" limit exceeded' in temporary tables

I've been able to observe that the performance degradation with TRUNCATE appears to happen when other ancillary processes are running that are also heavy users of temporary tables. If I used an exclusive tablespace, would that improve things? Cheers Jim On Wed, 31 Jul 2024 at 15:16, Jim Vanns

Re: Recent 027_streaming_regress.pl hangs

On 2024-07-25 Th 6:33 PM, Andrew Dunstan wrote: On 2024-07-25 Th 5:14 PM, Tom Lane wrote: I wrote: I'm confused by crake's buildfarm logs. AFAICS it is not running recovery-check at all in most of the runs; at least there is no mention of that step, for example here: https://buildfarm.postg

Re: Recent 027_streaming_regress.pl hangs

Andrew Dunstan writes: > There seem to be a bunch of recent failures, and not just on crake, and > not just on HEAD: > There were a batch of recovery-stage failures ending about 9 d

Re: On disable_cost

OK, here's a new patch version. I earlier committed the refactoring to avoid using disable_cost to force WHERE CURRENT OF to be implemented by a TID scan. In this version, I've dropped everything related to reworking enable_indexscan or any other enable_* GUC. Hence, this version of the patch set j

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Mon, Jul 15, 2024 at 2:02 PM Alexander Korotkov wrote: > On Mon, Jul 15, 2024 at 4:24 AM Alexander Korotkov > wrote: > > Thanks to Kyotaro for the review. And thanks to Ivan for the patch > > revision. I made another revision of the patch. > > I've noticed failures on cfbot. The attached r

Re: Recent 027_streaming_regress.pl hangs

On 2024-07-31 We 12:05 PM, Tom Lane wrote: Andrew Dunstan writes: There seem to be a bunch of recent failures, and not just on crake, and not just on HEAD: There were a batch of

Re: can we mark upper/lower/textlike functions leakproof?

On Wed, Jul 31, 2024 at 9:14 AM Joe Conway wrote: > In my opinion, for this use case and others, it should be possible to > redact the values substituted into log messages based on some criteria. > One of those criteria could be "I am in a leakproof call right now". In > fact in a similar fashion,

Re: can we mark upper/lower/textlike functions leakproof?

Robert Haas writes: > If there are some inputs that cause upper() and lower() to fail and > others that do not, the functions aren't leakproof, because an > attacker can extract information about values that they can't see by > feeding those values into these functions and seeing whether they get

Re: New compiler warnings in buildfarm

Hi, On 2024-07-31 10:11:07 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On 30.07.24 18:19, Tom Lane wrote: > >> Sometime in the last month or so, flaviventris's bleeding-edge > >> version of gcc has started whining[1] about truncation of a > >> string literal's implicit trailing '\0' in

Re: New compiler warnings in buildfarm

Hi, On 2024-07-31 11:32:56 -0700, Andres Freund wrote: > On 2024-07-31 10:11:07 -0400, Tom Lane wrote: > > It looks like serinus needs this fix too. > > Added to both. I've forced runs for both animals, so the bf should show > results of that soon. I Wonder if I should also should add -Wno-clobb

Re: can we mark upper/lower/textlike functions leakproof?

On 7/31/24 14:03, Tom Lane wrote: Robert Haas writes: If there are some inputs that cause upper() and lower() to fail and others that do not, the functions aren't leakproof, because an attacker can extract information about values that they can't see by feeding those values into these functions

Re: Remove last traces of HPPA support

Hi, On 2024-07-31 17:52:34 +1200, Thomas Munro wrote: > 2. The pg_atomic_unlocked_test_flag() function was surprising to me: > it returns true if it's not currently set (according to a relaxed > load). Most of this patch was easy, but figuring out that I had > reverse polarity here was a multi-c

Re: Remove last traces of HPPA support

Hi, On 2024-07-30 23:08:36 +1200, Thomas Munro wrote: > On Tue, Jul 30, 2024 at 12:39 PM Thomas Munro wrote: > > On Tue, Jul 30, 2024 at 11:16 AM Heikki Linnakangas wrote: > > > Looks good to me. > > > > Thanks. I'll wait just a bit longer to see if anyone else has comments. > > And pushed. Y

Re: Use pgBufferUsage for block reporting in analyze

On Wed, Jul 31, 2024 at 12:03 AM Anthonin Bonnefoy wrote: > > On Tue, Jul 30, 2024 at 9:21 AM Anthonin Bonnefoy > wrote: > > A possible change would be to pass an inh flag when an acquirefunc is > > called from acquire_inherited_sample_rows. The acquirefunc could then > > use an alternative log f

Re: [17+] check after second call to pg_strnxfrm is too strict, relax it

On Tue, 2024-07-30 at 23:01 +0300, Heikki Linnakangas wrote: > +1. A comment in the pg_strnxfrm() function itself would be good too. Committed, thank you. Backported to 16 (original email said 17, but that was a mistake). Regards, Jeff Davis

Re: Remove last traces of HPPA support

Hi, On 2024-07-31 22:32:19 +1200, Thomas Munro wrote: > > That old comment means that both SpinLockAcquire() and SpinLockRelease() > > acted as full memory barriers, and looking at the implementations, that > > was indeed so. With the new implementation, SpinLockAcquire() will have > > "acquire se

Re: can we mark upper/lower/textlike functions leakproof?

On 2024-07-31 We 2:43 PM, Joe Conway wrote: On 7/31/24 14:03, Tom Lane wrote: Robert Haas writes: If there are some inputs that cause upper() and lower() to fail and others that do not, the functions aren't leakproof, because an attacker can extract information about values that they can't s

Re: pg_verifybackup: TAR format backup verification

On Wed, Jul 31, 2024 at 9:28 AM Amul Sul wrote: > Fixed -- I did that because it was part of a separate group in pg_basebackup. Well, that's because pg_basebackup builds multiple executables, and these files needed to be linked with some but not others. It looks like when Andres added meson suppo

Re: can we mark upper/lower/textlike functions leakproof?

On Wed, Jul 31, 2024 at 2:43 PM Joe Conway wrote: > I still maintain that there is a whole host of users that would accept > the risk of side channel attacks via existence of an error or not, if > they could only be sure nothing sensitive leaks directly into the logs > or to the clients. We should

Re: can we mark upper/lower/textlike functions leakproof?

On Wed, Jul 31, 2024 at 2:03 PM Tom Lane wrote: > The problem here is that marking these functions leakproof is a > promise about a *whole bunch* of code, much of it not under our > control; worse, there's no reason to think all that code is stable. > A large fraction of it didn't even exist a few

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman wrote: > In back branches starting with 14, failing to remove tuples older than > OldestXmin during pruning caused vacuum to infinitely loop in > lazy_scan_prune(), as investigated on this [1] thread. Shouldn't somebody remove the entry that we hav

Re: can we mark upper/lower/textlike functions leakproof?

On 7/31/24 16:10, Robert Haas wrote: On Wed, Jul 31, 2024 at 2:43 PM Joe Conway wrote: I still maintain that there is a whole host of users that would accept the risk of side channel attacks via existence of an error or not, if they could only be sure nothing sensitive leaks directly into the l

Re: Popcount optimization using AVX512

Hi, On 2024-07-30 22:12:18 -0500, Nathan Bossart wrote: > On Tue, Jul 30, 2024 at 10:01:50PM -0500, Nathan Bossart wrote: > > On Tue, Jul 30, 2024 at 07:43:08PM -0700, Andres Freund wrote: > >> My point is that _xgetbv() is made available by -mavx512vpopcntdq > >> -mavx512bw > >> alone, without n

Re: pg_verifybackup: TAR format backup verification

Hi, On 2024-07-31 16:07:03 -0400, Robert Haas wrote: > On Wed, Jul 31, 2024 at 9:28 AM Amul Sul wrote: > > Fixed -- I did that because it was part of a separate group in > > pg_basebackup. > > Well, that's because pg_basebackup builds multiple executables, and > these files needed to be linked

Re: [BUG?] check_exclusion_or_unique_constraint false negative

It seems like I've identified the cause of the issue. Currently, any DirtySnapshot (or SnapshotSelf) scan over a B-tree index may skip (not find the TID for) some records in the case of parallel updates. The following scenario is possible: * Session 1 reads a B-tree page using SnapshotDirty and

Re: Changing default -march landscape

Hi, On 2024-07-30 21:59:44 -0500, Nathan Bossart wrote: > On Tue, Jul 30, 2024 at 07:39:18PM -0700, Andres Freund wrote: > > We can hide most of the dispatch cost in a static inline function that only > > does the runtime test if size is large enough - the size is a compile time > > constant most

Re: can we mark upper/lower/textlike functions leakproof?

Robert Haas writes: > I'm not sure what the right thing to do here is, but I think that it's > wrong to imagine that being unwilling to endorse probably-leakproof > things as leakproof -- or unwilling to put in the work to MAKE them > leakproof if they currently aren't -- has no security costs. W

Re: Popcount optimization using AVX512

On Wed, Jul 31, 2024 at 01:52:54PM -0700, Andres Freund wrote: > On 2024-07-30 22:12:18 -0500, Nathan Bossart wrote: >> As I started on this, I remembered why I needed it. The file >> pg_popcount_avx512_choose.c is compiled without the AVX-512 flags in order >> to avoid inadvertently issuing any A

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Wed, Jul 31, 2024 at 4:38 PM Peter Geoghegan wrote: > > On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman > wrote: > > In back branches starting with 14, failing to remove tuples older than > > OldestXmin during pruning caused vacuum to infinitely loop in > > lazy_scan_prune(), as investigated

Re: Fixing backslash dot for COPY FROM...CSV

Hi, In <4ffb7317-7e92-4cbd-a542-1e478af6a...@manitou-mail.org> "Re: Fixing backslash dot for COPY FROM...CSV" on Wed, 31 Jul 2024 15:42:41 +0200, "Daniel Verite" wrote: >> BTW, here is a diff after pgindent: > > PFA a v5 with the cosmetic changes applied. Thanks for updating the patch. >

Re: optimizing pg_upgrade's once-in-each-database steps

On 22.07.2024 21:07, Nathan Bossart wrote: On Fri, Jul 19, 2024 at 04:21:37PM -0500, Nathan Bossart wrote: However, while looking into this, I noticed that only one get_query callback (get_db_subscription_count()) actually customizes the generated query using information in the provided DbInfo

Re: Add mention of execution time memory for enable_partitionwise_* GUCs

On Wed, 31 Jul 2024 at 16:15, Ashutosh Bapat wrote: > We can commit your > version and see if users find it confusing. Ok. I've now pushed the patch. Thanks for reviewing it. David

Re: Remove last traces of HPPA support

On Thu, Aug 1, 2024 at 7:07 AM Andres Freund wrote: > Note that I would like to add a user for S_LOCK_FREE(), to detect repeated > SpinLockRelease(): > https://postgr.es/m/20240729182952.hua325647e2ggbsy%40awork3.anarazel.de What about adding a "magic" member in assertion builds? Here is my atte

Re: Support LIKE with nondeterministic collations

On Fri, 2024-05-03 at 16:58 +0200, Daniel Verite wrote: >    * Generating bounds for a sort key (prefix matching) > >    Having sort keys for strings allows for easy creation of bounds - >    sort keys that are guaranteed to be smaller or larger than any > sort >    key from a give range. For exam

Re: Logical Replication of sequences

Hi Vignesh, I have a question about the subscriber-side behaviour of currval(). == AFAIK it is normal for currval() to give error is nextval() has not yet been called [1] For example. test_pub=# create sequence s1; CREATE SEQUENCE test_pub=# select * from currval('s1'); 2024-08-01 07:42:48.

Re: Remove last traces of HPPA support

Hi, On 2024-08-01 10:09:07 +1200, Thomas Munro wrote: > On Thu, Aug 1, 2024 at 7:07 AM Andres Freund wrote: > > Note that I would like to add a user for S_LOCK_FREE(), to detect repeated > > SpinLockRelease(): > > https://postgr.es/m/20240729182952.hua325647e2ggbsy%40awork3.anarazel.de > > What

Re: Logical Replication of sequences

Hi Vignesh, I noticed that when replicating sequences (using the latest patches 0730_2*) the subscriber-side checks the *existence* of the sequence, but apparently it is not checking other sequence attributes. For example, consider: Publisher: "CREATE SEQUENCE s1 START 1 INCREMENT 2;" should be

Re: The stats.sql test is failing sporadically in v14- on POWER7/AIX 7.1 buildfarm animals

On Wed, Jul 31, 2024 at 02:00:00PM +0300, Alexander Lakhin wrote: > --- > /home/nm/farm/gcc64/REL_14_STABLE/pgsql.build/src/test/regress/expected/stats.out > 2022-03-30 01:18:17.0 + > +++ > /home/nm/farm/gcc64/REL_14_STABLE/pgsql.build/src/test/regress/results/stats.out > 2024-07-30

Re: Remove last traces of HPPA support

On Thu, Aug 1, 2024 at 10:38 AM Andres Freund wrote: > On 2024-08-01 10:09:07 +1200, Thomas Munro wrote: > > On Thu, Aug 1, 2024 at 7:07 AM Andres Freund wrote: > > > Note that I would like to add a user for S_LOCK_FREE(), to detect repeated > > > SpinLockRelease(): > > > https://postgr.es/m/2024

Re: Add LSN <-> time conversion functionality

Thanks for the review! v6 attached. On Sat, Jul 6, 2024 at 1:36 PM Andrey M. Borodin wrote: > > PgStartLSN = GetXLogInsertRecPtr(); > Should this be kind of RecoveryEndPtr? How is it expected to behave on > Standby in HA cluster, which was doing a crash recovery of 1y WALs in a day, > then is i

RE: Remove duplicate table scan in logical apply worker and code refactoring

Dear Hou, > Thanks for reviewing the patch, and your understanding is correct. > > Here is the updated patch 0001. I removed the comments as suggested by Amit. > > Since 0002 patch is only refactoring the code and I need some time to review > the comments for it, I will hold it until the 0001 is

Re: On disable_cost

On Thu, 1 Aug 2024 at 04:23, Robert Haas wrote: > OK, here's a new patch version. I think we're going down the right path here. I've reviewed both patches, here's what I noted down during my review: 0. I've not seen any mention so far about postgres_fdw's use_remote_estimate. Maybe changing th

Re: Evaluate arguments of correlated SubPlans in the referencing ExprState

Hi, On 2023-02-25 13:44:01 -0800, Andres Freund wrote: > Ended up simpler than I'd thought. I see small, consistent, speedups and > reductions in memory usage. For the sake of person following the link from the commit message to this thread in a few years, I thought it'd be useful to have an exam

v17 vs v16 performance comparison

Hello hackers, I've repeated the performance measurement for REL_17_STABLE (1e020258e) and REL_16_STABLE (6f6b0f193) and found several benchmarks where v16 is significantly better than v17. Please find attached an html table with all the benchmarking results. I had payed attention to: Best pg-sr

Re: Evaluate arguments of correlated SubPlans in the referencing ExprState

Hi, On 2024-07-19 21:17:12 -0700, Andres Freund wrote: > On 2024-07-18 16:01:19 -0400, Tom Lane wrote: > > Alena Rybakina writes: > > > I fixed it. The code remains the same. > > > > I see the cfbot is again complaining that this patch doesn't apply. > > > > In hopes of pushing this over the fi

RE: Conflict detection and logging in logical replication

On Wednesday, July 31, 2024 1:36 PM shveta malik wrote: > > On Wed, Jul 31, 2024 at 7:40 AM Zhijie Hou (Fujitsu) > > wrote: > > > > > > > > 2) > > > apply_handle_delete_internal() > > > > > > --Do we need to check "(!edata->mtstate || > > > edata->mtstate->operation != CMD_UPDATE)" in the else

Re: v17 vs v16 performance comparison

Alexander Lakhin writes: > I've repeated the performance measurement for REL_17_STABLE (1e020258e) > and REL_16_STABLE (6f6b0f193) and found several benchmarks where v16 is > significantly better than v17. Please find attached an html table with > all the benchmarking results. Thanks for doing th

Re: Speed up JSON escape processing with SIMD plus other optimisations

On Sun, 28 Jul 2024 at 00:51, David Rowley wrote: > I did another round of testing on the SIMD patch (attached as v5-0001) > as I wondered if the SIMD loop maybe shouldn't wait too long before > copying the bytes to the destination string. I had wondered if the > JSON string was very large that i

Re: Remove last traces of HPPA support

On Tue, Jul 30, 2024 at 12:39 PM Thomas Munro wrote: > On Tue, Jul 30, 2024 at 11:16 AM Heikki Linnakangas wrote: > > I think we should do: > > > > #ifdef _M_AMD64 > > #define __x86_64__ > > #endif > > > > somewhere, perhaps in src/include/port/win32.h. I suppose we could define our own PG_ARCH_

RE: [BUG?] check_exclusion_or_unique_constraint false negative

Dear Michail, Thanks for pointing out the issue! >* RelationFindReplTupleByIndex > >Amit, this is why I've included you in this previously solo thread :) >RelationFindReplTupleByIndex uses DirtySnapshot and may not find some records >if they are updated by a parallel transaction. This could lead

Re: v17 vs v16 performance comparison

On Thu, Aug 1, 2024 at 3:00 PM Alexander Lakhin wrote: > So it looks like q15 from TPC-DS is not the only query suffering from that > change. I'm going to try to set up a local repro to study these new cases. If you have a write-up somewhere of how exactly you run that, that'd be useful.

Re: Use pgBufferUsage for block reporting in analyze

On Wed, Jul 31, 2024 at 9:36 PM Masahiko Sawada wrote: > Meanwhile, I think we can push 0001 and 0002 patches since they are in > good shape. I've updated commit messages to them and slightly changed > 0002 patch to write "finished analyzing of table \"%s.%s.%s\" instead > of "analyze of table \"

Re: Assertion failure with summarize_wal enabled during pg_createsubscriber

On Wed, Jul 31, 2024 at 04:49:54PM +0300, Alexander Korotkov wrote: > On Mon, Jul 29, 2024 at 7:20 PM Robert Haas wrote: >> I support that idea in general but felt it was overkill in this case: >> it's new code, and there was only one existing caller of the function >> that got refactored, and I'm