Re: [HACKERS] [PATCHES] TODO Item - Add system view to show free

2005-10-31 Thread Simon Riggs
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,

[HACKERS] 8.1RC1 fails opr_sanity on osx

2005-10-31 Thread Adam Witney
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

Re: [HACKERS] LDAP Authentication?

2005-10-31 Thread Euler Taveira de Oliveira
--- 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.

Re: [HACKERS] 8.1RC1 fails opr_sanity on osx

2005-10-31 Thread Bruce Momjian
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

Re: [HACKERS] LDAP Authentication?

2005-10-31 Thread Bruno Almeida do Lago
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? ---

Re: [HACKERS] 8.1RC1 fails opr_sanity on osx

2005-10-31 Thread Adam Witney
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,

Re: [HACKERS] 8.1RC1 fails opr_sanity on osx

2005-10-31 Thread Bruce Momjian
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)

Re: [HACKERS] 8.1 Release Candidate 1 Bundled ...

2005-10-31 Thread Lamar Owen
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

Re: [HACKERS] 8.1RC1 fails opr_sanity on osx

2005-10-31 Thread Adam Witney
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

Re: [HACKERS] 8.1RC1 fails opr_sanity on osx

2005-10-31 Thread Tom Lane
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

[HACKERS] 8.1RC1 on Tru64

2005-10-31 Thread Honda Shigehiro
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: - $

[HACKERS] platform test

2005-10-31 Thread Mike Rylander
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

Re: [HACKERS] 8.1RC1 on Tru64

2005-10-31 Thread Andrew Dunstan
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

Re: [HACKERS] 8.1RC1 on Tru64

2005-10-31 Thread Honda Shigehiro
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Jim C. Nasby
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 ||

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Jim C. Nasby
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

Re: [HACKERS] FKs on temp tables: hard, or just omitted?

2005-10-31 Thread Jim C. Nasby
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...

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Bruce Momjian
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 ||

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Tom Lane
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Jim C. Nasby
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Bruce Momjian
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Jim C. Nasby
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Bruce Momjian
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Jim C. Nasby
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

Re: [HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-31 Thread Chris Browne
[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,

Re: [HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-31 Thread Tom Lane
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags

2005-10-31 Thread Gregory Maxwell
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

Re: [HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-31 Thread Mag Gam
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

Re: [HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-31 Thread Tom Lane
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Jim C. Nasby
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Alvaro Herrera
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

Re: [HACKERS] Spinlocks, yet again: analysis and proposed patches

2005-10-31 Thread Mark Wong
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Jim C. Nasby
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

[HACKERS] regression failures on WIndows in machines with some non-English locales

2005-10-31 Thread Andrew Dunstan
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

Re: slru.c race condition (was Re: [HACKERS] TRAP: FailedAssertion(!((itemid)-lp_flags 0x01),)

2005-10-31 Thread Tom Lane
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

Re: [HACKERS] regression failures on WIndows in machines with some non-English locales

2005-10-31 Thread Tom Lane
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

Re: [HACKERS] regression failures on WIndows in machines with some non-English

2005-10-31 Thread Petr Jelinek
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)

Re: [HACKERS] Spinlocks, yet again: analysis and proposed patches

2005-10-31 Thread Simon Riggs
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

Re: [HACKERS] 8.1 Release Candidate 1 Coming ...

2005-10-31 Thread Stefan Kaltenbrunner
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 ...