On Sun, Jul 22, 2007 at 08:05:12PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Somewhere along the way we seem to have made the syslogger's shutdown
message go to stderr, even if we have redirected it:
I'm pretty sure it has done that all along; at least the design
On Sun, 2007-07-22 at 08:53 -0700, Josh Berkus wrote:
Pavel Stehule wrote:
Hello,
I checked my tests again I have different results. Now I tested
PostgreSQL on dedicated server. Now 8.3 is about 20% faster. I didn't
see strong impression of autovacuum. All numbers are approximate
On Sat, 2007-07-21 at 13:30 -0400, Tom Lane wrote:
Note to all: we ***HAVE TO*** settle on some reasonable default
vacuum_cost_delay settings before we can ship 8.3. With no cost delay
and two or three workers active, 8.3's autovac does indeed send
performance into the tank.
Couple of
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had before, but now the
effects of two VACUUMs kill performance even more. I would suggest
I just came across yet another place where MingW isn't compatible with the
windows api. Specifically, their libsecur32.a file lacks at least one
function that is needed to implement SSPI authentication. The way I can see
it, there are three ways to solve it:
1) Simply state that SSPI
On Mon, 2007-07-23 at 10:04 +0100, Heikki Linnakangas wrote:
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had before, but now the
Magnus Hagander wrote:
I just came across yet another place where MingW isn't compatible with the
windows api. Specifically, their libsecur32.a file lacks at least one
function that is needed to implement SSPI authentication. The way I can see
it, there are three ways to solve it:
Ugh.
1)
On Mon, Jul 23, 2007 at 11:06:59AM +0100, Dave Page wrote:
Magnus Hagander wrote:
I just came across yet another place where MingW isn't compatible with the
windows api. Specifically, their libsecur32.a file lacks at least one
function that is needed to implement SSPI authentication. The
Dave Page wrote:
Magnus Hagander wrote:
I just came across yet another place where MingW isn't compatible with the
windows api. Specifically, their libsecur32.a file lacks at least one
function that is needed to implement SSPI authentication. The way I can see
it, there are three ways to
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Anyway, if you believe that DDL is infrequent, why are you resistant
to the idea of WAL-logging cache flushes?
First, cache invalidations are not the only problem caused by replaying
system-table updates. The whole SnapshotNow
I've been debugging some really weird crashes in libpq on win32, and I
think I've finally found the reason for the heap corruption that shows up
in msvc debug mode.
When run in debug mode, the runtime for msvc will *zero-pad the entire
buffer* in a strncpy() call. This in itself is not bad (just
Magnus Hagander [EMAIL PROTECTED] writes:
When run in debug mode, the runtime for msvc will *zero-pad the entire
buffer* in a strncpy() call. This in itself is not bad (just slow), but it
shows a rather bad bug in libpq.
[squint] That is the specified behavior of strncpy on every platform,
On Mon, Jul 23, 2007 at 10:28:57AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
When run in debug mode, the runtime for msvc will *zero-pad the entire
buffer* in a strncpy() call. This in itself is not bad (just slow), but it
shows a rather bad bug in libpq.
[squint]
Dave Page [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
1) Simply state that SSPI authentication in the backend cannot be built
with mingw, and require msvc build for it (the msvc api follows the windows
api, which is hardly surprising). We could add an autoconf test for it
that'd pick up
Florian G. Pflug [EMAIL PROTECTED] writes:
I came up with the following plan for both inval events and locks
.) Store two flags in the commit record of a transaction, for
transaction generated inval events and transaction held an
access exlusive lock.
.) Upon replay, block until no
Magnus Hagander [EMAIL PROTECTED] writes:
It could be interesting to have it write it *to the logfile* though, since
it'd then at least be in the same place as the others.
It does that too, no?
regards, tom lane
---(end of
On Mon, Jul 23, 2007 at 10:45:35AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
It could be interesting to have it write it *to the logfile* though, since
it'd then at least be in the same place as the others.
It does that too, no?
Ok, I admit writing that without
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
It could be interesting to have it write it *to the logfile* though, since
it'd then at least be in the same place as the others.
It does that too, no?
Yes, but if we make the message DEBUG1 it
Looking around the lc_messages stuff a bit, I notice it's set to
superuser-only.
I do use
ALTER USER joe SET lc_messages='sv_SE'
now and then to change the language for a user. And I see it's also
possible to use it on a database level by doing
ALTER DATABASE postgres SET lc_messages='sv_SE'
On Fri, Jul 20, 2007 at 10:32:35AM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Anyway, we detect this directly based on the C compiler's behavior,
and you can't argue with the compiler about it. Whatever it's
doing is right by definition.
Perhaps
Andrew Dunstan [EMAIL PROTECTED] writes:
Yes, but if we make the message DEBUG1 it won't normally. Still, I think
we could live with that. I'm not inclined to waste too much time on it.
Yeah. I think the only reason it was LOG initially was because the
syslogger was pretty experimental at the
Magnus Hagander wrote:
Looking around the lc_messages stuff a bit, I notice it's set to
superuser-only.
I do use
ALTER USER joe SET lc_messages='sv_SE'
now and then to change the language for a user. And I see it's also
possible to use it on a database level by doing
ALTER DATABASE
Magnus Hagander [EMAIL PROTECTED] writes:
Is there a reason for this?
Two arguments I can recall:
(1) Having log messages emitted in a language that the DBA can't read
would be a useful tactic for a Bad Guy trying to cover his tracks.
(2) Setting lc_messages to a value incompatible with the
It is so that the user cannot hide log messages he causes by setting the
language to something that the administrator cannot understand. (There are
more conceivable scenarios of that sort, such as exploiting the
administrator's ad hoc log parsing tool.)
--
Peter Eisentraut
On Mon, Jul 23, 2007 at 11:20:15AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Is there a reason for this?
Two arguments I can recall:
(1) Having log messages emitted in a language that the DBA can't read
would be a useful tactic for a Bad Guy trying to cover his
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Somebody had better double-check that. We don't need to be
pessimistic, we need to be *correct*, because the align values had
better match the way the compiler will lay out a C struct. Otherwise
struct-based access to catalog rows
Tom Lane wrote:
I see though that the comment in pg_config.h.win32 claims it was derived
from mechanically-generated configure output, so unless that's lying
it should be OK already.
It's not - it started out as a copy of the output of ./configure on mingw.
Started out as?
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had before, but now the
effects of two VACUUMs kill performance even more. I would
Hi,
I have a problem when trying to debug a shared library developed in C. Im
following the steps included in the docs, in chapter 33 (extending SQL),
section 33.9 (C-Language functions)
http://www.postgresql.org/docs/8.2/interactive/xfunc-c.html
Ive successfully compiled the example
On Mon, 2007-07-23 at 12:00 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had before, but now the
Simon Riggs wrote:
On Mon, 2007-07-23 at 12:00 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
The bad thing about having multiple autovacuum daemons active is that
you can get two large VACUUMs running at the same time. This gives you
the same small-VACUUM-starvation problem we had
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I came up with the following plan for both inval events and locks
.) Store two flags in the commit record of a transaction, for
transaction generated inval events and transaction held an
access exlusive lock.
.) Upon replay,
On 7/23/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Certainly it doesn't prevent starvation completely -- really there is no
way to completely prevent starvation unless you have as many workers as
you have tables, and one disk for each. What DSM does do is let the big
tables be vacuumed
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
Somebody had better double-check that. We don't need to be
pessimistic, we need to be *correct*, because the align values had
better match the way the compiler will lay out a C struct. Otherwise
struct-based access
On Jul 23, 2007, at 1:40 AM, Simon Riggs wrote:
Potential solution: Each autovac worker gets a range of table sizes
they
are allowed to VACUUM.
Anyone putting thought into this should check the archives; there was
quite a bit of discussion around it. For 8.3 we decided to KISS so
that
On Jul 22, 2007, at 8:54 AM, Josh Berkus wrote:
Tom,
Note to all: we ***HAVE TO*** settle on some reasonable default
vacuum_cost_delay settings before we can ship 8.3. With no cost
delay
and two or three workers active, 8.3's autovac does indeed send
performance into the tank.
I've been
Magnus Hagander wrote:
On Mon, Jul 23, 2007 at 10:28:57AM -0400, Tom Lane wrote:
Given this, I'll go ahead and fix fe-connect to support PQExpBuffers,
unless there are any objections.
I'm not against that, but I question what bug you've really found.
I never actually tested if it crashes on
Pavan Deolasee wrote:
On 7/23/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Certainly it doesn't prevent starvation completely -- really there is no
way to completely prevent starvation unless you have as many workers as
you have tables, and one disk for each. What DSM does do is let the big
Magnus Hagander [EMAIL PROTECTED] writes:
I also found at least one other place in libpq where it still does
fprintf(stderr). That should probably be fixed at the same time, right?
Yeah, we should be using the error message buffer if at all possible.
regards, tom lane
Magnus Hagander [EMAIL PROTECTED] writes:
I never actually tested if it crashes on mingw, but looking some more at it
it really should - once one of these errors happen.
Hm. Much easier than that - the code is new in HEAD. 8.2 did
fprintf(stderr). And HEAD still does that in at least one
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I never actually tested if it crashes on mingw, but looking some more at it
it really should - once one of these errors happen.
Hm. Much easier than that - the code is new in HEAD. 8.2 did
fprintf(stderr). And HEAD still does that in
Simon Riggs wrote:
On Sun, 2007-07-22 at 19:58 +0200, Florian G. Pflug wrote:
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
I'm currently working on correctly flushing the
catalog/relation/sgmr caches on a readonly PITR
slave during recovery.
I don't believe there is any
Sibte Abbas [EMAIL PROTECTED] writes:
I think printing the first 1K would make more sense.
If I understand you correctly, the code path which you are referring
to is the send_message_to_server_log() function in elog.c?
No, the place that has to change is where errstart() detects that we're
Jim Nasby wrote:
On Jul 22, 2007, at 8:54 AM, Josh Berkus wrote:
Tom,
Note to all: we ***HAVE TO*** settle on some reasonable default
vacuum_cost_delay settings before we can ship 8.3. With no cost delay
and two or three workers active, 8.3's autovac does indeed send
performance into the
Alvaro Herrera [EMAIL PROTECTED] writes:
OK, 20ms it is then. Here is a patch. I am taking the liberty to also
lower the vacuum and analyze threshold default values to 50, per
previous discussion.
Patch probably needs to touch docs (config.sgml at least) too?
In reference to
http://archives.postgresql.org/pgsql-jdbc/2007-02/msg00116.php
Which backend developers can assist to modify the
server to allow a modified UTF8?
Thanks
cody
Got a little couch potato?
Cody Bennett wrote:
In reference to
http://archives.postgresql.org/pgsql-jdbc/2007-02/msg00116.php
Which backend developers can assist to modify the
server to allow a modified UTF8?
I suspect you'll need divine intervention ...
cheers
andrew
---(end of
On 7/23/07, Tom Lane [EMAIL PROTECTED] wrote:
No, the place that has to change is where errstart() detects that we're
recursing. We could possibly have it first try to make a shorter string
and only give up entirely if recursion happens again, but given that
this is such a corner case I don't
On Sat, 2007-07-21 at 12:20 +0100, Simon Riggs wrote:
I'd like to help where I can if nobody else is currently doing this. I
would focus initially on some analysis of the various use cases to give
a better view on what we would need B-tree, clustered indexes and bitmap
indexes to do for us.
Simon Riggs [EMAIL PROTECTED] writes:
... BMI is not useful at all
for PKs, whilst GIT is specifically designed to handle them.
This seems a strange statement, because GIT doesn't look particularly
efficient for unique indexes AFAICS. In the worst case you'd have to
look individually at each
On Mon, 2007-07-23 at 17:19 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
... BMI is not useful at all
for PKs, whilst GIT is specifically designed to handle them.
This seems a strange statement, because GIT doesn't look particularly
efficient for unique indexes AFAICS. In
On 7/18/07, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't think we're ever going to fix things for the 7.3 error you're
getting - please take it out of your rotation. 7.3 isn't quite as dead
as Joshua suggested earlier, but it's certainly on life support.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
OK, 20ms it is then. Here is a patch. I am taking the liberty to also
lower the vacuum and analyze threshold default values to 50, per
previous discussion.
Patch probably needs to touch docs (config.sgml at least) too?
That's
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
I am taking the liberty to also lower the vacuum and analyze threshold
default values to 50, per previous discussion.
Did we also reach any consensus about lowering the percentage of dead tuples
in a table
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
I am taking the liberty to also lower the vacuum and analyze threshold
default values to 50, per previous discussion.
Did we also reach any consensus about lowering the percentage of dead
Hi,
I noticed in 8.3 there are chances where we can avoid WAL logging. For
example, 8.3's pgbench was modified to use TRUNCATE right before
COPY. Is there any documentation which describes that kind of
techniques? If there's none, I would volunteer the work to create such
a documentation since I
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
I am taking the liberty to also lower the vacuum and analyze threshold
default values to 50, per previous discussion.
Did we also reach any consensus about lowering the
Alvaro Herrera wrote:
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
I am taking the liberty to also lower the vacuum and analyze threshold
default values to 50, per previous discussion.
Did we also reach any consensus about lowering
The GucContext of log_autovacuum is PGC_BACKEND in the CVS HEAD,
but should it be PGC_SIGHUP? We cannot modify the variable on-the-fly
because the parameter is used only by autovacuum worker processes.
The similar variables, like autovacuum_vacuum_scale_factor, are
defined as PGC_SIGHUP.
Index:
Alvaro Herrera [EMAIL PROTECTED] wrote:
We didn't, but while I agree with the idea, I think 5% is too low. I
don't want autovacuum to get excessively aggressive. Is 10% not enough?
I think the threshold should be a little less than PCTFREE of indexes,
to avoid splitting of btree leaves. It
60 matches
Mail list logo
