"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
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
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
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
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
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
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
> 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
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.
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
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
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
## 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
> 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
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
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=
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
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
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
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
20 matches
Mail list logo