On Sat, Apr 6, 2024 at 5:10 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > Please see the attached v38 patch. Hi, thanks everyone for reviewing the design and patches so far. Here I'm with the v39 patches implementing inactive timeout based (0001) and XID age based (0002) invalidation mechanisms. I'm quoting the hackers who are okay with inactive timeout based invalidation mechanism: Bertrand Drouvot - https://www.postgresql.org/message-id/ZgL0N%2BxVJNkyqsKL%40ip-10-97-1-34.eu-west-3.compute.internal and https://www.postgresql.org/message-id/ZgPHDAlM79iLtGIH%40ip-10-97-1-34.eu-west-3.compute.internal Amit Kapila - https://www.postgresql.org/message-id/CAA4eK1L3awyzWMuymLJUm8SoFEQe%3DDa9KUwCcAfC31RNJ1xdJA%40mail.gmail.com Nathan Bossart - https://www.postgresql.org/message-id/20240325195443.GA2923888%40nathanxps13 Robert Haas - https://www.postgresql.org/message-id/CA%2BTgmoZTbaaEjSZUG1FL0mzxAdN3qmXksO3O9_PZhEuXTkVnRQ%40mail.gmail.com I'm quoting the hackers who are okay with XID age based invalidation mechanism: Nathan Bossart - https://www.postgresql.org/message-id/20240326150918.GB3181099%40nathanxps13 and https://www.postgresql.org/message-id/20240327150557.GA3994937%40nathanxps13 Alvaro Herrera - https://www.postgresql.org/message-id/202403261539.xcjfle7sksz7%40alvherre.pgsql Bertrand Drouvot - https://www.postgresql.org/message-id/ZgPHDAlM79iLtGIH%40ip-10-97-1-34.eu-west-3.compute.internal Amit Kapila - https://www.postgresql.org/message-id/CAA4eK1L3awyzWMuymLJUm8SoFEQe%3DDa9KUwCcAfC31RNJ1xdJA%40mail.gmail.com There was a point raised by Robert https://www.postgresql.org/message-id/CA%2BTgmoaRECcnyqxAxUhP5dk2S4HX%3DpGh-p-PkA3uc%2BjG_9hiMw%40mail.gmail.com for XID age based invalidation. An issue related to vacuum_defer_cleanup_age https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=be504a3e974d75be6f95c8f9b7367126034f2d12 led to the removal of the GUC https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1118cd37eb61e6a2428f457a8b2026a7bb3f801a. The same issue may not happen for the XID age based invaliation. This is because the XID age is not calculated using FullTransactionId but using TransactionId as the slot's xmin and catalog_xmin are tracked as TransactionId. There was a point raised by Amit https://www.postgresql.org/message-id/CAA4eK1K8wqLsMw6j0hE_SFoWAeo3Kw8UNnMfhsWaYDF1GWYQ%2Bg%40mail.gmail.com on when to do the XID age based invalidation - whether in checkpointer or when vacuum is being run or whenever ComputeXIDHorizons gets called or in autovacuum process. For now, I've chosen the design to do these new invalidation checks in two places - 1) whenever the slot is acquired and the slot acquisition errors out if invalidated, 2) during checkpoint. However, I'm open to suggestions on this. I've also verified the case whether the replication_slot_xid_age setting can help in case of server inching towards the XID wraparound. I've created a primary and streaming standby setup with hot_standby_feedback set to on (so that the slot gets an xmin). Then, I've set replication_slot_xid_age to 2 billion on the primary, and used xid_wraparound extension to reach XID wraparound on the primary. Once I start receiving the WARNINGs about VACUUM, I did a checkpoint after which the slot got invalidated enabling my VACUUM to freeze XIDs saving my database from XID wraparound problem. Thanks a lot Masahiko Sawada for an offlist chat about the XID age calculation logic. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
pgsql-hackers by date:
Соглашаюсь с условиями обработки персональных данных