On Sun, 2006-04-02 at 20:39 -0700, Martin Scholes wrote:
The lesson here is that whatever WAL magic has been performed on the
latest release gives over 100% speedup
That is good news.
and the speedup is so good that skipping WAL for indexes does
basically nothing.
I don't agree with this
Fixed in cvs for 7.4-8.2 releases.
Michael Fuhr wrote:
On Sat, Apr 01, 2006 at 03:40:19PM +0200, jeroen van iddekinge wrote:
When using intarray operator in a query, postgres dies and restart
itself when executing the following query:
select r1.bet_sentence r2.bet_sentence
from related
Title: Converted from Rich Text
Tom Lane wrote:
[ scratches head ... ] Actually, I'd have expected that you could still measure a difference. I thought it might be reduced to the point where we arguably shouldn't spend major effort on eliminating it. But no
difference at all
Hi!
I has needed deferrable constraint CHECK, but i'm sorry, because it has
not implemented.
I has studied the postgresql source code, and i think there are three
possibilities in implementation:
1. implementing deferrable check. It is not easy (there is no deferred
constraint manager), but
Simon Riggs [EMAIL PROTECTED] writes:
Thinking about this some more, I ask myself: why is it we log index
inserts at all? We log heap inserts, which contain all the information
we need to replay all index inserts also, so why bother?
(1) We can't run user-defined functions during log replay.
On Mon, 2006-04-03 at 09:55 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Thinking about this some more, I ask myself: why is it we log index
inserts at all? We log heap inserts, which contain all the information
we need to replay all index inserts also, so why bother?
I
Ühel kenal päeval, E, 2006-04-03 kell 01:48, kirjutas Tom Lane:
Martin Scholes [EMAIL PROTECTED] writes:
Ok Tom, I stand corrected.
I downloaded the latest snapshot and both scenarios (normal and WAL bypass =
for indexes) produced between 185 and 230 tps on my machine.
The lesson here
Ühel kenal päeval, E, 2006-04-03 kell 09:55, kirjutas Tom Lane:
(2) Some of the index code is itself deliberately nondeterministic.
I'm thinking in particular of the move-right-or-not choice in
_bt_insertonpg() when there are many equal keys, but randomization is
in general a useful
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, E, 2006-04-03 kell 09:55, kirjutas Tom Lane:
(2) Some of the index code is itself deliberately nondeterministic.
I'm thinking in particular of the move-right-or-not choice in
_bt_insertonpg() when there are many equal keys, but
Robert Watson [EMAIL PROTECTED] writes:
However, pid's in general uniquely identify a process only at the time they
are recorded. So any pid returned here is necessarily stale -- even if there
is another process with the pid returned by GETPID, it may actually be a
different process that
Robert Watson [EMAIL PROTECTED] writes:
Maybe I've misunderstood the problem here -- is the use of the GETPID
operation occuring within a coordinated set of server processes, or does it
also occur between client and server processes? I think it's quite
reasonable
to argue that a
Robert Watson [EMAIL PROTECTED] writes:
Any multi-instance application that uses unvirtualized System V IPC must know
how to distinguish between those instances.
Sure.
How is PostgreSQL deciding what semaphores to use? Can it be instructed to
use non-colliding ones by specifying an
I wanted to look through the SQL:2003 standard to update our conformance
feature list, but I noticed that the list of enumerated features is
exactly the same as in SQL:1999. So either I have an old draft that
does not have an updated feature taxonomy, or all the new features in
2003 are
On Apr 3, 2006, at 12:37 PM, Tom Lane wrote:
semaphore keys on each cycle of life, so you'd have to get fooled by
chance coincidence of existing PIDs every time over many cycles to
have a severe resource-leakage problem. (BTW, Marc, that's the reason
for *not* randomizing the key selection as
On Apr 1, 2006, at 16:37, Tom Lane wrote:
Just to clarify my point: what'd make sense to me is to describe this
generic autoconf behavior, and maybe include a small table listing
some
of the more-likely-to-be-useful variables. (configure --help
already
does that, on a very small scale.)
David Wheeler wrote:
But I'm not sure what other variables are supported.
I'm not sure if this list is complete, but it's a good approximation:
AWK
CC
CFLAGS
COLLATEINDEX
CPP
CPPFLAGS
DOCBOOKSTYLE
JADE
LDFLAGS
LDFLAGS_SL
LORDER
MSGFMT
MSGMERGE
NSGMLS
PERL
PTHREAD_CC
PYTHON
RANLIB
SGMLSPL
STRIP
* Tom Lane ([EMAIL PROTECTED]) wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a postmaster process is
terminated unexpectedly (ye olde
* Tom Lane ([EMAIL PROTECTED]) wrote:
BTW, Marc, it occurs to me that a workaround for you would be to create
a separate userid for postgres to run under in each jail; then the
regular protection mechanisms would prevent the different postmasters
from interfering with each others' semaphore
Stephen Frost [EMAIL PROTECTED] writes:
Could this be handled sensibly by using SEM_UNDO? Just a thought.
Interesting thought, but I think it doesn't work for the special case
where the semaphore's previous owner is actually our same PID ---
which is actually the more commonly exercised path,
On Apr 3, 2006, at 13:08, Peter Eisentraut wrote:
I'm not sure if this list is complete, but it's a good approximation:
Thanks. How's this, then?
Best,
David
--- configure 06 Mar 2006 09:41:42 -0800 1.485
+++ configure 03 Apr 2006 13:31:10 -0700
@@ -897,16 +897,36 @@
David Wheeler wrote:
On Apr 3, 2006, at 13:08, Peter Eisentraut wrote:
I'm not sure if this list is complete, but it's a good approximation:
Thanks. How's this, then?
Too verbose :-( How about putting the most important in configure, and
the rest in a text file? Configure can then say
David Wheeler wrote:
On Apr 3, 2006, at 13:08, Peter Eisentraut wrote:
I'm not sure if this list is complete, but it's a good
approximation:
Thanks. How's this, then?
configure is autogenerated. You can't patch in there.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Apr 3, 2006, at 13:37, Alvaro Herrera wrote:
Too verbose :-( How about putting the most important in configure,
and
the rest in a text file? Configure can then say Some of them are
here,
the rest can be found in file such-and-such.
Yeah, I'll create a table for INSTALL.
Best,
David
On Apr 3, 2006, at 13:44, Peter Eisentraut wrote:
configure is autogenerated. You can't patch in there.
Oh. Duh. I'll grep for it.
D
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
On Apr 3, 2006, at 13:49, David Wheeler wrote:
configure is autogenerated. You can't patch in there.
Oh. Duh. I'll grep for it.
Hrm. Is there a file somewhere from which the environment variable
section is generated? Or is it just created by autoconf?
Thanks,
David
David Wheeler [EMAIL PROTECTED] writes:
Hrm. Is there a file somewhere from which the environment variable
section is generated? Or is it just created by autoconf?
I believe that most of the configure --help text is autogenerated
by autoconf, and you're probably not going to have much luck
David Wheeler wrote:
Hrm. Is there a file somewhere from which the environment variable
section is generated? Or is it just created by autoconf?
Compare with
AC_ARG_VAR(DOCBOOKSTYLE, [location of DocBook stylesheets])dnl
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
* Robert Watson ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is certainly a problem with FBSD jails... Not only the
inconsistancy, but what happens if someone manages to get access to the
appropriate uid under one jail and starts sniffing or messing with the
Jonah H. Harris wrote:
As long as it's optional, I guess it's OK to let the administrator
deal with recovery. Of course, in addition to no-fsync, we'll have
another *possibly* dangerous option. BTW, I've seen no-fsync used far
too many times because people think they're hardware is
On Mon, 3 Apr 2006, Stephen Frost wrote:
* Robert Watson ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is certainly a problem with FBSD jails... Not only the
inconsistancy, but what happens if someone manages to get access to the
appropriate uid under one jail and
On Apr 2, 2006, at 6:13 PM, Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
On 4/2/06, Tom Lane [EMAIL PROTECTED] wrote:
If you're expecting that you'll be able to write BYTEA(n) and avoid
storing a length word, you'll find that it's not a trivial matter.
It may not be trivial,
* Marc G. Fournier ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
Running the Postgres instances under different uids (as you'd probably
expect to do anyway if not using the jails) is probably the right
approach. Doing that and using jails would probably work, just don't
Last summer, I wrote:
[ http://archives.postgresql.org/pgsql-hackers/2005-07/msg00320.php ]
It occurs to me that a cleaner solution would be to stop giving domain
types the same typinput routines as their base types. Instead, give
them all a specialized routine domain_in (comparable to
On Mon, Apr 03, 2006 at 01:31:50PM -0400, Jim Nasby wrote:
I'm not sure how other databases handle this, but I suspect it would
be OK performance-wise to tack on a length byte for these types when
dealing with functions and anything else that isn't directly tied to
a table where you can
34 matches
Mail list logo
