Re: [HACKERS] Installation on Duel-Core Pentium XP

2006-04-25 Thread Andrew Dunstan
Ben Clewett wrote: Hi, My first posting for a few years, I hope this the right place. I am trying trace consistent errors with installation of PostgreSQL onto XP with Intel Duel-Core CPUs. The errors are strange, files missing, things like that. Have any members experienced difficult with

Re: Catalog Access (was: [HACKERS] [GENERAL] Concurrency problem

2006-04-25 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Hannu Krosing wrote: >> Would this take effect even inside a single command ? in other words, if >> it were possible that an index appeared in middle of a big update, would >> the tuples updated after the index becomes visible be also added to the >> ind

Re: [HACKERS] ACL_CONNECT p.tch 6

2006-04-25 Thread Alvaro Herrera
Resend: my ISP reinstalled a stupid filter in their SMTP server. Gevik Babakhani wrote: > I have changed the revoke part of the patch. This time no restrictions, > only a warning message about a possible lockout. > > http://www.xs4all.nl/~gevik/patch/patch-0.6.diff Nah, after seeing Tom's commen

Re: Catalog Access (was: [HACKERS] [GENERAL] Concurrency problem

2006-04-25 Thread Alvaro Herrera
Hannu Krosing wrote: > Ühel kenal päeval, T, 2006-04-25 kell 13:58, kirjutas Tom Lane: > > Martijn van Oosterhout writes: > > > I think the basic problem is that DDL can't really work within a > > > transaction. If I do an ALTER TABLE, some of these changes need to show > > > up to concurrent tran

Re: Catalog Access (was: [HACKERS] [GENERAL] Concurrency problem

2006-04-25 Thread Hannu Krosing
Ühel kenal päeval, T, 2006-04-25 kell 13:58, kirjutas Tom Lane: > Martijn van Oosterhout writes: > > I think the basic problem is that DDL can't really work within a > > transaction. If I do an ALTER TABLE, some of these changes need to show > > up to concurrent transactions (maybe creating a uniq

[HACKERS] ACL_CONNECT patch 6

2006-04-25 Thread Gevik Babakhani
I have changed the revoke part of the patch. This time no restrictions, only a warning message about a possible lockout. http://www.xs4all.nl/~gevik/patch/patch-0.6.diff Tom, Alvaro, Do you think this will be accepted? -- [EM

Re: [HACKERS] Catalog Access

2006-04-25 Thread Joshua D. Drake
Martijn van Oosterhout wrote: On Tue, Apr 25, 2006 at 11:57:13AM -0700, Joshua D. Drake wrote: Martijn van Oosterhout wrote: http://www.thelinuxreview.com/pgsql-hackers/2005-03/msg00840.php O.k. I need to fix that... that should be an archives link ;0 http://archives.postgresql.org/pgsql-hack

Re: [HACKERS] Catalog Access

2006-04-25 Thread Martijn van Oosterhout
On Tue, Apr 25, 2006 at 11:57:13AM -0700, Joshua D. Drake wrote: > Martijn van Oosterhout wrote: > >http://www.thelinuxreview.com/pgsql-hackers/2005-03/msg00840.php > > O.k. I need to fix that... that should be an archives link ;0 > > http://archives.postgresql.org/pgsql-hackers/2005-03/msg00840.

Re: [HACKERS] Catalog Access

2006-04-25 Thread Joshua D. Drake
Martijn van Oosterhout wrote: On Tue, Apr 25, 2006 at 12:25:35PM -0500, Jim C. Nasby wrote: Is there anything in comments/docs/list archives about why catalog access uses a bunch of 'magic' instead of treating catalog tables the same as every other table? I realize that ultimately you have to bo

Re: [HACKERS] Installation on Duel-Core Pentium XP

2006-04-25 Thread Dave Page
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Clewett > Sent: 25 April 2006 16:54 > To: pgsql-hackers@postgresql.org > Subject: [HACKERS] Installation on Duel-Core Pentium XP > > Hi, > > My first posting for a few years, I hope this the ri

Re: Catalog Access (was: [HACKERS] [GENERAL] Concurrency problem building indexes)

2006-04-25 Thread Tom Lane
Martijn van Oosterhout writes: > I think the basic problem is that DDL can't really work within a > transaction. If I do an ALTER TABLE, some of these changes need to show > up to concurrent transactions (maybe creating a unique index?). The point is that DDL can't be MVCC. If for instance you a

Re: [HACKERS] Avoiding redundant fetches of btree index metapages

2006-04-25 Thread Alvaro Herrera
Tom Lane wrote: > Some experimentation over the weekend turned up the result that $SUBJECT > is a good idea. I had never thought about this much before, figuring > that in a heavily-used index the metapage would stay in cache anyway and > so fetching it at the start of each index search isn't cos

[HACKERS] Avoiding redundant fetches of btree index metapages

2006-04-25 Thread Tom Lane
Some experimentation over the weekend turned up the result that $SUBJECT is a good idea. I had never thought about this much before, figuring that in a heavily-used index the metapage would stay in cache anyway and so fetching it at the start of each index search isn't costing any extra I/O. Tha

Re: Catalog Access (was: [HACKERS] [GENERAL] Concurrency problem building indexes)

2006-04-25 Thread Martijn van Oosterhout
On Tue, Apr 25, 2006 at 12:25:35PM -0500, Jim C. Nasby wrote: > Is there anything in comments/docs/list archives about why catalog > access uses a bunch of 'magic' instead of treating catalog tables the > same as every other table? I realize that ultimately you have to > bootstrap somehow (kinda ha

[HACKERS] ISBN/ISSN/ISMN/EAN13 module

2006-04-25 Thread Jeremy Kronuz
I worked on this ISBN/ISSN/ISMN/EAN13 module about more than a year ago, and I was wondering if it could be made official, I honestly think it's better than the ISBN/ISSN currently included in the official release; plus mine would also probably support UPC codes and it already support the new ISB

Catalog Access (was: [HACKERS] [GENERAL] Concurrency problem building indexes)

2006-04-25 Thread Jim C. Nasby
On Tue, Apr 25, 2006 at 12:48:04PM -0400, Alvaro Herrera wrote: > I'm late to this thread, but maybe we can make the process of storing > the new data in pg_class take a lock using LockObject() or something > like that to serialize the access to the pg_class row. The idea would > be that this lock

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

2006-04-25 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I'm late to this thread, but maybe we can make the process of storing > the new data in pg_class take a lock using LockObject() or something > like that to serialize the access to the pg_class row. I'm inclined to think that the right solution is to fix

Re: [HACKERS] FOR UPDATE lock problem ?

2006-04-25 Thread Tom Lane
REYNAUD Jean-Samuel <[EMAIL PROTECTED]> writes: > When I use a "select for update" request whitch uses an index, the > locking system is inconsistant. I've applied the attached patch to HEAD and 8.1 to fix this. regards, tom lane Index: createplan.c

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

2006-04-25 Thread Alvaro Herrera
I'm late to this thread, but maybe we can make the process of storing the new data in pg_class take a lock using LockObject() or something like that to serialize the access to the pg_class row. The idea would be that this lock doesn't conflict with a LockRelation(), but it would of course conflict

[HACKERS] Installation on Duel-Core Pentium XP

2006-04-25 Thread Ben Clewett
Hi, My first posting for a few years, I hope this the right place. I am trying trace consistent errors with installation of PostgreSQL onto XP with Intel Duel-Core CPUs. The errors are strange, files missing, things like that. Have any members experienced difficult with this installation pa

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

2006-04-25 Thread Tom Lane
Wes <[EMAIL PROTECTED]> writes: > A while back, I saw a posting (I think from Tom) to the effect of index > creation converging due to disk caching. It was along the lines of the > slower index would be reading from disk data cached by the first index > creation's read. When the faster creation w

Re: [HACKERS] FOR UPDATE lock problem ?

2006-04-25 Thread Tom Lane
REYNAUD Jean-Samuel <[EMAIL PROTECTED]> writes: > test=# explain select s.id_session from users u, sessions s where > to_date IS NULL and u.id_user = s.id_user; >QUERY PLAN >

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

2006-04-25 Thread Wes
On 4/25/06 9:58 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote: > I can't think of any effect in the PG code that would make CREATE INDEX > commands tend to converge rather than diverge, so maybe there is some > external effect here. Wes, is your machine a dual processor by any > chance? Which OS X ve

Re: [HACKERS] [PATCHES] Implementing RESET CONNECTION ...

2006-04-25 Thread Tom Lane
Bruce Momjian writes: > Should we add it for 8.2 and see if we get any problem reports? No. I don't believe this can work without a far more invasive patch than this is. To point out just one problem, what of cached plans in plpgsql functions? Those can't be carried across a genuine connection

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-25 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > No other object type has the ability to require you to stop the server > and start a standalone backend to fix the mistake, which is what makes > this thing unique. This one doesn't either. I already pointed out two reasons why not: 1. you can connect

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-25 Thread Gevik Babakhani
On Tue, 2006-04-25 at 08:53 -0400, Alvaro Herrera wrote: > Gevik Babakhani wrote: > My point is that the behavior you describe is broken. The warning > should be issued but the command should be executed anyway. That way > the user executing it knows that he has locked everyone out of the > data

Re: [HACKERS] Google SoC--Idea Request

2006-04-25 Thread Jim C. Nasby
On Tue, Apr 25, 2006 at 08:39:57AM -0400, Jonah H. Harris wrote: > On 4/25/06, Bort, Paul <[EMAIL PROTECTED]> wrote: > > Maybe the SoC project here is just such a tuning advisor tool? Something > > that can run pgbench repeatedly, try different settings, and compare > > results. > > IIRC, that alr

[HACKERS] FOR UPDATE lock problem ?

2006-04-25 Thread REYNAUD Jean-Samuel
Hi all, I had a lock problem on my database. When I use a "select for update" request whitch uses an index, the locking system is inconsistant. Take this example: test=# \d users Table "public.users" Column | Type |Modifiers -+

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

2006-04-25 Thread Tom Lane
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes: > My answer to this would be to (have an option to) ommit this relpages > and reltuples update. Wouldn't help, unless you want to get rid of relhasindex too. > Wes, you could most likely solve your immediate problem if you did an > analyze

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

2006-04-25 Thread Zeugswetter Andreas DCP SD
> > Wes, you could most likely solve your immediate problem if you did an > > analyze before creating the indexes. > > I can try that. Is that going to be a reasonable thing to do when there's > 100 million rows per table? I obviously want to minimize the number of > sequential passes through t

Re: [HACKERS] [PATCHES] Implementing RESET CONNECTION ...

2006-04-25 Thread A.M.
To complete the connection pooling for multiple users, it would be great to have a protocol level option to change roles semi-permanently (to reduce permissions). RESET SESSION AUTHORIZATION would then bounce back to that (new, set) role until another protocol-level role "rollback". This would allo

Re: [HACKERS] [PATCHES] Implementing RESET CONNECTION ...

2006-04-25 Thread Bruce Momjian
OK, what would people like done with this patch? Our TODO list has: * -Add RESET CONNECTION command to reset all session state This would include resetting of all variables (RESET ALL), dropping of temporary tables, removing any NOTIFYs, cursors, open transac

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

2006-04-25 Thread Wes
On 4/25/06 2:18 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote: > So invent some made-up data. I'd be seriously surprised if this > behavior has anything to do with the precise data being indexed. > Experiment around till you've got something you don't mind posting > that exhibits the behavior you see.

Re: [HACKERS] Google SoC--Idea Request

2006-04-25 Thread Bruce Momjian
Tom Lane wrote: > "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

Re: [HACKERS] Summary of coverity bugs

2006-04-25 Thread Martijn van Oosterhout
On Tue, Apr 25, 2006 at 02:09:26PM +0200, Csaba Nagy wrote: > > I wanted to make a link to the cvsweb interface but my XSLT skills > > wern't up to that apparently. > > The following XSL fragment will do the trick for the cvsweb link: Thanks, done. If I could select the revision by date, that'd b

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-25 Thread Alvaro Herrera
Stephen Frost wrote: > * Alvaro Herrera ([EMAIL PROTECTED]) wrote: > > Gevik Babakhani wrote: > > > On Mon, 2006-04-24 at 23:16 -0400, Tom Lane wrote: > > > > Why are we debating this? It won't get accepted anyway, because the > > > > whole thing is silly. Show me one other object type that we is

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-25 Thread Stephen Frost
* Alvaro Herrera ([EMAIL PROTECTED]) wrote: > Gevik Babakhani wrote: > > On Mon, 2006-04-24 at 23:16 -0400, Tom Lane wrote: > > > Why are we debating this? It won't get accepted anyway, because the > > > whole thing is silly. Show me one other object type that we issue > > > such warnings for, or

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-25 Thread Alvaro Herrera
Gevik Babakhani wrote: > Hi > > On Mon, 2006-04-24 at 23:07 -0400, Alvaro Herrera wrote: > > 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 bu

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-25 Thread Alvaro Herrera
Gevik Babakhani wrote: > On Mon, 2006-04-24 at 23:16 -0400, Tom Lane wrote: > > Why are we debating this? It won't get accepted anyway, because the > > whole thing is silly. Show me one other object type that we issue > > such warnings for, or anyone else who has even suggested that we should. N

Re: [HACKERS] Protocol Message Graph

2006-04-25 Thread Simon Riggs
On Sun, 2006-04-23 at 18:43 -0400, Alvaro Herrera wrote: > Agent M wrote: > > I have created a directed graph using graphviz that shows the message > > flow/event stream. Perhaps this will be helpful to someone. Of course, > > corrections are also welcome. Thats a good start. > Maybe it would

Re: [HACKERS] Google SoC--Idea Request

2006-04-25 Thread Jonah H. Harris
On 4/25/06, Bort, Paul <[EMAIL PROTECTED]> wrote: > Maybe the SoC project here is just such a tuning advisor tool? Something > that can run pgbench repeatedly, try different settings, and compare > results. IIRC, that already exists. I think it was called pg_autotune or something similar. -- Jo

Re: [HACKERS] Google SoC--Idea Request

2006-04-25 Thread Bort, Paul
> > 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. Maybe the SoC project here is just such a tuning advisor tool? Something that can run pgbench repeatedly, try different settings, and co

Re: [HACKERS] Summary of coverity bugs

2006-04-25 Thread Csaba Nagy
> I wanted to make a link to the cvsweb interface but my XSLT skills > wern't up to that apparently. The following XSL fragment will do the trick for the cvsweb link: File http://developer.postgresql.org/cvsweb.cgi/ Cheers, Csaba.

[HACKERS] Summary of coverity bugs

2006-04-25 Thread Martijn van Oosterhout
I managed to export some data out into a sort of useful format, primarily the memory leaks. It not as nice as having it with the source, but it should allow people to find the problems (or confirm that they're not problems at all). The line references are all to HEAD. I wanted to make a link to the

Re: [HACKERS] Checking assumptions

2006-04-25 Thread Martijn van Oosterhout
On Mon, Apr 24, 2006 at 11:11:59PM -0400, Bruce Momjian wrote: > > Are we OK with the Coverity reports now? Well, you can see for yourself: http://scan.coverity.com/ We're down from the near-300 to just 60. They've unfixed the ereport() issue but it was fixed for two days which allowed me to is

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

2006-04-25 Thread Zeugswetter Andreas DCP SD
> > [ 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. > I did a pg_dumpall and removed the index creation

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-25 Thread Gevik Babakhani
On Mon, 2006-04-24 at 23:16 -0400, Tom Lane wrote: > Why are we debating this? It won't get accepted anyway, because the > whole thing is silly. Show me one other object type that we issue > such warnings for, or anyone else who has even suggested that we should. So, I am very much confused. Wha

Re: [HACKERS] TODO Item: ACL_CONNECT

2006-04-25 Thread Gevik Babakhani
Hi On Mon, 2006-04-24 at 23:07 -0400, Alvaro Herrera wrote: > 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. I have

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

2006-04-25 Thread Tom Lane
Wes <[EMAIL PROTECTED]> writes: > 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