Mailing lists [pgsql-hackers]

27 July 2019

• 00:20   Re: proposal: make NOTIFY list de-duplication optional Tom Lane
• 00:24   Re: TopoSort() fix Tom Lane
• 00:52   RE: [PATCH] Fix Proposal - Deadlock Issue in Single User Mode When IOFailure Occurs Chengchao Yu
• 01:15   Re: Duplicated LSN in ReorderBuffer Andres Freund
• 01:37   warning on reload for PGC_POSTMASTER, guc.c duplication, ... Andres Freund
• 01:58   Re: Patch for SortSupport implementation on inet/cdir Peter Geoghegan
• 02:25   Re: Patch for SortSupport implementation on inet/cdir Peter Geoghegan
• 02:27   Re: POC: Cleaning up orphaned files using undo logs Andres Freund
• 02:59   Re: SegFault on 9.6.14 Thomas Munro
• 05:12   Re: LLVM compile failing in seawasp Thomas Munro
• 05:28   Re: proposal: type info support functions for functions that use"any" type Pavel Stehule
• 05:44   Re: proposal: type info support functions for functions that use"any" type Pavel Stehule
• 05:58   Re: SegFault on 9.6.14 Amit Kapila
• 06:22   Re: Initdb failure Peter Eisentraut
• 06:26   Re: [HACKERS] WAL logging problem in 9.4.3? Noah Misch
• 06:42   Re: pg_upgrade version checking questions Peter Eisentraut
• 07:05   Re: LLVM compile failing in seawasp Fabien COELHO
• 07:12   Re: LLVM compile failing in seawasp Thomas Munro
• 09:40   Re: LLVM compile failing in seawasp Thomas Munro
• 09:44   Re: Add parallelism and glibc dependent only options to reindexdb Julien Rouhaud
• 10:40   Re: Built-in connection pooler Dave Cramer
• 11:49   Re: Built-in connection pooler Thomas Munro
• 13:27   Re: Add parallelism and glibc dependent only options to reindexdb Michael Paquier
• 16:46   Testing LISTEN/NOTIFY more effectively Tom Lane
• 17:02   Re: fsync error handling in pg_receivewal, pg_recvlogical Sehrope Sarkuni
• 17:06   Re: fsync error handling in pg_receivewal, pg_recvlogical Sehrope Sarkuni
• 17:31   Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) Bruce Momjian
• 17:33   Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) Bruce Momjian
• 17:38   Re: [PATCH] get rid of StdRdOptions, use individual binaryreloptions representation for each relation kind instead Tomas Vondra
• 17:42   Re: Testing LISTEN/NOTIFY more effectively Andres Freund
• 17:53   Re: Testing LISTEN/NOTIFY more effectively Tom Lane
• 18:15   Re: Testing LISTEN/NOTIFY more effectively Tom Lane
• 18:23   Re: Add parallelism and glibc dependent only options to reindexdb Julien Rouhaud
• 18:29   Adding column "mem_usage" to view pg_prepared_statements Daniel Migowski
• 18:55   Re: Testing LISTEN/NOTIFY more effectively Andres Freund
• 19:02   Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) Sehrope Sarkuni
• 19:08   Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) Joe Conway
• 19:11   Re: Adding column "mem_usage" to view pg_prepared_statements Andres Freund
• 19:15   tap tests driving the database via psql Andres Freund
• 19:39   Re: Testing LISTEN/NOTIFY more effectively Tom Lane
• 20:19   Re: Testing LISTEN/NOTIFY more effectively Andres Freund
• 20:32   Re: tap tests driving the database via psql David Fetter
• 20:34   Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) Bruce Momjian
• 20:53   Re: Testing LISTEN/NOTIFY more effectively Peter Geoghegan
• 21:14   Re: tap tests driving the database via psql Andres Freund
• 21:48   Re: tap tests driving the database via psql Andrew Dunstan
• 22:19   Re: idea: log_statement_sample_rate - bottom limit for sampling Tomas Vondra
• 22:20   Re: Testing LISTEN/NOTIFY more effectively Tom Lane
• 22:37   Re: tap tests driving the database via psql Andres Freund
• 22:48   Re: Testing LISTEN/NOTIFY more effectively Tom Lane
• 22:57   Re: tap tests driving the database via psql Andrew Dunstan
• 23:01   Re: tap tests driving the database via psql Andres Freund
• 23:18   Re: Testing LISTEN/NOTIFY more effectively Andres Freund
• 23:27   Re: Testing LISTEN/NOTIFY more effectively Tom Lane
• 23:45   Re: Testing LISTEN/NOTIFY more effectively Tom Lane
• 23:51   Re: Testing LISTEN/NOTIFY more effectively Andres Freund