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 ...
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 S
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)
---
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 broadcast)-
"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:
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
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
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
> > >
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
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 NUM_SLRU
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
-
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,
> >>
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 co
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
[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 t
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
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'
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
> > corrupt
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,
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 wri
"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 co
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_PR
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...
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 so
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 ||
> shared
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_CONNE
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 member
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
---
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:
- $ una
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 n
On 31/10/05 2:13 pm, "Bruce Momjian" wrote:
> Adam Witney wrote:
>> On 31/10/05 1:32 pm, "Bruce Momjian" 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 ma
>> 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.postgres
Adam Witney wrote:
> On 31/10/05 1:32 pm, "Bruce Momjian" 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 l
On 31/10/05 1:32 pm, "Bruce Momjian" 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, regressio
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?
--- M
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
so
--- 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
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 is
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
> performanc
39 matches
Mail list logo
