Re: problems with toast.* reloptions

>> Actually, I think there's a problem with this approach... You're right. I forgot we can reset the table options. While we could use a placeholder and resolve it on-demand, that seems like too much work.

Re: Fixes inconsistent behavior in vacuum when it processes multiple relations

>> Making the index cleanup stable takes a certain amount of cycles,, Thanks for your explanation!

Re: Fixes inconsistent behavior in vacuum when it processes multiple relations

> Attached is the remaining patch for HEAD, planned once v19 opens, and > the tests I have used on the back-branches as a txt to not confuse the > CI, for reference. Just want to make sure, are we not going to include my original test to catch the future regression? Also, could someone please let

Re: problems with toast.* reloptions

> I think we need to do something like the following to fix this: > > * Teach autovacuum to combine the TOAST reloptions with the main relation's > when processing TOAST tables (with the toast.* ones winning if both are > set). > > * Teach autovacuum to resolve reloptions for parameters like >

Re: Fixes inconsistent behavior in vacuum when it processes multiple relations

>> It's a bit odd that we have both `VacuumParams *params` and >> `struct VacuumParams *params`. Thanks for pointing that out, the attached new version fixed that. >> I'd suggest just marking the VacuumParams *params with const... I initially considered that approach. However, the current code p

Re: Fixes inconsistent behavior in vacuum when it processes multiple relations

>> However, Option 1) would be my go-to option for HEAD ... Updated my patch to apply the same rules to all VacuumParams. Also I am seeing clusterParams as a pass reference, not sure if we should also change that to prevent future issues. But that should be another patch. vacuum_tables_options_4

Re: Fixes inconsistent behavior in vacuum when it processes multiple relations

an Bossart wrote: > > On Wed, Jun 18, 2025 at 11:15:31AM -0400, shihao zhong wrote: > > I investigated the code and found a small bug with how we're passing > > the VacuumParams pointer. > > > > The call flow is > > ExecVacuum -> vacuum -> vacuum_rel >

Fixes inconsistent behavior in vacuum when it processes multiple relations

Hi team, One of our customers recently encountered an issue with PostgreSQL's pg_cron and VACUUM ANALYZE. They had configured a table with vacuum_truncate=false to prevent exclusive lock contention, assuming this would apply globally. However, VACUUM ANALYZE executed across the entire database doe

Re: Clock-skew management in logical replication

> > > Long-term, we should consider integrating with a distributed time > > service like AWS Time Sync Service. This ensures high accuracy and > > scalability for demanding applications. > > > I think the pluggable access method should make > this possible, no? > I am sorry that I did not explai

Re: Clock-skew management in logical replication

Nisha Moond writes: > Thoughts? Looking forward to hearing others' opinions! Had a productive conversation with Amit Kaplia today about time skew in distributed systems, and wanted to share some thoughts. Essentially, we're grappling with the classic distributed snapshot problem. In a multi-activ

Re: Fix incorrect PG_GETARG in pgcrypto

On Tue, Feb 13, 2024 at 7:08 PM Michael Paquier wrote: > > On Tue, Feb 13, 2024 at 05:36:36PM +0900, Michael Paquier wrote: > > You've indeed grabbed some historical inconsistencies here. Please > > note that your patch has reversed diffs (for example, the SQL > > definition of pgp_sym_encrypt_by

Fix incorrect PG_GETARG in pgcrypto

Hi hackers, I'd like to bring to your attention that I recently identified some functions in pgcrypto that are using PG_GETARG functions in a way that doesn't match the expected function signature of the stored procedures. This patch proposes a solution to address these inconsistencies and ensure

Re: Encoding protection for pgcrypto

On Fri, Feb 9, 2024 at 5:34 PM cary huang wrote: > > The following review has been posted through the commitfest application: > make installcheck-world: tested, failed > Implements feature: not tested > Spec compliant: not tested > Documentation:not tested > > Hello >

Encoding protection for pgcrypto

Hi hackers, Currently, pgp_sym_decrypt_text and pgp_pub_decrypt_text doesn't enforce database encoding validation even when returning text. This patch adds validation and dedicated tests to verify its effectiveness. Additionally, some existing unit tests were moved to the new tests as they failed

Re: Patch: Improve Boolean Predicate JSON Path Docs

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, passed I took a look for this commit, it looks correct to me

Re: Fix bogus Asserts in calc_non_nestloop_required_outer

I have reviewed the changes and it looks fine. The new status of this patch is: Ready for Committer

Re: EXCLUDE COLLATE in CREATE/ALTER TABLE document

Hi Jian, Thanks for your comments, a new version is attached. Thanks, Shihao On Fri, Nov 10, 2023 at 9:59 AM jian he wrote: > On Wed, Nov 1, 2023 at 10:30 AM shihao zhong > wrote: > > > > Thank you for your feedback on my previous patch. I have fixed the issue > and att

Re: Postgres Partitions Limitations (5.11.2.3)

That looks good to me! The new status of this patch is: Ready for Committer

Re: Commitfest manager November 2023

On Wed, Nov 1, 2023 at 7:59 AM Aleksander Alekseev wrote: > Hi, > > > I didn't see any recent mentions in the archives, so I'll volunteer to > > be CF manager for 2023-11. > > I would love to help with that if you need. > > -- > Thanks, > Shihao

Re: speed up a logical replica setup

I think this is duplicate with https://commitfest.postgresql.org/45/4637/ The new status of this patch is: Waiting on Author

Re: EXCLUDE COLLATE in CREATE/ALTER TABLE document

On Tue, Oct 31, 2023 at 9:07 PM Tom Lane wrote: > shihao zhong writes: > > I noticed that the CREATE/ALTER TABLE document does not mention that > > EXCLUDE can accept a collation. I created a documentation fix for this > > issue, and I have attached it to this email.

EXCLUDE COLLATE in CREATE/ALTER TABLE document

Hi hackers, I hope this email finds you well. I noticed that the CREATE/ALTER TABLE document does not mention that EXCLUDE can accept a collation. I created a documentation fix for this issue, and I have attached it to this email. Please let me know if you have any questions or concerns. Thanks

Re: Trigger violates foreign key constraint

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, passed It seems like people have been talking about this problem since 2010 (ht

Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs

Thanks for the answer. The code looks good to me. Thanks, Shihao On Thu, Oct 19, 2023 at 12:00 PM Tom Lane wrote: > shihao zhong writes: > > I do like the idea that we should keep the set and the altar system with > > the same behavior. But one thing I am worried about is th

Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs

I do like the idea that we should keep the set and the altar system with the same behavior. But one thing I am worried about is the typo detected here because I usually make that type of mistake myself. I believe we should have an extra log to explicitly tell the user this is a `custom variable` gu

Re: Fix a wrong comment in setrefs.c

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested That looks correct for me The new status of this patch is: Ready for Committ