Re: [HACKERS] pgsql oid question
Reggie Burnett [EMAIL PROTECTED] writes: Ok, that adds some clarity. Have base types (int32, etc) had the same oid values for a significant number of versions of PgSQL? What I am getting at is this: can I hard code oid values into an access layer for PgSQL? AFAIK, we have never renumbered an existing standard type. But we reserve the right to do it. Also, base types have appeared and disappeared in living memory (eg, datetime). Minimum prudence would be to #include pg_type.h and then write INT4OID rather than 23 (for example). A more paranoid approach is to establish a typename-oid cache on the client side and not believe anything you haven't probed during the current connection. The Java driver takes the paranoid approach, but some other clients such as the ODBC driver rely on #defines. The tradeoffs are pretty obvious, so make your own choice about what to do. 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: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
On Sat, 4 Jan 2003, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I never considered tag'ng for minor releases as having any importance, since the tarball's themselves provide the 'tag' ... branches give us the ability to back-patch, but tag's don't provide us anything ... do they? Well, a tag makes it feasible for someone else to recreate the tarball, given access to the CVS server. Dunno how important that is in the real world --- but I have seen requests before for us to tag release points. FWIW, in the real world, a release doesn't happen if it's not taqged. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
Peter Mount wrote: On Sat, 4 Jan 2003, Marc G. Fournier wrote: I'm just announcing here, since I'd like to see some ppl testing this out and let us know if there are any problems ... DNS is going to take a little while to propogate, so the old site may still come up in the interium ... another reason not to announce it right away :) Looks pretty good here. However, the bugs link on the main page is currently broken (404: Page not found) http://www.postgresql.org/bugs/bugs.php link from the main page. Ouch, sorry about that. It's fixed now too. :-) Regards and best wishes, Justin Clift Peter -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Upgrading rant.
On Sat, 2003-01-04 at 22:37, Tom Lane wrote: You're missing the point: I don't want to lock out everyone but the super-user, I want to lock out everyone, period. Superusers are just as likely to screw up pg_upgrade as anyone else. BTW: $ postmaster -N 1 -c superuser_reserved_connections=1 postmaster: superuser_reserved_connections must be less than max_connections. $ Well, first, let me say that the above just seems wrong. I can't think of any valid reason why reserved shouldn't be allowed to equal max. I also assumed that pg_update would be attempting to connect as the superuser. Therefore, if you only allow a single connection from the superuser and pg_upgrade is using it, that would seem fairly hard to mess things up. On top of that, that's also the risk of someone being a superuser. They will ALWAYS have the power to hose things. Period. As such, I don't consider that to be a valid argument. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
On Sun, 2003-01-05 at 06:41, Dan Langille wrote: On Sat, 4 Jan 2003, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I never considered tag'ng for minor releases as having any importance, since the tarball's themselves provide the 'tag' ... branches give us the ability to back-patch, but tag's don't provide us anything ... do they? Well, a tag makes it feasible for someone else to recreate the tarball, given access to the CVS server. Dunno how important that is in the real world --- but I have seen requests before for us to tag release points. FWIW, in the real world, a release doesn't happen if it's not taqged. Agreed! Any tarballs, rpms, etc., should be made from the tagged source. Period. If rpm's are made from a tarball that is made from tagged source, that's fine. Nonetheless, any official release (major or minor) should always be made from the resulting tagged source. This does two things. First, it validates that everything has been properly tagged. Two, it ensures that there are not any localized files or changes which might become part of a tarball/release which are not officially part of the repository. I can't stress enough that a release should never happen unless source has been tagged. Releases should ALWAYS be made from a checkout based on tags. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, a tag makes it feasible for someone else to recreate the tarball, given access to the CVS server. Dunno how important that is in the real world --- but I have seen requests before for us to tag release points. Any other arguments out there? FWIW, I use the tags often in some scripts that rely on the output of 'cvs status -v'. Seeing REL7_3_STABLE at the top of the Existing Tags list is a bit disconcerting when you know that it's not true. My scripts assume that the latest release should always be tagged. Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200208 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+GE1NvJuQZxSWSsgRAh/1AKCPEKQeQ3OnKzbeSl5DXstnwwiFPQCfQ2mn KplkOouzodJqZvQNN2tk8Fk= =OaZY -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] New Portal in Place, DNS switched ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of DNS, we should probably not put all of our eggs in one basket (subnet): $ whois postgresql.org ... Domain servers in listed order: NS.HUB.ORG 64.49.215.5 NS2.HUB.ORG 64.49.215.6 It would be nice if one or more nameservers were added that were not in the same subnet, especially because we have so many mirrors (subdomains) that are scattered all over the globe. Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301051008 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+GE5lvJuQZxSWSsgRAteAAJ9YQF/eOpS+bZl84HOT84HAiaRQtQCfawbI VpEZSB8oXoO3ycza4g6h5Hg= =19gB -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Upgrading rant.
Bruce Momjian wrote: pg_upgrade does work, assuming there are no changes to the index or heap file formats. (However, I now need to update it for schemas.) However, the last time I worked on it for 7.2, no one was really interested in testing it, so it never got done. In fact, there was a bug in the handling of clog or wal files, but I didn't find out about it until long after 7.2 because no one was using it. Is pg_upgrade too hard to run? Is no one really interested in it? As far as I've seen, it is a cool idea, but I can't trust it. I have the USA tiger census data in a database, it is over 60G with indexes, 30G+ of just data. Do you know how long that will take to dump and restore? Making one index on some of the tables takes 20 minutes. IMHO: (1) The PostgreSQL core development team has to commit to an in place upgrade. I think the in-place upgrade strategy is very important, and it will take an effort and commitment from the core development team. I doubt seriously it can be done in a robust and safe way if the feature is not a stated design goal. (2) Upgrade HAS HAS HAS to be fool proof. No one is going to use it if you say, backup your data just in case. It should be as trust worthy as postgresql itself. If it can't be that it is not a valid tool. Anything less will not be used by professionals and wouldn't be worth the effort. (3) It should be able to span more than one version. If I upgrade from two versions back, it should work. It should not balk. The above is simply my opinion, and probably not possible with previous versions, but moving forward, it should be, if it is a priority. If it is not a priority, then it is not worth doing. Again, just my opinion. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] New Portal in Place, DNS switched ...
-Original Message- From: Peter Mount [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 12:28 To: Marc G. Fournier Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] New Portal in Place, DNS switched ... On Sat, 4 Jan 2003, Marc G. Fournier wrote: I'm just announcing here, since I'd like to see some ppl testing this out and let us know if there are any problems ... DNS is going to take a little while to propogate, so the old site may still come up in the interium ... another reason not to announce it right away :) Looks pretty good here. However, the bugs link on the main page is currently broken (404: Page not found) http://www.postgresql.org/bugs/bugs.php link from the main page. Ack, knew we probably missed something... Leave it with me. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
-Original Message- From: Justin Clift [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 13:22 To: Peter Mount Cc: Marc G. Fournier; [EMAIL PROTECTED] Subject: Re: [HACKERS] New Portal in Place, DNS switched ... Peter Mount wrote: However, the bugs link on the main page is currently broken (404: Page not found) http://www.postgresql.org/bugs/bugs.php link from the main page. Ouch, sorry about that. It's fixed now too. Ahh you've done it - save me a job :-) /D ---(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] New Portal in Place, DNS switched ...
Any volunteers to act as a tertiary? :) We're actually working on adding a new server online that is offshore, which will also give us another subnet to work off of ... but having a third-party secondary server wouldn't hurt, you are right ... On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of DNS, we should probably not put all of our eggs in one basket (subnet): $ whois postgresql.org ... Domain servers in listed order: NS.HUB.ORG 64.49.215.5 NS2.HUB.ORG 64.49.215.6 It would be nice if one or more nameservers were added that were not in the same subnet, especially because we have so many mirrors (subdomains) that are scattered all over the globe. Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301051008 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+GE5lvJuQZxSWSsgRAteAAJ9YQF/eOpS+bZl84HOT84HAiaRQtQCfawbI VpEZSB8oXoO3ycza4g6h5Hg= =19gB -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 01:10 To: Marc G. Fournier Cc: Dan Langille; Peter Eisentraut; Greg Copeland; Bruce Momjian; PostgresSQL Hackers Mailing List Subject: Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ... Marc G. Fournier [EMAIL PROTECTED] writes: I never considered tag'ng for minor releases as having any importance, since the tarball's themselves provide the 'tag' ... branches give us the ability to back-patch, but tag's don't provide us anything ... do they? Well, a tag makes it feasible for someone else to recreate the tarball, given access to the CVS server. Dunno how important that is in the real world --- but I have seen requests before for us to tag release points. Any other arguments out there? I've often found tags useful when ppl have reported bugs that have occured between version - A quick way to see the changes that might have introduced the new bug when browsing though a web interface. Regards, Dave. ---(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] New Portal in Place, DNS switched ...
--On Sunday, January 05, 2003 12:52:11 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: Any volunteers to act as a tertiary? :) Sure, I have 2 NS's on my network with good upstream connectivity (UUNET, SPRINT, GENUITY, CW, SAVVIS). (207.158.72.11/207.158.72.45). Let me know what the primary is, and what domain(s) you want. the NS records listed in the root are: NS-A.lerctr.org [207.158.72.11] NS-B.lerctr.org [207.158.72.45] We're actually working on adding a new server online that is offshore, which will also give us another subnet to work off of ... but having a third-party secondary server wouldn't hurt, you are right ... Be more than happy to supply it. LER On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of DNS, we should probably not put all of our eggs in one basket (subnet): $ whois postgresql.org ... Domain servers in listed order: NS.HUB.ORG 64.49.215.5 NS2.HUB.ORG 64.49.215.6 It would be nice if one or more nameservers were added that were not in the same subnet, especially because we have so many mirrors (subdomains) that are scattered all over the globe. Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301051008 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+GE5lvJuQZxSWSsgRAteAAJ9YQF/eOpS+bZl84HOT84HAiaRQtQCfawbI VpEZSB8oXoO3ycza4g6h5Hg= =19gB -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] Upgrading rant.
-Original Message- From: mlw [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 16:36 To: Bruce Momjian Cc: Tom Lane; Hannu Krosing; Lamar Owen; [EMAIL PROTECTED] Subject: Re: [HACKERS] Upgrading rant. (2) Upgrade HAS HAS HAS to be fool proof. Agreed. No one is going to use it if you say, backup your data just in case. I think we would be irresponsible to _not_ say that, no matter how good we thought the code was. It should be as trust worthy as postgresql itself. If it can't be that it is not a valid tool. Anything less will not be used by professionals and wouldn't be worth the effort. Agreed again. But I still backup my PostgreSQL boxes, and would advise anyone else to as well. Frankly I'm glad I do, especially having had yet another Fujitsu disk die the other day. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Larry Rosenman wrote: --On Sunday, January 05, 2003 12:52:11 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: Any volunteers to act as a tertiary? :) Sure, I have 2 NS's on my network with good upstream connectivity (UUNET, SPRINT, GENUITY, CW, SAVVIS). (207.158.72.11/207.158.72.45). Let me know what the primary is, and what domain(s) you want. the NS records listed in the root are: NS-A.lerctr.org [207.158.72.11] NS-B.lerctr.org [207.158.72.45] right now, primary is 64.49.215.9, and the only domain I can see requiring is the *.postgresql.org one, which should just about cover everything, and is the only one maintained by 215.9 ... Should I use both of the above, or which would you prefer? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
Looks like your firewall needs to allow TCP/53 connections from me as well. I'm getting RST's. (BTW, TCP/53 can be used for large queries, so it should be allowed globally). LER --On Sunday, January 05, 2003 12:59:42 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: On Sun, 5 Jan 2003, Larry Rosenman wrote: --On Sunday, January 05, 2003 12:52:11 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: Any volunteers to act as a tertiary? :) Sure, I have 2 NS's on my network with good upstream connectivity (UUNET, SPRINT, GENUITY, CW, SAVVIS). (207.158.72.11/207.158.72.45). Let me know what the primary is, and what domain(s) you want. the NS records listed in the root are: NS-A.lerctr.org [207.158.72.11] NS-B.lerctr.org [207.158.72.45] right now, primary is 64.49.215.9, and the only domain I can see requiring is the *.postgresql.org one, which should just about cover everything, and is the only one maintained by 215.9 ... Should I use both of the above, or which would you prefer? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] New Portal in Place, DNS switched ...
--On Sunday, January 05, 2003 12:59:42 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: On Sun, 5 Jan 2003, Larry Rosenman wrote: --On Sunday, January 05, 2003 12:52:11 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: Any volunteers to act as a tertiary? :) Sure, I have 2 NS's on my network with good upstream connectivity (UUNET, SPRINT, GENUITY, CW, SAVVIS). (207.158.72.11/207.158.72.45). Let me know what the primary is, and what domain(s) you want. the NS records listed in the root are: NS-A.lerctr.org [207.158.72.11] NS-B.lerctr.org [207.158.72.45] right now, primary is 64.49.215.9, and the only domain I can see requiring is the *.postgresql.org one, which should just about cover everything, and is the only one maintained by 215.9 ... Should I use both of the above, or which would you prefer? Put them both in. I have a tendency to not have both down at the same time. Looks like you need to allow me AXFR. I've added it to both, but I'm getting no AXFR permission. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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
[HACKERS] Implementing a new Join Algorithm
Hi,
I am trying to test a new join algorithm by
implementing it on Postgresql.
It would be great if you could give me some start off
pointers so as to where all in the source code I will
have to make changes. (I figure that I need to make
executor nodes, so i might need to write nodeNewjoin.c
etc in src/backend/executor, and somehow get the
planner/optimizer to select the new algorithm)
I tried going through the developers guide (7.3.1) but
it has many figures missing, making my job of
understanding the mechanism very tough. The figures
I am referring to are
{PostgreSQL 7.3.1 Documentation
section 2.3.1: Figure \ref{parsetree},
\ref{where_clause}
section 2.3.2 Figure \ref{transformed},
\ref{transformed_where}
2.5.2 \ref{plan} \ref{simple_select}.
}
Could you please point out where these figures are
available.
Regards
Anagh Lal.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Tom Lane wrote: AFAICT none of the www mirrors have updated yet; that's starting to seem suspicious. the www mirrors don't update from the portal,they update from what is now the users-lounge area ... the portal itself isn't meant to be mirrors, as its pretty much completely database driven ... ---(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] New Portal in Place, DNS switched ...
Marc G. Fournier [EMAIL PROTECTED] writes: On Sun, 5 Jan 2003, Tom Lane wrote: AFAICT none of the www mirrors have updated yet; that's starting to seem suspicious. the www mirrors don't update from the portal,they update from what is now the users-lounge area ... But they aren't. Try going to the users-lounge area via the new portal. Show me even one mirror that isn't displaying the old home page. regards, tom lane ---(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] New Portal in Place, DNS switched ...
Two thoughts: Are there any plans to 'strip' the users lounge of duplicated information? (outdated news, various links, etc.). Will advocacy, gborg, archives, techdocs, etc. be updated to include links back to the portal site? BTW, the 'Users Lounge' search link is broken. http://www.postgresql.org/search.cgi no longer exists. On Sat, 2003-01-04 at 19:40, Marc G. Fournier wrote: I'm just announcing here, since I'd like to see some ppl testing this out and let us know if there are any problems ... DNS is going to take a little while to propogate, so the old site may still come up in the interium ... another reason not to announce it right away :) -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Rod Taylor wrote: Two thoughts: Are there any plans to 'strip' the users lounge of duplicated information? (outdated news, various links, etc.). Yes ... Will advocacy, gborg, archives, techdocs, etc. be updated to include links back to the portal site? Yes ... BTW, the 'Users Lounge' search link is broken. http://www.postgresql.org/search.cgi no longer exists. Guys? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Sun, 5 Jan 2003, Tom Lane wrote: AFAICT none of the www mirrors have updated yet; that's starting to seem suspicious. the www mirrors don't update from the portal,they update from what is now the users-lounge area ... But they aren't. Try going to the users-lounge area via the new portal. Show me even one mirror that isn't displaying the old home page. next phase ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
AFAICT none of the www mirrors have updated yet; that's starting to seem suspicious. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sat, 2003-01-04 at 19:40, Marc G. Fournier wrote: I'm just announcing here, since I'd like to see some ppl testing this out and let us know if there are any problems Why are there ads on the page? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 20:34 To: Marc G. Fournier Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] New Portal in Place, DNS switched ... Marc G. Fournier [EMAIL PROTECTED] writes: On Sun, 5 Jan 2003, Tom Lane wrote: AFAICT none of the www mirrors have updated yet; that's starting to seem suspicious. the www mirrors don't update from the portal,they update from what is now the users-lounge area ... But they aren't. Try going to the users-lounge area via the new portal. Show me even one mirror that isn't displaying the old home page. I see what you mean Tom. Marc, how can I get to the old server? I don't have a note of the IP address. We need to redirect from the current index.html to /user-lounge/index.html Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Implementing a new Join Algorithm
Anagh Lal [EMAIL PROTECTED] writes: I am trying to test a new join algorithm by implementing it on Postgresql. It would be great if you could give me some start off pointers so as to where all in the source code I will have to make changes. Lots of places ;-). You will find that a full-text indexing tool is an essential aid for working with the Postgres source code. I am partial to glimpse but others use other things (searching for glimpse in the pghackers list archives should turn up previous discussions of useful tools). Once you've got one, looking for files mentioning both merge and hash should locate all the incidental places you will need to hit. The primary work will certainly be in adding an executor/nodeNewjoin.c file and in teaching the planner how to plan the join type. I think most of the incidental work will be associated with creating new plan, executor-state, and path node types and adding support code for these where needed. This should be largely boilerplate that you can produce by emulating the existing join types. Frankly I'd consider a new join type to be an overly ambitious target for a person's first venture into the Postgres backend. You'd probably find it a good idea to tackle some smaller project(s) first ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Implementing a new Join Algorithm
Tom == Tom Lane [EMAIL PROTECTED] writes: Tom Anagh Lal [EMAIL PROTECTED] writes: I am trying to test a new join algorithm by implementing it on Postgresql. It would be great if you could give me some start off pointers so as to where all in the source code I will have to make changes. Tom Lots of places ;-). Tom You will find that a full-text indexing tool is an essential Tom aid for working with the Postgres source code. I am partial I've had great success with cscope. Especially with the XEmacs interfaces. I think in fact the easy part is the executor stuff because it's nicely localized. Getting the planner to choose a new option is a little messier. As part of the TelegraphCQ project we've implemented what smells like a symmetric hash join. Actually it's more like an N-way symmetric hash join. This is done using the new SteM operator which can work in a classical iterator model plan. With the Eddy operator we can avoid static dataflows. Since we were a bit chary of jumping headlong into the optimizer, we cheated. What we do is let the postgres optimizer do its thing and produce a plan with Hash Joins. Then we walk the plan and replace Hash Join nodes with our new SteM nodes. We call our conversion code in pg_exec_query_string() right after pg_plan_query() It's more complicated than that because we're actually implementing the Eddy operator. But if your goal is just to try out your nice new join algorithm, this would probably work and be a quick fix to get you started. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Evolutionary Database Design
This is an interesting paper on how a database can evolve its schema to fit its app. From SlashDot: http://martinfowler.com/articles/evodb.html Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
-Original Message- From: Rod Taylor [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 20:42 To: Marc G. Fournier Cc: PostgreSQL-development Subject: Re: [HACKERS] New Portal in Place, DNS switched ... Two thoughts: Are there any plans to 'strip' the users lounge of duplicated information? (outdated news, various links, etc.). Yes, as part of a redesign. Will advocacy, gborg, archives, techdocs, etc. be updated to include links back to the portal site? Don't they already? BTW, the 'Users Lounge' search link is broken. http://www.postgresql.org/search.cgi no longer exists. Umm, Marc? Is that a mnogo search.cgi? What do you want to do about it - move it or lose it? Regards, Dave. ---(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
[HACKERS] Question about bit.h and bit.c
I have a small nit Why is it that bit.h is in src/include/utils and bit.c is in src/backend/lib ? I can never for the life of me remember which is in which :-) -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
Will advocacy, gborg, archives, techdocs, etc. be updated to include links back to the portal site? Don't they already? If they do, it's not obvious. I don't see anything on archives, advocacy, or gborg. It looks like techdocs goes to the users lounge (PostgreSQL Home). -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Dave Page wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 20:34 To: Marc G. Fournier Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] New Portal in Place, DNS switched ... Marc G. Fournier [EMAIL PROTECTED] writes: On Sun, 5 Jan 2003, Tom Lane wrote: AFAICT none of the www mirrors have updated yet; that's starting to seem suspicious. the www mirrors don't update from the portal,they update from what is now the users-lounge area ... But they aren't. Try going to the users-lounge area via the new portal. Show me even one mirror that isn't displaying the old home page. I see what you mean Tom. Marc, how can I get to the old server? I don't have a note of the IP address. We need to redirect from the current index.html to /user-lounge/index.html 'K, but that won't help the mirrors themselves ... what we need to do is pull the users-lounge over to the new VM next ... Do you have access to 64.49.215.8? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Dave Page wrote: Umm, Marc? Is that a mnogo search.cgi? What do you want to do about it - move it or lose it? Move it, but its going to require some fixing up ... let's disable it for now and re-enable it once we've had some time to get it back in order? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [webmaster] [HACKERS] New Portal in Place, DNS switched ...
-Original Message- From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 21:03 To: Dave Page Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [webmaster] [HACKERS] New Portal in Place, DNS switched ... On Sun, 5 Jan 2003, Dave Page wrote: 'K, but that won't help the mirrors themselves ... what we need to do is pull the users-lounge over to the new VM next ... Do you have access to 64.49.215.8? Ugghh, what a mess. OK, I don't have root there, or ownership of the files so I can't do anything. For now, we need to redirect www.ca.postgresql.org/index.html to www.ca.postgresql.org/user-lounge/index.html - if we use a meta refresh tag then the mirrors shouldn't break. The new version on the new VM should be completely new in my opinion, but we should discuss that on the relevant list. Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about bit.h and bit.c
Sailesh Krishnamurthy [EMAIL PROTECTED] writes: Why is it that bit.h is in src/include/utils and bit.c is in src/backend/lib ? Possibly a more interesting question is why haven't we ditched them both ... AFAICT none of the bit.c routines are used anymore. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about bit.h and bit.c
Tom == Tom Lane [EMAIL PROTECTED] writes: Tom Sailesh Krishnamurthy [EMAIL PROTECTED] writes: Why is it that bit.h is in src/include/utils and bit.c is in src/backend/lib ? Tom Possibly a more interesting question is why haven't we Tom ditched them both ... AFAICT none of the bit.c routines are Tom used anymore. True. I just searched and found the only uses of the bitmask functions (now greatly expanded) in our code :-) -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(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] New Portal in Place, DNS switched ...
-Original Message- From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 21:06 To: Dave Page Cc: Rod Taylor; PostgreSQL-development Subject: RE: [HACKERS] New Portal in Place, DNS switched ... On Sun, 5 Jan 2003, Dave Page wrote: Umm, Marc? Is that a mnogo search.cgi? What do you want to do about it - move it or lose it? Move it, but its going to require some fixing up ... let's disable it for now and re-enable it once we've had some time to get it back in order? OK. It would help if I had root on www.ca.postgresql.org... Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Threads
On Saturday 04 January 2003 03:20 am, you wrote: I am sure, many of you would like to delete this message before reading, hold on. :-) I'm afraid most posters did not read the message. Those who replied Why bother? did not address your challenge: Our challenges may be..;-) Anyway you are absolutely right. Looks like evrybody thought it as an attempt to convert postgresql to a thread per connection model. I think threads are useful in difference situations namely parallelising blocking conditions and using multiple CPUs. This is indeed one of the few good reasons for threads. Indeed, large/robust systems use a mix. The consensus of the group is that those who do the work are not ready for threads. Which is fine. Looking into my crystal ball, I see that it will happen, though it appears so far away. I hope it happens and I will be able to contribute to it if I can. 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] Threads
Shridhar == Shridhar Daithankar [EMAIL PROTECTED] writes: Shridhar On Saturday 04 January 2003 03:20 am, you wrote: I am sure, many of you would like to delete this message before reading, hold on. :-) I'm afraid most posters did not read the message. Those who replied Why bother? did not address your challenge: Shridhar Our challenges may be..;-) Not having threading does reduce some of the freedom we've been having in our work. But then we have ripped the process model a fair bit and we have the freedom of an entirely new process to deal with data streams entering the system and we're experimenting with threading for asynchronous I/O there. However, in general I agree with the spirit of the previous messages in this thread that threading isn't the main issue for PG. One thing that I missed so far in the threading thread. Context switches are (IMHO) far cheaper between threads, because you save TLB flushes. Whether this makes a real difference in a data intensive application, I don't know. I wonder how easy it is to measure the x86 counters to see TLB flushes/misses. In a database system, even if one process dies, I'd be very chary of trusting it. So I am not too swayed by the fact that a process-per-connection gets you better isolation. BTW, many commercial database systems also use per-process models on Unix. However they are very aggressive with connection sharing and reuse - even to the point of reusing the same process for multiple active connections .. maybe at transaction boundaries. Good when a connection is maintained for a long duaration with short-lived transactions separated by fair amouns of time. Moreover, in db2 for instance, the same code base is used for both per-thread and per-process models - in other words, the entire code is MT-safe, and the scheduling mechanism is treated as a policy (Win32 is MT, and some Unices MP). AFAICT though, postgres code, such as perhaps the memory contexts is not MT-safe (of course the bufferpool/shmem accesses are safe). -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
-Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 22:03 To: Marc G. Fournier Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] New Portal in Place, DNS switched ... On Sat, 2003-01-04 at 19:40, Marc G. Fournier wrote: I'm just announcing here, since I'd like to see some ppl testing this out and let us know if there are any problems Why are there ads on the page? There were always ads there - they help pay for the boxes. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 2003-01-05 at 17:15, Dave Page wrote: There were always ads there Yes -- but AFAIK there were in the process of being phased out (furthermore, the old site only had ads on the initial mirror page, whereas they are much more widespread on the new site). they help pay for the boxes. Obviously, but it's VERY unprofessional for us to show ads to users on our website. It goes without saying, but pretty much every other non-trivial OSS project doesn't have ads on their main website. Displaying ads makes us look more like a Geocities site than a legitimate competitor to Oracle/DB2/etc. In fact, there are several groups that provide free hosting for OSS projects, without requiring them to display ads on their webpages (e.g. SourceForge, Savannah, etc.) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] New Portal in Place, DNS switched ...
On 5 Jan 2003, Neil Conway wrote: On Sun, 2003-01-05 at 17:15, Dave Page wrote: There were always ads there Yes -- but AFAIK there were in the process of being phased out (furthermore, the old site only had ads on the initial mirror page, whereas they are much more widespread on the new site). Good point. Marc, would it be possible to get a look at the figures involved: cost of hosting and income generated from ads. With these, we might be able to think up some alternative funding arrangements which make the site(s) look more professional whilst still covering the cost to the same extent. Thanks, Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Neil Conway wrote: On Sun, 2003-01-05 at 17:15, Dave Page wrote: There were always ads there Yes -- but AFAIK there were in the process of being phased out Not sure where you heard this from ... there were some site that still hadn't had them deployed on them, but there was never any intention of phasing them out ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
-Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: 05 January 2003 22:38 To: Dave Page Cc: Marc G. Fournier; [EMAIL PROTECTED] Subject: Re: [HACKERS] New Portal in Place, DNS switched ... On Sun, 2003-01-05 at 17:15, Dave Page wrote: There were always ads there Yes -- but AFAIK there were in the process of being phased out (furthermore, the old site only had ads on the initial mirror page, whereas they are much more widespread on the new site). they help pay for the boxes. Obviously, but it's VERY unprofessional for us to show ads to users on our website. It goes without saying, but pretty much every other non-trivial OSS project doesn't have ads on their main website. Displaying ads makes us look more like a Geocities site than a legitimate competitor to Oracle/DB2/etc. Don't get me wrong, I personnally would prefer to remove them, however unless we get suitable corporate sponsorship the servers still have to be paid for somehow. Purely speculation, but I would guess that the ads are not recouping all of the cash it costs hub.org to host the sites as it is. In fact, there are several groups that provide free hosting for OSS projects, without requiring them to display ads on their webpages (e.g. SourceForge, Savannah, etc.) You're surely not suggesting that the various postgresql.org servers and everything they do could be moved onto free space supplied by Sourceforge or similar? I don't think they'd want to host Gborg for us :-) Regards, Dave. ---(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] New Portal in Place, DNS switched ...
On Sun, 2003-01-05 at 18:05, Dave Page wrote: Don't get me wrong, I personnally would prefer to remove them, however unless we get suitable corporate sponsorship the servers still have to be paid for somehow. Granted. I'm just trying to point out that putting ads on our webspace is a pretty serious problem. If that's the *only* way to keep postgresql.org, then so be it -- but perhaps there's another way to get the necessary funds, as Gavin suggested (for example, a more efficient mirroring scheme, using zlib compression for the main web server, etc.) You're surely not suggesting that the various postgresql.org servers and everything they do could be moved onto free space supplied by Sourceforge or similar? No; I'm just pointing out that (a) putting ads on their websites is the exception, rather than the rule, among reputable OSS projects (b) even OSS projects that don't pay anything for their webspace don't need to use banner ads. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] AclId is defined in the wrong place
I'd like to move the typedef for AclId out of miscadmin.h, where it was originally placed, and into postgres.h or c.h where most other fundamental typedefs appear. As is, we've got a problem with miscadmin.h having to be included into many header files where it doesn't belong, and that problem is going to get worse. Any objection? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Dave Page wrote: Don't get me wrong, I personnally would prefer to remove them, however unless we get suitable corporate sponsorship the servers still have to be paid for somehow. Purely speculation, but I would guess that the ads are not recouping all of the cash it costs hub.org to host the sites as it is. Not even close ... in fact, most of the banners there are in recognition of those companies who themselves have provided invaluable resources for the project by providing mirror sites, to reduce the overall traffic hits on the central server ... ---(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] New Portal in Place, DNS switched ...
Neil Conway [EMAIL PROTECTED] writes: On Sun, 2003-01-05 at 18:05, Dave Page wrote: Don't get me wrong, I personnally would prefer to remove them, however unless we get suitable corporate sponsorship the servers still have to be paid for somehow. Granted. I'm just trying to point out that putting ads on our webspace is a pretty serious problem. If that's the *only* way to keep postgresql.org, then so be it -- but perhaps there's another way to get the necessary funds, as Gavin suggested I'm with Neil and Gavin on this: let's think about whether there's another way to finance the website. Perhaps there isn't, but let's at least take a hard look at it. Marc has put a *lot* of his own money into supporting the Postgres servers over the years. Maybe it's time for the rest of us to step up. 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] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: On Sun, 2003-01-05 at 18:05, Dave Page wrote: Don't get me wrong, I personnally would prefer to remove them, however unless we get suitable corporate sponsorship the servers still have to be paid for somehow. Granted. I'm just trying to point out that putting ads on our webspace is a pretty serious problem. If that's the *only* way to keep postgresql.org, then so be it -- but perhaps there's another way to get the necessary funds, as Gavin suggested I'm with Neil and Gavin on this: let's think about whether there's another way to finance the website. Perhaps there isn't, but let's at least take a hard look at it. Marc has put a *lot* of his own money into supporting the Postgres servers over the years. Maybe it's time for the rest of us to step up. Please understand something here ... a large portion of the banner ads are *not* paid ... they are recognition of the many mirror sites that are supporting the project by reducing the amount of bandwidth that is required on the central server ... We've only had a couple of ppl actually decide to subscribe to the banner ad service itself, so it hasn't be a major revenue stream ... ;) ---(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] New Portal in Place, DNS switched ...
Neil Conway wrote: On Sun, 2003-01-05 at 17:15, Dave Page wrote: There were always ads there Yes -- but AFAIK there were in the process of being phased out (furthermore, the old site only had ads on the initial mirror page, whereas they are much more widespread on the new site). they help pay for the boxes. Obviously, but it's VERY unprofessional for us to show ads to users on our website. It goes without saying, but pretty much every other non-trivial OSS project doesn't have ads on their main website. Displaying ads makes us look more like a Geocities site than a legitimate competitor to Oracle/DB2/etc. Ouch, Geocities. That hurts. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 5 Jan 2003, Bruce Momjian wrote: Neil Conway wrote: On Sun, 2003-01-05 at 17:15, Dave Page wrote: There were always ads there Yes -- but AFAIK there were in the process of being phased out (furthermore, the old site only had ads on the initial mirror page, whereas they are much more widespread on the new site). they help pay for the boxes. Obviously, but it's VERY unprofessional for us to show ads to users on our website. It goes without saying, but pretty much every other non-trivial OSS project doesn't have ads on their main website. Displaying ads makes us look more like a Geocities site than a legitimate competitor to Oracle/DB2/etc. Ouch, Geocities. That hurts. And if you go visit a Geocities site, its not even a close analogy ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
Marc G. Fournier wrote: On Sun, 5 Jan 2003, Bruce Momjian wrote: Neil Conway wrote: On Sun, 2003-01-05 at 17:15, Dave Page wrote: There were always ads there Yes -- but AFAIK there were in the process of being phased out (furthermore, the old site only had ads on the initial mirror page, whereas they are much more widespread on the new site). they help pay for the boxes. Obviously, but it's VERY unprofessional for us to show ads to users on our website. It goes without saying, but pretty much every other non-trivial OSS project doesn't have ads on their main website. Displaying ads makes us look more like a Geocities site than a legitimate competitor to Oracle/DB2/etc. Ouch, Geocities. That hurts. And if you go visit a Geocities site, its not even a close analogy ... I know ... It was just funny. I forgot the smiley. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
Patch applied. I added a small mention of IPv6 addresses to the pg_hba.conf documentation. Not sure where else to mention it. --- Bruce Momjian wrote: I have been working on a patch to implement IPv6 connections. A working patch was supplied by Nigel Kukard about two weeks ago, and I have been improving it. The original patch assumed the system has IPv6 functions, like getaddrinfo(), so the major work was patching it into our existing code that doesn't use IPv6 functions, so systems with/without IPv6 will be able to compile the same code. The patch is at: ftp://candle.pha.pa.us/pub/postgresql/mypatches/ipv6.full It has a configure test to determine if getaddrinfo() exists, and sets a #define and a Makefile variable appropriately. Most of the changes are in backend/libpq/pqcomm.c::StreamServerPort and interfaces/libpq/fe-connect.c::connectDBStart. There are also two new files, ip.c and ip.h, which contain IP-specific support functions. I have done my best to make the code as clear as possible. There are more define tests than I would like, but I am hesitant to split out more of the code into almost duplicate functions for IPv4 and IPv6 functionality. I have tested the code using IPv6 functions, and IPv4 functions. The system also has no IPv6 support in the kernel, so that has also been tested. The patch is about a week away from being applied, but I thought I would post the URL so folks can see where I am going. I am interested in improvements and testing with various configurations. FYI, I am also working with someone on the openprojects IRC channel #ipv6 on an IPv6 data type. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
On 5 Jan 2003, Neil Conway wrote: Obviously, but it's VERY unprofessional for us to show ads to users on our website. It goes without saying, but pretty much every other non-trivial OSS project doesn't have ads on their main website. Displaying ads makes us look more like a Geocities site than a legitimate competitor to Oracle/DB2/etc. I have no problem with the ads. I disagree with the viewpoints above. ---(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] Upgrading rant.
mlw wrote: I have the USA tiger census data in a database, it is over 60G with indexes, 30G+ of just data. Do you know how long that will take to dump and restore? Making one index on some of the tables takes 20 minutes. Oh, come on. How many tigers are their in the USA? Certainly not 30G+ worth. ;-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upgrading rant.
Greg Copeland wrote: On Sat, 2003-01-04 at 22:37, Tom Lane wrote: You're missing the point: I don't want to lock out everyone but the super-user, I want to lock out everyone, period. Superusers are just as likely to screw up pg_upgrade as anyone else. BTW: $ postmaster -N 1 -c superuser_reserved_connections=1 postmaster: superuser_reserved_connections must be less than max_connections. $ Well, first, let me say that the above just seems wrong. I can't think of any valid reason why reserved shouldn't be allowed to equal max. I also assumed that pg_update would be attempting to connect as the superuser. Therefore, if you only allow a single connection from the superuser and pg_upgrade is using it, that would seem fairly hard to mess things up. On top of that, that's also the risk of someone being a superuser. They will ALWAYS have the power to hose things. Period. As such, I don't consider that to be a valid argument. That was my feeling too. If you can't trust the other admins, it is hard for us to trust them either. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upgrading rant.
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, taking up the pg_upgrade banner, I think there are two things missing from the current code: 1) schema awareness -- easily fixed with some code 2) need to creat clog files to match incremented xid I can do 1, and I think Tom can help me with 2. I was just now wondering whether we really need to do that at all. We're already vacuuming the user tables before we bring 'em over. What if we VACUUM FREEZE them instead? Then there are *no* xids of interest in the tables being brought over, and no need to screw around with the xid counter in the new installation. That in turn would mean no need to mess with its pg_clog files. I think we'd still need to advance the xlog position past the old installation's xlog end, but we have the tool for that (pg_resetxlog) already. VACUUM FREEZE. Interesting idea. Did we have that in 7.2? I never thought of using it. Good idea. Why do we have to do WAL? Do we have WAL log id's in the tuple headers? I don't remember. I don't see them in a quick look. Also, I think we make index format changes more frequently that Tom recollects. Tom? Oh? Name one... not that they'd be a critical problem anyway, as we could easily reconstruct indexes via REINDEX rather than moving them over, any time we made such a change. I remember fixing index problems, and asking folks to rebuild indexes _after_ we fixed them, so I thought they had a new format. I guess they were just broken indexes that had to be rebuilt to get the fix. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upgrading rant.
Bruce Momjian [EMAIL PROTECTED] writes: VACUUM FREEZE. Interesting idea. Did we have that in 7.2? I never thought of using it. Good idea. IIRC, it was new in 7.2 --- but pg_upgrade goes back further than that. I am not sure if this idea just escaped us before, or if there's a hole in it. We need to study it carefully. Why do we have to do WAL? Do we have WAL log id's in the tuple headers? Not in tuple headers, but in page headers. The buffer manager will choke if the LSN fields point past the end of WAL. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] AclId is defined in the wrong place
Tom Lane wrote: I'd like to move the typedef for AclId out of miscadmin.h, where it was originally placed, and into postgres.h or c.h where most other fundamental typedefs appear. As is, we've got a problem with miscadmin.h having to be included into many header files where it doesn't belong, and that problem is going to get worse. Any objection? No problem, go ahead. I put it there only because I needed it for some of the prototypes, and I didn't want to be so bold as to move it even farther up into the include system, but if you like it there, that is fine. I did quite a bit of wholesale AclId mapping so you may want to look at the patch to see where I had to add miscadmin.h. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] AclId is defined in the wrong place
Bruce Momjian [EMAIL PROTECTED] writes: No problem, go ahead. I put it there only because I needed it for some of the prototypes, and I didn't want to be so bold as to move it even farther up into the include system, Properly so --- but if the consequence is to have to include miscadmin.h into other header files, then really you're polluting namespace more rather than less, because of the other baggage carried along by miscadmin.h. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Upgrading rant.
Bruce Momjian [EMAIL PROTECTED] writes: ... On top of that, that's also the risk of someone being a superuser. They will ALWAYS have the power to hose things. Period. As such, I don't consider that to be a valid argument. That was my feeling too. If you can't trust the other admins, it is hard for us to trust them either. Sigh. It's not about trust: it's about whether pg_upgrade can enforce or at least check its assumptions. I don't feel that it's a production-grade tool as long as it has to cross its fingers that the DBA made no mistakes. Also, if the previous example had no impact on you, try this one: $ postmaster -N 1 -c superuser_reserved_connections=0 $ pg_dumpall pg_dump: [archiver (db)] connection to database regression failed: FATAL: Sorry, too many clients already pg_dumpall: pg_dump failed on regression, exiting $ -N 1 *will* cause problems. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Upgrading rant.
On Saturday 04 January 2003 21:12, Peter Eisentraut wrote: I would recommend requiring users to do the schema dump before upgrading the binaries, so they'd do Nice theory. Won't work in RPM practice. I can't require the user to do _anything_. Due to the rules of RPM's, I can't even ask the user to do anything. All I have been able to do is prevent the upgrade from happening -- but that has its cost, too, as then older library versions have to be held back just for PostgreSQL, taking up the hapless user's disk space. While I _can_ version the binaries as Tom mentioned (and that I had thought about before), in an OS upgrade environment (where my RPMset lives more than by command line rpm invocation) I can't force the older set to be kept in a runnable form. It is very possible that the supporting libc shared libraries will be removed by the OS upgrade -- the old binaries may not even run when it is critical that they do run. In place post-binary-upgrade is the only way this is going to work properly in the environment I have to live with. That's why dump/restore is such a pain, as Tom remembers. If I can get older versions building again on newer systems, that will help buy some breathing room from my point of view. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upgrading rant.
On Sunday 05 January 2003 23:10, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: It is very possible that the supporting libc shared libraries will be removed by the OS upgrade -- the old binaries may not even run when it is critical that they do run. Urgh, that's a mess. Yah, it is a mess. I've been playing in that mudpit for three years If I can get older versions building again on newer systems, that will help buy some breathing room from my point of view. Worst-case, we could include a back-rev postmaster binary in new distributions. While I have in the past suggested this, I'm not happy with the idea, even though it may be the best short-term solution. However, that still requires us to keep the back revs buildable on newer OS releases, which evidently is less than trivial in the Linux world :-( That is the wonderful result of having so many rapidly developing applications, including our own. We have, I'm sure, given a few ulcers to Linux distributors too. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
Marc G. Fournier [EMAIL PROTECTED] writes: Please understand something here ... a large portion of the banner ads are *not* paid ... they are recognition of the many mirror sites that are supporting the project by reducing the amount of bandwidth that is required on the central server ... While the mirror sites deserve some recognition, I'm not convinced that that should translate to banner ads on the main portal. Could we set things up so that when you actually go to a mirror site, you see some discreet notice about this mirror sponsored by so-and-so? And I'm definitely not happy with reading Help Support This Site Post your Ad Here Pay Only for Visitors As Low As $0.10cdn per click-thru Hub.Org on the main site. That's several shades too mercenary for my taste. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] IPv6 detection
The IPv6 patch currently checks for the function getaddrinfo() and the include file netinet/ip6.h. Is this a sufficient test? Anyone with/without IPv6 that does match not this test? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
On Sun, 2003-01-05 at 20:32, Marc G. Fournier wrote: Not even close ... in fact, most of the banners there are in recognition of those companies who themselves have provided invaluable resources for the project by providing mirror sites, to reduce the overall traffic hits on the central server ... That's fair enough. However, many other OSS projects use a mirror system, but AFAIK not one of them compensates mirror operators through banner ads. For example, consider the Debian project. Mirroring the Debian archive requires FAR more disk and bandwidth than mirroring postgresql.org, but yet (a) they have plenty of mirrors (b) they don't have any banner ads on their website. My guess is that most mirror operators won't mind not getting to run banner ads on postgresql.org -- I'd think the reason they're hosting a mirror in the first-place is to contribute back to the project... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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
