Re: [GENERAL] Advise on primary key for detail tables (OS: Raspberry Pi)

Sorry for top posting. I have a serial in master table because I need to know data insertion order. DateTime on Raspberry Pi is not accurate due to power loss and lack of internet access to fetch correct time from. -Original Message- From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]

Re: [GENERAL] Archiving data to another server using copy, psql with pipe

Il 05/04/2017 23:26, pinker ha scritto: Hi, I'm trying to write an archive manager which will be first copying data from tables with where clause and then, after successful load into second server - delete them. The simplest (and probably fastest) solution I came up with is to use copy: psql -h l

Re: [GENERAL] Archiving data to another server using copy, psql with pipe

W dniu 2017-04-06 13:24:16 użytkownik Moreno Andreo napisał: > Il 05/04/2017 23:26, pinker ha scritto: > > Hi, > > I'm trying to write an archive manager which will be first copying data from > > tables with where clause and then, after successful load into second server > > - delete them. > >

Re: [GENERAL] A change in the Debian install

On Thu, Apr 06, 2017 at 12:05:51AM -0400, Tom Lane wrote: > rob stone writes: > > Upgraded to version 9.6.2-2 and these are the log entries on start-up:- > > > 2017-04-05 08:03:29 AESTLOG:  test message did not get through on > > socket for statistics collector ... > (But ... these statements

Re: [GENERAL] Archiving data to another server using copy, psql with pipe

Il 06/04/2017 13:58, pinker ha scritto: W dniu 2017-04-06 13:24:16 użytkownik Moreno Andreo napisał: Il 05/04/2017 23:26, pinker ha scritto: Hi, I'm trying to write an archive manager which will be first copying data from tables with where clause and then, after successful load into second s

Re: [GENERAL] Advise on primary key for detail tables (OS: Raspberry Pi)

On 04/06/2017 03:27 AM, Ertan Küçükoğlu wrote: Sorry for top posting. I have a serial in master table because I need to know data insertion order. DateTime on Raspberry Pi is not accurate due to power loss and lack of internet access to fetch correct time from. Understand, though it does beg t

Re: [GENERAL] Advise on primary key for detail tables (OS: Raspberry Pi)

-Original Message- From: Adrian Klaver [mailto:adrian.kla...@aklaver.com] Sent: Thursday, April 6, 2017 4:18 PM To: Ertan Küçükoğlu ; pgsql-general@postgresql.org Subject: Re: [GENERAL] Advise on primary key for detail tables (OS: Raspberry Pi) > On 04/06/2017 03:27 AM, Ertan Küçükoğlu wr

Re: [GENERAL] A change in the Debian install

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > (But ... these statements are based on an assumption of out-of-the- > box Postgres behavior. I would not exactly put it past the Debian > packagers to have decided to change this for reasons of their own, > and their track record of telling us about s

Re: [GENERAL] Archiving data to another server using copy, psql with pipe

W dniu 2017-04-06 14:28:04 użytkownik Moreno Andreo napisał: > Il 06/04/2017 13:58, pinker ha scritto: > > > > W dniu 2017-04-06 13:24:16 użytkownik Moreno Andreo > > napisał: > >> Il 05/04/2017 23:26, pinker ha scritto: > >>> Hi, > >>> I'm trying to write an archive manager which will be fir

Re: [GENERAL] Advise on primary key for detail tables (OS: Raspberry Pi)

On 04/06/2017 06:40 AM, Ertan Küçükoğlu wrote: -Original Message- From: Adrian Klaver [mailto:adrian.kla...@aklaver.com] Sent: Thursday, April 6, 2017 4:18 PM To: Ertan Küçükoğlu ; pgsql-general@postgresql.org Subject: Re: [GENERAL] Advise on primary key for detail tables (OS: Raspberry P

Re: [GENERAL] Archiving data to another server using copy, psql with pipe

Il 06/04/2017 16:10, pinker ha scritto: Error message says, as one could expect, that the second table has got smaller precision... The question isn't about this particular error - which was induced for purpose - but about atomicity of this operation Sorry, I read your message without paying t

Re: [GENERAL] Advise on primary key for detail tables (OS: Raspberry Pi)

On Thu, Apr 6, 2017 at 4:27 AM, Ertan Küçükoğlu wrote: > Sorry for top posting. > > I have a serial in master table because I need to know data insertion order. > DateTime on Raspberry Pi is not accurate due to power loss and lack of > internet access to fetch correct time from. Note that serial

Re: [GENERAL] A change in the Debian install

On Thu, Apr 6, 2017 at 3:46 PM, Stephen Frost wrote: > Tom, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > (But ... these statements are based on an assumption of out-of-the- > > box Postgres behavior. I would not exactly put it past the Debian > > packagers to have decided to change this for re

Re: [GENERAL] Archiving data to another server using copy, psql with pipe

On Thu, Apr 6, 2017 at 4:24 AM, Moreno Andreo wrote: > psql -h localhost postgres -c "copy (SELECT * FROM a WHERE time < now()) to > stdout " | psql -h localhost postgres -c "copy b from stdin" ​The first question at hand is whether the source psql command will provoke an EOF (which is the o

Re: [GENERAL] WAL being written during SELECT * query

2017-04-04 19:18 GMT+02:00 Scott Marlowe : > On Tue, Apr 4, 2017 at 9:46 AM, Tom DalPozzo wrote: > > Hi, > > I have a very big table (10GB). > > I noticed that many WAL segments are being written when elaborating read > > only transactions like this: > > select * from dati256 where id >43

Re: [GENERAL] WAL being written during SELECT * query

On Thu, Apr 6, 2017 at 8:51 AM, Tom DalPozzo wrote: > > What is the meaning of FPI_FOR_HINT? > ​ > ​Full Page Image for Hint [Bits] Its noted as being dependent upon checksums being enabled. I have a feel for the interactions involved here but not enough to explain them in detail. David J.

Re: [GENERAL] keeping WAL after dropping replication slots

On 04/04/2017 11:52 PM, Tom DalPozzo wrote: Hi, 2017-04-05 1:55 GMT+02:00 Adrian Klaver mailto:adrian.kla...@aklaver.com>>: On 04/04/2017 07:45 AM, Tom DalPozzo wrote: Postgres version? 9.6.1 Hi, I had two replication slots on my primary. Slaves off and (arou

Re: [GENERAL] A change in the Debian install

On Wed, 2017-04-05 at 21:14 -0700, Adrian Klaver wrote: > > What repos are you using, the Debian or the PGDG one? > > I guess the question I should really ask is, are you using a repo or  > some other method to upgrade? > > Upgraded from standard Debian repos. Nothing else was changed other

Re: [GENERAL] A change in the Debian install

On 04/06/2017 03:16 PM, rob stone wrote: On Wed, 2017-04-05 at 21:14 -0700, Adrian Klaver wrote: What repos are you using, the Debian or the PGDG one? I guess the question I should really ask is, are you using a repo or some other method to upgrade? Upgraded from standard Debian repos.

Re: [GENERAL] regexp_matches where clause - PG 9.1

2017-04-06 18:10 GMT+12:00 Patrick B : > > 2017-04-06 17:35 GMT+12:00 Arjen Nienhuis : > >> >> >> On Apr 6, 2017 05:57, "Patrick B" wrote: >> >> Hi guys, >> >> i've got this column: >> >> path_name character varying(255) >>> >> >> I store full S3 bucket path for the attachments of my application

Re: [GENERAL] regexp_matches where clause - PG 9.1

On Thu, Apr 6, 2017 at 6:33 PM, Patrick B wrote: > When actually I just want the 'main'' > ​SELECT * FROM tbl WHERE path_name ~ '/main$' ? David J. ​

Re: [GENERAL] regexp_matches where clause - PG 9.1

2017-04-07 14:08 GMT+12:00 David G. Johnston : > On Thu, Apr 6, 2017 at 6:33 PM, Patrick B > wrote: > >> When actually I just want the 'main'' >> > > ​SELECT * FROM tbl WHERE path_name ~ '/main$' ? > > David J. > ​ > David, That won't work. When performing the select, I got: /{s3bucket}/files

Re: [GENERAL] regexp_matches where clause - PG 9.1

On Apr 7, 2017 4:08 AM, "David G. Johnston" wrote: On Thu, Apr 6, 2017 at 6:33 PM, Patrick B wrote: > When actually I just want the 'main'' > ​SELECT * FROM tbl WHERE path_name ~ '/main$' ? David J. ​ Or just: SELECT 'main';

Re: [GENERAL] regexp_matches where clause - PG 9.1

On Apr 7, 2017 4:16 AM, "Patrick B" wrote: 2017-04-07 14:08 GMT+12:00 David G. Johnston : > On Thu, Apr 6, 2017 at 6:33 PM, Patrick B > wrote: > >> When actually I just want the 'main'' >> > > ​SELECT * FROM tbl WHERE path_name ~ '/main$' ? > > David J. > ​ > David, That won't work. When p

Re: [GENERAL] regexp_matches where clause - PG 9.1

On Thu, Apr 6, 2017 at 7:15 PM, Patrick B wrote: > > David, > That won't work. > ​Actually, it works fine, you just keep moving the under-specified problem space. ​ I'd suggest creating a self-contained running example that gets you close and show what the final output should be. David J.

Re: [GENERAL] regexp_matches where clause - PG 9.1

2017-04-07 14:19 GMT+12:00 David G. Johnston : > On Thu, Apr 6, 2017 at 7:15 PM, Patrick B > wrote: > >> >> David, >> That won't work. >> > > ​Actually, it works fine, you just keep moving the under-specified problem > space. > ​ > I'd suggest creating a self-contained running example that gets y

Re: [GENERAL] A change in the Debian install

On Thu, 2017-04-06 at 15:58 -0700, Adrian Klaver wrote: > On 04/06/2017 03:16 PM, rob stone wrote: > > > > > > Which is what has me confused. If you are using the postgresql- > common  > system then the *.conf files should be in  > /etc/postgresql/version/cluster_name/. > > Where exactly is P

Re: [GENERAL] A change in the Debian install

On 04/06/2017 08:01 PM, rob stone wrote: On Thu, 2017-04-06 at 15:58 -0700, Adrian Klaver wrote: On 04/06/2017 03:16 PM, rob stone wrote: Which is what has me confused. If you are using the postgresql- common system then the *.conf files should be in /etc/postgresql/version/cluster_name/.

Re: [GENERAL] keeping WAL after dropping replication slots

Hi, 2017-04-06 21:51 GMT+02:00 Adrian Klaver : > On 04/04/2017 11:52 PM, Tom DalPozzo wrote: > >> Hi, >> >> 2017-04-05 1:55 GMT+02:00 Adrian Klaver > >: >> >> On 04/04/2017 07:45 AM, Tom DalPozzo wrote: >> >> Postgres version? >> >> 9.6.1 >> >> >>

Re: [GENERAL] keeping WAL after dropping replication slots

Postgres version? 9.6.1 Have you considered upgrading to 9.6.2? There were some fixes, including WAL related: https://www.postgresql.org/docs/9.6/static/release-9-6-2.html Not exactly regarding what you see, though... Bye, Chris. -- Sent via pgsql-general mailing lis