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

On Wed, 2024-07-31 at 14:43 -0400, 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

Re: PG17beta2: SMGR: inconsistent type for nblocks

On Tue, 30 Jul 2024 at 14:32, Thomas Munro wrote: > > On Tue, Jul 30, 2024 at 11:24 PM Matthias van de Meent > wrote: > > 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

Re: Add LSN <-> time conversion functionality

This is a copy of my message for pgsql-hackers mailing list. Unfortunately original message was rejected due to one of recipients addresses is blocked. > On 1 Aug 2024, at 10:54, Andrey M. Borodin wrote: > > > >> On 1 Aug 2024, at 05:44, Melanie Plageman wrote: >> >> Thanks for the review!

Re: make pg_createsubscriber option names more consistent

On 31.07.24 11:15, Hayato Kuroda (Fujitsu) wrote: 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

Re: rare crash - FailedAssertion snapbuild.c Line: 580

Hello all, Any update on this? Thanks and regards Pradeep On Thu, Jul 25, 2024 at 1:09 PM Pradeep Kumar wrote: > Hello all, > > Message Id: > https://www.postgresql.org/message-id/flat/3808dc548e144c860fc3fe57de013809%40xs4all.nl#72629a188e99e14387230fccc8eef518 > > Actually I'm also facing

Re: [BUG?] check_exclusion_or_unique_constraint false negative

Hello, Hayato! > Thanks for pointing out the issue! Thanks for your attention! > IIUC, the issue can happen when two concurrent transactions using DirtySnapshot access > the same tuples, which is not specific to the parallel apply Not exactly, it happens for any DirtySnapshot scan over a

Re: Comment in portal.h

Hi, On Wed, Jul 31, 2024 at 8:55 AM Andy Fan wrote: > Etsuro Fujita writes: > > I noticed $SUBJECT while working on something else: > > > > /* > > * Where we store tuples for a held cursor or a PORTAL_ONE_RETURNING or > > * PORTAL_UTIL_SELECT query. (A cursor held past the end of

Re: Improving tracking/processing of buildfarm test failures

02.07.2024 15:00, Alexander Lakhin wrote: One month later,  I'd like to summarize failures that I've investigated and classified during June, 2024 on the aforementioned wiki page. (Maybe it would make sense to issue a monthly report with such information in the future.) Please take a look at

RE: Conflict detection and logging in logical replication

Dear Hou, Let me contribute the great feature. I read only the 0001 patch and here are initial comments. 01. logical-replication.sgml track_commit_timestamp must be specified only on the subscriber, but it is not clarified. Can you write down that? 02. logical-replication.sgml I felt that

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

On Thu, Aug 1, 2024 at 7:29 AM Hayato Kuroda (Fujitsu) wrote: > > > 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

Re: Pgoutput not capturing the generated columns

Hi, Here are my review comments for patch v22-0001 All comments now are only for the TAP test. == src/test/subscription/t/011_generated.pl 1. I added all new code for the missing combination test case "gen-to-missing". See nitpicks diff. - create a separate publication for this

Re: proposal: schema variables

čt 1. 8. 2024 v 9:45 odesílatel Erik Rijkers napsal: > doc-build fails: a slash tumbled backwards in doc/src/sgml: > > $ grep 'xref.*.\\>' *.sgml > plpgsql.sgml: (see ). > > That should simply be a forward slash, of course. > should be fixed in my today patchset > > Thanks, > > Erik

Re: proposal: schema variables

doc-build fails: a slash tumbled backwards in doc/src/sgml: $ grep 'xref.*.\\>' *.sgml plpgsql.sgml: (see ). That should simply be a forward slash, of course. Thanks, Erik Rijkers Op 8/1/24 om 08:12 schreef Pavel Stehule: Hi fresh rebase + fix format in doc Regards Pavel

Re: v17 vs v16 performance comparison

Hello Thomas. 01.08.2024 08:57, Thomas Munro wrote: 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

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

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: 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: [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: 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

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

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

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

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

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

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

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

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

Re: Remove last traces of HPPA support

: failed, lock not locked\n"); - return 1; - } - - S_UNLOCK(_lock.lock); - - if (test_lock.pad1 != 0x44 || test_lock.pad2 != 0x44) - { - printf("S_LOCK_TEST: failed, declared datatype is wrong size\n"); - return 1; - } - - if (!S_LOCK_FREE(_lock.lock)) - { - printf("S_LOCK_TEST: f

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 >

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

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 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

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

Re: Remove last traces of HPPA support

); - return 1; - } - - if (S_LOCK_FREE(_lock.lock)) - { - printf("S_LOCK_TEST: failed, lock not locked\n"); - return 1; - } - - S_UNLOCK(_lock.lock); - - if (test_lock.pad1 != 0x44 || test_lock.pad2 != 0x44) - { - printf("S_LOCK_TEST: failed, declared datatype is wrong size\n&q

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: 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

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 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: 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

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.

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: [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: 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: 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

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

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

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

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

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

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

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

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: 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

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.

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

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

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

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: 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: 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

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 recovery-stage

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

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

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 days ago caused by

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:

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

a performance degradation seemingly dominated by the TRUNCATE. > > My questions are; > > 1) Is the VACUUM necessary if I use TRUNCATE + COPY FREEZE (on the > temporary table)? > 2) Is there really any benefit to using FREEZE here or is it best to just > VACUUM the temporary tables

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.

Re: improve performance of pg_dump with many sequences

Committed. -- nathan

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: >>

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

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: 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

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: 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

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.

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

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

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,

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

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

Re: Remove last traces of HPPA support

discussion of spinlock implementation at page 2-34 of [1], it doesn't distinguish between 32 and 64, and it has that double-check thing. > > - * On platforms with weak memory ordering, the TAS(), TAS_SPIN(), and > > - * S_UNLOCK() macros must further include hardware-le

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: 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

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: 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

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

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

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

Re: Remove last traces of HPPA support

and - * S_UNLOCK() macros must further include hardware-level memory fence - * instructions to prevent similar re-ordering at the hardware level. - * TAS() and TAS_SPIN() must guarantee that loads and stores issued after - * the macro are not executed until the lock has been ob

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 > >

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

Re: Lack of possibility to specify CTAS TAM

t; On a related note, the description here seems outdated. > > https://www.postgresql.org/docs/current/runtime-config- > client.html#GUC-DEFAULT-TABLE-ACCESS-METHOD > Nevermind, re-reading it I see it is correct. The others are all covered by “create” while “select into” is called out because of its reliance on the default. David J.

Re: Logical Replication of sequences

- use an existing 'relkind' variable instead of calling get_rel_relkind(relid); nitpick - add another comment about skipping (for dropping tablesync slots) ~ 5. + /* + * If all the relations should be re-synchronized, then set the + * state to init for re-synchronization. This i

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.

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: > 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 ]

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: 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

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

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

<    1   2   3   4   5   6   7   8   9   10   >