Mailing lists [pgsql-hackers]

4 April 2018

• 00:01   Re: Comment update in BuildTupleFromCStrings() Bruce Momjian
• 00:29   Re: pgsql: Validate page level checksums in base backups Tom Lane
• 00:29   Re: pgsql: Validate page level checksums in base backups Tom Lane
• 00:45   Re: pgsql: Validate page level checksums in base backups Peter Geoghegan
• 00:45   Re: pgsql: Validate page level checksums in base backups Peter Geoghegan
• 00:48   Re: pgsql: Validate page level checksums in base backups Magnus Hagander
• 00:48   Re: pgsql: Validate page level checksums in base backups Magnus Hagander
• 00:55   Re: pgsql: Validate page level checksums in base backups Tom Lane
• 00:55   Re: pgsql: Validate page level checksums in base backups Tom Lane
• 00:56   Re: Optimize Arm64 crc32c implementation in Postgresql Daniel Gustafsson
• 01:11   Re: Foreign keys and partitioned tables Alvaro Herrera
• 01:46   open/lseek overhead with many partitions (including with "fasterpartitioning pruning") Justin Pryzby
• 01:50   Re: WIP: BRIN multi-range indexes Tomas Vondra
• 02:47   Re: Foreign keys and partitioned tables Alvaro Herrera
• 02:48   Re: pgsql: Validate page level checksums in base backups Michael Banck
• 02:48   Re: pgsql: Validate page level checksums in base backups Michael Banck
• 03:17   Re: pgsql: Validate page level checksums in base backups David Steele
• 03:17   Re: pgsql: Validate page level checksums in base backups David Steele
• 03:47   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Robert Haas
• 03:47   Re: [HACKERS] path toward faster partition pruning David Rowley
• 03:49   Re: Foreign keys and partitioned tables Alvaro Herrera
• 04:05   Re: [HACKERS] logical decoding of two-phase transactions Andrew Dunstan
• 04:07   Re: Optimize Arm64 crc32c implementation in Postgresql Thomas Munro
• 04:11   Re: Online enabling of checksums Tomas Vondra
• 05:01   Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key Andres Freund
• 05:22   Re: [HACKERS] path toward faster partition pruning David Rowley
• 05:59   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Thomas Munro
• 06:26   Re: open/lseek overhead with many partitions (including with "fasterpartitioning pruning") Amit Langote
• 06:27   Re: open/lseek overhead with many partitions (including with "fasterpartitioning pruning") David Rowley
• 06:31   Re: open/lseek overhead with many partitions (including with "fasterpartitioning pruning") Amit Langote
• 06:37   Re: open/lseek overhead with many partitions (including with "fasterpartitioning pruning") David Rowley
• 06:52   Re: Running Installcheck remotely Michael Paquier
• 06:56   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Bruce Momjian
• 07:13   Re: [HACKERS] path toward faster partition pruning David Rowley
• 07:54   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Thomas Munro
• 08:05   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Bruce Momjian
• 08:10   Re: [HACKERS] Runtime Partition Pruning David Rowley
• 08:14   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Bruce Momjian
• 08:27   Re: [HACKERS] Runtime Partition Pruning David Rowley
• 08:31   Re: [PATCH] Logical decoding of TRUNCATE Peter Eisentraut
• 08:31   Re: [HACKERS] Runtime Partition Pruning David Rowley
• 08:40   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Craig Ringer
• 08:44   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Thomas Munro
• 08:47   Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key Amit Kapila
• 09:08   Re: WIP: Covering + unique indexes. Peter Geoghegan
• 09:21   Re: [HACKERS] path toward faster partition pruning David Rowley
• 09:38   Re: Comment update in BuildTupleFromCStrings() Ashutosh Bapat
• 10:00   Re: [HACKERS] path toward faster partition pruning Tom Lane
• 10:03   Re: [HACKERS] path toward faster partition pruning David Rowley
• 10:48   Re: [HACKERS] Runtime Partition Pruning Beena Emerson
• 11:29   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Thomas Munro
• 11:42   Re: [HACKERS] path toward faster partition pruning Amit Langote
• 12:00   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Craig Ringer
• 12:27   Re: [HACKERS] Runtime Partition Pruning Amit Langote
• 13:03   Re: [PATCH] Logical decoding of TRUNCATE Simon Riggs
• 13:04   Re: [HACKERS] Runtime Partition Pruning David Rowley
• 13:04   Re: [HACKERS] path toward faster partition pruning Amit Langote
• 13:06   Re: [HACKERS] path toward faster partition pruning David Rowley
• 13:07   Re: [HACKERS] path toward faster partition pruning David Rowley
• 13:20   Re: [HACKERS] Runtime Partition Pruning Amit Langote
• 13:32   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Thomas Munro
• 13:51   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Craig Ringer
• 14:26   Re: Problem while setting the fpw with SIGHUP Kyotaro HORIGUCHI
• 14:35   Re: Optimize Arm64 crc32c implementation in Postgresql Heikki Linnakangas
• 14:54   Postgres stucks in deadlock detection Konstantin Knizhnik
• 15:23   Re: Optimize Arm64 crc32c implementation in Postgresql Heikki Linnakangas
• 15:38   Re: [HACKERS] GUC for cleanup indexes threshold. Alexander Korotkov
• 15:38   Re: pgsql: Validate page level checksums in base backups Magnus Hagander
• 15:38   Re: pgsql: Validate page level checksums in base backups Magnus Hagander
• 15:52   Re: json(b)_to_tsvector with numeric values Teodor Sigaev
• 15:53   Re: [HACKERS] logical decoding of two-phase transactions Nikhil Sontakke
• 16:31   Re: [HACKERS] Add support for tuple routing to foreign partitions Etsuro Fujita
• 17:13   Re: Optimize Arm64 crc32c implementation in Postgresql Thomas Munro
• 17:21   Re: Optimize Arm64 crc32c implementation in Postgresql Heikki Linnakangas
• 17:27   Re: json(b)_to_tsvector with numeric values Dmitry Dolgov
• 17:47   Re: Optimize Arm64 crc32c implementation in Postgresql Thomas Munro
• 17:58   Re: [HACKERS] logical decoding of two-phase transactions Nikhil Sontakke
• 18:00   Re: Optimize Arm64 crc32c implementation in Postgresql Thomas Munro
• 18:18   Re: Add default role 'pg_access_server_files' Stephen Frost
• 18:19   Re: pgsql: Validate page level checksums in base backups Michael Banck
• 18:19   Re: pgsql: Validate page level checksums in base backups Michael Banck
• 18:23   Re: Online enabling of checksums Michael Banck
• 18:46   Re: [HACKERS] MERGE SQL Statement for PG11 Jesper Pedersen
• 19:07   Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors Marina Polyakova
• 19:29   Re: [HACKERS] path toward faster partition pruning David Rowley
• 19:37   Re: Foreign keys and partitioned tables Peter Eisentraut
• 19:47   Re: pgsql: Validate page level checksums in base backups Alvaro Herrera
• 19:49   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Bruce Momjian
• 19:53   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Bruce Momjian
• 20:00   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Craig Ringer
• 20:09   Re: json(b)_to_tsvector with numeric values Teodor Sigaev
• 20:09   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Craig Ringer
• 20:25   Re: Rewrite of pg_dump TAP tests Stephen Frost
• 20:25   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Bruce Momjian
• 20:33   Re: new function for tsquery creartion Dmitry Ivanov
• 20:42   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Craig Ringer
• 20:49   Re: new function for tsquery creartion Aleksandr Parfenov
• 20:56   Re: Postgres stucks in deadlock detection Teodor Sigaev
• 21:13   Add support for printing/reading MergeAction nodes Marina Polyakova
• 21:23   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Antonis Iliopoulos
• 21:23   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Craig Ringer
• 21:45   Re: [HACKERS] path toward faster partition pruning Jesper Pedersen
• 22:19   Re: Add support for printing/reading MergeAction nodes Tom Lane
• 22:22   Re: [HACKERS] logical decoding of two-phase transactions Tomas Vondra
• 22:30   Re: [HACKERS] GUC for cleanup indexes threshold. Teodor Sigaev
• 22:56   Re: Foreign keys and partitioned tables Alvaro Herrera
• 22:57   Re: Add support for printing/reading MergeAction nodes Simon Riggs
• 23:07   Re: Add support for printing/reading MergeAction nodes Simon Riggs
• 23:08   Re: Add support for printing/reading MergeAction nodes Tom Lane
• 23:10   Re: pgsql: New files for MERGE Andres Freund
• 23:10   Re: pgsql: New files for MERGE Andres Freund
• 23:21   Re: Foreign keys and partitioned tables Alvaro Herrera
• 23:23   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Gasper Zejn
• 23:25   Re: pgsql: Validate page level checksums in base backups Magnus Hagander
• 23:31   Re: [HACKERS] Runtime Partition Pruning Jesper Pedersen
• 23:45   Re: some last patches breaks plan cache Tomas Vondra
• 23:51   Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS Bruce Momjian
• 23:51   Re: Add support for printing/reading MergeAction nodes Tom Lane
• 23:53   Re: SET TRANSACTION in PL/pgSQL Tomas Vondra
• 23:54   Re: some last patches breaks plan cache Tom Lane