sorry, actually becuase of one printf statement(i have added) because of
that, these has been occured. My mistake
On Mon, May 23, 2011 at 9:06 AM, Robert Haas wrote:
> On Sun, May 22, 2011 at 6:42 AM, Nick Raj wrote:
> > I am using contrib/cube code. I am building GIST index on cube data type
>
On Sun, May 22, 2011 at 6:42 AM, Nick Raj wrote:
> I am using contrib/cube code. I am building GIST index on cube data type
> then it leads to a very large size of log file (nearly 220 MB for only 12k
> records).
> While creating index on geometry field with gist gives 1KB size of log file
> for 1
Hi,
I am using contrib/cube code. I am building GIST index on cube data type
then it leads to a very large size of log file (nearly 220 MB for only 12k
records).
While creating index on geometry field with gist gives 1KB size of log file
for 17 lakh records.
Can someone please tell me how to stop
> > If I configure log_destination='eventlog', and then
> > redirect_stderr='on', PostgreSQL will attempt to create a
> logfile in
> > pg_log anyway.
>
> So don't do that --- redirect_stderr is only sensible to turn
> on if you mean to use logging to stderr.
I don't. Normally. But I had it tu
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> If I configure log_destination='eventlog', and then
> redirect_stderr='on', PostgreSQL will attempt to create a logfile in
> pg_log anyway.
So don't do that --- redirect_stderr is only sensible to turn on if you
mean to use logging to stderr.
The re
Digging into several win32 related issues right now, so I don't have the
time to investigate ATM, but I figured I should get it out here:
If I configure log_destination='eventlog', and then
redirect_stderr='on', PostgreSQL will attempt to create a logfile in
pg_log anyway. This file remains empty
Bruce Momjian wrote:
Actually, this is the current state of this issue.
Right, please comment on this. To recall, it uses shared memory for a
"switch to next logfile name" flag, which can't cause harm in case of
shmem corruption, and a postmaster opened filehandle (kept open) to a
dummy file
Actually, this is the current state of this issue.
---
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >Andreas Pflug <[EMAIL PROTECTED]> writes:
> >
> >
> >>>Answering my own question, the distribution of the current logfile
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Answering my own question, the distribution of the current logfile
name could be done trough a file handle.
would you mind commenting on my suggestion so I can continue on that topic?
There is no portable way to redistribu
Andreas Pflug <[EMAIL PROTECTED]> writes:
>> Answering my own question, the distribution of the current logfile
>> name could be done trough a file handle.
> would you mind commenting on my suggestion so I can continue on that topic?
There is no portable way to redistribute a file handle.
Andreas Pflug wrote:
Andreas Pflug wrote:
We agreed long ago that the
postmaster should never depend on the correctness of any shared memory
data structure; but this patch would make it do so.
I understand that, so what's the suggested way to store data common
for all backends?
Answering my o
Andreas Pflug wrote:
We agreed long ago that the
postmaster should never depend on the correctness of any shared memory
data structure; but this patch would make it do so.
I understand that, so what's the suggested way to store data common
for all backends?
Answering my own question, the dist
Tom Lane wrote:
I'll repeat what I said in response to your other posting:
Hm? I never posted something with shared mem usage before, what do you mean?
This uses a shared memory area with no lock, which seems a bad design;
AFAICS there should be no lock necessary.
We agreed long ago that the
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom doesn't like returning the server's logfile using a pgsql function
> unless logfile rotation is implemented, so here it is.
I'll repeat what I said in response to your other posting:
This uses a shared memory area with no lock, which seems a bad des
Tom doesn't like returning the server's logfile using a pgsql function
unless logfile rotation is implemented, so here it is.
This proposal doesn't include a daemon that triggers pg_logfile_rotate
when appropriate (timestamp and/or length dependent), pg_autovacuum
might be a good place to do that
15 matches
Mail list logo
