pgsql-hackers  

Messages by Thread

• • Re: Cleanup shadows variable warnings, round 1 Chao Li
  • Re: Cleanup shadows variable warnings, round 1 Peter Eisentraut
  • Re: Cleanup shadows variable warnings, round 1 Peter Smith
  • Re: Cleanup shadows variable warnings, round 1 Chao Li
  • Re: Cleanup shadows variable warnings, round 1 Álvaro Herrera
  • Re: Cleanup shadows variable warnings, round 1 Peter Smith
  • Re: Cleanup shadows variable warnings, round 1 Chao Li
  • Re: Cleanup shadows variable warnings, round 1 Peter Smith
  • Re: Cleanup shadows variable warnings, round 1 Andres Freund
  • Re: Cleanup shadows variable warnings, round 1 Álvaro Herrera
  • Re: Cleanup shadows variable warnings, round 1 Bilal Yavuz
• Re: Add support for specifying tables in pg_createsubscriber. vignesh C
  • Re: Add support for specifying tables in pg_createsubscriber. Shubham Khanna
  • Re: Add support for specifying tables in pg_createsubscriber. Peter Smith
  • Re: Add support for specifying tables in pg_createsubscriber. Peter Smith
  • Re:Re: Add support for specifying tables in pg_createsubscriber. tianbing
  • Re: Re: Add support for specifying tables in pg_createsubscriber. Peter Smith
  • Re: Re: Add support for specifying tables in pg_createsubscriber. vignesh C
  • Re: Re: Add support for specifying tables in pg_createsubscriber. Peter Smith
  • Re: Add support for specifying tables in pg_createsubscriber. Euler Taveira
  • Re: Add support for specifying tables in pg_createsubscriber. Peter Smith
• extend JSON_TABLE top level path expression jian he
  • Re: extend JSON_TABLE top level path expression jian he
• Fix a recent "shadow warning" in subscriptioncmds.c Peter Smith
  • Re: Fix a recent "shadow warning" in subscriptioncmds.c Chao Li
  • Re: Fix a recent "shadow warning" in subscriptioncmds.c Peter Smith
  • Re: Fix a recent "shadow warning" in subscriptioncmds.c Amit Kapila
  • Re: Fix a recent "shadow warning" in subscriptioncmds.c vignesh C
• Minor LLVM cleanups Thomas Munro
  • Re: Minor LLVM cleanups Matheus Alcantara
  • Re: Minor LLVM cleanups Andres Freund
• Simplify code building the LR conflict messages Peter Smith
  • Re: Simplify code building the LR conflict messages Tom Lane
  • Re: Simplify code building the LR conflict messages Peter Smith
  • Re: Simplify code building the LR conflict messages Tom Lane
  • Re: Simplify code building the LR conflict messages Peter Smith
  • Re: Simplify code building the LR conflict messages Álvaro Herrera
  • Re: Simplify code building the LR conflict messages Amit Kapila
  • Re: Simplify code building the LR conflict messages Tom Lane
  • Re: Simplify code building the LR conflict messages Tom Lane
  • Re: Simplify code building the LR conflict messages Amit Kapila
  • Re: Simplify code building the LR conflict messages Álvaro Herrera
  • Re: Simplify code building the LR conflict messages Mihail Nikalayeu
  • Re: Simplify code building the LR conflict messages Amit Kapila
  • Re: Simplify code building the LR conflict messages Amit Kapila
• Re: Few untranslated error messages in OAuth Álvaro Herrera
  • Re: Few untranslated error messages in OAuth Jacob Champion
  • Re: Few untranslated error messages in OAuth Álvaro Herrera
• Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Antonin Houska
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Mihail Nikalayeu
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Mihail Nikalayeu
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Antonin Houska
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Mihail Nikalayeu
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Mihail Nikalayeu
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Hannu Krosing
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Hannu Krosing
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Mihail Nikalayeu
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Antonin Houska
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Mihail Nikalayeu
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Antonin Houska
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Mihail Nikalayeu
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Hannu Krosing
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Mihail Nikalayeu
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Hannu Krosing
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Antonin Houska
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Antonin Houska
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Matthias van de Meent
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Antonin Houska
  • Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements Hannu Krosing
• Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION Maxim Orlov
  • Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION Heikki Linnakangas
  • Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION Maxim Orlov
  • RE: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION Hayato Kuroda (Fujitsu)
  • Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION Maxim Orlov
• weird ON CONFLICT clauses Álvaro Herrera
  • Re: weird ON CONFLICT clauses Peter Geoghegan
  • Re: weird ON CONFLICT clauses Álvaro Herrera
• Mention TABLEFUNC to make comment consistent with code Steve Lau
• [PATCH] Add `headerscheck` run_target to meson Miłosz Bieniek
  • Re: [PATCH] Add `headerscheck` run_target to meson Peter Eisentraut
  • Re: [PATCH] Add `headerscheck` run_target to meson Miłosz Bieniek
  • Re: [PATCH] Add `headerscheck` run_target to meson Nazir Bilal Yavuz
  • Re: [PATCH] Add `headerscheck` run_target to meson Nazir Bilal Yavuz
  • Re: [PATCH] Add `headerscheck` run_target to meson Miłosz Bieniek
  • Re: [PATCH] Add `headerscheck` run_target to meson Bilal Yavuz
• https://cfbot.cputube.org - certificate has expired Aleksander Alekseev
  • Re: https://cfbot.cputube.org - certificate has expired Nazir Bilal Yavuz
  • Re: https://cfbot.cputube.org - certificate has expired Aleksander Alekseev
  • Re: https://cfbot.cputube.org - certificate has expired Nazir Bilal Yavuz
  • Re: https://cfbot.cputube.org - certificate has expired Thomas Munro
  • Re: https://cfbot.cputube.org - certificate has expired Thomas Munro
• Remove unused function parameters, part 1: contrib Bertrand Drouvot
  • Re: Remove unused function parameters, part 1: contrib Kirill Reshke
  • Re: Remove unused function parameters, part 1: contrib Bertrand Drouvot
  • Re: Remove unused function parameters, part 1: contrib Jacob Champion
  • Re: Remove unused function parameters, part 1: contrib Nazir Bilal Yavuz
  • Re: Remove unused function parameters, part 1: contrib Bertrand Drouvot
• Re: pgsql: doc: Fix incorrect wording for --file in pg_dump Erik Rijkers
  • Re: pgsql: doc: Fix incorrect wording for --file in pg_dump Chao Li
  • Re: pgsql: doc: Fix incorrect wording for --file in pg_dump Michael Paquier
  • Re: pgsql: doc: Fix incorrect wording for --file in pg_dump Daniel Gustafsson
• Move WAL/RMGR sequence code into its own file and header Michael Paquier
  • Re: Move WAL/RMGR sequence code into its own file and header Heikki Linnakangas
  • Re: Move WAL/RMGR sequence code into its own file and header Michael Paquier
  • Re: Move WAL/RMGR sequence code into its own file and header Kirill Reshke
  • Re: Move WAL/RMGR sequence code into its own file and header Michael Paquier
  • Re: Move WAL/RMGR sequence code into its own file and header Michael Paquier
• Re: Consistently use palloc_object() and palloc_array() Chao Li
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Tom Lane
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Thomas Munro
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Michael Paquier
  • Re: Consistently use palloc_object() and palloc_array() Tom Lane
  • Re: Consistently use palloc_object() and palloc_array() Michael Paquier
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Tom Lane
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Tom Lane
  • Re: Consistently use palloc_object() and palloc_array() Michael Paquier
  • Re: Consistently use palloc_object() and palloc_array() Thomas Munro
  • Re: Consistently use palloc_object() and palloc_array() Michael Paquier
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Michael Paquier
  • Re: Consistently use palloc_object() and palloc_array() Michael Paquier
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Michael Paquier
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Thomas Munro
  • Re: Consistently use palloc_object() and palloc_array() Tom Lane
  • Re: Consistently use palloc_object() and palloc_array() Michael Paquier
  • Re: Consistently use palloc_object() and palloc_array() David Geier
  • Re: Consistently use palloc_object() and palloc_array() Peter Eisentraut
• show size of DSAs and dshash tables in pg_dsm_registry_allocations Nathan Bossart
  • Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations Rahila Syed
  • Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations Nathan Bossart
  • Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations Robert Haas
  • Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations Nathan Bossart
  • Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations Chao Li
  • Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations Nathan Bossart
  • Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations Rahila Syed
  • Re: show size of DSAs and dshash tables in pg_dsm_registry_allocations Nathan Bossart
• Re: oid2name : add objects file path Guillaume Lelarge
  • Re: oid2name : add objects file path David Bidoc
  • Re: oid2name : add objects file path Michael Paquier
• Remove unused struct fields Bertrand Drouvot
  • Re: Remove unused struct fields Nathan Bossart
  • Re: Remove unused struct fields Nathan Bossart
• Re: [PATCH] Better Performance for PostgreSQL with large INSERTs Filip Janus
  • Re: [PATCH] Better Performance for PostgreSQL with large INSERTs Philipp Marek
  • Re: [PATCH] Better Performance for PostgreSQL with large INSERTs Jakub Wartak
  • Re: [PATCH] Better Performance for PostgreSQL with large INSERTs Philipp Marek
• macOS - Sequoia CI task is stuck on the Postgres Github CI Nazir Bilal Yavuz
  • Re: macOS - Sequoia CI task is stuck on the Postgres Github CI Andres Freund
  • Re: macOS - Sequoia CI task is stuck on the Postgres Github CI Álvaro Herrera
  • Re: macOS - Sequoia CI task is stuck on the Postgres Github CI Andres Freund
• Question on PostgreSQL Table Partitioning – Performance of Queries That Do Not Use the Partition Key atma ram
  • Re: Question on PostgreSQL Table Partitioning – Performance of Queries That Do Not Use the Partition Key Aleksander Alekseev
• Second RewriteQuery complains about first RewriteQuery in edge case Bernice Southey
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Kirill Reshke
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Dean Rasheed
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Tom Lane
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Bernice Southey
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Bernice Southey
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Dean Rasheed
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Tom Lane
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Dean Rasheed
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Bernice Southey
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Dean Rasheed
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Tom Lane
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Dean Rasheed
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Dean Rasheed
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Tom Lane
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Dean Rasheed
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Bernice Southey
  • Re: Second RewriteQuery complains about first RewriteQuery in edge case Dean Rasheed
• Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amul Sul
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Michael Paquier
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amit Langote
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amul Sul
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Michael Paquier
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amit Langote
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Michael Paquier
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amit Langote
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amul Sul
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amit Langote
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Michael Paquier
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amul Sul
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Michael Paquier
  • Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp Amul Sul

• Earlier messages
• Later messages