Postgresql General Discussion

• Thread Index

• My postgres is not logging anymore
  • From: Maila Fatticcioni
• Select query regarding info
  • From: Yogesh. Sharma
• Re: pg_xlog on a hot_stanby slave
  • From: Xavier 12
• Re: pg_xlog on a hot_stanby slave
  • From: Sameer Kumar
• Re: Momentary Delay
  • From: Bill Moran
• writable cte triggers reverse order
  • From: Миша Тюрин
• Re: pg_class.reltuples VS pg_stat_all_tables.n_live_tup for estimation of table
  • From: William Dunn
• Re: pg_class.reltuples VS pg_stat_all_tables.n_live_tup for estimation of table
  • From: Tom Lane
• pg_class.reltuples VS pg_stat_all_tables.n_live_tup for estimation of table
  • From: William Dunn
• Index Advice in PG
  • From: Jony Cohen
• Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux
  • From: Tom Lane
• Re: serialization failure why?
  • From: Filipe Pina
• pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux
  • From: Douglas Stetner
• Re: serialization failure why?
  • From: Filipe Pina
• Re: Momentary Delay
  • From: Anderson Valadares
• Re: serialization failure why?
  • From: Kevin Grittner
• Re: serialization failure why?
  • From: Filipe Pina
• Re: Test for char errors
  • From: Michael Paquier
• Test for char errors
  • From: 夏高
• Re: pg_xlog on a hot_stanby slave
  • From: Xavier 12
• Re: pg_xlog on a hot_stanby slave
  • From: Xavier 12
• Re: pg_xlog on a hot_stanby slave
  • From: Xavier 12
• Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux
  • From: Albe Laurenz
• Feature Request: bigtsvector
  • From: CPT
• Re: serialization failure why?
  • From: Bill Moran
• Re: pg_xlog on a hot_stanby slave
  • From: Sameer Kumar
• pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux
  • From: Douglas Stetner
• Re: pg_xlog on a hot_stanby slave
  • From: Venkata Balaji N
• Issues trying to run bdr_init_copy with new setup
  • From: Jorge Torralba
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: pg_xlog on a hot_stanby slave
  • From: Guillaume Lelarge
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: pg_upgrade problem
  • From: Jerry Sievers
• Re: pg_upgrade problem
  • From: Melvin Davidson
• pg_upgrade problem
  • From: Melvin Davidson
• Re: pg_xlog on a hot_stanby slave
  • From: Xavier 12
• serialization failure why?
  • From: Filipe Pina
• Re: RegisterBackgroundWorker does not actually start a bg worker process in 9.4.4
  • From: John Lumby
• Re: FW: PostgreSQL and iptables
  • From: mephysto
• Re: Compression function
  • From: Bill Moran
• Re: BDR: Can a node live alone after being detached
  • From: Craig Ringer
• Re: BDR: Can a node live alone after being detached
  • From: Sylvain MARECHAL
• Re: pg_xlog on a hot_stanby slave
  • From: Guillaume Lelarge
• pg_xlog on a hot_stanby slave
  • From: Xavier 12
• Re: Compression function
  • From: Albe Laurenz
• Compression function
  • From: "Leonardo M. Ramé"
• Re: BDR: Can a node live alone after being detached
  • From: Craig Ringer
• Re: Momentary Delay
  • From: Bill Moran
• Re: Momentary Delay
  • From: Anderson Valadares
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: localtime ?
  • From: Adrian Klaver
• Re: localtime ?
  • From: James Cloos
• Re: localtime ?
  • From: James Cloos
• Re: localtime ?
  • From: Oliver Elphick
• Re: localtime ?
  • From: Adrian Klaver
• RegisterBackgroundWorker does not actually start a bg worker process in 9.4.4
  • From: John Lumby
• Re: Row count estimation bug in BETWEEN?
  • From: Yaroslav
• Re: localtime ?
  • From: James Cloos
• Re: localtime ?
  • From: Adrian Klaver
• Re: localtime ?
  • From: James Cloos
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: pg_last_xact_replay_timestamp lies
  • From: Anton
• BDR: Can a node live alone after being detached
  • From: Sylvain MARECHAL
• Re: pg_last_xact_replay_timestamp lies
  • From: Michael Paquier
• Re: pg_last_xact_replay_timestamp lies
  • From: Anton Bushmelev
• Re: pg_last_xact_replay_timestamp lies
  • From: Michael Paquier
• pg_last_xact_replay_timestamp lies
  • From: Anton Bushmelev
• Re: Row count estimation bug in BETWEEN?
  • From: Tom Lane
• Re: Row count estimation bug in BETWEEN?
  • From: Yaroslav
• Re: Row count estimation bug in BETWEEN?
  • From: Yaroslav
• Re: Row count estimation bug in BETWEEN?
  • From: Tom Lane
• Re: FW: PostgreSQL and iptables
  • From: José María Terry Jiménez
• Row count estimation bug in BETWEEN?
  • From: Щекин Ярослав
• Re: FW: PostgreSQL and iptables
  • From: Mephysto
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Steve Kehlet
• Re: Momentary Delay
  • From: Bill Moran
• Re: [PERFORM] pg bouncer issue what does sv_used column means
  • From: ktm@xxxxxxxx
• Re: [PERFORM] pg bouncer issue what does sv_used column means
  • From: Andrew Dunstan
• Re: [PERFORM] pg bouncer issue what does sv_used column means
  • From: Sheena, Prabhjot
• Re: [PERFORM] pg bouncer issue what does sv_used column means
  • From: Xenofon Papadopoulos
• Re: pg bouncer issue what does sv_used column means
  • From: Glyn Astill
• Re: double precision[] storage space questions
  • From: greg
• log_statement = 'mod' does not log all data modifying statements
  • From: Jack Christensen
• [PERFORM] pg bouncer issue what does sv_used column means
  • From: Sheena, Prabhjot
• Re: double precision[] storage space questions
  • From: Francisco Olarte
• Re: Suggested (or existing) way to parse currency into numeric?
  • From: David G. Johnston
• Re: Suggested (or existing) way to parse currency into numeric?
  • From: Adrian Klaver
• Re: Suggested (or existing) way to parse currency into numeric?
  • From: David G. Johnston
• Re: Suggested (or existing) way to parse currency into numeric?
  • From: Adrian Klaver
• Suggested (or existing) way to parse currency into numeric?
  • From: David G. Johnston
• Re: cached row type not invalidated after DDL change
  • From: Adrian Klaver
• BDR: Node join and leave questions
  • From: sym39
• Re: database-level lockdown
  • From: Filipe Pina
• cached row type not invalidated after DDL change
  • From: Manuel Kniep
• FW: PostgreSQL and iptables
  • From: Holger.Friedrich-Fa-Trivadis
• Re: PostgreSQL and iptables
  • From: Melvin Davidson
• Re: PostgreSQL and iptables
  • From: Mephysto
• Re: PostgreSQL and iptables
  • From: Melvin Davidson
• PostgreSQL and iptables
  • From: mephysto
• Re: double precision[] storage space questions
  • From: Tom Lane
• double precision[] storage space questions
  • From: greg
• Re: user constructed where clause
  • From: Yelai, Ramkumar IN BLR STS
• Re: support for ltree
  • From: Tom Lane
• Re: Alter column from text[] to uuid[]
  • From: Keith Rarick
• Re: support for ltree
  • From: David G. Johnston
• Re: support for ltree
  • From: David G. Johnston
• Re: support for ltree
  • From: Michael Shapiro
• Re: support for ltree
  • From: Melvin Davidson
• support for ltree
  • From: Michael Shapiro
• Re: 9.3.9 ?
  • From: Magnus Hagander
• Re: 9.3.9 ?
  • From: Albe Laurenz
• 9.3.9 ?
  • From: Birta Levente
• Re: pg_bulkload
  • From: Takashi Ohnishi
• Re: localtime ?
  • From: Adrian Klaver
• Re: localtime ?
  • From: James Cloos
• Re: localtime ?
  • From: Tom Lane
• localtime ?
  • From: James Cloos
• Re: GCC error and libmpfr.so.4 not found
  • From: Asif Naeem
• Re: Alter column from text[] to uuid[]
  • From: Tom Lane
• Re: GCC error and libmpfr.so.4 not found
  • From: Asma Riyaz
• Re: Alter column from text[] to uuid[]
  • From: Adrian Klaver
• Re: GCC error and libmpfr.so.4 not found
  • From: John R Pierce
• Re: GCC error and libmpfr.so.4 not found
  • From: Asma Riyaz
• Alter column from text[] to uuid[]
  • From: Keith Rarick
• pg_bulkload
  • From: Nguyen, Phuonglan H.
• Re: GCC error and libmpfr.so.4 not found
  • From: Tom Lane
• Re: database-level lockdown
  • From: Tom Lane
• Re: GCC error and libmpfr.so.4 not found
  • From: Jimmy Yih
• database-level lockdown
  • From: Filipe Pina
• Re: GCC error and libmpfr.so.4 not found
  • From: Asma Riyaz
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Jeff Janes
• Re: GCC error and libmpfr.so.4 not found
  • From: Jimmy Yih
• Re: Random order by but first 3
  • From: David G. Johnston
• Re: SET LOCAL synchronous_commit TO OFF
  • From: Thom Brown
• Random order by but first 3
  • From: Arup Rakshit
• SET LOCAL synchronous_commit TO OFF
  • From: Robert DiFalco
• Installing Postgres manually GCC error and libmpfr.so.4 not found
  • From: asmariyaz23
• Re: Prevent roles not having admin option from granting themselves to other roles
  • From: Adrian Klaver
• Re: Prevent roles not having admin option from granting themselves to other roles
  • From: Charles Clavadetscher
• Re: GCC error and libmpfr.so.4 not found
  • From: Asma Riyaz
• Re: select count(*);
  • From: Marc Mamin
• Re: select count(*);
  • From: Geoff Winkless
• Re: select count(*);
  • From: Adrian Klaver
• Re: select count(*);
  • From: Francisco Olarte
• Re: select count(*);
  • From: Yves Dorfsman
• Re: GCC error and libmpfr.so.4 not found
  • From: Geoff Winkless
• Re: Prevent roles not having admin option from granting themselves to other roles
  • From: Charles Clavadetscher
• Re: select count(*);
  • From: Tom Lane
• Re: select count(*);
  • From: Geoff Winkless
• GCC error and libmpfr.so.4 not found
  • From: Asma Riyaz
• Re: select count(*);
  • From: Marc Mamin
• Re: select count(*);
  • From: Geoff Winkless
• Re: Planner cost adjustments
  • From: Francisco Olarte
• Re: select count(*);
  • From: Marc Mamin
• Re: select count(*);
  • From: Chris Mair
• select count(*);
  • From: Marc Mamin
• Re: Prevent roles not having admin option from granting themselves to other roles
  • From: Adrian Klaver
• Re: Planner cost adjustments
  • From: Daniel Begin
• Re: Planner cost adjustments
  • From: Bill Moran
• Prevent roles not having admin option from granting themselves to other roles
  • From: Charles Clavadetscher
• Re: Missing WALs when doing pg_basebackup from slave...
  • From: marin
• Re: Missing WALs when doing pg_basebackup from slave...
  • From: Venkata Balaji N
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Noah Misch
• Re: Planner cost adjustments
  • From: Daniel Begin
• Re: Indexed views like SQL Server - NOT Materialized Views
  • From: Kevin Grittner
• Re: Indexed views like SQL Server - NOT Materialized Views
  • From: Nicolas Paris
• Re: Indexed views like SQL Server - NOT Materialized Views
  • From: Kevin Grittner
• Missing WALs when doing pg_basebackup from slave...
  • From: marin
• Re: Indexed views like SQL Server - NOT Materialized Views
  • From: William Dunn
• Indexed views like SQL Server - NOT Materialized Views
  • From: inspector morse
• The purpose of the core team
  • From: Bruce Momjian
• Re: user constructed where clause
  • From: David G. Johnston
• user constructed where clause
  • From: Yelai, Ramkumar IN BLR STS
• Re: Postgresql BDR Replication Setup Issue
  • From: Ravi Tammineni
• Re: Inserting from multiple processes?
  • From: Dave Johansen
• Re: BDR: DDL lock problem with function inside a schema
  • From: sym39
• Re: BDR: DDL lock problem with function inside a schema
  • From: Craig Ringer
• Re: Momentary Delay
  • From: Bill Moran
• Re: Postgresql BDR Replication Setup Issue
  • From: Ian Barwick
• Re: Joins between foreign tables
  • From: Jason Dusek
• Re: Momentary Delay
  • From: Anderson Valadares
• BDR: DDL lock problem with function inside a schema
  • From: sym39
• Postgresql BDR Replication Setup Issue
  • From: Ravi Tammineni
• Re: Joins between foreign tables
  • From: Geoff Montee
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Inserting from multiple processes?
  • From: Dave Johansen
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: BDR - Failure of Primary Server - How to recover?
  • From: cchee-ob
• Re: Momentary Delay
  • From: Adrian Klaver
• Joins between foreign tables
  • From: Jason Dusek
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: Momentary Delay
  • From: Anderson Valadares
• Re: Momentary Delay
  • From: Adrian Klaver
• Momentary Delay
  • From: Anderson Valadares
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: Albe Laurenz
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: David G. Johnston
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: Adrian Klaver
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: Adrian Klaver
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: otheus uibk
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: otheus uibk
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: Tomas Vondra
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: Guillaume Lelarge
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: Albe Laurenz
• Re: pg_start_backup does not actually allow for consistent, file-level backup
  • From: Jan Lentfer
• pg_start_backup does not actually allow for consistent, file-level backup
  • From: otheus uibk
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: BDR - Failure of Primary Server - How to recover?
  • From: Craig Ringer
• Re: SQL Server access from PostgreSQL
  • From: Serge Fonville
• Re: SQL Server access from PostgreSQL
  • From: Geoff Montee
• Re: Thousands of schemas and ANALYZE goes out of memory
  • From: Jeff Janes
• Re: [PERFORM] Query running slow for only one specific id. (Postgres 9.3) version
  • From: Matheus de Oliveira
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Joshua D. Drake
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Tom Lane
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: alter column type
  • From: Casey Deccio
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: alter column type
  • From: John R Pierce
• Re: alter column type
  • From: Tom Lane
• Re: [PERFORM] Re: Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• [PERFORM] Re: Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• Re: alter column type
  • From: Ravi Krishna
• Re: alter column type
  • From: Ravi Krishna
• Re: alter column type
  • From: Casey Deccio
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Steve Kehlet
• Re: alter column type
  • From: John R Pierce
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: alter column type
  • From: Casey Deccio
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• [PERFORM] Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Igor Neyman
• [PERFORM] Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Sheena, Prabhjot
• Re: alter column type
  • From: Michael Nolan
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: alter column type
  • From: Ravi Krishna
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Tom Lane
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [PERFORM] Query running slow for only one specific id. (Postgres 9.3) version
  • From: Steve Crawford
• Re: alter column type
  • From: Melvin Davidson
• [PERFORM] Re: Query running slow for only one specific id. (Postgres 9.3) version
  • From: Igor Neyman
• [PERFORM] Query running slow for only one specific id. (Postgres 9.3) version
  • From: Sheena, Prabhjot
• Re: replicating many to one
  • From: Shuwn Yuan Tee
• Re: postgres_fdw - push down conditionals for ENUMs
  • From: Sergiy Zuban
• alter column type
  • From: Casey Deccio
• Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Tom Lane
• BDR - Failure of Primary Server - How to recover?
  • From: cchee-ob
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Planner cost adjustments
  • From: Kevin Grittner
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Noah Misch
• Re: Database designpattern - product feature
  • From: William Dunn
• Re: replicating many to one
  • From: Sergey Konoplev
• Re: Automatic Client routing
  • From: Bill Moran
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: replicating many to one
  • From: Doiron, Daniel
• Re: replicating many to one
  • From: John R Pierce
• Re: replicating many to one
  • From: Wayne E. Seguin
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• replicating many to one
  • From: Doiron, Daniel
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: cannot connect to database through ECPG but can through psql
  • From: Tom Lane
• Re: cannot connect to database through ECPG but can through psql
  • From: Andreas Kretschmer
• cannot connect to database through ECPG but can through psql
  • From: Seann Reed
• Re: Row visibility issue with consecutive triggers, one being DEFERRED
  • From: Marc Mamin
• Re: pg_relation_size performance issue
  • From: Adrian Klaver
• Re: pg_relation_size performance issue
  • From: Melvin Davidson
• Re: pg_relation_size performance issue
  • From: Hans Guijt
• Re: pg_relation_size performance issue
  • From: Melvin Davidson
• Re: pg_relation_size performance issue
  • From: Melvin Davidson
• Re: pg_relation_size performance issue
  • From: Melvin Davidson
• Re: Row visibility issue with consecutive triggers, one being DEFERRED
  • From: Tom Lane
• Re: pg_relation_size performance issue
  • From: Tom Lane
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Row visibility issue with consecutive triggers, one being DEFERRED
  • From: Marc Mamin
• Automatic Client routing
  • From: Ravi Krishna
• Re: pg_relation_size performance issue
  • From: Marc Mamin
• Re: pg_relation_size performance issue
  • From: Hans Guijt
• pg_relation_size performance issue
  • From: Hans Guijt
• Row visibility issue with consecutive triggers, one being DEFERRED
  • From: Marc Mamin
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Noah Misch
• Re: Database designpattern - product feature
  • From: Adrian Stern
• Re: Database designpattern - product feature
  • From: Jan de Visser
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: Database designpattern - product feature
  • From: Roxanne Reid-Bennett
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: Problem when temp_tablespace get full?
  • From: Jan Lentfer
• Re: Problem when temp_tablespace get full?
  • From: Daniel Begin
• Re: Database designpattern - product feature
  • From: Gmail
• Re: Problem when temp_tablespace get full?
  • From: David G. Johnston
• Problem when temp_tablespace get full?
  • From: Daniel Begin
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Planner cost adjustments
  • From: Daniel Begin
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: Database designpattern - product feature
  • From: Adrian Stern
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: Planner cost adjustments
  • From: Bill Moran
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: TRIGGER TRUNCATE -- CASCADE or RESTRICT
  • From: Gavin Flower
• Re: pl/python composite type array as input parameter
  • From: Adrian Klaver
• Re: Minor revision downgrade (9.2.11 -> 9.2.10)
  • From: Fabio Ugo Venchiarutti
• Re: postgres db permissions
  • From: Adrian Klaver
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• ALTER EVENT TRIGGER as non superuser
  • From: Andreas Ulbrich
• Re: TRIGGER TRUNCATE -- CASCADE or RESTRICT
  • From: Andreas Ulbrich
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: TRIGGER TRUNCATE -- CASCADE or RESTRICT
  • From: Melvin Davidson
• Re: TRIGGER TRUNCATE -- CASCADE or RESTRICT
  • From: Andreas Ulbrich
• Re: pl/python composite type array as input parameter
  • From: Filipe Pina
• Re: postgres db permissions
  • From: Melvin Davidson
• Re: postgres db permissions
  • From: Joshua D. Drake
• Re: postgres db permissions
  • From: Steve Pribyl
• Re: postgres db permissions
  • From: Tom Lane
• Re: postgres db permissions
  • From: Steve Pribyl
• Re: postgres db permissions
  • From: Adrian Klaver
• Re: postgres db permissions
  • From: Melvin Davidson
• Re: postgres db permissions
  • From: Joshua D. Drake
• Re: postgres db permissions
  • From: Adrian Klaver
• Re: postgres db permissions
  • From: Steve Pribyl
• Re: postgres db permissions
  • From: Adrian Klaver
• Re: postgres db permissions
  • From: Steve Pribyl
• Re: postgres db permissions
  • From: Melvin Davidson
• Re: Planner cost adjustments
  • From: Daniel Begin
• Re: postgres db permissions
  • From: Steve Pribyl
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: postgres db permissions
  • From: Joshua D. Drake
• postgres db permissions
  • From: Steve Pribyl
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Noah Misch
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: Database designpattern - product feature
  • From: William Dunn
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Database designpattern - product feature
  • From: Dorian Hoxha
• Re: pl/python composite type array as input parameter
  • From: Adrian Klaver
• Re: odbc to emulate mysql for end programs
  • From: Adrian Klaver
• Re: advocating LTS release and feature-train release cycles
  • From: Adrian Klaver
• Re: Python 3.2 XP64 and Numpy...
  • From: Adrian Klaver
• Re: TRIGGER TRUNCATE -- CASCADE or RESTRICT
  • From: Melvin Davidson
• Automatic Failover
  • From: Ivann Ruiz
• Re: Minor revision downgrade (9.2.11 -> 9.2.10)
  • From: Melvin Davidson
• Re: advocating LTS release and feature-train release cycles
  • From: Jan de Visser
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: advocating LTS release and feature-train release cycles
  • From: Andrew Sullivan
• Re: odbc to emulate mysql for end programs
  • From: Andrew Sullivan
• Re: Minor revision downgrade (9.2.11 -> 9.2.10)
  • From: Bruce Momjian
• Re: odbc to emulate mysql for end programs
  • From: Thomas Kellerer
• Re: odbc to emulate mysql for end programs
  • From: Mimiko
• Re: Database designpattern - product feature
  • From: Adrian Stern
• Re: advocating LTS release and feature-train release cycles
  • From: Tomas Vondra
• Re: Database designpattern - product feature
  • From: Dorian Hoxha
• Re: pl/python composite type array as input parameter
  • From: Filipe Pina
• Re: pl/python composite type array as input parameter
  • From: Filipe Pina
• Re: TRIGGER TRUNCATE -- CASCADE or RESTRICT
  • From: Albe Laurenz
• Re: pl/python composite type array as input parameter
  • From: Rémi Cura
• Re: pl/python composite type array as input parameter
  • From: Rémi Cura
• Re: Python 3.2 XP64 and Numpy...
  • From: Rémi Cura
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Noah Misch
• Re: advocating LTS release and feature-train release cycles
  • From: Zenaan Harkness
• Minor revision downgrade (9.2.11 -> 9.2.10)
  • From: Fabio Ugo Venchiarutti
• Re: advocating LTS release and feature-train release cycles
  • From: Jan de Visser
• Re: advocating LTS release and feature-train release cycles
  • From: Adrian Klaver
• Re: advocating LTS release and feature-train release cycles
  • From: Arthur Silva
• Re: pl/python composite type array as input parameter
  • From: Adrian Klaver
• Re: odbc to emulate mysql for end programs
  • From: John R Pierce
• Re: odbc to emulate mysql for end programs
  • From: William Dunn
• Re: Help me recovery databases.
  • From: Evi-M
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: odbc to emulate mysql for end programs
  • From: Adrian Klaver
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• TRIGGER TRUNCATE -- CASCADE or RESTRICT
  • From: Andreas Ulbrich
• Re: Find out what on what function depends an index
  • From: Andreas Ulbrich
• Re: Is my standby fully connected?
  • From: William Dunn
• odbc to emulate mysql for end programs
  • From: Mimiko
• Re: Database designpattern - product feature
  • From: Dorian Hoxha
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Is my standby fully connected?
  • From: Guillaume Lelarge
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Is my standby fully connected?
  • From: Guillaume Lelarge
• Is my standby fully connected?
  • From: Ivann Ruiz
• Re: Python 3.2 XP64 and Numpy...
  • From: Adrian Klaver
• Re: Python 3.2 XP64 and Numpy...
  • From: Rémi Cura
• Re: Python 3.2 XP64 and Numpy...
  • From: Rémi Cura
• Re: pl/python composite type array as input parameter
  • From: Filipe Pina
• Database designpattern - product feature
  • From: Adrian Stern
• Re: Find out what on what function depends an index
  • From: Tom Lane
• Find out what on what function depends an index
  • From: Andreas Ulbrich
• Re: Curious case of huge simple btree indexes bloat.
  • From: Maxim Boguk
• Re: date type changing to timestamp without time zone in postgres 9.4
  • From: Adrian Klaver
• Re: date type changing to timestamp without time zone in postgres 9.4
  • From: Albe Laurenz
• Re: date type changing to timestamp without time zone in postgres 9.4
  • From: Rishi Gokhale
• Re: My index doesn't write anymore but read
  • From: ben.play
• Re: Efficient sorting the results of a join, without denormalization
  • From: Francisco Olarte
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: [to_tsvector] German Compound Words
  • From: Sven R. Kunze
• Re: date type changing to timestamp without time zone in postgres 9.4
  • From: Albe Laurenz
• Re: [to_tsvector] German Compound Words
  • From: Sven R. Kunze
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Noah Misch
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Noah Misch
• Re: JSONB matching element count
  • From: Michael Paquier
• Re: replacing jsonb field value
  • From: Michael Paquier
• Re: Postgresql 9.4 upgrade openSUSE13.1
  • From: Adrian Klaver
• Re: Help me recovery databases.
  • From: Melvin Davidson
• Re: Help me recovery databases.
  • From: Tomas Vondra
• Re: Efficient sorting the results of a join, without denormalization
  • From: Glen M. Witherington
• Postgresql 9.4 upgrade openSUSE13.1
  • From: Arup Rakshit
• Help me recovery databases.
  • From: Evi-M
• Re: Efficient sorting the results of a join, without denormalization
  • From: Bill Moran
• Re: Efficient sorting the results of a join, without denormalization
  • From: Francisco Olarte
• Re: How to retrieve Comment text using SQL, not psql?
  • From: Francisco Olarte
• Re: Curious case of huge simple btree indexes bloat.
  • From: Tom Lane
• JSONB matching element count
  • From: Arup Rakshit
• Re: date type changing to timestamp without time zone in postgres 9.4
  • From: Adrian Klaver
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Efficient sorting the results of a join, without denormalization
  • From: Glen M. Witherington
• advocating LTS release and feature-train release cycles
  • From: Zenaan Harkness
• Re: replacing jsonb field value
  • From: Andreas Kretschmer
• Re: Efficient sorting the results of a join, without denormalization
  • From: Tom Lane
• date type changing to timestamp without time zone in postgres 9.4
  • From: Rishi Gokhale
• Re: Efficient sorting the results of a join, without denormalization
  • From: Glen M. Witherington
• Re: Efficient sorting the results of a join, without denormalization
  • From: David G. Johnston
• Curious case of huge simple btree indexes bloat.
  • From: Maxim Boguk
• Efficient sorting the results of a join, without denormalization
  • From: Glen M. Witherington
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: replacing jsonb field value
  • From: Glyn Astill
• Re: How to retrieve Comment text using SQL, not psql?
  • From: Melvin Davidson
• Re: How to retrieve Comment text using SQL, not psql?
  • From: Adrian Klaver
• Re: How to retrieve Comment text using SQL, not psql?
  • From: Melvin Davidson
• Re: replacing jsonb field value
  • From: Andreas Kretschmer
• Re: How to retrieve Comment text using SQL, not psql?
  • From: Pavel Stehule
• How to retrieve Comment text using SQL, not psql?
  • From: Bob Futrelle
• Re: replacing jsonb field value
  • From: Michael Paquier
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• replacing jsonb field value
  • From: john.tiger
• Re: Planner cost adjustments
  • From: Daniel Begin
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Andres Freund
• Re: Planner cost adjustments
  • From: Tomas Vondra
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Steve Kehlet
• Re: Planner cost adjustments
  • From: Daniel Begin
• Re: Fwd: Raster performance
  • From: PT
• Re: Planner cost adjustments
  • From: PT
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Bruce Momjian
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Fwd: Raster performance
  • From: David Haynes II
• Re: Between with a list of ranges possible ?
  • From: John McKown
• Re: Between with a list of ranges possible ?
  • From: Stephen Cook
• Re: Between with a list of ranges possible ?
  • From: John R Pierce
• Re: Between with a list of ranges possible ?
  • From: Raymond O'Donnell
• Re: Between with a list of ranges possible ?
  • From: Andreas Kretschmer
• Re: Between with a list of ranges possible ?
  • From: John R Pierce
• Between with a list of ranges possible ?
  • From: Arup Rakshit
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Planner cost adjustments
  • From: Tomas Vondra
• Re: Planner cost adjustments
  • From: Melvin Davidson
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Tom Lane
• Planner cost adjustments
  • From: Daniel Begin
• Re: Fwd: Raster performance
  • From: PT
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: Python 3.2 XP64 and Numpy...
  • From: Adrian Klaver
• Re: Change UUID type default output representation
  • From: Peter Eisentraut
• Re: pl/python composite type array as input parameter
  • From: Peter Eisentraut
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Thomas Munro
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Change UUID type default output representation
  • From: Randall Lucas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Joshua D. Drake
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: Python 3.2 XP64 and Numpy...
  • From: Alban Hertroys
• Re: Partitioning and performance
  • From: Tom Lane
• Re: WAL Streaming Failure PostgreSQL 9.4
  • From: Jeff Janes
• Re: Partitioning and performance
  • From: Tom Lane
• Re: Partitioning and performance
  • From: Ravi Krishna
• Re: Partitioning and performance
  • From: Ravi Krishna
• Re: WAL Streaming Failure PostgreSQL 9.4
  • From: Joshua D. Drake
• WAL Streaming Failure PostgreSQL 9.4
  • From: Ivann Ruiz
• Re: Partitioning and performance
  • From: Ravi Krishna
• Re: Partitioning and performance
  • From: Tom Lane
• Re: Partitioning and performance
  • From: Jan Lentfer
• Re: Partitioning and performance
  • From: Melvin Davidson
• Re: Partitioning and performance
  • From: Jan Lentfer
• Re: Partitioning and performance
  • From: Ravi Krishna
• Re: Python 3.2 XP64 and Numpy...
  • From: Rémi Cura
• Re: [to_tsvector] German Compound Words
  • From: Sven R. Kunze
• Re: [to_tsvector] German Compound Words
  • From: Oleg Bartunov
• Partitioning and performance
  • From: Ravi Krishna
• Re: Fwd: Raster performance
  • From: David Haynes II
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• [to_tsvector] German Compound Words
  • From: Sven R. Kunze
• Re: 9.4.2 -> 9.4.3
  • From: Chris Mair
• Re: phppgadmin : login failed
  • From: arnaud gaboury
• Re: phppgadmin : login failed
  • From: Ian Barwick
• phppgadmin : login failed
  • From: arnaud gaboury
• Re: 9.4.2 -> 9.4.3
  • From: Devrim GÜNDÜZ
• 9.4.2 -> 9.4.3
  • From: Chris Mair
• [Postgresql NLS support] : Help on using NLS , Custom dictionary to enhance our website search functionality
  • From: Nivedita Kulkarni
• Re: [SQL] extracting PII data and transforming it across table.
  • From: John R Pierce
• Re: Constraint exclusion not working - need different constraints?
  • From: Tom Lane
• Re: Constraint exclusion not working - need different constraints?
  • From: Doug Gorley
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Robert Haas
• ERROR: missing chunk number 0 for toast value 1821556134 in pg_toast_17881
  • From: Tory M Blue
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• Re: Python 3.2 XP64 and Numpy...
  • From: Adrian Klaver
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Steve Kehlet
• Re: Constraint exclusion not working - need different constraints?
  • From: Tom Lane
• Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Alvaro Herrera
• 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
  • From: Steve Kehlet
• Constraint exclusion not working - need different constraints?
  • From: Doug Gorley
• Re: Fwd: Raster performance
  • From: PT
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: PT
• Python 3.2 XP64 and Numpy...
  • From: Rémi Cura
• Re: delaying autovacuum freeze via storage params?
  • From: Steve Kehlet
• Re: Reg: BULK COLLECT
  • From: Simon Riggs
• Re: duplicate key value violates unique constraint "pg_class_relname_nsp_index"
  • From: Tom Lane
• Re: Reg: BULK COLLECT
  • From: Andy Colson
• Re: duplicate key value violates unique constraint "pg_class_relname_nsp_index"
  • From: Adrian Klaver
• Re: duplicate key value violates unique constraint "pg_class_relname_nsp_index"
  • From: Melvin Davidson
• [plainto_tsquery] using OR
  • From: Sven R. Kunze
• Re: Re: duplicate key value violates unique constraint "pg_class_relname_nsp_index"
  • From: Albe Laurenz
• Re: Re: duplicate key value violates unique constraint "pg_class_relname_nsp_index"
  • From: Mitu Verma
• Re: Re: duplicate key value violates unique constraint "pg_class_relname_nsp_index"
  • From: Pete Hollobon
• Re: duplicate key value violates unique constraint "pg_class_relname_nsp_index"
  • From: Albe Laurenz
• Re: Can we simulate Oracle Flashback with pg_export_snapshot()?
  • From: Albe Laurenz
• duplicate key value violates unique constraint "pg_class_relname_nsp_index"
  • From: Mitu Verma
• Re: Reg: BULK COLLECT
  • From: Medhavi Mahansaria
• Re: delaying autovacuum freeze via storage params?
  • From: Alvaro Herrera
• delaying autovacuum freeze via storage params?
  • From: Steve Kehlet
• Re: Can we simulate Oracle Flashback with pg_export_snapshot()?
  • From: William Dunn
• Fwd: Raster performance
  • From: David Haynes II
• Re: MD5 password storage - should be the same everywhere?
  • From: Francisco Reyes
• Re: Queries for unused/useless indexes
  • From: Melvin Davidson
• Re: Queries for unused/useless indexes
  • From: William Dunn
• Re: dba scripts & queries
  • From: John McKown
• Re: Queries for unused/useless indexes
  • From: William Dunn
• dba scripts & queries
  • From: Melvin Davidson
• Re: [tsvector] to_tsvector called multiple times
  • From: Albe Laurenz
• Re: [tsvector] to_tsvector called multiple times
  • From: Sven R. Kunze
• really nice article about postgres popularity in startups on techrepublic
  • From: Merlin Moncure
• Re: [tsvector] to_tsvector called multiple times
  • From: Albe Laurenz
• Re: [tsvector] to_tsvector called multiple times
  • From: Sven R. Kunze
• Re: [tsvector] to_tsvector called multiple times
  • From: Sven R. Kunze
• Re: [tsvector] to_tsvector called multiple times
  • From: Albe Laurenz
• Re: [tsvector] to_tsvector called multiple times
  • From: Sven R. Kunze
• Re: [tsvector] to_tsvector called multiple times
  • From: Sven R. Kunze
• Re: [tsvector] to_tsvector called multiple times
  • From: Oleg Bartunov
• Re: [tsvector] to_tsvector called multiple times
  • From: Albe Laurenz
• [tsvector] to_tsvector called multiple times
  • From: Sven R. Kunze
• Re: Replacing uuid-ossp with uuid-freebsd
  • From: Piotr Gasidło
• Re: FW: Constraint exclusion in partitions
  • From: Francisco Olarte
• Re: MD5 password storage - should be the same everywhere?
  • From: Adrian Klaver
• Re: MD5 password storage - should be the same everywhere?
  • From: Yves Dorfsman
• Re: MD5 password storage - should be the same everywhere?
  • From: Yves Dorfsman
• Re: MD5 password storage - should be the same everywhere?
  • From: Adrian Klaver
• MD5 password storage - should be the same everywhere?
  • From: Francisco Reyes
• Re: FW: Constraint exclusion in partitions
  • From: Daniel Begin
• Re: Queries for unused/useless indexes
  • From: Peter J. Holzer
• Re: Queries for unused/useless indexes
  • From: Melvin Davidson
• Re: Strange replication problem - segment restored from archive but still requested from master
  • From: Guillaume Lelarge
• Re: Queries for unused/useless indexes
  • From: Peter J. Holzer
• Re: Replacing uuid-ossp with uuid-freebsd
  • From: Jan de Visser
• Re: Replacing uuid-ossp with uuid-freebsd
  • From: Adrian Klaver
• Replacing uuid-ossp with uuid-freebsd
  • From: Piotr Gasidło
• Re: Reg: BULK COLLECT
  • From: Adrian Klaver
• Re: Reg: BULK COLLECT
  • From: Allan Kamau
• Re: Strange replication problem - segment restored from archive but still requested from master
  • From: Piotr Gasidło
• Re: Reg: BULK COLLECT
  • From: Andy Colson
• Reg: BULK COLLECT
  • From: Medhavi Mahansaria
• Re: Strange replication problem - segment restored from archive but still requested from master
  • From: Guillaume Lelarge
• Re: Server tries to read a different config file than it is supposed to
  • From: twoflower
• SOLVED: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Marcos Ortiz
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Adrian Klaver
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Marcos Ortiz
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Scott Marlowe
• Re: Re: Server tries to read a different config file than it is supposed to
  • From: Tom Lane
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Francisco Olarte
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Arup Rakshit
• Re: PG and undo logging
  • From: Tom Lane
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Adrian Klaver
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Arup Rakshit
• Re: Enum in foreign table: error and correct way to handle.
  • From: Peter Swartz
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Adrian Klaver
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: rob stone
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Oliver Elphick
• Re: PG and undo logging
  • From: Ravi Krishna
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Arup Rakshit
• Re: How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Oliver Elphick
• Re: FW: Constraint exclusion in partitions
  • From: Francisco Olarte
• How to skip duplicate records while copying from CSV to table in Postgresql using "COPY"
  • From: Arup Rakshit
• Re: FW: Constraint exclusion in partitions
  • From: Francisco Olarte
• Re: Server tries to read a different config file than it is supposed to
  • From: twoflower
• Re: FW: Constraint exclusion in partitions
  • From: Bill Moran
• Re: PG and undo logging
  • From: Scott Marlowe
• Re: FW: Constraint exclusion in partitions
  • From: Daniel Begin
• Re: PG and undo logging
  • From: David G. Johnston
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Adrian Klaver
• Re: [NOVICE] Constraint exclusion in partitions
  • From: David G. Johnston
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Adrian Klaver
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Marcos Ortiz
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Adrian Klaver
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Marcos Ortiz
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Marcos Ortiz
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Adrian Klaver
• Re: Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Tom Lane
• Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3
  • From: Marcos Ortiz
• Re: Re: Server tries to read a different config file than it is supposed to
  • From: Adrian Klaver
• Re: FW: Constraint exclusion in partitions
  • From: Daniel Begin
• Re: Re: Server tries to read a different config file than it is supposed to
  • From: Tom Lane
• Re: PG and undo logging
  • From: Ravi Krishna
• Re: FW: Constraint exclusion in partitions
  • From: Daniel Begin
• Re: PG and undo logging
  • From: Jan de Visser
• Re: Re: Server tries to read a different config file than it is supposed to
  • From: Adrian Klaver
• Re: Server tries to read a different config file than it is supposed to
  • From: Tom Lane
• Re: Server tries to read a different config file than it is supposed to
  • From: Adrian Klaver
• Re: PG and undo logging
  • From: David G. Johnston
• PG and undo logging
  • From: Ravi Krishna
• Re: FW: Constraint exclusion in partitions
  • From: Bill Moran
• Re: FW: Constraint exclusion in partitions
  • From: melvin6925
• Re: FW: Constraint exclusion in partitions
  • From: Daniel Begin
• Re: Enum in foreign table: error and correct way to handle.
  • From: Tom Lane
• Re: Enum in foreign table: error and correct way to handle.
  • From: Peter Swartz
• Re: Server tries to read a different config file than it is supposed to
  • From: twoflower
• Re: Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Tom Lane
• Re: Server tries to read a different config file than it is supposed to
  • From: Tom Lane
• Re: Server tries to read a different config file than it is supposed to
  • From: Adrian Klaver
• Re: Server tries to read a different config file than it is supposed to
  • From: Adrian Klaver
• Re: Server tries to read a different config file than it is supposed to
  • From: rob stone
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Thomas Kellerer
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Thomas Kellerer
• Server tries to read a different config file than it is supposed to
  • From: twoflower
• Re: FW: Constraint exclusion in partitions
  • From: Francisco Olarte
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Arjen Nienhuis
• Re: Queries for unused/useless indexes
  • From: Melvin Davidson
• Re: Queries for unused/useless indexes
  • From: Venkata Balaji N
• Re: About COPY command (and probably file fdw too)
  • From: Stefan Stefanov
• Re: About COPY command (and probably file fdw too)
  • From: Stefan Stefanov
• Re: FW: Constraint exclusion in partitions
  • From: David G. Johnston
• FW: Constraint exclusion in partitions
  • From: Daniel Begin
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Bill Moran
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Tom Lane
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Bill Moran
• Re: Strange replication problem - segment restored from archive but still requested from master
  • From: Piotr Gasidło
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Bill Moran
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Dennis Jenkins
• Re: About COPY command (and probably file fdw too)
  • From: Brent Wood
• Re: date with month and year
  • From: Gilles Darold
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Tom Lane
• Queries for unused/useless indexes
  • From: Melvin Davidson
• Re: Different result depending on order of joins
  • From: John McKown
• Re: Different result depending on order of joins
  • From: Christofer C. Bell
• Re: Different result depending on order of joins
  • From: Tim Rowe
• Re: Different result depending on order of joins
  • From: Nicklas Av�n
• Re: Different result depending on order of joins
  • From: Albe Laurenz
• Different result depending on order of joins
  • From: Nicklas Avén
• Re: Grouping By Similarity (using pg_trgm)?
  • From: Oleg Bartunov
• Re: date with month and year
  • From: Karsten Hilbert
• Re: Can we simulate Oracle Flashback with pg_export_snapshot()?
  • From: Albe Laurenz
• Re: date with month and year
  • From: Tim Clarke
• Re: date with month and year
  • From: Alban Hertroys
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Alban Hertroys
• Re: Strange replication problem - segment restored from archive but still requested from master
  • From: Piotr Gasidło
• Re: Strange replication problem - segment restored from archive but still requested from master
  • From: Piotr Gasidło
• Re: Strange replication problem - segment restored from archive but still requested from master
  • From: Fujii Masao
• Re: date with month and year
  • From: Adrian Klaver
• Re: date with month and year
  • From: Alvaro Herrera
• Re: date with month and year
  • From: Adrian Klaver
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Bill Moran
• Re: date with month and year
  • From: Adrian Klaver
• Re: Strange replication problem - segment restored from archive but still requested from master
  • From: Venkata Balaji N
• Re: Enum in foreign table: error and correct way to handle.
  • From: Ian Barwick
• Re: RLS policy issue
  • From: Stephen Frost
• RLS policy issue
  • From: Ted Toth
• Re: Unit tests and foreign key constraints
  • From: Andy Chambers
• Re: date with month and year
  • From: Karsten Hilbert
• Re: date with month and year
  • From: Brian Dunavant
• Re: date with month and year
  • From: Paul Jungwirth
• Re: Unit tests and foreign key constraints
  • From: Martijn van Oosterhout
• Re: date with month and year
  • From: Karsten Hilbert
• Re: date with month and year
  • From: Thomas Kellerer
• Re: date with month and year
  • From: David G. Johnston
• Re: About COPY command (and probably file fdw too)
  • From: David G. Johnston
• Re: date with month and year
  • From: Paul Jungwirth
• Strange replication problem - segment restored from archive but still requested from master
  • From: Piotr Gasidło
• Re: About COPY command (and probably file fdw too)
  • From: Melvin Davidson
• Re: Unit tests and foreign key constraints
  • From: Dave Owens
• Re: Unit tests and foreign key constraints
  • From: Martijn van Oosterhout
• Re: About COPY command (and probably file fdw too)
  • From: Nicolas Paris
• Re: About COPY command (and probably file fdw too)
  • From: Stefan Stefanov
• Re: date with month and year
  • From: Jan de Visser
• Re: date with month and year
  • From: Brian Dunavant
• Unit tests and foreign key constraints
  • From: Andy Chambers
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Jan de Visser
• Re: date with month and year
  • From: Steve Crawford
• Re: Replicate over pgbouncer?
  • From: Joseph Kregloh
• Re: Replicate over pgbouncer?
  • From: Andomar
• Re: Replicate over pgbouncer?
  • From: Melvin Davidson
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Brown, Joseph E.
• Re: date with month and year
  • From: Daniel Torres
• Re: Replicate over pgbouncer?
  • From: Peter Eisentraut
• Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Tom Lane
• Re: Replicate over pgbouncer?
  • From: Andomar
• Re: date with month and year
  • From: Paul Jungwirth
• Re: date with month and year
  • From: Steve Crawford
• Re: date with month and year
  • From: Joshua D. Drake
• Re: date with month and year
  • From: Paul Jungwirth
• Re: date with month and year
  • From: David G. Johnston
• Re: date with month and year
  • From: John McKown
• date with month and year
  • From: Daniel Torres
• Re: Replicate over pgbouncer?
  • From: David G. Johnston
• Re: [SQL] extracting PII data and transforming it across table.
  • From: Suresh Raja
• Re: [SQL] extracting PII data and transforming it across table.
  • From: Steve Midgley
• extracting PII data and transforming it across table.
  • From: Suresh Raja
• Replicate over pgbouncer?
  • From: Andomar
• Allowing postgresql to accept 0xff syntax for data types that it makes sense for?
  • From: Bill Moran
• Re: pg_xlog Concern
  • From: Venkata Balaji N
• Re: About COPY command (and probably file fdw too)
  • From: Nicolas Paris
• About COPY command (and probably file fdw too)
  • From: Stefan Stefanov
• Re: Consistent state for pg_dump and pg_dumpall
  • From: John R Pierce
• Enum in foreign table: error and correct way to handle.
  • From: Peter Swartz
• Re: Consistent state for pg_dump and pg_dumpall
  • From: Michael Nolan
• Re: Consistent state for pg_dump and pg_dumpall
  • From: David G. Johnston
• Consistent state for pg_dump and pg_dumpall
  • From: Michael Nolan
• Can we simulate Oracle Flashback with pg_export_snapshot()?
  • From: William Dunn
• Re: Slaves show different results for query
  • From: Musall Maik
• Re: Slaves show different results for query
  • From: Tom Lane
• Re: Slaves show different results for query
  • From: Adrian Klaver
• Re: Slaves show different results for query
  • From: Musall Maik
• Re: Slaves show different results for query
  • From: Adrian Klaver
• Re: Slaves show different results for query
  • From: Musall Maik
• Re: Slaves show different results for query
  • From: Melvin Davidson
• partitioned tables
  • From: George Neuner
• Re: pg_xlog Concern
  • From: PT
• Re: Memory Utilization Issue
  • From: Naveed Shaikh
• Re: pg_xlog Concern
  • From: Mathew Moon
• Re: Memory Utilization Issue
  • From: Mathew Moon
• Re: Testing Views
  • From: Gavin Flower
• Re: Optimizing a read-only database
  • From: François Battail
• Re: Optimizing a read-only database
  • From: Sameer Thakur
• Re: Optimizing a read-only database
  • From: Sameer Thakur
• Re: Optimizing a read-only database
  • From: Sameer Thakur