Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I don't think we should care too much about indexes. We can rebuild
them...but losing heap sectors means *data loss*.
If you're so concerned about *data loss* then none of this will be
acceptable to you at all. We are talking about
Am Freitag, 15. Juli 2005 14:19 schrieb Greg Sabino Mullane:
The use case is when you want to prepare a query, but only if it's not
already prepared on that connection.
This has been covered before, but to reiterate: why would you need this?
Any application worth its salt should be tracking
On Fri, Jul 15, 2005 at 08:06:15PM -0500, Kris Jurka wrote:
On Fri, 15 Jul 2005, Marko Kreen wrote:
[buildfarm machine dragonfly]
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
Well the buildfarm machine kudu is actually the same machine just
building
with the Sun
I don't think our problem is partial writes of WAL, which we already
check, but heap/index page writes, which we currently do not check for
partial writes.
---
Kevin Brown wrote:
Tom Lane wrote:
Simon Riggs [EMAIL
Rod Taylor wrote:
This may sound silly, but any chance we could change autovacuum_* GUC
variables to be vacuum_auto_* instead?
This way when you issue a SHOW ALL, all of the vacuum related parameters
would be in the same place.
Well, the autovacuum items control just autovacuum, while
On Sat, 2005-07-16 at 08:17 -0400, Bruce Momjian wrote:
Rod Taylor wrote:
This may sound silly, but any chance we could change autovacuum_* GUC
variables to be vacuum_auto_* instead?
This way when you issue a SHOW ALL, all of the vacuum related parameters
would be in the same place.
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
Well the buildfarm machine kudu is actually the same machine just building
with the Sun compiler and it works fine. It links all of libz.a into
libpgcrypto.so while gcc refuses to.
I googled a
On Sat, 16 Jul 2005, Christopher Kings-Lynne wrote:
This has been covered before, but to reiterate: why would you need this?
Any application worth its salt should be tracking which statements it
has already prepared (after all, they cannot span connections). Seems
a waste of resources
On Sat, 16 Jul 2005, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
I googled a bit and found two suggestions:
1. http://curl.haxx.se/mail/lib-2002-01/0092.html
(Use -mimpure-text on linking line)
This sure seems like a crude band-aid rather than an actual solution.
The bug as
Kris Jurka [EMAIL PROTECTED] writes:
On Sat, 16 Jul 2005, Tom Lane wrote:
This sure seems like a crude band-aid rather than an actual solution.
The bug as I see it is that gcc is choosing to link libz.a rather than
libz.so --- why is that happening?
The link line says -L/usr/local/lib -lz
On Sat, 16 Jul 2005, Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
The link line says -L/usr/local/lib -lz and libz.a is in /usr/local/lib
while libz.so is in /usr/lib.
Well, that is a flat-out configuration error on the local sysadmin's
part. I can't think of any good
Kris Jurka [EMAIL PROTECTED] writes:
consider what would happen if the shared library didn't exist at all and
only a static version were available. Until this recent batch of pgcrypto
changes everything built fine.
Well, the right answer to that really is that pgcrypto ought not try to
link
Tom Lane wrote:
ISTM the point of the delay parameters
for autovac is to put a lid on its impact on interactive response. Seen
in that light, you do not care exactly which table it's hitting at the
moment.
Unless the table in question takes a big lock when it's VACUUMed
like tables with GiST
Bruce Momjian wrote:
I don't think our problem is partial writes of WAL, which we already
check, but heap/index page writes, which we currently do not check for
partial writes.
Hmm...I've read through the thread again and thought about the problem
further, and now think I understand what
I spent a little time today cleaning up easily-fixed problems that are
causing buildfarm failures in various back branches. Hopefully that
will result in a few more green entries over the new few days. While
I was looking, I noticed several machines that seem to be failing
because of local
Pete St. Onge [EMAIL PROTECTED] writes:
Perhaps this will help in the diagnosis of why REL7_2_STABLE fails on
arbor (aka caribou). Please let me know if there is anything I can try
on this side, or if there is any other info you could use.
[EMAIL PROTECTED]:~$ flex -V
flex 2.5.31
Ah. PG
Hi all,
This small patch improves the performance of INSERT and UPDATE. By my
machine, these changes raised the performance about 5%~10% in pgbench.
Please take a benchmark in a reliable environment. Since I may forget
some required changes, I specify that this patch is experimental. But
note
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
ISTM the point of the delay parameters
for autovac is to put a lid on its impact on interactive response. Seen
in that light, you do not care exactly which table it's hitting at the
moment.
Unless the table in question takes a big lock
Hiroki Kataoka [EMAIL PROTECTED] writes:
This small patch improves the performance of INSERT and UPDATE. By my
machine, these changes raised the performance about 5%~10% in pgbench.
Wouldn't it be a lot less invasive to search down from the end, instead
of changing the page header format?
Hiroki Kataoka [EMAIL PROTECTED] writes:
This small patch improves the performance of INSERT and UPDATE. By my
machine, these changes raised the performance about 5%~10% in pgbench.
BTW, in profiling the backend I've never seen PageAddItem take more than
about 1% of the runtime, and in pgbench
20 matches
Mail list logo
