Re: Proposal to CREATE FOREIGN TABLE LIKE

On Feb 19, 2025 at 14:53 +0800, Michael Paquier , wrote: > There was a hole in the tests for the option LIKE_STORAGE. Removing > the check for it in transformTableLikeClause() did now show a diff in > the tests. In the case of foreign tables, extended for storage is a > correct choice when using a

Re: missing assert in makeString

Hi st 19. 2. 2025 v 7:48 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I investigated the crashes in "xmlnamespaces to xmlelement" patch and it > > looks like there was a badly used makeString function. The argument > should > > not be null, elsewhere serialization to string fails - a

Re: BUG #18815: Logical replication worker Segmentation fault

Sergey Belyashov writes: > The 4th patch is not applicable for the current REL_17_STABLE branch. Yeah, I saw that, didn't work on fixing it yet. It looked like the diffs were mostly about the ExecOpen/CloseIndices calls in apply_handle_tuple_routing, which we already knew are completely bogus.

Re: BUG #18815: Logical replication worker Segmentation fault

Hi, The 4th patch is not applicable for the current REL_17_STABLE branch. There are a lot of differences from master in the worker.c. Best regards, Sergey Belyashov ср, 19 февр. 2025 г. в 01:24, Tom Lane : > > I wrote: > > I don't intend 0003 for back-patch, but the rest of this has to go > > ba

Re: Proposal to CREATE FOREIGN TABLE LIKE

On Tue, Feb 18, 2025 at 08:43:02PM +0800, Zhang Mingli wrote: > On Feb 18, 2025 at 09:54 +0800, Zhang Mingli , wrote: > > > > Will address the comments later,  thanks for review! > > Done in patch v6. There was a hole in the tests for the option LIKE_STORAGE. Removing the check for it in transfo

Re: missing assert in makeString

Pavel Stehule writes: > I investigated the crashes in "xmlnamespaces to xmlelement" patch and it > looks like there was a badly used makeString function. The argument should > not be null, elsewhere serialization to string fails - and deserialization > doesn't support this case. > I propose to add

missing assert in makeString

Hi I investigated the crashes in "xmlnamespaces to xmlelement" patch and it looks like there was a badly used makeString function. The argument should not be null, elsewhere serialization to string fails - and deserialization doesn't support this case. https://cirrus-ci.com/task/6543809942650880

Re: Forbid to DROP temp tables of other sessions

Hi, I'm sorry for the long lull. Considering that it is still important for some users to be able to clean other sessions' temporary directories, I suggest adding a GUC that will allow superuser to do this. We keep only one option - to drop tables, because only this feature works properly in postgr

Re: Improve CRC32C performance on SSE4.2

On Wed, Feb 19, 2025 at 1:28 AM Devulapalli, Raghuveer wrote: > The runtime detection code could also be appended with function > __attribute__((constructor)) so that it gets executed before main. Hmm! I didn't know about that, thanks! It works on old gcc/clang, so that's good. I can't verify on

Re: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided.

On Tue, Feb 18, 2025 at 2:43 PM Zhijie Hou (Fujitsu) wrote: > > On Thursday, February 13, 2025 11:28 AM Shubham Khanna > wrote: > > Hi, > > > The attached patch contains the required changes. > > Thanks for updating the patch. I think it's a useful feature. > > Here are few review comments: > >

Re: Remove wal_[sync|write][_time] from pg_stat_wal and track_wal_io_timing

On Tue, Feb 18, 2025 at 10:43:15AM +, Bertrand Drouvot wrote: > === Remarks As mentioned on a previous thread, I am siding with the removal of these fields. There are more benefits on terms of granularity of this data to encourage users to move away from pg_stat_wal and stick to pg_stat_io.

Re: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided.

On Tue, Feb 18, 2025 at 7:32 AM Hayato Kuroda (Fujitsu) wrote: > > Dear Shubham, > > Thanks for updating the patch. Few comments. > > ``` > + If a database is present on the source but missing on the target, an > + error is raised. > ``` > > I'm not sure this description is accurate. I

Re: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided.

On Fri, Feb 14, 2025 at 5:27 PM Ashutosh Bapat wrote: > > Hi Shubham, > Here are some review comments from my side > > > On Thu, Feb 13, 2025 at 8:58 AM Shubham Khanna > wrote: > > The attached patch contains the required changes. > > > > clusterdb, vacuumdb use -a and -all for all databases. Do

Re: [fixed] Trigger test

Just a rebase.From 76c4ca0f63091551b3f579c2c74345438e3d62d7 Mon Sep 17 00:00:00 2001 From: Bondar Dmitrii Date: Wed, 19 Feb 2025 09:37:48 +0700 Subject: [PATCH v4] Triggers test fix --- contrib/spi/refint.c | 25 - src/test/regress/expected/triggers.out | 39 ++

Re: test_escape: invalid option -- 'c'

On Wed, Feb 19, 2025 at 10:31:40AM +0800, Japin Li wrote: > I didn't add the 'f' option since the usage() does not declare it. > If you add this, we also should update the usage(), right? Yes, we should. -- Michael signature.asc Description: PGP signature

RE: ReplicationSlotRelease() crashes when the instance is in the single user mode

Dear hackers, Based on the discussion, I feel it is enough to add quick error out for SQL functions. PSA attached. Best regards, Hayato Kuroda FUJITSU LIMITED > -Original Message- > From: Hayato Kuroda (Fujitsu) > Sent: Tuesday, February 18, 2025 5:24 PM > To: 'Michael Paquier' > Cc:

Re: Unsafe access BufferDescriptors array in BufferGetLSNAtomic()

Richard Guo 于2025年2月19日周三 10:30写道： > On Wed, Feb 19, 2025 at 9:58 AM Richard Guo > wrote: > > On Wed, Feb 19, 2025 at 9:44 AM Michael Paquier > wrote: > > > On Wed, Feb 19, 2025 at 09:36:35AM +0900, Richard Guo wrote: > > > > I plan to push this shortly. This is arguably a bug, but it hasn't >

Re: test_escape: invalid option -- 'c'

On Wed, 19 Feb 2025 at 09:53, Michael Paquier wrote: > On Tue, Feb 18, 2025 at 12:46:50PM +0900, Michael Paquier wrote: >> You are right, obviously. The only reason why this is not showing up >> is that the TAP test uses the long option --conninfo. Speaking of >> which, this had better use fat c

Re: GetRelationPath() vs critical sections

Hi, On 2024-10-06 11:53:59 +0800, Andy Fan wrote: > Thomas Munro writes: > > > On Thu, Sep 5, 2024 at 3:58 AM Andres Freund wrote: > >> Obviously we could add a version of GetRelationPath() that just prints > >> into a > >> caller provided buffer - but that's somewhat awkward API wise. > > > >

Re: Why does exec_simple_query requires 2 snapshots

Andy Fan writes: > Tom Lane writes: >> Many years ago, we committed a patch to do exactly that. We had >> to back it out again because it broke too many real-world scenarios. >> I'm too lazy to search the archives for you, but you might be able >> to find the commit and revert by searching the g

Re: Unsafe access BufferDescriptors array in BufferGetLSNAtomic()

On Wed, Feb 19, 2025 at 9:58 AM Richard Guo wrote: > On Wed, Feb 19, 2025 at 9:44 AM Michael Paquier wrote: > > On Wed, Feb 19, 2025 at 09:36:35AM +0900, Richard Guo wrote: > > > I plan to push this shortly. This is arguably a bug, but it hasn't > > > caused any real issues, and nobody has compl

Re: Virtual generated columns

On Tue, 18 Feb 2025 at 13:12, Richard Guo wrote: > > > It seems to me that, for a relation in the rangetable that has virtual > > generated columns, we can consider it a subquery to some extent. For > > instance, suppose we have a query: > > > > select ... from ... join t on ...; > > > > and supp

Re: Why does exec_simple_query requires 2 snapshots

Tom Lane writes: > Andy Fan writes: >> My question is why can't we share the same snapshot for the 2 cases? >> parser & planner requires Catalog Snapshot which should be the >> latest one, but in the above case, looks the executor can reuse it as >> well. Is there anything I missed? > > Many ye

Re: [Feature Request] INSERT FROZEN to Optimize Large Cold Data Imports and Migrations

HI > Ok you mean that xid64 will remove the need for freezing... it's a way to see things. When xid64 is implemented, there will be no need to trigger vacuum_failsafe_age,it has a long enough time to vacuum freeze, it will have less of an impact on performance，I think that problem may be due to

Re: Unsafe access BufferDescriptors array in BufferGetLSNAtomic()

On Wed, Feb 19, 2025 at 9:44 AM Michael Paquier wrote: > On Wed, Feb 19, 2025 at 09:36:35AM +0900, Richard Guo wrote: > > I plan to push this shortly. This is arguably a bug, but it hasn't > > caused any real issues, and nobody has complained about it until now, > > so I don't think it needs to b

Re: Issues with 2PC at recovery: CLOG lookups and GlobalTransactionData

On Thu, Jan 30, 2025 at 03:36:20PM +0900, Michael Paquier wrote: > And I am beginning a new thread about going through an issue that Noah > has mentioned at [1], which is that the 2PC code may attempt to do > CLOG lookups at very early stage of recovery, where the cluster is not > in a consistent s

Re: test_escape: invalid option -- 'c'

On Tue, Feb 18, 2025 at 12:46:50PM +0900, Michael Paquier wrote: > You are right, obviously. The only reason why this is not showing up > is that the TAP test uses the long option --conninfo. Speaking of > which, this had better use fat commas to combine the option/value > pairs in these commands

Re: Unsafe access BufferDescriptors array in BufferGetLSNAtomic()

On Wed, Feb 19, 2025 at 09:36:35AM +0900, Richard Guo wrote: > I plan to push this shortly. This is arguably a bug, but it hasn't > caused any real issues, and nobody has complained about it until now, > so I don't think it needs to be back-patched. Any thoughts? I can see a point in doing a bac

Re: Parallel heap vacuum

On Mon, Feb 17, 2025 at 1:11 PM Masahiko Sawada wrote: > > On Fri, Feb 14, 2025 at 2:21 PM Melanie Plageman > wrote: > > > > Since the failure rate is defined as a percent, couldn't we just have > > parallel workers set eager_scan_remaining_fails when they get their > > chunk assignment (as a per

Re: pg_stat_statements and "IN" conditions

On Tue, Feb 18, 2025 at 08:48:43AM -0600, Sami Imseih wrote: >> Btw, if you would like to share a code delta, please do not post it as a >> patch or diff. This hijacks the CI pipeline, because CFbot thinks that's >> a new version of the original patch. > > You're right. Sorry about that. Exchangi

Re: Unsafe access BufferDescriptors array in BufferGetLSNAtomic()

On Tue, Feb 4, 2025 at 4:59 PM Richard Guo wrote: > On Thu, Nov 7, 2024 at 7:07 PM Tender Wang wrote: > > While learning gist index insert codes, I find a little issue with > > BufferGetLSNAtomic(). > > At first, it wants to get bufHdr by accessing the buffer descriptor array, > > as below: > >

Re: Commitfest app release on Feb 17 with many improvements

On Tue, Feb 18, 2025 at 11:39:54PM +0100, Jelte Fennema-Nio wrote: > On Tue, 18 Feb 2025 at 22:15, Bruce Momjian wrote: > > Looking at the live version, I can sort the "Stats" column from smallest > > to largest, but not from largest to smallest. Is this intended? > > The next release to prod in

Re: Inconsistent GUC descriptions

On Tue, Feb 18, 2025 at 02:42:36PM +0900, Michael Paquier wrote: > Keeping it simple.. I agree that your suggestions and your two > patches make things better, so OK for me. There may be a point in > backpatching as this is user-visible? Perhaps not. Done that as f2e4c2b2039e. -- Michael sign

Re: Commitfest Manager for March

On Tue, Feb 18, 2025 at 02:42:44PM +0530, vignesh C wrote: > I noticed that no one has volunteered yet for the March 2025 > Commitfest, so I’d like to volunteer to be one of the CF managers for > March 2025 Commitfest. Thanks! -- Michael signature.asc Description: PGP signature

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

Apart from two doc issues, this is ready: On Tue, Feb 18, 2025 at 01:23:20PM -0800, Masahiko Sawada wrote: > On Mon, Feb 17, 2025 at 2:57 PM Noah Misch wrote: > > On Fri, Jan 17, 2025 at 05:11:41PM -0800, Masahiko Sawada wrote: > +However, when upgrading from PostgreSQL > 17 or, > +

Re: Commitfest app release on Feb 17 with many improvements

On Tue, 18 Feb 2025 at 00:38, Peter Geoghegan wrote: > > On Mon, Feb 17, 2025 at 4:33 PM Thomas Munro wrote: > > This looks fantastic. Thanks so much for working on it! And all the > > other usability improvements too. > > +1. Thanks all, I'm also very happy that it's deployed. > I very much

Re: Commitfest app release on Feb 17 with many improvements

On Tue, 18 Feb 2025 at 23:57, Jelte Fennema-Nio wrote: > > I like "Useful links that you can use and bookmark", but I'd prefer if > > there was only one link that I needed to bookmark. That is, I'd like > > it if "Your entries in the current commitfest", "Your entries in the > > open commitfest",

Re: Optimization for lower(), upper(), casefold() functions.

On Wed, 2025-02-19 at 01:54 +0300, Alexander Borisov wrote: > In proposing the patch for v3, I struck a balance between improving > performance and reducing binary size, without sacrificing code > clarity. Fair enough. I will continue reviewing v3. Regards, Jeff Davis

Re: Optimization for lower(), upper(), casefold() functions.

19.02.2025 01:02, Jeff Davis пишет: On Tue, 2025-02-11 at 23:08 +0300, Alexander Borisov wrote: I tried the approach via a range table. The result was worse than without the table. With branching in a function, the result is better. Patch v3 — ranges binary search by branches. Patch v4 — ranges

Re: Commitfest app release on Feb 17 with many improvements

On Tue, 18 Feb 2025 at 22:15, Bruce Momjian wrote: > Looking at the live version, I can sort the "Stats" column from smallest > to largest, but not from largest to smallest. Is this intended? The next release to prod in ~2 weeks will have that as one of the new features (courtesy of Akshat). Yo

Re: per backend WAL statistics

On Tue, Feb 18, 2025 at 10:45:29AM +, Bertrand Drouvot wrote: > Agree, done that way in the dedicated thread ([1]). > > [1]: > https://www.postgresql.org/message-id/flat/Z7RkQ0EfYaqqjgz/%40ip-10-97-1-34.eu-west-3.compute.internal Thanks for splitting this part into its own thread. -- Michael

Re: BUG #18815: Logical replication worker Segmentation fault

I wrote: > I don't intend 0003 for back-patch, but the rest of this has to go > back as far as the bug can be observed, which I didn't test yet. Ah: this bug is new in v17, because neither brininsertcleanup nor the whole aminsertcleanup infrastructure exist before that. So that leaves us with a q

Re: Optimization for lower(), upper(), casefold() functions.

On Tue, 2025-02-11 at 23:08 +0300, Alexander Borisov wrote: > I tried the approach via a range table. The result was worse than > without the table. With branching in a function, the result is > better. > > Patch v3 — ranges binary search by branches. > Patch v4 — ranges binary search by table. T

Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation

On Mon, Feb 17, 2025 at 2:57 PM Noah Misch wrote: > > On Fri, Jan 17, 2025 at 05:11:41PM -0800, Masahiko Sawada wrote: > > Thank you for reviewing the patches. I agree with all the comments you > > made. I've addressed them and I've attached new version patches that > > now have some regression te

Re: Commitfest app release on Feb 17 with many improvements

On Tue, Feb 4, 2025 at 05:27:18PM +0100, Álvaro Herrera wrote: > On 2025-Jan-31, Jelte Fennema-Nio wrote: > > > 3. Showing total additions/deletions of the most recent patchset on > > patch and commitfest pages > > 4. Showing additions/deletions of the first patch of the most recent > > patchset

Re: explain analyze rows=%.0f

On 17/2/2025 15:19, Robert Haas wrote: On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov if (nloops > 1) Instead of: if (nloops > 1 && rows_is_fractonal) I don't think it's really safe to just cast a double back to int64. In practice, the number of tuples should never be large enough to overflow

Re: Proposal: Progressive explain

Fixed a corner case where pg_stat_progress_explain is looking at its own plan. Previous message in this thread contains all relevant implementation details of the last patch. On Tue, Feb 18, 2025 at 3:31 PM Rafael Thofehrn Castro wrote: > Hello all, > > Sending a new version of the patch that i

Re: BUG #18815: Logical replication worker Segmentation fault

[ redirecting to -hackers for patch discussion ] Here's a completed set of patches for bug #18815 [1] (which, briefly, is that the logrep worker opens/closes indexes multiple times and thereby breaks brininsertcleanup). 0001 adds a subscriber-side BRIN index to 013_partition.pl, which replicates

Re: Improve pgindent exclude handling: ignore empty lines

Hello You are right, when I was writing the commit message I was thinking about trim, but the script only uses chomp. I edited the commit message to correctly describe the new behavior: ignoring only the empty line, as that was my main intention with the patch. On Fri, Feb 14, 2025 at 3:24 PM An

Re: Disabling vacuum truncate for autovacuum

On Mon, Jan 27, 2025 at 03:38:39PM -0500, Robert Haas wrote: > Also, how sure are we that turning this off globally is a solid idea? > Off-hand, it doesn't sound that bad: there are probably situations in > which autovacuum never truncates anything anyway just because the tail > blocks of the relat

Re: AIO v2.3

On Mon, Feb 17, 2025 at 4:01 PM Andres Freund wrote: > If one instead integrates with resowners, that kind of thing works, because > exec_simple_query() calls PortalDrop(), which in turn calls > ResourceOwnerRelease(). Hmm, so maybe that's a reason to do it via resowner.c, then. The fact that it'

RE: Improve CRC32C performance on SSE4.2

Hi John, Just a few comments on v7: > pg_cpucap_crc32c I like the idea of moving all CPU runtime detection to a single module outside of implementations. This makes it easy to extend in the future and keeps the functionalities separate. > - Rename the CRC choose*.c files to pg_cpucap_{x86,

Re: Proposal: Progressive explain

Hello all, Sending a new version of the patch that includes important changes addressing feedback provided by Greg and Tomas. So, including the previous version (v5) sent on Jan 29, these are the highlights of what has changed: - Progressive plan printed on regular interval defined by progressive

Re: Fix outdated code comments in nodeAgg.c

On Tue, 2025-02-18 at 20:11 +0800, Zhang Mingli wrote: > Thanks for review, added it to > commitfest https://commitfest.postgresql.org/patch/5580/ Committed. Thank you! Regards, Jeff Davis

Re: Clarification on Role Access Rights to Table Indexes

On Tue, Feb 18, 2025 at 11:30 AM Tom Lane wrote: > I have no objection to it, but I wasn't as entirely convinced > as you are that it's the only plausible answer. Hmm, OK. > One specific thing I'm slightly worried about is that a naive > implementation would probably cause this function to lock

Re: moving some code out of explain.c

On Tue, Feb 18, 2025 at 1:04 PM Robert Haas wrote: > I think in cases like this there is a tendency to want to achieve an > even split of the original file, but in practice I think that tends > not to be difficult to achieve. These two patches combined move about > 1000 lines of code into separate

Re: Expanding HOT updates for expression and partial indexes

Changes v6 to v7: * Fixed documentation oversight causing build failure * Changed how I convey attribute len/by-val in IndexInfo * Fixed method to shortcut index_unchanged_by_update() when possible -greg v7-0001-Expand-HOT-update-path-to-include-expression-and-.patch Description: v7-0001-Expa

moving some code out of explain.c

While contemplating some additions to explain.c, I noticed that this file has become rather large -- 5924 lines on master. I'm generally not a fan of very large source files, and I think it would be a good idea to start splitting this one up before things get completely out of control. Here are a f

RE: Improve CRC32C performance on SSE4.2

Hi John, I added dispatch logic for the new pclmul version on top of your v5 (which seems outdated now and so I will refrain from posting a patch here). Could you take a look at the approach here to see if this makes sense? The logic in the pg_comp_crc32c_choose function is the main change an

Re: Add Pipelining support in psql

On Tue, Feb 18, 2025 at 8:23 AM Michael Paquier wrote: > This is a pretty cool patch. I like the structure you have used for > the integration with the tracking of the number of commands, the > number of syncs (like pgbench) put in a pipeline, the number of > results requested and the number of r

Re: Extend postgres_fdw_get_connections to return remote backend pid

Hi Fujii, On Tue, Feb 18, 2025 at 10:25 PM Fujii Masao wrote: > > I assume you're planning to extend postgres_fdw_get_connections() to > also return the result of PQbackendPID(entry->conn). > However, the patch you attached doesn't seem to include that change. > Did you attach the wrong patch?

Re: Improve statistics estimation considering GROUP-BY as a 'uniqueiser'

Hi all, Following the discussion on improving statistics estimation by considering GROUP BY as a unique constraint, I’ve prepared a patch that integrates GROUP BY into cardinality estimation in a similar way to DISTINCT. This patch ensures that when a subquery contains a GROUP BY clause, the

Re: Extend postgres_fdw_get_connections to return remote backend pid

On 2025/02/18 23:44, Sagar Shedge wrote: Dear Hackers, I want to propose to extend existing postgres_fdw_get_connections functionality to return remote server backend pid. Using postgres_fdw extension, backend can establish connections to remote postgres servers. Recently we added functionali

Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

On Tue, Feb 18, 2025 at 4:19 AM Tatsuo Ishii wrote: > > Attached version doesn't use the nonnulls array if an Exclude is > > specified, as I think it's not going to work with exclusions (as it's > > only an optimization, this is ok and can be taken out entirely if you > > prefer). I've also added

Re: Clarification on Role Access Rights to Table Indexes

Robert Haas writes: > That is a +1 for the specific design of "check SELECT on the index's > table". I don't want to be closed-minded: if you have some strong > reason for believing that's the wrong thing to do, I'm all ears. > However, I'm presently of the view that it is exactly the right thing

Re: Improve cleaning files on Postgres crashes

Em ter., 18 de fev. de 2025 13:21, Tom Lane escreveu: > Ranier Vilela writes: > > There are some reports that Postgres does not handle correctly cleaning > the > > files used when it crashes. [1] > > I think that function *fcloseall* can help a little bit. > > Mainly on Windows. > Thanks for ans

Re: Clarification on Role Access Rights to Table Indexes

On Tue, Feb 18, 2025 at 11:02 AM Tom Lane wrote: > Is that a +1 for the specific design of "check SELECT on the index's > table", or just a +1 for changing something here? That is a +1 for the specific design of "check SELECT on the index's table". I don't want to be closed-minded: if you have so

Re: Improve cleaning files on Postgres crashes

Ranier Vilela writes: > There are some reports that Postgres does not handle correctly cleaning the > files used when it crashes. [1] > I think that function *fcloseall* can help a little bit. > Mainly on Windows. I doubt that this is a good thing to try to do during a panic exit. In the first pl

Re: [PATCH] snowball: fix potential NULL dereference

Maksim Korotkov writes: > On 2025-02-11 19:53, Tom Lane wrote: >> You should report this upstream; >> (Whenever they apply the patch, we should then re-sync...) > FYI, the patch to fix this problem was applied by upstream. Thanks. Barring objections, I'll do a full resync per src/backend/snowba

Re: Add “FOR UPDATE NOWAIT” lock details to the log.

On 2025/02/18 18:33, Yuki Seino wrote: On 2025/02/13 2:31, Jelte Fennema-Nio wrote: On Wed, 12 Feb 2025 at 12:32, Fujii Masao wrote: What do you think if we simply don't log anything for SKIP LOCKED? Implementing both NOWAIT and SKIP LOCKED could take time and make the patch more complex.

Re: Clarification on Role Access Rights to Table Indexes

Robert Haas writes: > On Mon, Feb 17, 2025 at 5:18 PM David G. Johnston > wrote: >>> I have a very vague recollection that we concluded that SELECT >>> privilege was a reasonable check because if you have that you >>> could manually prewarm by reading the table. That would lead >>> to the conclu

Re: Extend postgres_fdw_get_connections to return remote backend pid

Added a CF entry for the same https://commitfest.postgresql.org/patch/5581/ -- Sagar Dilip Shedge, SDE AWS

Re: Confine vacuum skip logic to lazy_scan_skip

Melanie Plageman writes: > On Sun, Feb 16, 2025 at 1:12 PM Tom Lane wrote: >> Basically, Coverity doesn't understand that a successful call to >> read_stream_next_buffer must set per_buffer_data here. I don't >> think there's much chance of teaching it that, so we'll just >> have to dismiss this

Re: Why does exec_simple_query requires 2 snapshots

Andy Fan writes: > My question is why can't we share the same snapshot for the 2 cases? > parser & planner requires Catalog Snapshot which should be the > latest one, but in the above case, looks the executor can reuse it as > well. Is there anything I missed? Many years ago, we committed a patc

Re: Clarification on Role Access Rights to Table Indexes

On Mon, Feb 17, 2025 at 5:18 PM David G. Johnston wrote: >> I have a very vague recollection that we concluded that SELECT >> privilege was a reasonable check because if you have that you >> could manually prewarm by reading the table. That would lead >> to the conclusion that the minimal fix is

Re: [Feature Request] INSERT FROZEN to Optimize Large Cold Data Imports and Migrations

On Tue, Feb 18, 2025 at 9:17 AM Sébastien wrote: > Sorry it won't work. It just delays the problem. But still the freeze > procedure must rewrite all pages. > Actually, a 64-bit transaction ID allows for quite a "delay" - like hundreds of millions of years at your current rate. :) (Yes, there a

Re: New "single" COPY format

On 2025-02-17 Mo 7:05 PM, David G. Johnston wrote: On Sat, Dec 21, 2024 at 1:57 AM Joel Jacobson wrote: How about: COPY table_name [ ( column_name ) ] { FROM | TO } 'filename' (FORMAT jsonb); - If column list is omitted, table_name must have exactly one column. - If colum

Re: Bug in nbtree SAOP scans with non-required arrays, truncated high key

On Tue, Feb 18, 2025 at 8:34 AM Laurenz Albe wrote: > Just for the record: a customer just ran into this bug. REINDEX did > not fix the bad query result, but update to 17.3 did. That's surprising, since REINDEX definitely will "fix" my test case when run on an unpatched server with the bug. The

Re: pg_stat_statements and "IN" conditions

> > > This test was to catch a crash that was happening in older version of > > > the patch, so it doesn't have to verify the actual pgss entry. > > > > It seems odd to keep this test because of crash behavior experienced > > in a previous version of the patch. if the crash reason was understood >

Extend postgres_fdw_get_connections to return remote backend pid

Dear Hackers, I want to propose to extend existing postgres_fdw_get_connections functionality to return remote server backend pid. Using postgres_fdw extension, backend can establish connections to remote postgres servers. Recently we added functionality to get connection status which can help use

Re: [Feature Request] INSERT FROZEN to Optimize Large Cold Data Imports and Migrations

Sorry it won't work. It just delays the problem. But still the freeze procedure must rewrite all pages. Le mar. 18 févr. 2025, 04:12, wenhui qiu a écrit : > Hello Sébastien > this case can be solved by xid64,but it seems like very few people > are interested.But it seems to me that xid64 s

Re: Confine vacuum skip logic to lazy_scan_skip

On Sun, Feb 16, 2025 at 1:12 PM Tom Lane wrote: > > Thomas Munro writes: > > Thanks! It's green again. > > The security team's Coverity instance complained about this patch: > > *** CID 1642971: Null pointer dereferences (FORWARD_NULL) > /srv/coverity/git/pgsql-git/postgresql/src/backend/acces

Re: UUID v7

Sergey Prokhorenko sergeyprokhore...@yahoo.com.au On Monday 17 February 2025 at 04:21:31 am GMT+3, Andrew Alsup wrote: Sergey, I took a look at your patch for chapter 9.14 "UUID Functions" docs page. You've added some really good content here. I think section 9.14.4. "Deciding Wheth

Re: [PATCH] snowball: fix potential NULL dereference

Hi On 2025-02-11 19:53, Tom Lane wrote: You should report this upstream; (Whenever they apply the patch, we should then re-sync...) FYI, the patch to fix this problem was applied by upstream. --- Best regards, Korotkov Maksim PostgresPro m.korot...@postgrespro.ru

Re: [Feature Request] INSERT FROZEN to Optimize Large Cold Data Imports and Migrations

Hello weuhui, It's not a problem with heavy insert table but heavy delete. Also triggering more frequent autovacuum will not help because autovacuum does not delete recently dead tuples when a large and slow vacuum freeze operation older than their delete is still running in parallel. The solution

Re: New buildfarm animals with FIPS mode enabled

On 2025-Feb-17, Daniel Gustafsson wrote: > On 17 Feb 2025, at 20:23, Tom Lane wrote: > > Obviously, we could talk about extending the regression tests' > > support for these cases, but I'm really dubious that it's worth > > the work. > > Agreed. This means that unless Mark is willing to instal

Re: Bug in nbtree SAOP scans with non-required arrays, truncated high key

On Thu, 2024-12-19 at 11:09 -0500, Peter Geoghegan wrote: > I should point out (for the benefit of Tom, or whoever writes the next > set of release notes) that I think that this bug is very unlikely to > occur in practice. Getting wrong answers to queries could only happen > given an index with mor

Re: SIMD optimization for list_sort

On Tue, Feb 18, 2025 at 1:49 PM R, Rakshit wrote: > > Hi All, > > Thank you very much for your feedback! We investigated the recommendations as > we developed the current patch. Please refer to the comments below. > > > I'd suggest targeting pg_qsort() directly, instead of list_sort(). > > list_

Re: Virtual generated columns

On Tue, Feb 18, 2025 at 7:09 PM Richard Guo wrote: > It seems to me that, for a relation in the rangetable that has virtual > generated columns, we can consider it a subquery to some extent. For > instance, suppose we have a query: > > select ... from ... join t on ...; > > and suppose t.b is a v

Re: test_escape: invalid option -- 'c'

Michael Paquier writes: > On Tue, Feb 18, 2025 at 11:12:13AM +0800, Japin Li wrote: >> When I test test_escape, I find the usage of test_escape declares it >> support -c option, however, when I use it, it complains it is an >> invalid option. >> >> Here is a patch to fix it. > > You are right, o

Re: Enhancing Memory Context Statistics Reporting

Hi, > > Thanks for updating the patch! > > The below comments would be a bit too detailed at this stage, but I’d > like to share the points I noticed. > > Thanks for sharing the detailed comments. I have incorporated some of them into the new version of the patch. I will include the rest when I re

Improve cleaning files on Postgres crashes

Hi. There are some reports that Postgres does not handle correctly cleaning the files used when it crashes. [1] I think that function *fcloseall* can help a little bit. Mainly on Windows. /* * Closes all of the calling process's open streams. * On Windows, close and remove all temporary files cr

Re: Improve statistics estimation considering GROUP-BY as a 'uniqueiser'

On 17/2/2025 02:06, Alexander Korotkov wrote: On Thu, Nov 28, 2024 at 4:39 AM Andrei Lepikhov wrote: Here we also could count number of scanned NULLs separately in vardata_extra and use it in upper GROUP-BY estimation. What could be the type of vardata_extra? And what information could it st

Re: Proposal to CREATE FOREIGN TABLE LIKE

On Feb 18, 2025 at 09:54 +0800, Zhang Mingli , wrote: > > Will address the comments later,  thanks for review! Done in patch v6. -- Zhang Mingli HashData v6-0001-CREATE-FOREIGN-TABLE-LIKE.patch Description: Binary data

Fix api misuse (src/bin/pg_amcheck/pg_amcheck.c)

Hi. Similar to commit 5b94e27 [1] The correct function when freeing memory in the frontend, using the function PQescapeIdentifier, must be PQfreemem. Trivial patch attached. best regards, Ranier Vilela [1] https://www.postgresql.org/message-id/C

Re: Should heapam_estimate_rel_size consider fillfactor?

On 18/02/2025 14:01, Tomas Vondra wrote: On 2/4/25 17:54, Tomas Vondra wrote: On 2/4/25 16:02, Tomas Vondra wrote: ... Thanks for the report. And yeah, clamping it to 1 seems like the right fix for this. I wonder if it's worth inventing some sort of test for this, shouldn't be too hard I guess

Re: Support a wildcard in backtrace_functions

> On 18 Feb 2025, at 09:34, Jelte Fennema-Nio wrote: > > On Thu, 27 Jun 2024 at 12:43, Jelte Fennema-Nio wrote: >> Attached is a rebased patchset of my previous proposal, including a >> few changes that Michael preferred: > > Rebased again. (got notified because of the new commitfest rebase ema

Re: Fix outdated code comments in nodeAgg.c

On Feb 10, 2025 at 16:45 +0800, Richard Guo , wrote: > On Sun, Feb 9, 2025 at 11:15 PM Zhang Mingli wrote: > > By reading the codes in nodeAgg.c, I found that some comments are outdated. > > The comments referred to the function lookup_hash_entry(), which has been > > removed in commit b563594. >

Re: Proposal to CREATE FOREIGN TABLE LIKE

On Feb 18, 2025 at 09:54 +0800, Zhang Mingli , wrote: > > Will address the comments later,  thanks for review! Done in patch v6. -- Zhang Mingli HashData v6-0001-CREATE-FOREIGN-TABLE-LIKE.patch Description: Binary data

Re: Should heapam_estimate_rel_size consider fillfactor?

On 2/4/25 17:54, Tomas Vondra wrote: > On 2/4/25 16:02, Tomas Vondra wrote: >> ... >> >> Thanks for the report. And yeah, clamping it to 1 seems like the right >> fix for this. I wonder if it's worth inventing some sort of test for >> this, shouldn't be too hard I guess. >> >> In any case, I'll tak

  1   2   >