On Fri, 2005-10-28 at 12:50 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
There are a few issues with current FSM implementation, IMHO, discussing
as usual the very highest end of performance:
Do you have any evidence that the FSM is actually a source of
performance issues,
Just the one fail on OSX 10.3.9
opr_sanity ... FAILED
Is this a known problem, or something specific to my machine... I can post
regression.diffs (quite long) if required ...
Thanks
Adam
--
This message has been scanned for viruses and
dangerous content by MailScanner, and
--- Magnus Hagander wrote:
It should be fairly easy to write a LDAP backend to password
authentication using openldap, winldap or whatever ldap library is
available.
I support the idea. It would be a good gain for PostgreSQL
authentication.
If you want to discuss ideas, drop me a line.
Adam Witney wrote:
Just the one fail on OSX 10.3.9
opr_sanity ... FAILED
Is this a known problem, or something specific to my machine... I can post
regression.diffs (quite long) if required ...
Uh, regression.diffs is large? MY guess is your backend crashed, for
some
I can help on this one too.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Euler Taveira de
Oliveira
Sent: Monday, October 31, 2005 9:44 AM
To: Satoshi Nagayasu; Magnus Hagander
Cc: PostgreSQL-development
Subject: Re: [HACKERS] LDAP Authentication?
---
On 31/10/05 1:32 pm, Bruce Momjian pgman@candle.pha.pa.us wrote:
Adam Witney wrote:
Just the one fail on OSX 10.3.9
opr_sanity ... FAILED
Is this a known problem, or something specific to my machine... I can post
regression.diffs (quite long) if required ...
Uh,
Adam Witney wrote:
On 31/10/05 1:32 pm, Bruce Momjian pgman@candle.pha.pa.us wrote:
Adam Witney wrote:
Just the one fail on OSX 10.3.9
opr_sanity ... FAILED
Is this a known problem, or something specific to my machine... I can post
regression.diffs (quite long)
The developer.postgresql.org machine really isn't geared to handle
downloads.. Any reason you can't just stick it on the standard ftp sites
and have it mirrored along with everything else?
This is taken from our spec:
# Pre-release RPM's should not be put up on the public ftp.postgresql.org
On 31/10/05 2:13 pm, Bruce Momjian pgman@candle.pha.pa.us wrote:
Adam Witney wrote:
On 31/10/05 1:32 pm, Bruce Momjian pgman@candle.pha.pa.us wrote:
Adam Witney wrote:
Just the one fail on OSX 10.3.9
opr_sanity ... FAILED
Is this a known problem, or something specific
Adam Witney [EMAIL PROTECTED] writes:
http://bugs.sgul.ac.uk/downloads/temp/regression1.diffs
http://bugs.sgul.ac.uk/downloads/temp/regression2.diffs
http://bugs.sgul.ac.uk/downloads/temp/regression3.diffs
If you'd looked, you would have noticed that they're all variations on
psql: could not
Hello,
I tried RC1 on Tru64 box(with Compaq C V6.1-011)) and succeed :
bash-2.05b$ make MAX_CONNECTIONS=2 check
...
== shutting down postmaster ==
postmaster stopped
==
All 98 tests passed.
==
Environments:
- $
4x AMD Opteron (tm) Processor 852
-
[EMAIL PROTECTED] /tmp/pgtestbuild/postgresql-8.1RC1 $ uname -a
Linux localhost 2.6.12-gentoo-r10 #1 SMP Fri Sep 9 09:43:22 EDT 2005
x86_64 AMD Opteron (tm) Processor 852 AuthenticAMD GNU/Linux
Honda Shigehiro wrote:
Hello,
I tried RC1 on Tru64 box(with Compaq C V6.1-011)) and succeed :
bash-2.05b$ make MAX_CONNECTIONS=2 check
The seems to be a very low setting for MAX_CONNECTIONS. Any particular
reason for that?
(side note - we'd very much welcome a Tru64 buildfarm
From: Andrew Dunstan [EMAIL PROTECTED]
Subject: Re: [HACKERS] 8.1RC1 on Tru64
Date: Mon, 31 Oct 2005 11:12:09 -0500
I tried RC1 on Tru64 box(with Compaq C V6.1-011)) and succeed :
bash-2.05b$ make MAX_CONNECTIONS=2 check
The seems to be a very low setting for MAX_CONNECTIONS. Any
On Sun, Oct 30, 2005 at 06:17:53PM -0500, Tom Lane wrote:
I'd like Jim to test this theory by seeing if it helps to reverse the
order of the if-test elements at lines 294/295, ie make it look like
if (shared-page_status[slotno] != SLRU_PAGE_READ_IN_PROGRESS ||
Sorry, two more things...
Will increasing shared_buffers make this less likely to occur? Or is
this just something that's likely to happen when there are things like
seqscans that are putting buffers near the front of the LRU? (The 8.0.3
buffer manager does something like that, right?)
Is this
On Sun, Oct 30, 2005 at 05:31:07PM -0800, Josh Berkus wrote:
Folks,
Thanks, all! Now, if only I could remember who asked me the question ...
ISTM we should add a note about this to the docs...
Here's a patch for create_table.sgml, though there's probably some other
places this could go...
Jim C. Nasby wrote:
On Sun, Oct 30, 2005 at 06:17:53PM -0500, Tom Lane wrote:
I'd like Jim to test this theory by seeing if it helps to reverse the
order of the if-test elements at lines 294/295, ie make it look like
if (shared-page_status[slotno] != SLRU_PAGE_READ_IN_PROGRESS ||
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sun, Oct 30, 2005 at 06:17:53PM -0500, Tom Lane wrote:
This won't do as a permanent patch, because it isn't guaranteed to fix
the problem on machines that don't strongly order writes, but it should
work on Opterons, at least well enough to confirm the
On Mon, Oct 31, 2005 at 01:05:06PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sun, Oct 30, 2005 at 06:17:53PM -0500, Tom Lane wrote:
This won't do as a permanent patch, because it isn't guaranteed to fix
the problem on machines that don't strongly order writes, but it
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sun, Oct 30, 2005 at 06:17:53PM -0500, Tom Lane wrote:
This won't do as a permanent patch, because it isn't guaranteed to fix
the problem on machines that don't strongly order writes, but it should
work on Opterons, at least well
On Mon, Oct 31, 2005 at 01:01:14PM -0500, Bruce Momjian wrote:
This incident has made me wonder if it's worth creating two classes of
assertions. The (hopefully more common) set of assertions would be for
things that shouldn't happen, but if go un-caught won't result in heap
corruption. A
Jim C. Nasby wrote:
On Mon, Oct 31, 2005 at 01:01:14PM -0500, Bruce Momjian wrote:
This incident has made me wonder if it's worth creating two classes of
assertions. The (hopefully more common) set of assertions would be for
things that shouldn't happen, but if go un-caught won't result
On Mon, Oct 31, 2005 at 01:34:17PM -0500, Bruce Momjian wrote:
There is no way if the system has some incorrect value whether that
would later corrupt the data or not. Anything the system does that it
shouldn't do is a potential corruption problem.
But is it safe to say that there are areas
[EMAIL PROTECTED] (Tom Lane) writes:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3:
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php
[ shrug... ] The reports of this problem have not given enough
information to fix it,
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Tom Lane) writes:
(My guess is that the problem is a compiler or libc bug anyway,
given that one report says that replacing a memcpy call with an
equivalent loop makes the failure go away.)
It seems unlikely to be a compiler bug as
On 10/31/05, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Mon, Oct 31, 2005 at 01:34:17PM -0500, Bruce Momjian wrote:
There is no way if the system has some incorrect value whether that
would later corrupt the data or not. Anything the system does that it
shouldn't do is a potential corruption
Is this issue only on AIX 5.3 ML1 thru ML 3?
Does the build work fine with 5.2 (ALL MLs)?
On 10/31/05, Tom Lane [EMAIL PROTECTED] wrote:
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Tom Lane) writes:
(My guess is that the problem is a compiler or libc bug anyway,
given that
Mag Gam [EMAIL PROTECTED] writes:
Is this issue only on AIX 5.3 ML1 thru ML 3?
Does the build work fine with 5.2 (ALL MLs)?
There's an AIX 5.2 machine in the buildfarm, and it seems happy. I have
no idea about details beyond that ...
regards, tom lane
Now that I've got a little better idea of what this code does, I've
noticed something interesting... this issue is happening on an 8-way
machine, and NUM_SLRU_BUFFERS is currently defined at 8. Doesn't this
greatly increase the odds of buffer conflicts? Bug aside, would it be
better to set
Jim C. Nasby wrote:
Now that I've got a little better idea of what this code does, I've
noticed something interesting... this issue is happening on an 8-way
machine, and NUM_SLRU_BUFFERS is currently defined at 8. Doesn't this
greatly increase the odds of buffer conflicts? Bug aside, would it
On Thu, 20 Oct 2005 23:03:47 +0100
Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2005-10-19 at 14:07 -0700, Mark Wong wrote:
This isn't exactly elegant coding, but it provides a useful improvement
on an 8-way SMP box when run on 8.0 base. OK, lets be brutal: this looks
pretty darn
On Mon, Oct 31, 2005 at 09:02:59PM -0300, Alvaro Herrera wrote:
Jim C. Nasby wrote:
Now that I've got a little better idea of what this code does, I've
noticed something interesting... this issue is happening on an 8-way
machine, and NUM_SLRU_BUFFERS is currently defined at 8. Doesn't this
I have become aware that regression is failing due to ordering
differences on Windows machines in some non-English locales
(specifically, Czech, but the potential is there for more failures).
The problem seems to be that the regression suite and initdb don't do
enough between them to ensure
Jim C. Nasby [EMAIL PROTECTED] writes:
AFAIK they're not using subtransactions at all, but I'll check.
Well, yeah, they are ... else you'd never have seen this failure.
regards, tom lane
---(end of broadcast)---
TIP 9: In
Andrew Dunstan [EMAIL PROTECTED] writes:
The simple solution seems to be to add --no-locale to the initdb args in
pg_regress.sh.
Er ... what exactly does that do that setting LC_ALL=C doesn't?
regards, tom lane
---(end of
Tom Lane wrote:
The simple solution seems to be to add --no-locale to the initdb args in
pg_regress.sh.
Er ... what exactly does that do that setting LC_ALL=C doesn't?
Windows are ignoring locale enviroment variables so you can't do that
--
Regards
Petr Jelinek (PJMODOS)
On Mon, 2005-10-31 at 16:10 -0800, Mark Wong wrote:
On Thu, 20 Oct 2005 23:03:47 +0100
Simon Riggs [EMAIL PROTECTED] wrote:
On Wed, 2005-10-19 at 14:07 -0700, Mark Wong wrote:
This isn't exactly elegant coding, but it provides a useful improvement
on an 8-way SMP box when run on
Mag Gam wrote:
Is this issue only on AIX 5.3 ML1 thru ML 3?
Does the build work fine with 5.2 (ALL MLs)?
5.3 ML1 works but it is affected by the System include Bug mentioned in
our AIX-FAQ. ML3 is supposed to fix that specific problem but breaks in
another more difficult way as it seems ...
39 matches
Mail list logo