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 c
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 ar
* 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
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 triv
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 s
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 invin
* 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 th
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/
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 lu
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
---
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?
http://www.postgresql.org/d
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,
Davi
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/
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 s
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 @@
--with
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
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 pat
* 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
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.)
* 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 often-recomme
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
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 mandat
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 al
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 co
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 th
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, b
Ü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 algori
Ü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.
>
> > T
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
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 repla
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
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 al
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 r1,r
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 th
34 matches
Mail list logo
