pgsql-hackers  

Messages by Thread

• Small code cleanup Mark Dilger
  • Re: Small code cleanup Tom Lane
  • Re: Small code cleanup Mark Dilger
  • Re: Small code cleanup Tom Lane
  • Re: Small code cleanup Mark Dilger
• Wrong width of UNION statement Kenichiro Tanaka
  • Re: Wrong width of UNION statement Tom Lane
• [POC] Fast COPY FROM command for the table with foreign partitions Andrey Lepikhov
• Compatible defaults for LEAD/LAG Vik Fearing
  • Re: Compatible defaults for LEAD/LAG Tom Lane
  • Re: Compatible defaults for LEAD/LAG Vik Fearing
  • Re: Compatible defaults for LEAD/LAG Vik Fearing
  • Re: Compatible defaults for LEAD/LAG Tom Lane
  • Re: Compatible defaults for LEAD/LAG Pavel Stehule
  • Re: Compatible defaults for LEAD/LAG Tom Lane
  • Re: Compatible defaults for LEAD/LAG Pavel Stehule
• A wrong index choose issue because of inaccurate statistics Andy Fan
• Proposal: remove string "contains errors; unaffected changes were applied" Антон Пацев
  • Re: Proposal: remove string "contains errors; unaffected changes were applied" Justin Pryzby
• Re: pie-in-sky idea: 'sensitive' function parameters Chapman Flack
  • Re: pie-in-sky idea: 'sensitive' function parameters Robert Haas
  • Re: pie-in-sky idea: 'sensitive' function parameters Chapman Flack
  • Re: pie-in-sky idea: 'sensitive' function parameters Tom Lane
  • Re: pie-in-sky idea: 'sensitive' function parameters Robert Haas
  • Re: pie-in-sky idea: 'sensitive' function parameters Tom Lane
  • Re: pie-in-sky idea: 'sensitive' function parameters Chapman Flack
  • Re: pie-in-sky idea: 'sensitive' function parameters Robert Haas
• PG function with pseudotype "anyelement" for IN, OUT parameter shows wrong behaviour. Prabhat Sahu
  • Re: PG function with pseudotype "anyelement" for IN, OUT parameter shows wrong behaviour. Pavel Stehule
  • Re: PG function with pseudotype "anyelement" for IN, OUT parameter shows wrong behaviour. Prabhat Sahu
• proposal: possibility to read dumped table's name from file Pavel Stehule
  • Re: proposal: possibility to read dumped table's name from file Tom Lane
  • Re: proposal: possibility to read dumped table's name from file Pavel Stehule
  • Re: proposal: possibility to read dumped table's name from file David Fetter
  • Re: proposal: possibility to read dumped table's name from file Tom Lane
  • Re: proposal: possibility to read dumped table's name from file Pavel Stehule
  • Re: proposal: possibility to read dumped table's name from file Justin Pryzby
• Re: Speeding up parts of the planner using a binary search tree structure for nodes Ashutosh Bapat
• pg_dump fail to not dump public schema orders Adrien Nayrat
  • Re: pg_dump fail to not dump public schema orders David G. Johnston
  • Re: pg_dump fail to not dump public schema orders Tom Lane
  • Re: pg_dump fail to not dump public schema orders Adrien Nayrat
  • Re: pg_dump fail to not dump public schema orders David G. Johnston
• Does PG server process keep backend info brajmohan saxena
• RE: archive status ".ready" files may be created too early matsumura....@fujitsu.com
  • Re: archive status ".ready" files may be created too early Bossart, Nathan
• feature idea: use index when checking for NULLs before SET NOT NULL John Bachir
  • Re: feature idea: use index when checking for NULLs before SET NOT NULL Sergei Kornilov
  • Re: feature idea: use index when checking for NULLs before SET NOT NULL Oleksandr Shulgin
  • Re: feature idea: use index when checking for NULLs before SET NOT NULL Komяpa
  • Re: feature idea: use index when checking for NULLs before SET NOT NULL John Bachir
  • Re: feature idea: use index when checking for NULLs before SET NOT NULL Sergei Kornilov
  • Re: feature idea: use index when checking for NULLs before SET NOT NULL John Bachir
  • Re: feature idea: use index when checking for NULLs before SET NOT NULL Justin Pryzby
  • Re: feature idea: use index when checking for NULLs before SET NOT NULL John Bachir
• OpenSSL 3.0.0 compatibility Daniel Gustafsson
  • Re: OpenSSL 3.0.0 compatibility Laurenz Albe
  • Re: OpenSSL 3.0.0 compatibility Daniel Gustafsson
  • Re: OpenSSL 3.0.0 compatibility Peter Eisentraut
  • Re: OpenSSL 3.0.0 compatibility Daniel Gustafsson
  • Re: OpenSSL 3.0.0 compatibility Peter Eisentraut
  • Re: OpenSSL 3.0.0 compatibility Michael Paquier
  • Re: OpenSSL 3.0.0 compatibility Peter Eisentraut
  • Re: OpenSSL 3.0.0 compatibility Daniel Gustafsson
  • Re: OpenSSL 3.0.0 compatibility Andrew Dunstan
  • Re: OpenSSL 3.0.0 compatibility Peter Eisentraut
  • Re: OpenSSL 3.0.0 compatibility Andrew Dunstan
  • Re: OpenSSL 3.0.0 compatibility Daniel Gustafsson
  • Re: OpenSSL 3.0.0 compatibility Andrew Dunstan
  • Re: OpenSSL 3.0.0 compatibility Tom Lane
• Conflict of implicit collations doesn't propagate out of subqueries Markus Winand
  • Re: Conflict of implicit collations doesn't propagate out of subqueries Tom Lane
  • Re: Conflict of implicit collations doesn't propagate out of subqueries Markus Winand
• Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() Mark Dilger
• Incorrect comment in be-secure-openssl.c Daniel Gustafsson
  • Re: Incorrect comment in be-secure-openssl.c Michael Paquier
  • Re: Incorrect comment in be-secure-openssl.c Michael Paquier
  • Re: Incorrect comment in be-secure-openssl.c Robert Haas
  • Re: Incorrect comment in be-secure-openssl.c Michael Paquier
  • Re: Incorrect comment in be-secure-openssl.c Daniel Gustafsson
• Read access for pg_monitor to pg_replication_origin_status view Martín Marqués
  • Re: Read access for pg_monitor to pg_replication_origin_status view Martín Marqués
  • Re: Read access for pg_monitor to pg_replication_origin_status view Michael Paquier
  • Re: Read access for pg_monitor to pg_replication_origin_status view Martín Marqués
  • Re: Read access for pg_monitor to pg_replication_origin_status view Martín Marqués
• Re: Resolving the python 2 -> python 3 mess Noah Misch
  • Re: Resolving the python 2 -> python 3 mess Tom Lane
• SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Vladimir Sitnikov
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Michael Paquier
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Kyotaro Horiguchi
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Michael Paquier
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Kyotaro Horiguchi
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Vladimir Sitnikov
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Kyotaro Horiguchi
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Dave Cramer
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Kyotaro Horiguchi
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Michael Paquier
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Kyotaro Horiguchi
  • Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762 Masahiko Sawada
• future pg+llvm compilation is broken Fabien COELHO
  • Re: future pg+llvm compilation is broken Justin Pryzby
  • Re: future pg+llvm compilation is broken Fabien COELHO
• Re: BufFileRead() error signalling Alvaro Herrera
  • Re: BufFileRead() error signalling Michael Paquier
  • Re: BufFileRead() error signalling Alvaro Herrera
  • Re: BufFileRead() error signalling Robert Haas
  • Re: BufFileRead() error signalling Thomas Munro
  • Re: BufFileRead() error signalling Alvaro Herrera
• Explain Analyze (Rollback off) Suggestion David G. Johnston
  • Re: Explain Analyze (Rollback off) Suggestion Robert Haas
  • Re: Explain Analyze (Rollback off) Suggestion Tom Lane
  • Re: Explain Analyze (Rollback off) Suggestion David G. Johnston
  • Re: Explain Analyze (Rollback off) Suggestion Robert Haas
  • Re: Explain Analyze (Rollback off) Suggestion David G. Johnston
  • Re: Explain Analyze (Rollback off) Suggestion Tom Lane
  • Re: Explain Analyze (Rollback off) Suggestion David G. Johnston
• Re: New 'pg' consolidated metacommand patch David G. Johnston
  • Re: New 'pg' consolidated metacommand patch Mark Dilger
  • Re: New 'pg' consolidated metacommand patch Dave Page
  • Re: New 'pg' consolidated metacommand patch Dave Page
  • Re: New 'pg' consolidated metacommand patch Mark Dilger
  • Re: New 'pg' consolidated metacommand patch Magnus Hagander
  • Re: New 'pg' consolidated metacommand patch Mark Dilger
  • Re: New 'pg' consolidated metacommand patch Christoph Moench-Tegeder
  • Re: New 'pg' consolidated metacommand patch Robert Haas
  • Re: New 'pg' consolidated metacommand patch Robert Haas
  • Re: New 'pg' consolidated metacommand patch Isaac Morland
  • Re: New 'pg' consolidated metacommand patch Peter Eisentraut
  • Re: New 'pg' consolidated metacommand patch Isaac Morland
  • Re: New 'pg' consolidated metacommand patch Christopher Browne
  • Re: New 'pg' consolidated metacommand patch Mark Dilger
  • Re: New 'pg' consolidated metacommand patch Peter Eisentraut
  • Re: New 'pg' consolidated metacommand patch Robert Haas
• PG_CRON logging Rajin Raj
• max_slot_wal_keep_size comment in postgresql.conf Jeff Janes
  • Re: max_slot_wal_keep_size comment in postgresql.conf Kyotaro Horiguchi
  • Re: max_slot_wal_keep_size comment in postgresql.conf Isaac Morland
  • Re: max_slot_wal_keep_size comment in postgresql.conf Kyotaro Horiguchi
  • Re: max_slot_wal_keep_size comment in postgresql.conf Michael Paquier
  • Re: max_slot_wal_keep_size comment in postgresql.conf Fujii Masao
  • Re: max_slot_wal_keep_size comment in postgresql.conf Kyotaro Horiguchi
  • Re: max_slot_wal_keep_size comment in postgresql.conf Michael Paquier
  • Re: max_slot_wal_keep_size comment in postgresql.conf Michael Paquier
  • Re: max_slot_wal_keep_size comment in postgresql.conf Kyotaro Horiguchi
• Make the qual cost on index Filter slightly higher than qual cost on index Cond. Andy Fan
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Ashutosh Bapat
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Andy Fan
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Andy Fan
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Ashutosh Bapat
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Andy Fan
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Tomas Vondra
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Tom Lane
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Andy Fan
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Andy Fan
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Andy Fan
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Ashutosh Bapat
  • Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond. Andy Fan
• Re: SyncRepGetSyncStandbysPriority() vs. SIGHUP Noah Misch
• Why don't you to document pg_shmem_allocations view's name list? Masahiro Ikeda
  • Re: Why don't you to document pg_shmem_allocations view's name list? Michael Paquier
  • Re: Why don't you to document pg_shmem_allocations view's name list? Masahiro Ikeda
• New Feature Request Bert Scalzo
  • Re: New Feature Request Bruce Momjian
  • Re: New Feature Request Michael Paquier
  • Re: New Feature Request Tom Lane
  • Re: New Feature Request Tomas Vondra
  • Re: New Feature Request Konstantin Knizhnik
  • Re: New Feature Request Bert Scalzo
  • Re: New Feature Request Peter Eisentraut
• hash join error improvement (old) Alvaro Herrera
  • Re: hash join error improvement (old) Tom Lane
  • Re: hash join error improvement (old) Alvaro Herrera
  • Re: hash join error improvement (old) Tom Lane
  • Re: hash join error improvement (old) Alvaro Herrera
  • Re: hash join error improvement (old) Alvaro Herrera
  • Re: hash join error improvement (old) Tom Lane
  • Re: hash join error improvement (old) Thomas Munro
• Re: SimpleLruTruncate() mutual exclusion Noah Misch
• what can go in root.crt ? Chapman Flack
  • Re: what can go in root.crt ? Chapman Flack
  • Re: what can go in root.crt ? Bruce Momjian
  • Re: what can go in root.crt ? Chapman Flack
  • Re: what can go in root.crt ? Andrew Dunstan
  • Re: what can go in root.crt ? Chapman Flack
  • Re: what can go in root.crt ? Laurenz Albe
  • Re: what can go in root.crt ? Bruce Momjian
  • Re: what can go in root.crt ? Chapman Flack
  • Re: what can go in root.crt ? Isaac Morland
  • Re: what can go in root.crt ? Chapman Flack
  • Re: what can go in root.crt ? Alvaro Herrera
  • Re: what can go in root.crt ? Isaac Morland
  • Re: what can go in root.crt ? Chapman Flack
  • Re: what can go in root.crt ? Craig Ringer
  • Re: what can go in root.crt ? Chapman Flack
• Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Peter Eisentraut
  • Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Tom Lane
  • Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch David Fetter
  • Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Vik Fearing
  • Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Tom Lane
  • Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Vik Fearing

• Earlier messages