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.
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: s
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 lower
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 abou
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 t
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
"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 tup
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?
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 sup
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
"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 e
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
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
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 broad
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?
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?
reg
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
>>> performan
"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
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 work
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
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 o
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 lan
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 t
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
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 us
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 we'
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
>>> str
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 qui
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 repl
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 p
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 t
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 tabl
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 sug
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"
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 cat
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 cove
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
http://developer.
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
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 postgres
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
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.
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'
(u
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 w
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 with
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 broadcast)-
"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
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'
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.
>
>
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
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 s
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
bu
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 so
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.
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.
>
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
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 authenticatio
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 sugg
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 th
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 appro
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 de
60 matches
Mail list logo
