Re: Non-reproducible AIO failure

Hello, 02.06.2025 09:00, Alexander Lakhin wrote: With additional logging (the patch is attached), I can see the following: ... !!!pgaio_io_reclaim [63817]| ioh: 0x1046b5660, ioh->op: 1, ioh->state: 6, ioh->result: 8192, ioh->num_callbacks: 2 !!!AsyncReadBuffers [63817] (1)| blocknum: 18, ioh: 0

Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

On Tue, Jun 3, 2025 at 3:55 PM Amit Kapila wrote: > > > You haven't shared the exact test scenario, but I am assuming the > above tests are for very large transactions, as you are comparing > streaming and non-streaming modes. Can we see results with short > transaction size (say one insert or one

Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

On Fri, May 30, 2025 at 4:41 PM Ajin Cherian wrote: > > I ran a series of tests using both streaming and non-streaming logical > replication modes with the patch. In non-streaming mode, the patch > showed a significant performance improvement — up to +68% in the best > case, with a -6% regression

Re: Foreign key validation failure in 18beta1

On Mon, Jun 2, 2025 at 9:56 PM Alvaro Herrera wrote: > > Hello > > I find this coding somewhat confusing. Now you have a function > "QueueFkConstraintValidation" which may queue a FK queue constraint > validation, if the flag "queueValidation" is given, but it may also do > something else -- make

Re: C11 / VS 2019

On Mon, Jun 02, 2025 at 08:52:00AM -0500, Nathan Bossart wrote: > On Mon, Jun 02, 2025 at 05:44:12AM +0200, Peter Eisentraut wrote: >> Summary: >> 1. require VS 2019 >> 2. use C11 >> >> Thoughts? > > +1 +1 to move on for both of these. I got convinced about the benefits of C11 and the simplific

Re: Fix slot synchronization with two_phase decoding enabled

On Mon, Jun 2, 2025 at 10:55 AM Amit Kapila wrote: > > On Fri, May 30, 2025 at 3:00 PM Nisha Moond wrote: > > > > Agree that we need to cover the simple pg_dump and pg_restore with the > > patch. > > > > When pg_dump and pg_restore are used outside of pg_upgrade, there's no > > guarantee that th

Re: pg_upgrade: warn about roles with md5 passwords

On Mon, Jun 02, 2025 at 02:55:40PM -0500, Nathan Bossart wrote: > So, right now the upgrade directory will be something like: > > ./pg_upgrade_output.d/20250602T095620.137 > > cleanup_output_dirs() recursively deletes everything in the timestamp > directory (and the directory itself), and t

Re: Encapsulate io_uring process count calculation

On Tue, Jun 03, 2025 at 12:16:21PM +0800, Japin Li wrote: > I've replaced the hardcoded arithmetic expression for calculating TotalProcs > within the pgaio_uring_shmem_init() with a call to the dedicated > pgaio_uring_procs() function. > > This can make the code's intent clearer. Simplifies futur

Re: bt_index_parent_check and concurrently build indexes

On Mon, Jun 02, 2025 at 05:40:18PM -0700, Donghang Lin wrote: > Your finding is right on point! We recently used bt_index_parent_check to > verify concurrently built indexes in a concurrent workload, > bt_index_parent_check often gave such false positive error. Good thing is that this is tracked i

Encapsulate io_uring process count calculation

I've replaced the hardcoded arithmetic expression for calculating TotalProcs within the pgaio_uring_shmem_init() with a call to the dedicated pgaio_uring_procs() function. This can make the code's intent clearer. Simplifies future modifications to the calculation, as it only needs to be updated

Re: Persist injection points across server restarts

On Mon, Jun 02, 2025 at 12:42:35PM -0700, Jeff Davis wrote: > Unless that other thread is blocked for some reason, I'd suggest just > going ahead with the SQL callable function first. That seems > independently useful. Thanks. Having InjectionPointList() was also required for the other thread. >

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

Isaac Morland writes: > On Mon, 2 Jun 2025 at 22:52, jian he wrote: > Do we consider INSERT associated with user defined function a security >> bug? > A very old issue for INSERT/UPDATE/DELETE, but until this patch not an > issue for SELECT from a table (although if I understand correctly earlie

Re: Add CHECK_FOR_INTERRUPTS in polling loop code path in XactLockTableWait

Hi all, Thank you for the earlier pushed patch—after testing it, things work well. Per Fujii’s and Kevin’s ideas and suggestions[1], [2], I’ve tried to extend it to add a new wait event and a progressive backoff mechanism for XactLockTableWait in logical replication scenarios. New wait event • X

Re: track generic and custom plans in pg_stat_statements

> Now, one thing I don't like is the fact that the columns stats_since > and minmax_stats_since > are in between counters all of the sudden. I think we either need to > move them to > the front of the view, after the query field or within this patch > move them after the > new generic/custom plan

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Mon, 2 Jun 2025 at 22:52, jian he wrote: Do we consider INSERT associated with user defined function a security > bug? for > example, the following, INSERT with a check constraint. > [] If so, then it's a very old issue... > A very old issue for INSERT/UPDATE/DELETE, but until this pat

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Tue, Jun 3, 2025 at 9:19 AM Tom Lane wrote: > > In any case, this doesn't feel like something to be defining and > implementing post-beta1. Even if it were not security-critical, > the amount of complication involved is well past our standards > for what can go in post-feature-freeze. > > I'm

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

On Fri, May 09, 2025 at 02:08:26PM +0900, Michael Paquier wrote: > On Tue, Feb 18, 2025 at 04:57:47PM -0800, Noah Misch wrote: > > As I wrote in [1], "By the time we reach consistency, every file in > > pg_twophase will be applicable (not committed or aborted)." If we find > > otherwise, the user

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Mon, 2025-06-02 at 21:19 -0400, Tom Lane wrote: > Maybe we can make a conservative approximation that's good > enough to be useful, but I'm not certain. Right. If the alternative is reverting the feature, the idea would be to save it for at least some common use cases where the expression is ob

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

Jeff Davis writes: > On Thu, 2025-05-29 at 11:12 -0400, Tom Lane wrote: >> Perhaps a compromise is to invent RunAsUser but only apply it to >> virtual columns for now, leaving the view case as a research >> project. Then we aren't destroying the performance of any >> existing queries. > Could we

Re: wrong query results on bf leafhopper

Hi, On Thu, 29 May 2025 at 02:32, Andres Freund wrote: > On 2025-05-28 22:51:14 +0930, Robins Tharakan wrote: > Recently leafhopper failed again on the same test. For now I've paused it. > > To rule out the compiler (and its maturity on the architecture), I'll > > upgrade > > gcc (to nightly, o

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

On 2025/06/02 14:42, Peter Eisentraut wrote: On 30.05.25 18:12, Fujii Masao wrote: On 2025/05/31 0:28, Fujii Masao wrote:   Otherwise, maybe "log_lock_failures" would be better. Yes, this seems better for consistency with log_lock_waits. Patch attached. This looks good to me. I've pu

Re: bt_index_parent_check and concurrently build indexes

Hi Michail > It turns out that bt_index_parent_check is not suitable for validating indexes built concurrently. Your finding is right on point! We recently used bt_index_parent_check to verify concurrently built indexes in a concurrent workload, bt_index_parent_check often gave such false positive

Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them

On Thu, 2025-05-29 at 11:12 -0400, Tom Lane wrote: > Perhaps a compromise is to invent RunAsUser but only apply it to > virtual columns for now, leaving the view case as a research > project.  Then we aren't destroying the performance of any > existing queries. Could we instead check that the expr

Re: MergeAppend could consider sorting cheapest child path

Hi, Alexander! On Wed, May 7, 2025 at 12:06 PM Alexander Pyhalov wrote: > Andrei Lepikhov писал(а) 2025-05-07 12:03: > > On 7/5/2025 08:57, Alexander Pyhalov wrote: > >> Andrei Lepikhov писал(а) 2025-05-07 08:02: > >>> On 5/5/2025 15:56, Alexander Pyhalov wrote: > Andrei Lepikhov писал(а) 20

Re: Periodic FSM vacuum doesn't happen in one-pass strategy vacuum.

On Mon, Apr 7, 2025 at 11:52 AM Masahiko Sawada wrote: > > On Mon, Apr 7, 2025 at 8:30 AM Melanie Plageman > wrote: > > > > On Fri, Apr 4, 2025 at 6:07 PM Masahiko Sawada > > wrote: > > > > > > I'm going to push this fix up to HEAD and v17 early next week, unless > > > there is no objection. >

Re: pg_get_multixact_members not documented

-- Sami Imseih Amazon Web Services (AWS) On Mon, Jun 2, 2025 at 3:03 PM Nathan Bossart wrote: > On Mon, Jun 02, 2025 at 12:46:51PM -0500, Sami Imseih wrote: > > v1-0001 is the documentation only patch. I improved upon the description > > suggested in [0] > > Your patch adds an entry to the "Tra

Re: Correcting freeze conflict horizon calculation

On Mon, Jun 2, 2025 at 4:00 PM Melanie Plageman wrote: > I think, however, that I can't avoid keeping a separate counter for > the horizon for the VM record. Pruning and freezing horizon is the > newest "modified" (pruned or frozen) tuple xid, whereas the VM record > needs the newest live committe

Re: pg_get_multixact_members not documented

On Mon, Jun 02, 2025 at 12:46:51PM -0500, Sami Imseih wrote: > v1-0001 is the documentation only patch. I improved upon the description > suggested in [0] Your patch adds an entry to the "Transaction ID and Snapshot Information Functions" table, while Álvaro's introduced a new "Multixact Functions

Re: Correcting freeze conflict horizon calculation

On Mon, Jun 2, 2025 at 3:40 PM Peter Geoghegan wrote: > > On Mon, Jun 2, 2025 at 3:30 PM Melanie Plageman > wrote: > > > But, for cases when a few tuples are frozen on the page, it seems like it > > could > > be worth it? > > In general, I don't expect that we're all that likely to freeze some >

Re: pg_upgrade: warn about roles with md5 passwords

On Mon, Jun 02, 2025 at 12:41:47PM -0700, Jeff Davis wrote: > On Mon, 2025-06-02 at 12:04 -0500, Nathan Bossart wrote: >> That seems worth considering.  Another option could be to just >> document >> that files generated for warnings will be lost without --retain.  >> WDYT? > > I haven't looked in

Re: Correcting freeze conflict horizon calculation

On Mon, Jun 2, 2025 at 3:40 PM Melanie Plageman wrote: > Oh, and, more specifically, in my previous email, I was wondering if, > and why, in 16 this diff wouldn't be correct I *think* that it would be correct. Again, it is certainly possible to make the conflict horizon precisely the oldest safe

Re: pg_upgrade: warn about roles with md5 passwords

On Mon, 2025-06-02 at 12:04 -0500, Nathan Bossart wrote: > > > That seems worth considering.  Another option could be to just > document > that files generated for warnings will be lost without --retain.  > WDYT? I haven't looked into it yet, but copying the files to an "upgrade_warnings" directo

Re: Correcting freeze conflict horizon calculation

On Mon, Jun 2, 2025 at 3:05 PM Peter Geoghegan wrote: > > On Mon, Jun 2, 2025 at 2:50 PM Melanie Plageman > wrote: > > As you've explained, it will always be <= OldestXmin. And, if the > > record only freezes tuples (meaning it makes no other changes to the > > page) and all of those tuples' xmin

Re: Improve explicit cursor handling in pg_stat_statements

> > The FETCH and CLOSE are already not clear to what underlying SQL > > they are referring to, and there is not much chance to actually > > improve that unless > > we track a cursor queryId in pg_stat_statements ( at that point we can show > > that > > FETCH or CLOSE refer to this specific cursor

Re: Persist injection points across server restarts

On Wed, 2025-04-30 at 14:35 +0900, Michael Paquier wrote: > - 0001 is a patch I have stolen from a different thread (see [1]), > introducing InjectionPointList() that retrieves a list of the > injection points attached. Unless that other thread is blocked for some reason, I'd suggest just going ah

Re: Correcting freeze conflict horizon calculation

On Mon, Jun 2, 2025 at 3:30 PM Melanie Plageman wrote: > I understand that if I wanted to actually use the newest frozen xmin > as the conflict horizon when the page is not all-frozen, I'd need a > new counter since visibility_cutoff_xid is calculated across all live > tuples older than OldestXmin

Re: Correcting freeze conflict horizon calculation

On Mon, Jun 2, 2025 at 3:05 PM Peter Geoghegan wrote: > > On Mon, Jun 2, 2025 at 2:50 PM Melanie Plageman > wrote: > > As you've explained, it will always be <= OldestXmin. And, if the > > record only freezes tuples (meaning it makes no other changes to the > > page) and all of those tuples' xmin

Re: pg_get_multixact_members not documented

> > Want to put together a patch? > > Yes, will do v1-0001 is the documentation only patch. I improved upon the description suggested in [0] > > For extra credit, maybe we could add a test or two, too... I can add tests, even though we don't really have system function specific testing. A simpl

Re: tighten generic_option_name, or store more carefully in catalog?

Chapman Flack writes: > On 06/02/25 14:13, Tom Lane wrote: >> Here's a proposed patch for the "=" issue. Whether or not we should >> rethink FDW validation behavior, doing so surely couldn't be >> back-patched. But I think this much should be. > LGTM Pushed, thanks for looking at it.

Re: Proposal: Limitations of palloc inside checkpointer

Hi, Xuneng Zhou! On Tue, Apr 15, 2025 at 7:02 AM Xuneng Zhou wrote: > I've moved this entry to the July CommitFest. The CI reported an unused > variable warning in patch v5, so I've addressed it by removing the unused > one. Sorry for not catching the issue locally. Thank you for your work on

Re: tighten generic_option_name, or store more carefully in catalog?

On 06/02/25 14:13, Tom Lane wrote: > Here's a proposed patch for the "=" issue. Whether or not we should > rethink FDW validation behavior, doing so surely couldn't be > back-patched. But I think this much should be. LGTM Regards, -Chap

ABI Compliance Checker GSoC Project

Hackers, I’d like to introduce Mankirat Singh, a Google Summer of Code student that Pavlo Golub and I are mentoring this year. He’s started work on his project, an ABI Compliance Checker. The plan is to work out the patterns, integrate it into the Build Farm, and get it sending regular reports

Re: Correcting freeze conflict horizon calculation

On Mon, Jun 2, 2025 at 2:50 PM Melanie Plageman wrote: > As you've explained, it will always be <= OldestXmin. And, if the > record only freezes tuples (meaning it makes no other changes to the > page) and all of those tuples' xmins were considered when calculating > prunestate->visibility_cutoff_

Re: track generic and custom plans in pg_stat_statements

> I reviewed v6: > > - applies to master cleanly, builds, tests pass and all works as expected > - overall, the patch looks great and I found no major issues > - tests and docs look good overall Thanks for the valuable feedback! > - in docs, one minor comment: > > "Total number of statements

Re: Correcting freeze conflict horizon calculation

On Thu, May 29, 2025 at 11:37 AM Peter Geoghegan wrote: > > Your concern is that the horizon might be overly aggressive/too > conservative. But your patch (for 16) makes us take the > don't-use-snapshotConflictHorizon-twice block *less* frequently (and > the "use OldestXmin conservatively" block *

Re: ARM/ARM64 SpinLockAcquire and SpinLockRelease are not full barriers

Good day, hackers. 13.05.2025 19:22, Yura Sokolov wrote: > Good day. > > During conversation about other patch, Andres pointed out SpinLockAcquire > have semantic of full memory barrier [1] . > > spin.h also states: > >> Load and stores operation in calling code are guaranteed not to be > reord

Re: SpinLockAcquire and SpinLockRelease is broken on ARM/ARM64? (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

Good day, Andres. Good day, hackers. 05.05.2025 10:30, Yura Sokolov wrote: > 21.03.2025 19:33, Andres Freund пишет: >> Hi, >> >> On 2025-03-21 14:35:16 +0300, Yura Sokolov wrote: >>> From 080c9e0de5e6e10751347e1ff50b65df424744cb Mon Sep 17 00:00:00 2001 >>> From: Yura Sokolov >>> Date: Mon, 3 Feb

Re: tighten generic_option_name, or store more carefully in catalog?

Here's a proposed patch for the "=" issue. Whether or not we should rethink FDW validation behavior, doing so surely couldn't be back-patched. But I think this much should be. regards, tom lane diff --git a/src/backend/access/common/reloptions.c b/src/backend/access/comm

Re: pg_upgrade: warn about roles with md5 passwords

On Mon, Jun 02, 2025 at 09:45:55AM -0700, Jeff Davis wrote: > On Mon, 2025-06-02 at 10:32 -0500, Nathan Bossart wrote: >> The one thing I don't like about this check is that it's probably not >> great >> from a security standpoint to effectively announce which roles have >> MD5 >> passwords. > > D

Re: Improve hash join's handling of tuples with null join keys

Thomas Munro writes: > On Tue, May 6, 2025 at 12:12 PM Tomas Vondra wrote: >> On 5/6/25 01:11, Tom Lane wrote: >>> The attached patch is a response to the discussion at [1], where >>> it emerged that lots of rows with null join keys can send a hash >>> join into too-many-batches hell, if they are

Re: Vacuum statistics

On 02.06.2025 19:25, Alexander Korotkov wrote: On Tue, May 13, 2025 at 12:49 PM Alena Rybakina wrote: On 12.05.2025 08:30, Amit Kapila wrote: On Fri, May 9, 2025 at 5:34 PM Alena Rybakina wrote: I did a rebase and finished the part with storing statistics separately from the relation stat

Re: pg_upgrade: warn about roles with md5 passwords

On Mon, 2025-06-02 at 10:32 -0500, Nathan Bossart wrote: > Since MD5 passwords are slated to be marked as deprecated in v18, I > figured > it might be a good idea to add a check for roles with MD5 passwords > to > pg_upgrade.  I'm tempted to suggest that we apply this to v18, but > I'm > content to

Re: Foreign key validation failure in 18beta1

Hello I find this coding somewhat confusing. Now you have a function "QueueFkConstraintValidation" which may queue a FK queue constraint validation, if the flag "queueValidation" is given, but it may also do something else -- makes no sense IMO. I think it's better to split this function in two;

Re: Vacuum statistics

On Tue, May 13, 2025 at 12:49 PM Alena Rybakina wrote: > On 12.05.2025 08:30, Amit Kapila wrote: > > On Fri, May 9, 2025 at 5:34 PM Alena Rybakina > > wrote: > >> I did a rebase and finished the part with storing statistics separately > >> from the relation statistics - now it is possible to di

Re: RelationGetNumberOfBlocks called before vacuum_get_cutoffs

On Mon, Jun 2, 2025 at 10:31 AM Peter Geoghegan wrote: > > On Mon, Jun 2, 2025 at 10:27 AM Melanie Plageman > wrote: > > Attached what I plan to push shortly. > > Looks good to me. Thanks! pushed.

pg_upgrade: warn about roles with md5 passwords

Since MD5 passwords are slated to be marked as deprecated in v18, I figured it might be a good idea to add a check for roles with MD5 passwords to pg_upgrade. I'm tempted to suggest that we apply this to v18, but I'm content to leave it for v19 if nobody feels too strongly about it. The one thing

Re: Suggestion to add --continue-client-on-abort option to pgbench

Hi, Hackers. I've attached the patch that I failed to include in my previous email. (I'm still a bit confused about how to attach files using the standard Mail client on macOS.) Best Regards, Rintaro IkedaFrom fca20d18dbedc8a9c66408da3e7139cd4192ff5b Mon Sep 17 00:00:00 2001 From: "Rintaro.Ike

Re: RelationGetNumberOfBlocks called before vacuum_get_cutoffs

On Sun, Jun 1, 2025 at 2:23 PM Peter Geoghegan wrote: > > I have to imagine that you moved rel_pages initialization back so that > it took place next to the initialization of other, similar BlockNumber > fields from LVRelState. IIRC I wrote a comment about this issue at > least in part because I u

Re: RelationGetNumberOfBlocks called before vacuum_get_cutoffs

On Mon, Jun 2, 2025 at 10:27 AM Melanie Plageman wrote: > Attached what I plan to push shortly. Looks good to me. -- Peter Geoghegan

Re: Suggestion to add --continue-client-on-abort option to pgbench

Hi, hakers.On Tue, May 13, 2025 at 11:27 AM Dilip Kumar wrote:1. You need to update the stats for this new counter in the"accumStats()" function.2. IMHO, " continue-on-error " is more user-friendly than"continue-client-on-error".3. There are a lot of whitespace errors, so th

Re: fix notes about password encryption in pg_authid docs

On Mon, Jun 02, 2025 at 09:16:10AM -0500, Nathan Bossart wrote: > I noticed that the docs for the pg_authid catalog still indicate that > passwords might be stored "unencrypted," which hasn't been possible since > commit eb61136. The attached patch attempts to fix that. If acceptable, > I'd back-

fix notes about password encryption in pg_authid docs

I noticed that the docs for the pg_authid catalog still indicate that passwords might be stored "unencrypted," which hasn't been possible since commit eb61136. The attached patch attempts to fix that. If acceptable, I'd back-patch it to all supported versions. -- nathan

Re: Avoid orphaned objects dependencies, take 3

Hi, On Thu, May 22, 2025 at 12:38:50PM -0700, Jeff Davis wrote: > Which > call sites are the most interesting ones that need special attention? I think the ones that need special attention are the ones that check for the permissions on the referenced objects *after* recordMultipleDependencies is

Re: Avoid orphaned objects dependencies, take 3

Hi, On Thu, May 22, 2025 at 09:40:47AM -0400, Robert Haas wrote: > On Thu, May 22, 2025 at 8:15 AM Bertrand Drouvot > wrote: > > That would probably address Robert's concern [1] "acquiring two locks on > > the same > > object with different lock modes where we should really only acquire one" >

Re: SQL:2011 application time

Peter Eisentraut writes: > On 26.05.25 23:18, Paul A Jungwirth wrote: >> Here do we want to say "respective operator class" instead of >> "respective operator family"? Or "operator class/family"? Technically >> btree_gist attaches it to the whole opfamily, but that's only because >> there is no ap

alter check constraint enforceability

hi. Currently in pg18, we can add not enforced check constraints. but we can not do ALTER TABLE ALTER CONSTRAINT [NOT] ENFORCED for check constraint. The attached patch is implementation of changing enforceability of check constraint. From 486cf69121b0ea37a5c050bf1ceaa67196acd682 Mon Sep 17 00:0

Re: [PING] fallocate() causes btrfs to never compress postgresql files

On Tue, 3 Jun 2025, Thomas Munro wrote: On Mon, Jun 2, 2025 at 10:14 PM Dimitrios Apostolou wrote: On Sun, 1 Jun 2025, Thomas Munro wrote: Or for a completely different approach: I wonder if ftruncate() would be more efficient on COW systems anyway. The minimum thing we need is for the file

Re: C11 / VS 2019

On Mon, Jun 02, 2025 at 05:44:12AM +0200, Peter Eisentraut wrote: > Summary: > 1. require VS 2019 > 2. use C11 > > Thoughts? +1 -- nathan

Re: [PING] fallocate() causes btrfs to never compress postgresql files

On Sun, Jun 1, 2025 at 02:00:17AM +1200, Thomas Munro wrote: > I suppose something like the 0001 part could be back-patched if this > is considered a serious enough problem without other workarounds, so I > did this in two steps. I wonder if there are good reasons to want to > change the number o

Re: RFC: Logging plan of the running query

On 2025-05-23 17:50, Atsushi Torikoshi wrote: Thanks for the idea and the sample patch! Agreed. I’ll go ahead and implement a new patch based on this approach. Updated the patch. Here are some notes: As with the previous patches, this one wraps not only the currently executing plan node but

Re: Suggestions for improving \conninfo output in v18

On Sunday, June 1, 2025, Fujii Masao wrote: > > On 2025/06/02 14:24, David G. Johnston wrote: > >> On Sunday, June 1, 2025, Fujii Masao > > wrote: >> > Also, I noticed that the "Client User" column reflects the user at >> the time of connection, while th

Re: Logical Replication of sequences

On Thu, May 29, 2025 at 8:09 PM vignesh C wrote: > These comments are handled in the attached v2025029 version patch. > Thanks for the patches. I am still reviewing but please find few comments: 1) Only persistent sequences are included in the publication. Temporary sequences a

Re: [PING] fallocate() causes btrfs to never compress postgresql files

On Mon, Jun 2, 2025 at 10:14 PM Dimitrios Apostolou wrote: > On Sun, 1 Jun 2025, Thomas Munro wrote: > > Or for a completely different approach: I wonder if ftruncate() would > > be more efficient on COW systems anyway. The minimum thing we need is > > for the file system to remember the new size

Re: Proposal for enabling auto-vectorization for checksum calculations

On Fri, May 23, 2025 at 4:54 AM Matthew Sterrett wrote: > Okay, I've determined that versions of LLVM/Clang before 19 crash when > compiling this patch for some reason; it seems that both make > check-world and make install will crash with the affected LLVM > versions. > Unfortunately, what matter

Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

On Thu, May 29, 2025 at 5:29 PM Alexander Korotkov wrote: > > On Tue, May 27, 2025 at 2:26 PM Amit Kapila wrote: > > Yeah, we should be able to change ABI during beta, but I can't comment > > on the idea of effective_restart_lsn without seeing the patch or a > > detailed explanation of this idea.

Re: [PING] fallocate() causes btrfs to never compress postgresql files

On Sun, 1 Jun 2025, Thomas Munro wrote: Or for a completely different approach: I wonder if ftruncate() would be more efficient on COW systems anyway. The minimum thing we need is for the file system to remember the new size, 'cause, erm, we don't. All the rest is probably a waste of cycles, si

Re: support fast default for domain with constraints

hi. attached is to fix the regress test failure[0] in V5. I also did some test simplification. [0] https://api.cirrus-ci.com/v1/artifact/task/6014753866252288/log/src/test/regress/regression.diffs From 1df9fc6e8e645463e864f44492d532def74c8437 Mon Sep 17 00:00:00 2001 From: jian he Date: Mon, 24

Re: Speedup truncations of temporary relation forks

31.05.2025 17:23, Daniil Davydov пишет: > Hi, > > On Sat, May 31, 2025 at 7:41 PM Fujii Masao > wrote: >> >> Here are a few review comments on the patch: >> >> + for (j = 0; j < nforks; j++) >> { >> - InvalidateLocalBuffer(bufHdr, true); >> +

Re: Missing pg_depend entries for constraints created by extensions (deptype 'e')

On Sun, Jun 1, 2025, at 18:04, Tom Lane wrote: > I'm pretty skeptical that this situation justifies the amount of > pg_depend bloat that you're suggesting. I also don't think it'd be > easy or cheap for pg_dump to detect objects that should be dumped > because they lack an 'e' dependency but depen

Re: [PING] fallocate() causes btrfs to never compress postgresql files

On Sat, May 31, 2025 at 4:33 PM Tomas Vondra wrote: > > On 5/31/25 16:00, Thomas Munro wrote: > > On Fri, May 30, 2025 at 3:58 AM Dimitrios Apostolou wrote: > >> All I'm saying is that this is a regression for PostgreSQL users that keep > >> tablespaces on compressed Btrfs. What could be done fro

[PATCH] Support for basic ALTER TABLE progress reporting.

Hi, while testing int->bigint migrations for our db at work I really missed ALTER TABLE progress reporting and during the waits I checked the code. It seems to me that ALTERs can be mostly categorized as 1) trivial ones - metadata rewrites, fast adding/removing columns, trying to change column type

Re: Assertion failure in smgr.c when using pg_prewarm with partitioned tables

On 2025-05-30 01:44, Fujii Masao wrote: I've pushed the 0001 patch. Thanks! Thanks! This is not directly relation to your proposal, but while reading the index_checkable() function, I noticed that ReleaseSysCache() is not called after SearchSysCache1(). Shouldn't we call ReleaseSysCache() her

Re: SQL:2011 application time

On 26.05.25 23:18, Paul A Jungwirth wrote: On Sun, May 25, 2025 at 10:57 PM Peter Eisentraut wrote: Here we added a gist support function that we internally refer to by the symbol GIST_STRATNUM_PROC. This translated from "well-known" strategy numbers to opfamily-specific strategy numbers. How