Re: [GENERAL] Perl script is killed by SIGPIPE

Dear Daniel, Yes , we are using DBI for connection. Basically we observed that after dbh->do() return nothing if we are trying to insert duplicate entry. But it is not occurred always. It return exit 1 if try to insert duplicate entry into Db. But sometime it return nothing and child script is

Re: [GENERAL] pg_rewind copy so much data

Hi, Thanks for your response. I have just replayed switching master and slave once again: - one master and one slave (total size of each server is more than 4GB). Currently the last log of the slave is "started streaming WAL from primary at 2/D600 on timeline 10". - stop master, the slave

Re: [GENERAL] pg_rewind copy so much data

On Wed, Sep 13, 2017 at 12:41 PM, Hung Phan wrote: > I have tested pg_rewind (ver 9.5) with the following scenario: > > - one master and one slave (total size of each server is more than 4GB) > - set wal_log_hint=on and restart both > - stop master, promote slave > - start

[GENERAL] pg_rewind copy so much data

Hi, I have tested pg_rewind (ver 9.5) with the following scenario: - one master and one slave (total size of each server is more than 4GB) - set wal_log_hint=on and restart both - stop master, promote slave - start old master again (now two servers have diverged) - stop old master, run pg_rewind

Re: [GENERAL] WAL & ready files retained after turning off log shipping

On Tue, Sep 12, 2017 at 11:43 PM, Ron Johnson wrote: > On 09/07/2017 09:32 AM, Tom Lane wrote: >> >> Ron Johnson writes: >>> >>> On 09/07/2017 09:08 AM, Tom Lane wrote: Manual cleanup shouldn't be very hard, fortunately. Run pg_controldata

Re: [GENERAL] Aquameta 0.1 - Request for reviews, contributors

Thanks Nico. I definitely like this syntax better. -- Eric Hanson CEO, Aquameta Labs 503-929-1073 www.aquameta.com On Fri, Sep 8, 2017 at 4:26 PM, Nico Williams wrote: > > Here's a review comment. Just one for now. > > Looking at the meta module, I see things like

Re: [GENERAL] Perl script is killed by SIGPIPE

> Daniel Verite wrote: > > Yogesh Sharma wrote: > > > We have found child script is killed by signal 13 SIGPIPE. When > > duplicate key violates error occured, script is killed but not all time. > > "child script" and this kind of error suggests that a forked process inherits > a database

Re: [GENERAL] PostgreSQL COPY Statement Error On Linux

George: On Tue, Sep 12, 2017 at 6:40 PM, George Neuner wrote: > Francisco already pointed out that Linux doesn't understand the > backslashes in the file path, however it should be noted that Windows > *does* understand forward slashes and that [modulo disk names in >

Re: [GENERAL] PostgreSQL COPY Statement Error On Linux

On Tue, 12 Sep 2017 11:30:02 +0100, Osahon Oduware wrote: >I am trying to utilize the "COPY" statement below to copy a .CSV file to a >table in a PostgreSQL database.: >*COPY .() FROM >'\\shared\network\path\to\csv\test.csv' DELIMITER ',' CSV HEADER;* > >This works with

Re: [GENERAL] contrecord is requested

On Tue, Sep 12, 2017 at 10:19 AM, Jeff Janes wrote: > On Mon, Sep 11, 2017 at 1:27 PM, Scott Marlowe > wrote: >> >> So we have a db we're trying to rewind and get synced to the master. >> pg_rewind says it doesn't need rewinding, and when we try to

Re: [GENERAL] PostgreSQL COPY Statement Error On Linux

Hi Francisco, Thanks for your response. I would try this out and give you feedback. On Tue, Sep 12, 2017 at 12:00 PM, Francisco Olarte wrote: > On Tue, Sep 12, 2017 at 12:30 PM, Osahon Oduware > wrote: > > I am trying to utilize the "COPY"

Re: [GENERAL] PostgreSQL COPY Statement Error On Linux

Hi Charles, Thanks for your response. I would try this out and give you feedback. On Tue, Sep 12, 2017 at 12:01 PM, Charles Clavadetscher < clavadetsc...@swisspug.org> wrote: > Hello > > > > *From:* pgsql-general-ow...@postgresql.org [mailto:pgsql-general-owner@ > postgresql.org] *On Behalf Of

Re: [GENERAL] contrecord is requested

On Mon, Sep 11, 2017 at 1:27 PM, Scott Marlowe wrote: > So we have a db we're trying to rewind and get synced to the master. > pg_rewind says it doesn't need rewinding, and when we try to bring it > up, it gets this error: > > "contrecord is requested by 2E7/4028" >

Re: [GENERAL] pgxn manager down

On Tue, Sep 12, 2017 at 02:56:26PM +0200, Chris Travers wrote: > Normally I would not email the general list over this but it has been over > a day and the google group for pgxn seems low enough traffic I figure I > would mention it here. > > manager.pgxn.org is giving internal server errors

Re: [GENERAL] WAL & ready files retained after turning off log shipping

On 09/07/2017 09:32 AM, Tom Lane wrote: Ron Johnson writes: On 09/07/2017 09:08 AM, Tom Lane wrote: Manual cleanup shouldn't be very hard, fortunately. Run pg_controldata to see where the last checkpoint is, and delete WAL files whose names indicate they are before

Re: [GENERAL] Joining 16 tables seems slow

2017-09-12 14:01 GMT+02:00 Tom Lane : > "Frank Millman" writes: > > Pavel Stehule wrote: > >> 2017-09-12 8:45 GMT+02:00 Frank Millman : > >>> I am experimenting with optimising a SQL statement. One version uses > 4 LEFT JOIN’s and a

Re: [GENERAL] Joining 16 tables seems slow

On Tue, Sep 12, 2017 at 3:15 PM, Frank Millman wrote: > > 2017-09-12 12:39 GMT+02:00 Pavel Stehule : > >> >> >> 2017-09-12 12:25 GMT+02:00 Frank Millman : >> >>> Pavel Stehule wrote: >>> >>> 2017-09-12 9:36 GMT+02:00 Frank Millman

Re: [GENERAL] Perl script is killed by SIGPIPE

Yogesh Sharma wrote: > We have found child script is killed by signal 13 SIGPIPE. When duplicate > key violates error occured, script is killed but not all time. "child script" and this kind of error suggests that a forked process inherits a database connection opened by a parent

Re: [GENERAL] Joining 16 tables seems slow

2017-09-12 12:39 GMT+02:00 Pavel Stehule : 2017-09-12 12:25 GMT+02:00 Frank Millman : Pavel Stehule wrote: 2017-09-12 9:36 GMT+02:00 Frank Millman : Pavel Stehule wrote: > > 2017-09-12 8:45

[GENERAL] pgxn manager down

Hi; Normally I would not email the general list over this but it has been over a day and the google group for pgxn seems low enough traffic I figure I would mention it here. manager.pgxn.org is giving internal server errors (which means no new extensions can be released on the platform). If

Re: [GENERAL] Joining 16 tables seems slow

"Frank Millman" writes: > Pavel Stehule wrote: >> 2017-09-12 8:45 GMT+02:00 Frank Millman : >>> I am experimenting with optimising a SQL statement. One version uses 4 >>> LEFT JOIN’s and a 5-way CASE statement in the body. The second moves the >>>

Re: [GENERAL] Perl script is killed by SIGPIPE

On Mon, Sep 11, 2017 at 9:02 PM, Yogesh Sharma wrote: > Dear All, > > > We have one perl script that is opening DB connection and performaing > insert DB operation.When duplicate entry Comming in query,Postgres > forecfully killing process itself and in Postgres log

Re: [GENERAL] Joining 16 tables seems slow

2017-09-12 12:39 GMT+02:00 Pavel Stehule : > > > 2017-09-12 12:25 GMT+02:00 Frank Millman : > >> Pavel Stehule wrote: >> >> 2017-09-12 9:36 GMT+02:00 Frank Millman : >> >>> Pavel Stehule wrote: >>> > >>> > 2017-09-12 8:45 GMT+02:00

Re: [GENERAL] PostgreSQL COPY Statement Error On Linux

On Tue, Sep 12, 2017 at 12:30 PM, Osahon Oduware wrote: > I am trying to utilize the "COPY" statement below to copy a .CSV file to a > table in a PostgreSQL database.: > COPY .() FROM > '\\shared\network\path\to\csv\test.csv' DELIMITER ',' CSV HEADER; > > This works with

Re: [GENERAL] PostgreSQL COPY Statement Error On Linux

Hello From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Osahon Oduware Sent: Dienstag, 12. September 2017 12:30 To: pgsql-general@postgresql.org Subject: [GENERAL] PostgreSQL COPY Statement Error On Linux Hi All, I am trying to utilize the

Re: [GENERAL] Joining 16 tables seems slow

2017-09-12 12:25 GMT+02:00 Frank Millman : > Pavel Stehule wrote: > > 2017-09-12 9:36 GMT+02:00 Frank Millman : > >> Pavel Stehule wrote: >> > >> > 2017-09-12 8:45 GMT+02:00 Frank Millman : >> >>> I am using 9.4.4 on Fedora 22. >>> >>> I

[GENERAL] PostgreSQL COPY Statement Error On Linux

Hi All, I am trying to utilize the "COPY" statement below to copy a .CSV file to a table in a PostgreSQL database.: *COPY .() FROM '\\shared\network\path\to\csv\test.csv' DELIMITER ',' CSV HEADER;* This works with a PostgreSQL database installed in a WINDOWS environment (Windows 7), but

Re: [GENERAL] Joining 16 tables seems slow

Pavel Stehule wrote: 2017-09-12 9:36 GMT+02:00 Frank Millman : Pavel Stehule wrote: > > 2017-09-12 8:45 GMT+02:00 Frank Millman : I am using 9.4.4 on Fedora 22. I am experimenting with optimising a SQL statement. One version uses 4 LEFT

Re: [GENERAL] Joining 16 tables seems slow

2017-09-12 9:36 GMT+02:00 Frank Millman : > Pavel Stehule wrote: > > > > 2017-09-12 8:45 GMT+02:00 Frank Millman : > >> I am using 9.4.4 on Fedora 22. >> >> I am experimenting with optimising a SQL statement. One version uses 4 >> LEFT JOIN’s and a 5-way

Re: [GENERAL] Joining 16 tables seems slow

Ron Johnson wrote: > On 09/12/2017 01:45 AM, Frank Millman wrote: Hi all I am using 9.4.4 on Fedora 22. I am experimenting with optimising a SQL statement. One version uses 4 LEFT JOIN’s and a 5-way CASE statement in the body. The second moves the filtering into the JOIN section, and I end

Re: [GENERAL] Joining 16 tables seems slow

Pavel Stehule wrote: > > 2017-09-12 8:45 GMT+02:00 Frank Millman : I am using 9.4.4 on Fedora 22. I am experimenting with optimising a SQL statement. One version uses 4 LEFT JOIN’s and a 5-way CASE statement in the body. The second moves the filtering into the JOIN

Re: [GENERAL] Joining 16 tables seems slow

On 09/12/2017 01:45 AM, Frank Millman wrote: Hi all I am using 9.4.4 on Fedora 22. I am experimenting with optimising a SQL statement. One version uses 4 LEFT JOIN’s and a 5-way CASE statement in the body. The second moves the filtering into the JOIN section, and I end up with 16 LEFT JOIN’s

Re: [GENERAL] Joining 16 tables seems slow

hi 2017-09-12 8:45 GMT+02:00 Frank Millman : > Hi all > > I am using 9.4.4 on Fedora 22. > > I am experimenting with optimising a SQL statement. One version uses 4 > LEFT JOIN’s and a 5-way CASE statement in the body. The second moves the > filtering into the JOIN section,

[GENERAL] Joining 16 tables seems slow

Hi all I am using 9.4.4 on Fedora 22. I am experimenting with optimising a SQL statement. One version uses 4 LEFT JOIN’s and a 5-way CASE statement in the body. The second moves the filtering into the JOIN section, and I end up with 16 LEFT JOIN’s and no CASE statements. My test involves