Re: [GENERAL] a couple questions about convert()

2014-09-21 Thread smcg2297
On 09/19/2014 08:50 AM, Tom Lane wrote: > smcg2...@frii.com writes: >> In a postgresql-9.3.1 database with UTF8 encoding I can do: > >> select convert_from (E'\\x68656c6c6f', 'LATIN1'); >>convert_from >> -- >>hello > >> But when I explicitly give the "to" encoding: > >>

Re: [GENERAL] unique index on embedded json object

2014-09-21 Thread Peter Geoghegan
On Sun, Sep 21, 2014 at 5:23 AM, Lee Jason wrote: > {"id": "12345", > "bags": [{ > "sku": "abc123", > "price": 0, > }, > { > "sku": "abc123", > "price": 0, > }] > } That's invalid JSON - there are stray commas. > However, I want sku of bags to be unique. It means the json can't

Re: [GENERAL] unique index on embedded json object

2014-09-21 Thread John R Pierce
On 9/21/2014 5:23 AM, Lee Jason wrote: > * > * > Any suggestions, please? Thank you. store your structured data in conventional SQL tables. -- john r pierce 37N 122W somewhere on the middle of the left coast

[GENERAL] unique index on embedded json object

2014-09-21 Thread Lee Jason
Hi forks, I am testing postgresql 9.4 beta2 right now. I am wondering if it is possible to create a unique index on embedded json object? For example, I create a table names "products" CREATE TABLE products (oid serial primary key, data jsonb) Now, I try to insert json object into data column.

Re: [GENERAL] can't restore database created with pg_dump

2014-09-21 Thread Eric Smith
Thank you for the help! Regards, Eric On Sep 20, 2014, at 6:55 AM, Adrian Klaver wrote: > On 09/19/2014 07:51 PM, Eric Smith wrote: >> All, >> >> I created a backup using pg_dump, postgres 8.3. I'm trying to restore that >> into a new postgres 9.3.5 installation. I just created the default

[GENERAL] Detecting query timeouts properly

2014-09-21 Thread Evan Martin
Hello, I'm using PostgreSQL 9.2.8 via Npgsql 2.2.0. When a query times out it returns error 57014 with the message "canceling statement due to statement timeout". I use the message to detect the timeout and re-try in some cases. It seems a bit wrong to rely on the message, though - I presume

Re: [GENERAL] Strategy for moving a large DB to another machine with least possible down-time

2014-09-21 Thread Andy Colson
On 09/21/2014 06:36 AM, Andreas Joseph Krogh wrote: Hi all. PG-version: 9.3.5 I have a DB large enough for it to be impractical to pg_dump/restore it (would require too much down-time for customer). Note that I'm noe able to move the whole cluster, only *one* DB in that cluster. What is the bes

Re: [GENERAL] Strategy for moving a large DB to another machine with least possible down-time

2014-09-21 Thread Andreas Joseph Krogh
På søndag 21. september 2014 kl. 16:10:54, skrev Adrian Klaver < adrian.kla...@aklaver.com >: On 09/21/2014 06:50 AM, Andreas Joseph Krogh wrote: > På søndag 21. september 2014 kl. 15:48:00, skrev Adrian Klaver > mailto:adrian.kla...@aklaver.com>>: > >     On

Re: [GENERAL] Strategy for moving a large DB to another machine with least possible down-time

2014-09-21 Thread Adrian Klaver
On 09/21/2014 06:50 AM, Andreas Joseph Krogh wrote: På søndag 21. september 2014 kl. 15:48:00, skrev Adrian Klaver mailto:adrian.kla...@aklaver.com>>: On 09/21/2014 05:44 AM, Andreas Joseph Krogh wrote: > På søndag 21. september 2014 kl. 13:51:00, skrev Bill Moran > mailto:wmo...@p

Re: [GENERAL] Strategy for moving a large DB to another machine with least possible down-time

2014-09-21 Thread Andreas Joseph Krogh
På søndag 21. september 2014 kl. 15:48:00, skrev Adrian Klaver < adrian.kla...@aklaver.com >: On 09/21/2014 05:44 AM, Andreas Joseph Krogh wrote: > På søndag 21. september 2014 kl. 13:51:00, skrev Bill Moran > mailto:wmo...@potentialtech.com>>: > > > I see t

Re: [GENERAL] Strategy for moving a large DB to another machine with least possible down-time

2014-09-21 Thread Adrian Klaver
On 09/21/2014 05:44 AM, Andreas Joseph Krogh wrote: På søndag 21. september 2014 kl. 13:51:00, skrev Bill Moran mailto:wmo...@potentialtech.com>>: I see this limitation in Slyny: http://slony.info/documentation/2.2/limitations.html Slony-I does not automatically replicate * Changes

Re: [GENERAL] Strategy for moving a large DB to another machine with least possible down-time

2014-09-21 Thread Andreas Joseph Krogh
På søndag 21. september 2014 kl. 13:51:00, skrev Bill Moran < wmo...@potentialtech.com >: On Sun, 21 Sep 2014 13:36:18 +0200 (CEST) Andreas Joseph Krogh wrote: > Hi all.   PG-version: 9.3.5   I have a DB large enough for it to be impractical > to pg_dump/rest

Re: [GENERAL] Strategy for moving a large DB to another machine with least possible down-time

2014-09-21 Thread Bill Moran
On Sun, 21 Sep 2014 13:36:18 +0200 (CEST) Andreas Joseph Krogh wrote: > Hi all.   PG-version: 9.3.5   I have a DB large enough for it to be > impractical > to pg_dump/restore it (would require too much down-time for customer). Note > that I'm noe able to move the whole cluster, only *one* DB i

[GENERAL] Strategy for moving a large DB to another machine with least possible down-time

2014-09-21 Thread Andreas Joseph Krogh
Hi all.   PG-version: 9.3.5   I have a DB large enough for it to be impractical to pg_dump/restore it (would require too much down-time for customer). Note that I'm noe able to move the whole cluster, only *one* DB in that cluster.   What is the best way to perform such a move, can i use PITR, r