pgsql-hackers  

Messages by Thread

• • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] vignesh C
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] vignesh C
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Amit Kapila
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Noah Misch
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Noah Misch
  • Re: Adding REPACK [concurrently] Tom Lane
  • Re: Adding REPACK [concurrently] Srinath Reddy Sadipiralla
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] John Naylor
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Srinath Reddy Sadipiralla
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Tomas Vondra
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Tom Lane
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Amit Kapila
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Antonin Houska
  • RE: Adding REPACK [concurrently] Hayato Kuroda (Fujitsu)
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Amit Kapila
  • Re: Adding REPACK [concurrently] Robert Treat
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Amit Kapila
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Amit Kapila
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Robert Treat
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Andres Freund
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Alexander Lakhin
  • Re: Adding REPACK [concurrently] Justin Pryzby
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Chao Li
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Antonin Houska
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Tom Lane
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Tom Lane
  • Re: Adding REPACK [concurrently] Alvaro Herrera
  • Re: Adding REPACK [concurrently] Mihail Nikalayeu
  • Re: Adding REPACK [concurrently] Andres Freund
• Re: Add tab completion for SERVER and CONNECTION keywords in psql Yamaguchi Atsuo
  • Re: Add tab completion for SERVER and CONNECTION keywords in psql Masahiko Sawada
• Re: Fixes inconsistent behavior in vacuum when it processes multiple relations Nathan Bossart
  • Re: Fixes inconsistent behavior in vacuum when it processes multiple relations Michael Paquier
  • Re: Fixes inconsistent behavior in vacuum when it processes multiple relations Nathan Bossart
  • Re: Fixes inconsistent behavior in vacuum when it processes multiple relations Michael Paquier
  • Re: Fixes inconsistent behavior in vacuum when it processes multiple relations Nathan Bossart
  • Re: Fixes inconsistent behavior in vacuum when it processes multiple relations Nathan Bossart
  • Re: Fixes inconsistent behavior in vacuum when it processes multiple relations Nathan Bossart
• Re: pg_stat_replication.*_lag sometimes shows NULL during active replication Fujii Masao
  • Re: pg_stat_replication.*_lag sometimes shows NULL during active replication Fujii Masao
  • Re: pg_stat_replication.*_lag sometimes shows NULL during active replication Shinya Kato
  • Re: pg_stat_replication.*_lag sometimes shows NULL during active replication Fujii Masao
• Re: Don't synchronously wait for already-in-progress IO in read stream Andres Freund
  • Re: Don't synchronously wait for already-in-progress IO in read stream Melanie Plageman
  • Re: Don't synchronously wait for already-in-progress IO in read stream Andres Freund
  • Re: Don't synchronously wait for already-in-progress IO in read stream Melanie Plageman
  • Re: Don't synchronously wait for already-in-progress IO in read stream Andres Freund
  • Re: Don't synchronously wait for already-in-progress IO in read stream Andres Freund
  • Re: Don't synchronously wait for already-in-progress IO in read stream Melanie Plageman
  • Re: Don't synchronously wait for already-in-progress IO in read stream Andres Freund
  • Re: Don't synchronously wait for already-in-progress IO in read stream Melanie Plageman
  • Re: Don't synchronously wait for already-in-progress IO in read stream Andres Freund
  • Re: Don't synchronously wait for already-in-progress IO in read stream Alexander Lakhin
  • Re: Don't synchronously wait for already-in-progress IO in read stream Melanie Plageman
  • Re: Don't synchronously wait for already-in-progress IO in read stream Melanie Plageman
  • Re: Don't synchronously wait for already-in-progress IO in read stream Andres Freund
  • Re: Don't synchronously wait for already-in-progress IO in read stream Melanie Plageman
  • Re: Don't synchronously wait for already-in-progress IO in read stream Andres Freund
  • Re: Don't synchronously wait for already-in-progress IO in read stream Melanie Plageman
• BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt Yura Sokolov
  • Re: BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt Andres Freund
  • Re: BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt Yura Sokolov
  • Re: BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt Yura Sokolov
  • Re: BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt Yura Sokolov
  • Re: BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt Michael Paquier
  • Re: BM_IO_ERROR flag is lost in TerminateBufferIO due to order of operations in UnlockBufHdrExt Yura Sokolov
• Re: SQL-level pg_datum_image_equal Matthias van de Meent
  • Re: SQL-level pg_datum_image_equal David Rowley
  • Re: SQL-level pg_datum_image_equal Matthias van de Meent
  • Re: SQL-level pg_datum_image_equal David Rowley
  • Re: SQL-level pg_datum_image_equal Matthias van de Meent
  • Re: SQL-level pg_datum_image_equal Tom Lane
  • Re: SQL-level pg_datum_image_equal Matthias van de Meent
• Re: Use CASEFOLD() internally rather than LOWER() Mark Dilger
  • Re: Use CASEFOLD() internally rather than LOWER() Jeff Davis
  • Re: Use CASEFOLD() internally rather than LOWER() Mark Dilger
• Re: Test timings are increasing too fast for cfbot Tomas Vondra
  • Re: Test timings are increasing too fast for cfbot Andres Freund
  • Re: Test timings are increasing too fast for cfbot David Rowley
  • Re: Test timings are increasing too fast for cfbot Andres Freund
  • Re: Test timings are increasing too fast for cfbot Andres Freund
• Re: Proposal to allow setting cursor options on Portals Dave Cramer
  • Re: Proposal to allow setting cursor options on Portals Jelte Fennema-Nio
• Re: [PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch Andrew Jackson
  • Re: [PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch Jacob Champion
• Re: COMMENTS are not being copied in CREATE TABLE LIKE Carlos Alves
  • Re: COMMENTS are not being copied in CREATE TABLE LIKE Carlos Alves
  • Re: COMMENTS are not being copied in CREATE TABLE LIKE Jim Jones
• Re: [PATCH] no table rewrite when set column type to constrained domain Viktor Holmberg
• Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
  • Re: Exit walsender before confirming remote flush in logical replication Vitaly Davydov
  • Re: Exit walsender before confirming remote flush in logical replication Alexander Korotkov
  • Re: Exit walsender before confirming remote flush in logical replication Andrey Silitskiy
  • Re: Exit walsender before confirming remote flush in logical replication Andrey Silitskiy
  • Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
  • Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
  • Re: Exit walsender before confirming remote flush in logical replication Andrey Silitskiy
  • Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
  • Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
  • Re: Exit walsender before confirming remote flush in logical replication Andres Freund
  • Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
  • Re: Exit walsender before confirming remote flush in logical replication Chao Li
  • Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
  • Re: Exit walsender before confirming remote flush in logical replication Chao Li
  • Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
  • Re: Exit walsender before confirming remote flush in logical replication Evgeny Voropaev
  • Re: Exit walsender before confirming remote flush in logical replication Fujii Masao
• Re: Two issues leading to discrepancies in FSM data on the standby server Andrey Borodin
  • Re: Two issues leading to discrepancies in FSM data on the standby server Alexey Makhmutov
  • Re: Two issues leading to discrepancies in FSM data on the standby server Melanie Plageman
  • Re: Two issues leading to discrepancies in FSM data on the standby server Alexander Korotkov
  • Re: Two issues leading to discrepancies in FSM data on the standby server Melanie Plageman
• Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c) lakshmi
  • Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c) Ranier Vilela
• Re: Lowering the default wal_blocksize to 4K John Naylor
  • Re: Lowering the default wal_blocksize to 4K Andres Freund
• Re: [PATCH] Precompute string lengths in PerformRadiusTransaction zengman
• Re: access numeric data in module Ed Behn
• Re: Stack-based tracking of per-node WAL/buffer usage Heikki Linnakangas
  • Re: Stack-based tracking of per-node WAL/buffer usage Lukas Fittl
  • Re: Stack-based tracking of per-node WAL/buffer usage Andres Freund
  • Re: Stack-based tracking of per-node WAL/buffer usage Andres Freund
  • Re: Stack-based tracking of per-node WAL/buffer usage Andres Freund
  • Re: Stack-based tracking of per-node WAL/buffer usage Andres Freund
  • Re: Stack-based tracking of per-node WAL/buffer usage Zsolt Parragi
  • Re: Stack-based tracking of per-node WAL/buffer usage Lukas Fittl
  • Re: Stack-based tracking of per-node WAL/buffer usage Andres Freund
  • Re: Stack-based tracking of per-node WAL/buffer usage Lukas Fittl
  • Re: Stack-based tracking of per-node WAL/buffer usage Andres Freund
  • Re: Stack-based tracking of per-node WAL/buffer usage Heikki Linnakangas
  • Re: Stack-based tracking of per-node WAL/buffer usage Lukas Fittl
• Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables Jim Jones
  • Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables Zsolt Parragi
  • Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables Jim Jones
  • Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables Chao Li
  • Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables Antonin Houska
  • Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables Jim Jones
  • Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables Jim Jones
  • Re: VACUUM FULL, CLUSTER, and REPACK block on other sessions' temp tables Jim Jones

• Later messages