Thanks for the reply,
Been reading hackers of Aug 2004 and found the threads. It's a common habit to
create two lines on the configuration files, in order to maintain the copy of the
default conf file. I guess this should be the worst scenery for a freshly incoming DBA
trying to put things in
This issue was resently discussed on hackers. It is a known issue, not very
convinient for the user. Nevertheless it is not fixed in 8.0, but will
perhaps be addressed in the next major release.
(Remembering, it was a non-trivial thing to change.)
Best Regards,
Michael Paesold
G u i d o B a r o s
Again me,
To make it easier.
Situation A:
log_something = true
Situation B:
# log_something =
Situation C:
log_something = false
After the pg_ctl reload:
Situation B = Situation A
Situation C <> (Situation A || Situation B)
Is this the expected behavior?
Conclusion:
If you comment a
The solution appeared as something I didn't know
On the .conf file
Previous situation:
#log_something=false
log_something=true
Worst situation
#log_something=false
#log_something=true
Nice situation
log_something=false
#log_something=true
Ok, the problem was that I assumed that commentin
Am Mittwoch, 1. September 2004 12:06 schrieb G u i d o B a r o s i o:
> The problem is the time that the postgres takes to perform/return a
> query. For example, trying the \d command takes between 4 or 5
> seconds. This table is very big, but I am not asking for the rows, only
> asking the tabl
Dear all,
I am currently experiencing troubles with the performance of my critical's database.
The problem is the time that the postgres takes to perform/return a query. For
example, trying the \d command takes between 4 or 5 seconds. This table is
very big, but I am not asking for the row
