date:20040227


  Ahh. I forgot to detail my ideas on this. It seems to me that we cannot
  drop a table space until the directory is empty.

Agreed.

 
 How would it get to be empty?  Are you thinking of some sort of connect
 database to tablespace and disconnect database from tablespace
 commands that would respectively create and delete the per-database
 subdirectory?  That seems moderately reasonable to me.  We could then

I would only allow the drop if the directory only contains empty db oid 
directories.

Andreas

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Thread safe connection-name mapping in ECPG. Is it required?


 I'm not sure I understand you correctly. The SQL standard says you can
 call your statement as this:
 exec sql at CONNECTION select 1;
 
 Here CONNECTION of course is a string, the name of the connection. So,
 yes, we have to maintain that list to make sure we get the right
 connection.

I thought the main problem was an exec sql set connection :hostvar,
where hostvar is a string determined at runtime. Else above could be translated at 
precompile time to anything more efficient than a string search.

Oh, just noticed above is not standard, but sure is very useful.

Andreas

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Thread safe connection-name mapping in ECPG. Is it

Michael Meskes wrote:
On Mon, Feb 23, 2004 at 09:27:40PM +0530, Shridhar Daithankar wrote:
What I wonder is, do we really need to maintain that level of lookup? Can't we 
just say a connection is a 'struct connection *' which should be opaque and 
should not be touched or poked inside, just like PGConn.
I'm not sure I understand you correctly. The SQL standard says you can
call your statement as this:
exec sql at CONNECTION select 1;
Here CONNECTION of course is a string, the name of the connection. So,
yes, we have to maintain that list to make sure we get the right
connection.
Or what were you asking?
I am asking for CONNECTION being a variable of data type 'connection *' rather 
than 'const char *'. That would avoid name lookups.

Is that out of spec?

 Shridhar

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly

Re: [HACKERS] Thread safe connection-name mapping in ECPG. Is it


 I am asking for CONNECTION being a variable of data type 'connection *' rather 
 than 'const char *'. That would avoid name lookups.
 
 Is that out of spec?

Yes, but the preprocessor could still add an optimization ala 'connection *' for
the hardcoded cases (exec sql set connection 'myconn1'; exec sql at 'myconn1' ...).
It needs to maintain the string list for the non hardcoded cases though.

Andreas

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Thread safe connection-name mapping in ECPG. Is it

Zeugswetter Andreas SB SD wrote:

I am asking for CONNECTION being a variable of data type 'connection *' rather 
than 'const char *'. That would avoid name lookups.

Is that out of spec?
Yes, but the preprocessor could still add an optimization ala 'connection *' for
the hardcoded cases (exec sql set connection 'myconn1'; exec sql at 'myconn1' ...).
It needs to maintain the string list for the non hardcoded cases though.
How about, allowing 'connection *'? If somebody puts a 'connection *' there it 
is used. If it is a string a name search is performed. Best of both worlds.

Can that be an acceptable compromise?

 Shridhar

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Tablespaces


 I do not intend to undertake raw disk tablespaces for 7.5. I'd be
 interested if anyone could provide some real world benchmarking of file
 system vs. raw disk. Postgres benefits a lot from kernel file system cache
 at the moment.

Yes, and don't forget that pg also relys on the OS for grouping and
sorting the physical writes and doing readahead where appropriate.

The use of raw disks is usually paired with the use of kernel aio.
The difference is said to be up to 30% on Solaris. I can assert, that
it made the difference between a bogged down system and a much better behaved
DB on Sun here.

My experience with kaio on AIX Informix is, that kaio is faster as long as IO
is not the bottleneck (disk 100% busy is the metric to watch, not Mb/s), while
for an IO bound system the Informix builtin IO threads that can be used instead
win. (Since they obviously do better at grouping, sorting and readahead
than the AIX kernel does for kaio)

Overall I think the price and komplexity is too high, especially since there are 
enough platforms where the kernel does a pretty good job at grouping, sorting and 
readahead. Additionally the kernel takes non PostgreSQL IO into account.

Andreas

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Bort, Paul

 -Original Message-
 From: Greg Stark [mailto:[EMAIL PROTECTED]
 Sent: Friday, February 27, 2004 12:17 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

[...snip...]
 I might suggest again RT. It's open source and has serious commercial
 traction. The postgres port needs a lot of work for it to 
 really catch up to
 the original MySQL implementation so most of the users are 
 using it with
 MySQL. 

A second for considering RT. I've been using RT 3.0.6 for about five months
now for our internal support and (closed-source) bug tracking, and can
report that it works very smoothly with PostgreSQL. I had more problems with
getting all the Perl dependencies lined up than anything else, but that was
mostly my ignorance regarding big Perl apps and Apache.

It also can accept tickets via web or e-mail, so using it would not require
reducing the available methods for submitting bugs.

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] bgwriter never dies

2004-02-27 Thread Bruno Wolff III

On Thu, Feb 26, 2004 at 17:09:21 -0500,
  Tom Lane [EMAIL PROTECTED] wrote:
 Simon Riggs [EMAIL PROTECTED] writes:
  Should we have a pgmon process that watches the postmaster
  and restarts it if required?
 
 I doubt it; in practice the postmaster is *very* reliable (because it
 doesn't do much), and so I'm not sure that adding a watchdog is going to
 increase the net reliability of the system.  The sorts of things that
 could take out the postmaster are likely to take out a watchdog too.

Running postgres under daemontools is an easy way to accomplish this.
The one case it won't handle is if some process gets the process id
from the old postgres process before the new one starts up.

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Andrew Dunstan



Josh Berkus wrote:

Tom,

 

Possibly workable, but what's your definition of registered user?
   

Signing up via a webform, getting an e-mailed password back, logging in.

 

I'd hope that anyone subscribed to any of the mailing lists would be
considered registered, for instance.  Not sure if we can do that with
either BZ or GForge; anyone know?
   

Usually it works the other way around; people can't subscribe until they've 
registered via web.
 



I believe it should not be hard to do a one-time bulk registration of 
everyone on the lists, if that was desired.

Stepping back a bit and gathering a few threads.

BZ versions etc. There is finally some movement in the mainline BZ code 
to get DB independence into it - and the first DB to benefit will be 
Postgres.  Dave Lawrence at RedHat appears to be working again on 
landing this (after a long hiatus). See  
http://bugzilla.mozilla.org/show_bug.cgi?id=98304 and 
http://bugzilla.mozilla.org/show_bug.cgi?id=146679 . The reason I would 
prefer to go with mainline BZ (assuming we go with BZ at all) is that my 
past experience of upgrading BZ has not been pleasant, and I am sure it 
would be even harder doing it from a fork like the RedHat one.

Signal to Noise. It's not at all clear to me why a bug tracking system 
should have a worse signal to noise ratio than a mailing list with 
similar access rules, especially since we also provide the facility to 
log bugs through a web form directly off the postgresql.org home page. 
But even if it does, that can be managed by good triage. That should 
improve the ratio for all but those doing the triage. Personally, I'd be 
surprised if it took one knowledgable person more than 30 minutes a day 
to weed out the garbage (sorry for the mixed metaphor), and if the load 
was spread across several people it would be just a few minutes a day 
for any one of them, at a significant saving to everyone else.

Email interface: it should not be beyond the wit of man to provide some 
level of email interface to any reasonable bug tracking system. Whether 
or not it is worth doing depends on the demand. Two obvious places for 
it would be 1) to allow initial logging of a bug via email, and 2) 
periodically run query 'foo' and email me the results. Getting a once a 
day digest of new bug reports might be quite nice in fact.

One size fits all: I understood that this discussion arose in the 
context of a suggestion to migrate GBorg to a GForge base (a proposal I 
generally support). What is right for the core project might well not be 
right for GBorg projects. Perhaps a conservative approach might be to 
try things out on GBorg/GForge and see how things go, without touching 
how the core operates for now.

cheers

andrew



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

On Friday 27 February 2004 19:59, Andrew Dunstan wrote:
 I believe it should not be hard to do a one-time bulk registration of
 everyone on the lists, if that was desired.

I agree. If possible we could also run postgresql registration system where we 
can track general usage of postgresql on various fronts, for the information 
people are willing to put their name on. It could be a massive advocacy 
ammo..

 Signal to Noise. It's not at all clear to me why a bug tracking system
 should have a worse signal to noise ratio than a mailing list with
 similar access rules, especially since we also provide the facility to
 log bugs through a web form directly off the postgresql.org home page.
 But even if it does, that can be managed by good triage. That should
 improve the ratio for all but those doing the triage. Personally, I'd be
 surprised if it took one knowledgable person more than 30 minutes a day
 to weed out the garbage (sorry for the mixed metaphor), and if the load
 was spread across several people it would be just a few minutes a day
 for any one of them, at a significant saving to everyone else.

Look at KDE bugzilla. They first make you search and then file the bug. I have 
seen duplicates dropping from several thousands to few hundreds. Simple but 
effective step. For sure postgresql will hardly receive that kind of bug 
flurry.

They put a direct report a bug in KDE2.0. Click on a menu item and it send a 
bug report. As a result they had massive duplicates. Now the menu item give 
you a URL to click on, then you go and search etc. Very nice system.

 Email interface: it should not be beyond the wit of man to provide some
 level of email interface to any reasonable bug tracking system. Whether
 or not it is worth doing depends on the demand. Two obvious places for
 it would be 1) to allow initial logging of a bug via email, and 2)
 periodically run query 'foo' and email me the results. Getting a once a
 day digest of new bug reports might be quite nice in fact.

Logging bugs via email is a bad idea because you can not enforce the fields. 
Would you like somebody filing a bug via mail and leaving postgresql version 
out?

Let people use webforms. It is nice enough IMHO..

 Shridhar

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Karl DeBisschop

On Fri, 27 Feb 2004 09:17:13 -0500
Bort, Paul [EMAIL PROTECTED] wrote:

  -Original Message-
  From: Greg Stark [mailto:[EMAIL PROTECTED]
  
 [...snip...]
  I might suggest again RT. It's open source and has serious
  commercial traction. The postgres port needs a lot of work for it to
  
  really catch up to
  the original MySQL implementation so most of the users are 
  using it with
  MySQL. 
  
 
 A second for considering RT. I've been using RT 3.0.6 for about five
 months now for our internal support and (closed-source) bug tracking,
 and can report that it works very smoothly with PostgreSQL. I had more
 problems with getting all the Perl dependencies lined up than anything
 else, but that was mostly my ignorance regarding big Perl apps and
 Apache.

That perl dependency issue is not such a small one, IMHO. We've used RT
in the past, but ditched it because without installing a compiler on the
exposed server, we spent far too much time trying to keep all those
modules up-to-date. If you run an mod_perl web server anyway, maybe it's
not such a big deal. But if you do not, I'm not sure RT is good enough
to justify the extra work.

That said, if the perl module depencies are not a big deal for you, the
UI is nice. Just IMHO not nice enugh to justify the extra work when
there are so many other options to choose from.

(FWIW, I would love to see more effort in keeping bugzilla's current
versions up-to-date wrt to postgresql, and I note that full postgresql
compatibility is part of the next major release [2.18]. But my hopes are
probably not worth the bits required to transmit them)

-- 
Karl DeBisschop ([EMAIL PROTECTED])
Pearson Education/Infoplease (http://www.infoplease.com)

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Greg Stark


Tom Lane [EMAIL PROTECTED] writes:

 As for raising the barrier, you can presently submit bug reports to
 pgsql-bugs by either mail or webform.  Most of the bug trackers I'm
 aware of are webform-only.  I don't consider that a step forward,
 especially since a webform isn't very conducive to making good reports
 (it's hard to attach test cases, for instance).

There are plenty of bug tracking systems that use email extensively. In fact I
think the traditional approach was to be entirely email based. GNATS, the
venerable candidate in this field for example, is entirely email based. But
GNATS kind of sucks.

The Debian system is entirely email controllable, including command messages
to close, reassign, etc. bugs. It depends on people following instructions and
following up to the numeric address it sends you.

RT behaves like a ticketing system where it assigns you a ticket number on the
initial email and then tracks subsequent emails by the subject and other
headers.

I dislike BZ for the way it *forces* you to use the web interface. I prefer
email based systems for the simple reason that I already have a perfectly good
tool for composing text and reading conversations. It alerts me when I get
messages, sorts the messages into folders etc. The last thing I want to do is
have to remember 20 different web sites to check to see if there's any news.
And the last thing I want to do when I have a long detailed explanation of a
problem is try typing into some little bitty box in a web browser with the
pitiful editing features they have.

I also dislike BZ for aesthetic reasons. If one person is editing a ticket
while another person updates the same ticket, it refuses your edits and you
have to start all over. I think all the updates are stored in one big field.

-- 
greg


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Question on pg_dump

2004-02-27 Thread Michael Brusser

I first tried to take care of the problem by removing -L $libpath
from the arg list passed to createlang. This worked in a way that 
probin in pg_proc had value $libdir/plpgsql. 

Later it turned out the embedded library path was used, and install
failed when there was no access to the build environment.

Now I put the -L $libpath argument back in place, then I update
pg_proc with the dynamic value. This works fine, but such approach
looks too intrusive. I think I also tried to set env LD_LIBRARY_PATH,
which by some reason did not help.

Is there a better way to handle this and avoid updating pg_proc?

Thank you.


 Michael Brusser [EMAIL PROTECTED] writes:
  I'm running Postgres v.7.3.4.
  In my database dump file I see this:
 
  CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
  AS '/home/tmichael/build/relipg21/syncinc/lib.sol2/plpgsql',
  'plpgsql_call_handler'
  LANGUAGE c;
 
  The hardcoded library path may become an obstacle when loading
  data into a different server. Is there a way to avoid this?
 
 The preferred way to write it nowadays is '$libdir/plpgsql', but
 you evidently have a legacy value embedded in your pg_proc table.
 pg_dump will not second-guess this, and so the old full-path
 approach will persist over dump/reloads until you do something about it.
 
 I'd suggest editing the dump file before you reload, or even manually
 updating pg_proc.probin for this function entry so that future dumps
 are right.
 
   regards, tom lane



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Thread safe connection-name mapping in ECPG. Is it

2004-02-27 Thread Michael Meskes

On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar wrote:
 How about, allowing 'connection *'? If somebody puts a 'connection *' there 
 it is used. If it is a string a name search is performed. Best of both 
 worlds.

How shall anyone put a pointer to a connection struct inside the SQL
statement?

It would help me a lot if you'd be able to give some examples.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Question on pg_dump

2004-02-27 Thread Michael Brusser

Sorry, I forgot to mention that I also considered bypassing createlang
and using direct sql:

... RETURNS LANGUAGE_HANDLER AS '${pglib}/plpgsql' ...

but I'm not sure if this is much better then updating pg_proc.
-

 I first tried to take care of the problem by removing -L $libpath
 from the arg list passed to createlang. This worked in a way that
 probin in pg_proc had value $libdir/plpgsql.

 Later it turned out the embedded library path was used, and install
 failed when there was no access to the build environment.

 Now I put the -L $libpath argument back in place, then I update
 pg_proc with the dynamic value. This works fine, but such approach
 looks too intrusive. I think I also tried to set env LD_LIBRARY_PATH,
 which by some reason did not help.

 Is there a better way to handle this and avoid updating pg_proc?

 Thank you.

 
  Michael Brusser [EMAIL PROTECTED] writes:
   I'm running Postgres v.7.3.4.
   In my database dump file I see this:
 
   CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
   AS '/home/tmichael/build/relipg21/syncinc/lib.sol2/plpgsql',
   'plpgsql_call_handler'
   LANGUAGE c;
 
   The hardcoded library path may become an obstacle when loading
   data into a different server. Is there a way to avoid this?
 
  The preferred way to write it nowadays is '$libdir/plpgsql', but
  you evidently have a legacy value embedded in your pg_proc table.
  pg_dump will not second-guess this, and so the old full-path
  approach will persist over dump/reloads until you do something about it.
 
  I'd suggest editing the dump file before you reload, or even manually
  updating pg_proc.probin for this function entry so that future dumps
  are right.
 
  regards, tom lane



 ---(end of broadcast)---
 TIP 7: don't forget to increase your free space map settings




---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Thread safe connection-name mapping in ECPG. Is it

On Friday 27 February 2004 20:54, Michael Meskes wrote:
 On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar wrote:
  How about, allowing 'connection *'? If somebody puts a 'connection *'
  there it is used. If it is a string a name search is performed. Best of
  both worlds.

 How shall anyone put a pointer to a connection struct inside the SQL
 statement?

 It would help me a lot if you'd be able to give some examples.

EXEC SQL BEGIN DECLARE SECTION;
 connect *connectionPtr;
EXEC SQL END DECLARE SECTION;

EXEC SQL CONNECT TO db AS connectionPtr;
EXEC SQL AT connectionPtr SELECT 1;

After all, it is matter of parsing some code and emitting equivalent C code, 
isn't it?

 Shridhar

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Tablespaces

2004-02-27 Thread scott.marlowe

On Fri, 27 Feb 2004, Zeugswetter Andreas SB SD wrote:

 
   Ahh. I forgot to detail my ideas on this. It seems to me that we cannot
   drop a table space until the directory is empty.
 
 Agreed.
 
  
  How would it get to be empty?  Are you thinking of some sort of connect
  database to tablespace and disconnect database from tablespace
  commands that would respectively create and delete the per-database
  subdirectory?  That seems moderately reasonable to me.  We could then
 
 I would only allow the drop if the directory only contains empty db oid 
 directories.

Wouldn't this be better tracked in the dependency tracking that's already 
built into postgresql?  Checking to see if the directory is empty is open 
to race conditions, but locking the dependency tracking while dropping a 
tablespace isn't.



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Tablespaces

2004-02-27 Thread scott.marlowe

On Fri, 27 Feb 2004, Gavin Sherry wrote:

 On Thu, 26 Feb 2004, Alex J. Avriette wrote:
 
  On Thu, Feb 26, 2004 at 11:22:28PM +1100, Gavin Sherry wrote:
 
   Certainly, table spaces are used in many ways in oracle, db2, etc. You can
   mirror data across them, have different buffer sizes for example.
   In some implementations, they can be raw disk partitions (no file system).
   I don't intend going this far, however.
 
  Perhaps now would be a good time to bring up my directio on Solaris question
  from a year or so back? Is there any interest in the ability to use raw
  disk?
 
 I do not intend to undertake raw disk tablespaces for 7.5. I'd be
 interested if anyone could provide some real world benchmarking of file
 system vs. raw disk. Postgres benefits a lot from kernel file system cache
 at the moment. Also, I believe that database designers have traditionally
 made bad file system designers. Raw database partitions often lack the
 tools essential to a scalable environment. For example, the ability to
 resize partitions.

Is possible / reasonable / smart and or dumb to look at implementing the 
tablespaces as riding atop the initlocation handled stuff.  I.e. 
postgresql can only create tablespaces in areas that are created by 
initlocation, thus keeping it in its box, so to speak?


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] CVS HEAD compile warning

Michael Meskes [EMAIL PROTECTED] writes:
 At this point I think our first question is whether flex 2.5.31 is
 correctly detecting a hole in the ecpg lexer rules that was missed by
 flex 2.5.4, or whether the warning is simply wrong.

 Yes, that's it. The big problem seems to be that flex does not have a
 way to help finding that hole.

Yeah, I was scratching my head over that too.  You'd think there'd be
some more useful debug output.

FWIW, I found two basic causes of that failure when I was fixing the
other lexers:

* not accounting for the fact that . matches everything but newline.
  You can write .|\n instead.

* not ensuring that a single character can always be matched.  For
  instance, one lexer had several rules for \ followed by various
  things, but no rule that could match \ not followed by anything,
  which meant that \ just before EOF was a missing case.

But I'm not sure that helps, since flex 2.5.4 detected those cases.
We don't really know what we're dealing with in this ecpg situation...

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Tablespaces

scott.marlowe [EMAIL PROTECTED] writes:
 On Fri, 27 Feb 2004, Zeugswetter Andreas SB SD wrote:
 How would it get to be empty?  Are you thinking of some sort of connect
 database to tablespace and disconnect database from tablespace
 commands that would respectively create and delete the per-database
 subdirectory?  That seems moderately reasonable to me.  We could then
 
 I would only allow the drop if the directory only contains empty db oid 
 directories.

That's subject to race conditions (ie, someone creating a table about
the same time you are deciding it's okay to drop the tablespace).  There
needs to be some interlock, and I think that associating that lock with
infrequently executed connect/disconnect operations would be good from a
performance standpoint.

 Wouldn't this be better tracked in the dependency tracking that's already 
 built into postgresql?

No, because dependencies are local to individual databases.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Tablespaces

scott.marlowe [EMAIL PROTECTED] writes:
 Is possible / reasonable / smart and or dumb to look at implementing the 
 tablespaces as riding atop the initlocation handled stuff.

In my mind, one of the main benefits of this work will be that we'll be
able to get *rid* of the initlocation stuff.  It's a crock.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Tablespaces

2004-02-27 Thread scott.marlowe

On Fri, 27 Feb 2004, Tom Lane wrote:

 scott.marlowe [EMAIL PROTECTED] writes:
  Is possible / reasonable / smart and or dumb to look at implementing the 
  tablespaces as riding atop the initlocation handled stuff.
 
 In my mind, one of the main benefits of this work will be that we'll be
 able to get *rid* of the initlocation stuff.  It's a crock.

OK, that's fine, but I keep thinking that a superuser should have to 
create the tablespace itself, and then tables can be assigned by users 
based on the rights assigned by the dba / superuser.  Is that how we're 
looking at doing it, or will any user be able to create a tablespace 
anywhere postgresql has write permission, or will only dbas be able to 
create AND use table spaces. I'm just not sure how that's gonna be 
handled, and haven't seen it addressed.


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Josh Berkus

Folks:

ALTERNATIVE BUG TRACKERS:

Jira:   Core did look at and consider (and debate) Jira.   Atlassian are 
enthusiastic PostgreSQL supporters and offered to host Jira for us.   
However, Jira is not OSS and for various reasons it would be difficult to 
host a Jira installation at Hub.org.   We're very reluctant to endorse any 
non-OSS, externally hosted solution becuase of the distinct possibility that 
the company will have a change of management and drop us.  There is also a 
significant political issue; by adopting a non-OSS piece of infrastructure, 
we are effectively saying that OSS software isn't good enough, in the eyes of 
many members of the public.

RT:   I've been using RT for OSCON, and am not wowed by it.Of course, I 
can say the same of BZ and GForge-Tracker.   From my perspective, it's 
neither better nor worse than the other solutions, although the interaction 
with e-mail is nice.
More importantly, *we* would have to do the port to PostgreSQL.   This is 
pretty much prohibitive; how long have we been working on an update to the 
main site, Techdocs, and/or Advocacy?If we pick a solution which is not 
ready *right now* I fear that we will still be having this discussion in late 
2005.   I also don't see any good reason, politically, to adopt a tool by a 
community who are not at all enthusiastic about Postgres -- when there a 
those available that are.

Both of the above alternatives have 2 major issues:
1) They are each bug trackers and bug trackers only.   They do not deal with 
community or code management at all.   I would tend to prefer an integrated 
solution where one is available.

2) For whatever reason, most of our volunteer web crew seem to be PHP 
developers.   We haven't attracted many Perl or Java programmers to helping 
with the site.   This may be a chicken-and-egg thing, but unless there are 
several untapped Perl Hackers/Java programmers waiting to jump in and do 
integration work for RT, Jira, or whatever, any non-PHP solution 
automatically carries a detraction.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Josh Berkus

Paul,

 Your main concern about RT isn't true, at least here at my office. I
 installed RT, with no prior experience with any OSS tracker, back in
 October, and it worked on PostgreSQL the first time. (PostgreSQL support was
 one of the main reasons I chose it to track issues on my
 PostgreSQL/Perl-based webapp.) I made this point in an earlier post in this
 thread. There is no conversion effort needed with RT 3.0.6, it just works on
 PostgreSQL. 

My apologies, then!   I was operating off of the statements of others, and the 
fact that the only RT impelementations I've used were running on MySQL.   So, 
questions:

1) can you compare/contrast RT vs. BZ vs. Simplified bug-tracking, like 
GForge?

2) What help, if any, would we be able to get in supporting RT from the RT 
community?

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Andrew Dunstan



Greg Stark wrote:

I also dislike BZ for aesthetic reasons. If one person is editing a ticket
while another person updates the same ticket, it refuses your edits and you
have to start all over. I think all the updates are stored in one big field.
 

AFAICS it's one row per comment, at least in the 2.17 code base. BZ does 
have horrible locking issues - they are being dealt with as part of the 
bugs I referred to elsewhere.

cheers

andrew

---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org

Re: [HACKERS] CVS HEAD compile warning

2004-02-27 Thread tswan

 Tom Lane wrote:


 Red Hat's still shipping 2.5.4a according to a quick look...

 Well Red Hat's still ship Postgres 7.3.4 ...

 I'm not considering anymore RH to be up to date with various versions
 :-(

 Gaetano



Not to jump immediately to RH's defense, but Fedora Core 2 (currently in
beta) is going to ship with PostgreSQL 7.4.x.   AFAIK, the update strategy
for most Red Hat distributions does not include major application version
changes in a release maintenance update.  RH will often backport patches
to fix bugs or security issues from newer versions of applications so that
library version numbers do not change and it doesn't adversely affect any
other dependent systems.

Look at this list's archive to see how difficult it is to update from
7.3.x to 7.4.x without the RPM or automated upgrade issue.  There has been
some talk about resurrecting pg_upgrade, but that's not an easy task. 
Even then, that may not solve the entire upgrade problem for RPM based
distributions.



---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Bort, Paul

 
 My apologies, then!   I was operating off of the statements 
 of others, and the 
 fact that the only RT impelementations I've used were running 
 on MySQL.   So, 
 questions:
 
 1) can you compare/contrast RT vs. BZ vs. Simplified 
 bug-tracking, like 
 GForge?

I've used Bugzilla for searching for FOP issues, and a couple other places,
and I find the RT search much more obvious. I can get what I want out of
Bugzilla, but usually by creating a really broad search and sifting entries
one at a time for likely candidates. The fact that an RT search is iterative
is much more obvious, because the bottom of the search page lists all of the
current criteria, and the box for adding new ones. Add or remove, and re-run
the search. I like the trick that it does with mutually exclusive
conditions: It assumes an 'or' between them. (eg, all tickets that are in
state 'open' or 'closed'.) 

OTOH, Bugzilla tracks a whole pile more fields by default. I've taken to
putting version numbers in the ticket subject in RT because for the small
project here, it's easier than learning how to add a version field. (I
haven't tried adding my own fields.) 

Both handle attachments and comments sanely. I don't know if BZ has an
e-mail interface, but the one in RT has filled the basic needs here. (We
haven't pushed the limits of the e-mail part.)

I have never tried to install BZ. RT's install (RedHat 8.0, PostgreSQL 7.2.4
from RPMs) was straightforward once all the Perl modules were up to date.
(All of the needed modules were available from CPAN.)

I don't recall using any simplified bug tracking on-line, except maybe at
ImageMagick.com, which seems to be more a forum or mailing list search, with
no real tracking fields.

 
 2) What help, if any, would we be able to get in supporting 
 RT from the RT 
 community?

I'm afraid I have no idea what or where the larger RT community is. I know
there's commercial support available from the author (whom I have no contact
with), and I found the answers to my (self-created) problems during setup
using Google. I found RT because of a (don't ban me, please ;-) discussion
on SlashDot. (http://slashdot.org/article.pl?sid=03/10/06/1854211) There
were a large number of proponents of RT there; their posts claimed years of
use at many sites. 

I would be happy to lend my meager talents to setting it up for a trial, if
that's where the group decides to go.

But Josh made a good point off-list: are we trying to solve the problem of
ticket/bug tracking, or community/collaboration in general? 

My $0.02: CVS handles the code, mailing lists handle the dialog, and a
ticket/bug tracker keeps people from losing things. About all that leaves
for the web site to do is advocate PostgreSQL (which I think it does nicely)
and related projects, and provide some glue (like how to find the name of
the other lists or projects to see what they're doing.) New tools or old,
every day with PostgreSQL is a good day. 



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

[HACKERS] snapshot libpq compile fails under cygwin/win32 with -j 2

2004-02-27 Thread tswan

When compiling the 2004-02-27 snapshot with make -j 2, the compile of
libpq fails with the following error.

dlltool --export-all --output-def pq.def fe-auth.o fe-connect.o fe-exec.o
fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o
pqsignal.o fe-secure.o dllist.o md5.o ip.o wchar.o encnames.o
getaddrinfo.o path.o thread.o
dlltool --export-all --output-def pq.def fe-auth.o fe-connect.o fe-exec.o
fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o
pqsignal.o fe-secure.o dllist.o md5.o ip.o wchar.o encnames.o
getaddrinfo.o path.o thread.o
dllwrap -o pq.dll --dllname pq.dll --def pq.def fe-auth.o fe-connect.o
fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o
pqexpbuffer.o pqsignal.o fe-secure.o dllist.o md5.o ip.o wchar.o
encnames.o getaddrinfo.o path.o thread.o ../../../src/utils/dllinit.o
-L../../../src/port -L/usr/local/lib -lssl -lcrypto -lcrypt
dllwrap -o pq.dll --dllname pq.dll --def pq.def fe-auth.o fe-connect.o
fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o
pqexpbuffer.o pqsignal.o fe-secure.o dllist.o md5.o ip.o wchar.o
encnames.o getaddrinfo.o path.o thread.o ../../../src/utils/dllinit.o
-L../../../src/port -L/usr/local/lib -lssl -lcrypto -lcrypt
dlltool --dllname pq.dll --def pq.def --output-lib libpq.a
dlltool --dllname pq.dll --def pq.def --output-lib libpq.a
dlltool: Can't open .lib file: libpq.a
make[3]: *** [pq.dll] Error 1
make[3]: *** Deleting file `pq.dll'
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory
`/tmp/build/postgresql-snapshot/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/build/postgresql-snapshot/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/build/postgresql-snapshot/src'
make: *** [all] Error 2

This may be a dependency issue for the make process.  Rerunning make
without the -j 2 option completes without any problems.

Thomas


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Tablespaces

2004-02-27 Thread tswan


 I do not intend to undertake raw disk tablespaces for 7.5. I'd be
 interested if anyone could provide some real world benchmarking of file
 system vs. raw disk. Postgres benefits a lot from kernel file system
 cache
 at the moment.

 Yes, and don't forget that pg also relys on the OS for grouping and
 sorting the physical writes and doing readahead where appropriate.



Most people I know want tablespaces in order to limit or preallocate the
disk space used by a table or database in addition to controlling the
physical location of a table or database.

I know on linux, there is the option of creating an empty file or a
specific size using dd, mounting it through loopback, formatting it,
symlinking the appropriate OID/TID (or mounting the lpb device in the
appropriate directory) and then you control how much space that
directory/mount point can contain.

Of course, with MVCC you would have to vacuum frequently, as you could
miss some updates if there weren't enough tuples marked as free.  If there
were in-place updates, the preallocation and limitation much easier, but
that's not how PG works.

If the tablespace disk space allocation is exceeded there would need to be
some graceful reporting condition back to the client.  UPDATE/INSERT
failed (tablespace size exceeded), (tablespace full), (disk full) or
some other error may need to be handled/reported.


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Tablespaces

2004-02-27 Thread Gavin Sherry

On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote:

 
  I do not intend to undertake raw disk tablespaces for 7.5. I'd be
  interested if anyone could provide some real world benchmarking of file
  system vs. raw disk. Postgres benefits a lot from kernel file system
  cache
  at the moment.
 
  Yes, and don't forget that pg also relys on the OS for grouping and
  sorting the physical writes and doing readahead where appropriate.
 
 

 Most people I know want tablespaces in order to limit or preallocate the
 disk space used by a table or database in addition to controlling the
 physical location of a table or database.

 I know on linux, there is the option of creating an empty file or a
 specific size using dd, mounting it through loopback, formatting it,
 symlinking the appropriate OID/TID (or mounting the lpb device in the
 appropriate directory) and then you control how much space that
 directory/mount point can contain.

 Of course, with MVCC you would have to vacuum frequently, as you could
 miss some updates if there weren't enough tuples marked as free.  If there
 were in-place updates, the preallocation and limitation much easier, but
 that's not how PG works.

I do not intend to work on such a system for the initial introduction of
table spaces. The problem is, of course, knowing when you're actually out
of space in a table space in any given transaction. Given that WAL is on a
different partition (at least for the moment) the table space will not
have transaction X's data written to it until after transaction X is
finished. And we cannot error out a transaction which is already commited.

The solution is to keep track of free space and error out at some
percentage of free space remaining. But I don't want to complicate
tablespaces too much in 7.5.

Thanks,

Gavin

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Andrew Dunstan

Bort, Paul wrote:

My apologies, then! I was operating off of the statements
of others, and the
fact that the only RT impelementations I've used were running
on MySQL. So,
questions:

1) can you compare/contrast RT vs. BZ vs. Simplified
bug-tracking, like
GForge?

I've used Bugzilla for searching for FOP issues, and a couple other places,
and I find the RT search much more obvious. I can get what I want out of
Bugzilla, but usually by creating a really broad search and sifting entries
one at a time for likely candidates. The fact that an RT search is iterative
is much more obvious, because the bottom of the search page lists all of the
current criteria, and the box for adding new ones. Add or remove, and re-run
the search. I like the trick that it does with mutually exclusive
conditions: It assumes an 'or' between them. (eg, all tickets that are in
state 'open' or 'closed'.)

OTOH, Bugzilla tracks a whole pile more fields by default. I've taken to
putting version numbers in the ticket subject in RT because for the small
project here, it's easier than learning how to add a version field. (I
haven't tried adding my own fields.)

Both handle attachments and comments sanely. I don't know if BZ has an
e-mail interface, but the one in RT has filled the basic needs here. (We
haven't pushed the limits of the e-mail part.)
I have never tried to install BZ. RT's install (RedHat 8.0, PostgreSQL 7.2.4
from RPMs) was straightforward once all the Perl modules were up to date.
(All of the needed modules were available from CPAN.)
I don't recall using any simplified bug tracking on-line, except maybe at
ImageMagick.com, which seems to be more a forum or mailing list search, with
no real tracking fields.

2) What help, if any, would we be able to get in supporting
RT from the RT
community?

I'm afraid I have no idea what or where the larger RT community is. I know
there's commercial support available from the author (whom I have no contact
with), and I found the answers to my (self-created) problems during setup
using Google. I found RT because of a (don't ban me, please ;-) discussion
on SlashDot. (http://slashdot.org/article.pl?sid=03/10/06/1854211) There
were a large number of proponents of RT there; their posts claimed years of
use at many sites.

[some stuff about RT]

FWIW there's a good directory of bug tracking systems on google:
http://directory.google.com/Top/Computers/Software/Configuration_Management/Bug_Tracking/Free/

I have looked at RT briefly today, and its technology appears to be
sound. (Just the fact that it will run under both mod_perl and FastCGI
means that a lot of common insanity is missing - these environments are
very good at blowing up with badly written software. They are also far
more scalable than standard CGI web environments, so we would be less
likely to have performance issues.)

I would be happy to lend my meager talents to setting it up for a trial, if
that's where the group decides to go.
ditto

But Josh made a good point off-list: are we trying to solve the problem of
ticket/bug tracking, or community/collaboration in general?

The discussion arose in the context of an alternative to the rather
simple bug tracking system that comes with GForge. The biggest issue
with any replacement would be to plug it in successfully. If too much
glue is needed, we haven't really made an advance on the current GBorg
code base.

cheers

andrew

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

2004-02-27 Thread Josh Berkus

Mikhail,

 For a standalone bug/issue tracking tool take a look on 
 http://roundup.sourceforge.net

I don't see PostgreSQL support listed -- just SQLite and MySQL.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Tablespaces