Re: [GENERAL] bdr_init_copy fails when starting 2nd BDR node

2014-12-30 Thread John Casey
> What was your bdr config at this point? The error message indicates that it tries to > connect to port 5432 on localhost - but the copy was taken from 'main_node_ip'. > Perhaps you forgot to specify the ehost in the config? # Here is my conf on the DR server (where I am running bdr_init_copy) b

Re: [GENERAL] Improving performance of merging data between tables

2014-12-30 Thread Maxim Boguk
On Wed, Dec 31, 2014 at 11:10 AM, Pawel Veselov wrote > > > [skipped] > > 2) try pg_stat_statements, setting "pg_stat_statements.track = all". see: >>> http://www.postgresql.org/docs/9.4/static/pgstatstatements.html >>> >>> I have used this to profile some functions, and it worked pretty well. >>

Re: [GENERAL] Improving performance of merging data between tables

2014-12-30 Thread Pawel Veselov
On Mon, Dec 29, 2014 at 9:29 PM, Pawel Veselov wrote: [skipped] >>> 1) How do I find out what exactly is consuming the CPU in a PL/pgSQL >>> function? All I see is that the calls to merge_all() function take long >>> time, and the CPU is high while this is going on. >>> >>> [skipped] 2) try pg

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

2014-12-30 Thread Andrew Dunstan
On 12/30/2014 09:20 AM, Tom Lane wrote: Bernd Helmle writes: --On 29. Dezember 2014 12:55:11 -0500 Tom Lane wrote: Given the lack of previous complaints, this probably isn't backpatching material, but it sure seems like a bit of attention to consistency would be warranted here. Now that i r

Re: [GENERAL] bdr_init_copy fails when starting 2nd BDR node

2014-12-30 Thread Andres Freund
Hi, On 2014-12-29 23:51:05 -0500, John Casey wrote: > I've been having issues while attempting to begin BDR replication. If I set > up the main node, then use bdr_init_copy, it always fails on second node, as > shown below. > > > > postgres$ rm -Rf $PGDATA > > postgres$ echo db_password | pg_

Re: [GENERAL] extra function calls from query returning composite type

2014-12-30 Thread Merlin Moncure
On Mon, Dec 29, 2014 at 9:06 AM, Ronald Peterson wrote: > I added a 'raise notice' to a plpgsql function I was working on > recently, and noticed that my notification was being raised more often > than I'd expect. The notification is raised in a function ('getone' > in my example below) that ret

[GENERAL] bdr_init_copy fails when starting 2nd BDR node

2014-12-30 Thread John Casey
I've been having issues while attempting to begin BDR replication. If I set up the main node, then use bdr_init_copy, it always fails on second node, as shown below. postgres$ rm -Rf $PGDATA postgres$ echo db_password | pg_basebackup -X stream -h main_node_ip -p 5432 -U username -D $PGDATA po

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

2014-12-30 Thread David Johnston
On Tue, Dec 30, 2014 at 8:54 AM, Adrian Klaver wrote: > On 12/30/2014 07:43 AM, David G Johnston wrote: > >> Tom Lane-2 wrote >> >>> Bernd Helmle < >>> >> >> mailings@ >>> >> >> > writes: >>> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane < >>> >> tgl@.pa >>> >> >> > wrote: >>>

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

2014-12-30 Thread Adrian Klaver
On 12/30/2014 07:43 AM, David G Johnston wrote: Tom Lane-2 wrote Bernd Helmle < mailings@ > writes: --On 29. Dezember 2014 12:55:11 -0500 Tom Lane < tgl@.pa > wrote: Given the lack of previous complaints, this probably isn't backpatching material, but it sure seems like a bit of at

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

2014-12-30 Thread David G Johnston
Tom Lane-2 wrote > Bernd Helmle < > mailings@ > > writes: >> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane < > tgl@.pa > > wrote: >>> Given the lack of previous complaints, this probably isn't backpatching >>> material, but it sure seems like a bit of attention to consistency >>> would be warr

Re: [GENERAL] vacuum vs pg_repack vs pg_reorg

2014-12-30 Thread Kevin Grittner
sramay wrote: > I have a database of size 1.5 TB. The attachments are stored in bytea. > The attachment table is consuming maximum space. The database version is > 9.1.x and Streaming Replication is set. Now, I have to removed old records > to make way for new records without increasing SAN

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

2014-12-30 Thread Tom Lane
Bernd Helmle writes: > --On 29. Dezember 2014 12:55:11 -0500 Tom Lane wrote: >> Given the lack of previous complaints, this probably isn't backpatching >> material, but it sure seems like a bit of attention to consistency >> would be warranted here. > Now that i read it i remember a client compl

Re: [GENERAL] Improving performance of merging data between tables

2014-12-30 Thread Andy Colson
On 12/29/2014 11:29 PM, Pawel Veselov wrote: Andy, thanks for looking into this. On Mon, Dec 29, 2014 at 9:00 AM, Andy Colson mailto:a...@squeakycode.net>> wrote: On 12/28/2014 3:49 PM, Pawel Veselov wrote: Hi. I was wondering if anybody would have any ideas on how to im

Re: [HACKERS] [GENERAL] ON_ERROR_ROLLBACK

2014-12-30 Thread Bernd Helmle
--On 29. Dezember 2014 12:55:11 -0500 Tom Lane wrote: Given the lack of previous complaints, this probably isn't backpatching material, but it sure seems like a bit of attention to consistency would be warranted here. Now that i read it i remember a client complaining about this some time