On 2/19/07, Greg Smith [EMAIL PROTECTED] wrote:
log_destination = 'stderr,sql' # Valid values are combinations of
# stderr, syslog, sql, and eventlog,
# depending on platform.
+1
# These are relevant when logging to sql:
log_sql_table = 'pg_log'
Attached is the long-awaited guc patch that makes values fall back to their
default values when they got removed (or commented) from the configuration
file. This has always been a source of confusion.
There are three not-so-obvious cases that I'd like to comment:
First one:
In the configuration
Guillaume Smet escribió:
On 2/19/07, Greg Smith [EMAIL PROTECTED] wrote:
log_destination = 'stderr,sql' # Valid values are combinations of
# stderr, syslog, sql, and eventlog,
# depending on platform.
+1
Please don't do that. We already have a
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Please don't do that. We already have a combined GUC option that is
used to change two different things (DateStyle) and I regularly see
people confused about how to use it.
Perhaps I don't understand your combined GUC option but ISTM it's
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Here is a patch further cleaning up dummy process startup and the
bootstrap code itself a little.
Could we please call the dummy processes something else? Dummy
seems a bit belittling for such important things like bgwriter
Guillaume Smet escribió:
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Please don't do that. We already have a combined GUC option that is
used to change two different things (DateStyle) and I regularly see
people confused about how to use it.
Perhaps I don't understand your combined
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Here is a patch further cleaning up dummy process startup and the
bootstrap code itself a little.
Could we please call the dummy processes something else? Dummy
seems a bit belittling for such
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I don't think the syslog option is so nice to use these days; the
redirect_stderr stuff is more powerful and easy to use.
Did you already analyze logs of a highly loaded platform using stderr?
It's impossible to guarantee the consistency of
Guillaume Smet escribió:
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I don't think the syslog option is so nice to use these days; the
redirect_stderr stuff is more powerful and easy to use.
Did you already analyze logs of a highly loaded platform using stderr?
It's impossible to
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW I've got serious reservations about whether this bit is safe:
+ /* The table could've grown since vacuum
started, and there
+ * might already be dead
Guillaume Smet escribió:
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
So add the session ID (%c) to log_line_prefix.
It could work if log_line_prefix was added before every line but it's
definitely not the case:
myuser mydb 45d9d615.4abe LOG: duration : 185.223 ms, statement :
Updated version applied. I reduced the numering changes for the macros.
There was also documentation text for dow and a few others that said
(for typetimestamp/type values only), but in fact the field worked
for timestamptz and date too, so I removed the mentions. If people
get confused, I
Alvaro Herrera wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW I've got serious reservations about whether this bit is safe:
+ /* The table could've grown since vacuum started, and
there
+* might already
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
On Mon, 2007-02-19 at 19:38 +, Simon Riggs wrote:
On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
Chris Campbell [EMAIL PROTECTED] writes:
Is there additional logging information I can turn on to get
Did we come to a conclusion on this?
---
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The consequence will be, though, that psql will accept a syntax
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Please put this on hold until we decide what to do
Alvaro Herrera wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Please put this on hold
Alvaro Herrera [EMAIL PROTECTED] wrote:
Please put this on hold until we decide what to do with Heikki's patch
to update OldestXmin during vacuum.
Yes, I think his patch is very useful, but it has a little conflict
with my patch.
One idea is to count the tuples actually cleared during
OK, I took Korry's gmon.out patch and Nikhil's configure.in patch and
made a combined version. It seems the gmon.out and -pg flags are
GCC-specific, rather than being platform-specific, so what I did was to
allow --enable-profiling to only work with GCC.
Patch attached.
I think I'll go with Tom's Plan B for HEAD, but not do anything more for
8.2 than has already been done.
cheers
andrew
Bruce Momjian wrote:
Did we come to a conclusion on this?
---
Andrew Dunstan wrote:
Andrew
Here is a preliminary patch for removing Query from the executor API.
I've created a new top plan node type, which I chose to call
PlannedStmt. I have not yet done anything about replacing the runtime
representation of the range table, but I'm intending to tackle that after
completing this part.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is not a bug, this is a definitional disagreement, and your TODO
entry presupposes an answer that I don't particularly agree with.
Well, our documentation suggests thaat [1] is the same as [1:1]:
Guillaume Smet [EMAIL PROTECTED] writes:
(each query is run on a different backend). With stderr you don't have
sufficient information to know the query you should append the text
to. Syslog adds useful context information (pid, command line, command
number) which allows you to guarantee the
Tom Lane escribió:
Guillaume Smet [EMAIL PROTECTED] writes:
(each query is run on a different backend). With stderr you don't have
sufficient information to know the query you should append the text
to. Syslog adds useful context information (pid, command line, command
number) which
Bruce Momjian [EMAIL PROTECTED] writes:
+ CFLAGS=$CFLAGS -DPROFILE_PID_DIR -pg ${PROFILE_CFLAGS}
Kindly use AC_DEFINE instead of random -D in CFLAGS (which is the wrong
place for -D anyway). Also, what exactly is the point here of
PROFILE_CFLAGS? I thought it was supposed to allow
Reposting - looks like the message did not get through in the first
attempt. My apologies if multiple copies are received.
This is the next version of the HOT WIP patch. Since the last patch that
I sent out, I have implemented the HOT-update chain pruning mechanism.
When following a HOT-update
Ühel kenal päeval, T, 2007-02-20 kell 12:08, kirjutas Pavan Deolasee:
Reposting - looks like the message did not get through in the first
attempt. My apologies if multiple copies are received.
This is the next version of the HOT WIP patch. Since the last patch
that
I sent out, I have
29 matches
Mail list logo
