Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Wes
On 4/25/06 1:01 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote: >> Where do you want me to send it to? > > pgsql-bugs would be appropriate. It's not that small that I would want to post it to a list. Also, I think I've sanitized the data, but I wouldn't want to post it on a public list. Or are you j

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread ipig
Maybe you can develop a graphic interface just like Fedora Core setup interface which can choose packages installing, then the user can choose config file and then have a little change in parameters. - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Jonah H. Harris" <[EMAI

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Tom Lane
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > On 4/25/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote: >> Personally I would much rather see a tuning advisor tool in more general >> use than just provide small/medium/large config setting files. > True dat. One thing that has to be figured out befo

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Andrew Dunstan
Jim C. Nasby wrote: On Mon, Apr 24, 2006 at 11:05:18PM -0400, Tom Lane wrote: "Jonah H. Harris" <[EMAIL PROTECTED]> writes: While the student could do some benchmarking on relatively new hardware and make suggestions, I agree with Tom. Having to keep support for older platforms doesn'

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Tom Lane
Wes <[EMAIL PROTECTED]> writes: > Where do you want me to send it to? pgsql-bugs would be appropriate. > Of course, since your hardware is different, it may not show up since it > appears to be a timing thing.. I'm on a PB G4 1Ghz. My G4 is in the shop at the moment, but Apple promised it back

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Wes
On 4/24/06 11:02 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote: > [ shrug... ] Worksforme. > > There is a short interval at the end of the first CREATE INDEX on the > table where the problem would happen if another CREATE INDEX tries to > modify the pg_class row before the first one's committed. Tha

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Jonah H. Harris
On 4/25/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > We have already done some initdb tuning improvements for 8.2 Cool, I hadn't looked at this. > I would have liked to increase max_connections too, but that would have > caused problems on OSX, apparently. See previous discussion. Yeah, their

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Jim C. Nasby
On Mon, Apr 24, 2006 at 11:05:18PM -0400, Tom Lane wrote: > "Jonah H. Harris" <[EMAIL PROTECTED]> writes: > > While the student could do some benchmarking on relatively new > > hardware and make suggestions, I agree with Tom. Having to keep > > support for older platforms doesn't leave much flexib

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Tom Lane
Wes <[EMAIL PROTECTED]> writes: > I can duplicate the error at will. [ shrug... ] Worksforme. There is a short interval at the end of the first CREATE INDEX on the table where the problem would happen if another CREATE INDEX tries to modify the pg_class row before the first one's committed. Tha

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Wes
>> Long ago. I just tested it again, and AFAICS you can create indexes >> concurrently so long as the underlying table isn't changing (ie, >> neither reltuples nor relpages changes). > > Hrm, the OP seemed to find a case that was having problems: > http://archives.postgresql.org/pgsql-general/200

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-24 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Gevik Babakhani wrote: >> If one is going to revoke the last ACL_CONNECT, a warning is going to >> issued then that part of the REVOKE gets canceled. > Humm, no, the WARNING is issued but the REVOKE is executed anyway. Why are we debating this? It won

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Jonah H. Harris
On 4/24/06, Tom Lane <[EMAIL PROTECTED]> wrote: > We've talked more than once about offering multiple alternative > starting-point postgresql.conf files to give people an idea of what to > do for small/medium/large installations. MySQL have done that for years > and it doesn't seem that users are

Re: [HACKERS] Checking assumptions

2006-04-24 Thread Bruce Momjian
Are we OK with the Coverity reports now? --- Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Fri, Apr 21, 2006 at 09:12:51AM +0800, Christopher Kings-Lynne wrote: > > >I havn't been able to find any more s

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-24 Thread Alvaro Herrera
Gevik Babakhani wrote: > If one is going to revoke the last ACL_CONNECT, a warning is going to > issued then that part of the REVOKE gets canceled. Humm, no, the WARNING is issued but the REVOKE is executed anyway. -- Alvaro Herrerahttp://www.CommandPrompt.com/ P

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Wes
On 4/24/06 7:54 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote: >> Long ago. I just tested it again, and AFAICS you can create indexes >> concurrently so long as the underlying table isn't changing (ie, >> neither reltuples nor relpages changes). > > Hrm, the OP seemed to find a case that was havi

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Tom Lane
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > While the student could do some benchmarking on relatively new > hardware and make suggestions, I agree with Tom. Having to keep > support for older platforms doesn't leave much flexibility to change > the defaults. Another point here is that the de

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Jonah H. Harris
On 4/24/06, Tom Lane <[EMAIL PROTECTED]> wrote: > I doubt this is SoC material, simply because the issues have little to > do with coding and a lot to do with persuading people to drop default > support for old platforms. Which is not something a student is likely > to succeed at. While the stude

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Where do we stand with getting much more reasonable default values in > postgresql.conf? Maybe that should be a SoC project, or is it too small? Define "much more reasonable". I doubt this is SoC material, simply because the issues have little to do wi

Re: [HACKERS] Unresolved Win32 bug reports

2006-04-24 Thread Qingqing Zhou
""Jim C. Nasby"" <[EMAIL PROTECTED]> wrote > > There a patched build available for testing? (I'd rather not have to > figure out how to get windows builds working, unless there's some kind > of instructions somewhere...) > -- Not yet - the patch is still pending. Regards, Qingqing --

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-24 Thread Gevik Babakhani
Hi, The following is also added to a new patch. > > At this moment the owner of the database CAN REVOKE himself form the > > ACL_OBJECT_DATABASE. If the implementation above is acceptable then I > > can work on this one :) > > Hmm, what do you want to do about it? ISTM the owner should be able

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Jim C. Nasby
On Mon, Apr 24, 2006 at 08:42:41PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > Was the code ever changed so that it won't update relpages if the number > > is the same? > > Long ago. I just tested it again, and AFAICS you can create indexes > concurrently so long as th

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Was the code ever changed so that it won't update relpages if the number > is the same? Long ago. I just tested it again, and AFAICS you can create indexes concurrently so long as the underlying table isn't changing (ie, neither reltuples nor relpages

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Jim C. Nasby
On Mon, Apr 24, 2006 at 08:14:33PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > Since this seems to only be an issue due to trying to update pg_class > > for the table, perhaps CREATE INDEX can just ignore errors there? > > Lessee, where would ignoring an error potential

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Since this seems to only be an issue due to trying to update pg_class > for the table, perhaps CREATE INDEX can just ignore errors there? Lessee, where would ignoring an error potentially cause the greatest damage? I can hardly think of a less critical

Re: [HACKERS] [GENERAL] Concurrency problem building indexes

2006-04-24 Thread Jim C. Nasby
moving to -hackers On Sun, Apr 23, 2006 at 09:06:59AM -0500, Wes wrote: > Postgres: 8.1.3 > OS: Mac OS X 10.4.6 > > I've run into another concurrency issue - parallel building of indexes. > When I try to build multiple indexes at a time, I randomly get: > > ERROR: tuple concurrently updated >

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Bruce Momjian
Kris Jurka wrote: > > > On Mon, 24 Apr 2006, Bruce Momjian wrote: > > > Great, fix attached and applied. > > > > You also need to change lines 48 and 64 of heapam.h to use the same > coding. Done. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Kris Jurka
On Mon, 24 Apr 2006, Bruce Momjian wrote: Great, fix attached and applied. You also need to change lines 48 and 64 of heapam.h to use the same coding. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Bruce Momjian
Kris Jurka wrote: > > > On Mon, 24 Apr 2006, Martijn van Oosterhout wrote: > > > Perhaps someone could check if changing the test explicitly check > > against NULL: > > > >> ((attnum) > (int) (tup)->t_data->t_natts) ? \ > >> ( \ > >> (((isnull) != NULL)? (

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Martijn van Oosterhout
On Mon, Apr 24, 2006 at 05:39:30PM -0400, Tom Lane wrote: > > Yes, this coding removes the warning. > > Oh, good, that seems like a reasonable change to make (it's arguably > more clear than the original anyway). > > Is this the only place where the warning shows up? ISTM there's quite > a lot o

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Tom Lane
Kris Jurka <[EMAIL PROTECTED]> writes: > On Mon, 24 Apr 2006, Martijn van Oosterhout wrote: >> Perhaps someone could check if changing the test explicitly check >> against NULL: >> >> ((attnum) > (int) (tup)->t_data->t_natts) ? \ >> ( \ >> (((isnull) != NULL)? (*(isnull) = true) : (dummyret)NULL),

Re: [HACKERS] pgsql: Improve our private implementation of cbrt() to give results of

2006-04-24 Thread Magnus Hagander
Confirmed to work on Win32 Visual C++. With this patch, Win32 VisualC++ now passes all regression tests. Thanks, Tom! //Magnus > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Monday, April 24, 2006 10:37 PM > To: pgsql-committer

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Kris Jurka
On Mon, 24 Apr 2006, Martijn van Oosterhout wrote: Perhaps someone could check if changing the test explicitly check against NULL: ((attnum) > (int) (tup)->t_data->t_natts) ? \ ( \ (((isnull) != NULL)? (*(isnull) = true) : (dummyret)NULL), \

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Martijn van Oosterhout
On Mon, Apr 24, 2006 at 01:16:04PM -0500, Kris Jurka wrote: > > > On Mon, 24 Apr 2006, Gevik Babakhani wrote: > > >I noticed the following compile warnings. Perhaps someone is interested > >to know about them. > > Also I was testing a gcc 4.2 snapshot (20060419) and it has a whole lot of > war

Re: [HACKERS] Regression error on float8

2006-04-24 Thread Magnus Hagander
> > That totally didn't work on visual c++ at least. It fixes those two > > ones, but it breaks the other lines in the same test: > > It's a couple bricks shy of a load (doesn't handle zero or > negative input correctly) but easily fixed. I'm just about > to commit it. Great. I'll check it ou

Re: [HACKERS] Regression error on float8

2006-04-24 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > That totally didn't work on visual c++ at least. It fixes those two > ones, but it breaks the other lines in the same test: It's a couple bricks shy of a load (doesn't handle zero or negative input correctly) but easily fixed. I'm just about to comm

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Bruce Momjian
Tom Lane wrote: > Kris Jurka <[EMAIL PROTECTED]> writes: > > Also I was testing a gcc 4.2 snapshot (20060419) and it has a whole lot of > > warnings stemming from heap_getattr's isnull check: > > aclchk.c:791: warning: the address of 'isNull', will always evaluate as > > 'true' > > We need to lo

Re: [HACKERS] Regression error on float8

2006-04-24 Thread Magnus Hagander
> > What do you think is best - try to adapt that version, or > update our > > regression tests outputs to accept the output from our current code? > > Given that our output gets very very close, perhaps we should > take a hint from the end of the MinGW version, do a single > Newton iteration

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Bruce Momjian
Gevik Babakhani wrote: > I noticed the following compile warnings. Perhaps someone is interested > to know about them. > > /usr/bin/flex -o'pgc.c' pgc.l > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g > -Wno-erro

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Tom Lane
Kris Jurka <[EMAIL PROTECTED]> writes: > Also I was testing a gcc 4.2 snapshot (20060419) and it has a whole lot of > warnings stemming from heap_getattr's isnull check: > aclchk.c:791: warning: the address of 'isNull', will always evaluate as > 'true' We need to lobby the gcc maintainers to not

Re: [HACKERS] Regression error on float8

2006-04-24 Thread Tom Lane
Martijn van Oosterhout writes: > Given that our output gets very very close, perhaps we should take a > hint from the end of the MinGW version, do a single Newton iteration to > fixup those last few digits. That seems like a plan to me. regards, tom lane

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-24 Thread Gevik Babakhani
> Ok, good. This is what people was aiming for initially, I hope. What > do people think, particularly those who wanted to manage pg_hba.conf via > SQL commands? I guess for this one more people have to play with the new functionality. > Without looking at the surrounding code, I'm a bit wary

Re: [HACKERS] Regression error on float8

2006-04-24 Thread Martijn van Oosterhout
On Mon, Apr 24, 2006 at 03:01:51PM +0200, Magnus Hagander wrote: > If I undefine HAVE_CBRT on Linux, I get the exact same failure! So it > seems our own version of cbrt() is broken wrt our own regression tests > :-( Must be that nobody else (at least on i386) uses that code. > What do you think

Re: [HACKERS] 2x compile warning

2006-04-24 Thread Kris Jurka
On Mon, 24 Apr 2006, Gevik Babakhani wrote: I noticed the following compile warnings. Perhaps someone is interested to know about them. Also I was testing a gcc 4.2 snapshot (20060419) and it has a whole lot of warnings stemming from heap_getattr's isnull check: aclchk.c:791: warning: the

Re: [HACKERS] bug# 2073 - Clarification

2006-04-24 Thread Tom Lane
Dhanaraj M <[EMAIL PROTECTED]> writes: > Pl. look at the following code, which is taken from alter_table.sql > (regression test) The regression test is designed to check for the current behavior. If we were to change the behavior, then of course we'd need to change the regression test as well. P

Re: [HACKERS] Further reduction of bufmgr lock contention

2006-04-24 Thread Mark Wong
Tom Lane wrote: Simon Riggs <[EMAIL PROTECTED]> writes: On Fri, 2006-04-21 at 13:01 -0400, Tom Lane wrote: I've been looking into Gavin Hamill's recent report of poor performance with PG 8.1 on an 8-way IBM PPC64 box. Keep in mind that Gavin's 8-way turns back into a pumpkin on Monday :-(

Re: [HACKERS] Regression error on float8

2006-04-24 Thread Magnus Hagander
> > I'm getting the following regression errors with a backend > built using > > Visual C++: > > Is HAVE_CBRT getting defined? Either their cbrt() routine or > our default one seems to be generating slightly-off answers. > The default one (at the bottom of float.c) certainly looks a > bit c

[HACKERS] TODO Item: ACL_CONNECT

2006-04-24 Thread Gevik Babakhani
Hi > I don't understand. The code should look like this: > > if (acl in pg_database == NULL) > acl = acldefault > else > acl = acl in pg_database > if (has_permission(acl, user, ACL_CONNECT)) > can connect > else > can't connect > To my surprise the code you described a

Re: [HACKERS] Further reduction of bufmgr lock contention

2006-04-24 Thread Gavin Hamill
On Fri, 21 Apr 2006 17:38:01 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > I believe the particular test case being looked at here is read-only > (Gavin, is that correct?) Yes - I made sure the devels made it readonly so I could farm search requests out to Slony-replicated machines (ended up runnin

[HACKERS] ecpg memory leaks

2006-04-24 Thread Michael Meskes
Martijn, thanks for finfing those leaks. I haven't been around last week, so it took until today to commit the fixes. But they are in now. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL

Re: [HACKERS] Google SoC--Idea Request

2006-04-24 Thread Jim C. Nasby
Where do we stand with getting much more reasonable default values in postgresql.conf? Maybe that should be a SoC project, or is it too small? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nas

[HACKERS] 2x compile warning

2006-04-24 Thread Gevik Babakhani
I noticed the following compile warnings. Perhaps someone is interested to know about them. /usr/bin/flex -o'pgc.c' pgc.l gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -Wno-error -I./../include -I. -I../../../../s

Re: [HACKERS] Unresolved Win32 bug reports

2006-04-24 Thread Jim C. Nasby
On Mon, Apr 24, 2006 at 10:23:07AM +0800, Qingqing Zhou wrote: > > "Tom Lane" <[EMAIL PROTECTED]> wrote > > Martijn van Oosterhout writes: > > > On Thu, Apr 20, 2006 at 12:17:07PM -0500, Jim C. Nasby wrote: > > >> Here's one to add to the list: running pgbench with a moderately heavy > > >> load

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-24 Thread Alvaro Herrera
Gevik Babakhani wrote: > To my surprise the code you described above was already there :) > function aclchk.c:pg_database_aclmask:1696 Sure, that sort of was my point :-) > If the above is okay and correct. Then I guess for simple systems one > could only enter the line below in pg_hba.conf >

[HACKERS] bug# 2073 - Clarification

2006-04-24 Thread Dhanaraj M
Bug- raised: = BUG #2073: Can't drop sequence when created via SERIAL column Answered: Right. We have this TODO item: * %Disallow changing default expression of a SERIAL column? which would prevent you from changing the default expression for a SERIAL column. So the

Re: [HACKERS] Further reduction of bufmgr lock contention

2006-04-24 Thread Qingqing Zhou
"Tom Lane" <[EMAIL PROTECTED]> wrote > > The thing that's nagging at me at the moment is the realization that a > partitioned hashtable will eat more shared memory than a single > hashtable. It wasn't that long ago that we had to do some hacking to > ensure that the buffer hashtable couldn't run