Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread Tom Lane
"David G. Johnston" writes: > ​Admittedly, I'm not sure how you would fix any problems without access to > the server and its config files - at which point you are back to simply > reviewing those. Yeah. Other related problems include being unable to *find* the log

Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread Adrian Klaver
On 04/07/2016 10:06 AM, Alex Ignatov wrote: On 07.04.2016 17:59, Rob Sargent wrote: On Apr 7, 2016, at 8:26 AM, Alex Ignatov wrote: On 07.04.2016 16:53, Tom Lane wrote: Alex Ignatov writes: My question is: is there any option(s) to

Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread David G. Johnston
On Thu, Apr 7, 2016 at 10:37 AM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Thu, Apr 7, 2016 at 10:06 AM, Alex Ignatov > wrote: > >> It matter when your pg host is down and all you have is log file. It is >> very usual situation. You need historical

Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread David G. Johnston
On Thu, Apr 7, 2016 at 10:06 AM, Alex Ignatov wrote: > It matter when your pg host is down and all you have is log file. It is > very usual situation. You need historical info. ​I think this would be a good idea. Is it something you are thinking of writing now that

Re: [GENERAL] what database schema version management system to use?

2016-04-07 Thread John R Pierce
On 4/7/2016 3:21 AM, Berend Tober wrote: John R Pierce wrote: On 4/6/2016 3:55 AM, Alexey Bashtanov wrote: I am searching for a proper database schema version management system. At my $job we're old school. our schemas are versioned. there's a settings table with (setting TEXT, value

Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread Alex Ignatov
On 07.04.2016 17:59, Rob Sargent wrote: On Apr 7, 2016, at 8:26 AM, Alex Ignatov wrote: On 07.04.2016 16:53, Tom Lane wrote: Alex Ignatov writes: My question is: is there any option(s) to log non-default postgresql.conf values to log

Re: [GENERAL] 9.5 new features

2016-04-07 Thread Alvaro Herrera
I just noticed this old thread. Thomas Kellerer wrote: > > 62.1. Introduction > > ... > > "A block range is a group of pages that are physically adjacent in the > > table; for each block range, some summary info is stored by the index." > > > > From the above, may I presume that it is best to

Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread Rob Sargent
> On Apr 7, 2016, at 8:26 AM, Alex Ignatov wrote: > > > >> On 07.04.2016 16:53, Tom Lane wrote: >> Alex Ignatov writes: >>> My question is: is there any option(s) to log non-default >>> postgresql.conf values to log file? >> No, but you

Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread Alex Ignatov
On 07.04.2016 16:53, Tom Lane wrote: Alex Ignatov writes: My question is: is there any option(s) to log non-default postgresql.conf values to log file? No, but you can easily find all the non-default settings by querying the pg_settings view.

Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread Tom Lane
Alex Ignatov writes: > My question is: is there any option(s) to log non-default > postgresql.conf values to log file? No, but you can easily find all the non-default settings by querying the pg_settings view. regards, tom lane -- Sent via

Re: [GENERAL] PostgreSQL 9.5.1 -> PG_REWIND NOT FOUND

2016-04-07 Thread Adrian Klaver
On 04/06/2016 11:31 PM, sgringer wrote: I have found it in this folder /usr/lib/postgresql/9.5/bin the command "pg_rewind" don't work globally like othe pg That is where the other Postgres commands are located also, correct? So can you access pg_dump, for example? -- Adrian Klaver

Re: [GENERAL] database is not accepting commands to avoid wraparound data loss in database

2016-04-07 Thread Merlin Moncure
On Wed, Apr 6, 2016 at 10:13 AM, pedrovlf wrote: > Hi, > > I'm following error in my DBMS, > > < 2016-04-05 17:02:42.053 BRT >ERROR: database is not accepting commands to > avoid wraparound data loss in database "zabbix" > < 2016-04-05 17:02:42.053 BRT >HINT: Stop the

Re: [GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread Christoph Moench-Tegeder
## Alex Ignatov (a.igna...@postgrespro.ru): > My question is: is there any option(s) to log non-default > postgresql.conf values to log file? Depending on your use case, I'd start with a simple query: SELECT name, setting FROM pg_settings WHERE source <> 'default' Wrap that in a COPY, or

Re: [GENERAL] Problem after replication switchover

2016-04-07 Thread Lars Arvidson
> If it's just storing the logs, I doubt it's the cause of the problem. You can > ignore my message. I had too much fun fighting with Gluster recently. Hehe, hope you came through on top ;). Anyways, I added an md5sum calculation in the archiving script just to be able to verify that the files

Re: [GENERAL] Trying to understand page structures in PG

2016-04-07 Thread Rakesh Kumar
On Wed, Apr 6, 2016 at 6:33 AM, Albe Laurenz wrote: > Rakesh Kumar wrote: > Every row has two system columns associated with it: xmin and xmax > > xmin is the transaction ID that created the row, while xmax is > the transaction ID that removed the row. > > So when an

[GENERAL] Non-default postgresql.conf values to log

2016-04-07 Thread Alex Ignatov
Hello! For example in oracle alert.log file we have: ... System parameters with non-default values: processes= 300 nls_language = "AMERICAN" nls_territory= "RUSSIA" memory_target= 720M control_files=

Re: [GENERAL] what database schema version management system to use?

2016-04-07 Thread Karsten Hilbert
On Thu, Apr 07, 2016 at 06:21:10AM -0400, Berend Tober wrote: > I would be interested in knowing specifically how the ".SQL file which > updates the previous version to the new version" is generated. Is there a > tool that does that based on the difference between new and old? Or is that > update

Re: [GENERAL] Deadlock between VACUUM and ALTER TABLE commands

2016-04-07 Thread Alexey Bashtanov
Hello Kevin, On 06/04/16 23:22, Kevin Burke wrote: /Why mess around with DISABLE/ENABLE TRIGGER instead of TRUNCATE?/ We observed that TRUNCATE took about 200ms, but this method takes about 13ms. Over a our test suite TRUNCATE is going to more or less double the length of the suite. We

Re: [GENERAL] PostgreSQL 9.5.1 -> PG_REWIND NOT FOUND

2016-04-07 Thread John R Pierce
On 4/6/2016 11:31 PM, sgringer wrote: I have found it in this folder /usr/lib/postgresql/9.5/bin the command "pg_rewind" don't work globally like othe pg $ export PATH=/usr/lib/postgresql/9.5/bin:$PATH $ pg_rewind --help -- john r pierce, recycling bits in santa cruz -- Sent via

Re: [GENERAL] PostgreSQL 9.5.1 -> PG_REWIND NOT FOUND

2016-04-07 Thread sgringer
I have found it in this folder /usr/lib/postgresql/9.5/bin the command "pg_rewind" don't work globally like othe pg -- View this message in context: http://postgresql.nabble.com/PostgreSQL-9-5-1-PG-REWIND-NOT-FOUND-tp5897145p5897332.html Sent from the PostgreSQL - general mailing list archive