Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
Greg Copeland writes: Just a reminder, there still doesn't appear to be a 7.3.1 tag. There is a long tradition of systematically failing to tag releases in this project. Don't expect it to improve. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump.options.diff
Serguei Mokhov writes: #if defined(HAVE_GETOPT_LONG) #define xo(long,short,desc) printf(%s %s\n, long, desc) #else #define xo(long,short,desc) printf(%s %s\n, short, desc) #endif seems relatively generic, so it could be used by more than one tool. As long as we're spending time on this, why not just write our own version of getopt_long()? -- Peter Eisentraut [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 ...
On Sat, 4 Jan 2003, Peter Eisentraut wrote: Greg Copeland writes: Just a reminder, there still doesn't appear to be a 7.3.1 tag. There is a long tradition of systematically failing to tag releases in this project. Don't expect it to improve. It was I who suggested that a release team would be a good idea. I think that was soundly rejected. I still think it's a good idea. If only to ensure that things are properly tagged, the right annoucements go out at the right times, that a code freeze goes into effect, etc. These concepts are not new. A release is an important step in the life cycle. I volunteered to document the release procedure as it resides only within lore and a couple of heads. I have yet to start. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Threads
Umm. No. User or system level threads, the statement is true. If a thread kills over, the process goes with it. Furthermore, on Win32 Hm. This is a database system. If one of the backend processes dies unexpectedly, I'm not sure I would trust the consistency and state of the others. Or maybe I'm just being chicken. -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upgrading rant.
Oliver Elphick [EMAIL PROTECTED] writes: On Sat, 2003-01-04 at 02:17, Tom Lane wrote: There isn't any simple way to lock *everyone* out of the DB and still allow pg_upgrade to connect via the postmaster, and even if there were, the DBA could too easily forget to do it. I tackled this issue in the Debian upgrade scripts. I close the running postmaster and open a new postmaster using a different port, so that normal connection attempts will fail because there is no postmaster running on the normal port. That's a good kluge, but still a kluge: it doesn't completely guarantee that no one else connects while pg_upgrade is trying to do its thing. I am also concerned about the consequences of automatic background activities. Even the periodic auto-CHECKPOINT done by current code is not obviously safe to run behind pg_upgrade's back (it does make WAL entries). And the auto-VACUUM that we are currently thinking of is even less obviously safe. I think that someday, running pg_upgrade standalone will become *necessary*, not just a good safety feature. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
Dan Langille [EMAIL PROTECTED] writes: On Sat, 4 Jan 2003, Peter Eisentraut wrote: There is a long tradition of systematically failing to tag releases in this project. Don't expect it to improve. It was I who suggested that a release team would be a good idea. We *have* a release team. Your problem is that Marc, who is the man who would need to do this, doesn't appear to consider it an important thing to do. Try to convince him to put it on his checklist. 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, 2003-01-04 at 04:27, Peter Eisentraut wrote: Greg Copeland writes: Just a reminder, there still doesn't appear to be a 7.3.1 tag. There is a long tradition of systematically failing to tag releases in this project. Don't expect it to improve. Well, I thought I remembered from the release team thread that it was said there was a punch list of things that are done prior to actually releasing. If not, it certainly seems like we need one. If there is one, tagging absolutely needs to be on it. If we have one and this is already on the list, seems we need to be eating our own food. ;) -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Threads
On Sat, 2003-01-04 at 06:59, Kaare Rasmussen wrote: Umm. No. User or system level threads, the statement is true. If a thread kills over, the process goes with it. Furthermore, on Win32 Hm. This is a database system. If one of the backend processes dies unexpectedly, I'm not sure I would trust the consistency and state of the others. Or maybe I'm just being chicken. I'd call that being wise. That's the problem with using threads. Should a thread do something naughty, the state of the entire process is in question. This is true regardless if it is a user mode, kernel mode, or hybrid thread implementation. That's the power of using the process model that is currently in use. Should it do something naughty, we bitch and complain politely, throw our hands in the air and exit. We no longer have to worry about the state and validity of that backend. This creates a huge systemic reliability surplus. This is also why the concept of a hybrid thread/process implementation keeps coming to the surface on the list. If you maintain the process model and only use threads for things that ONLY relate to the single process (single session/connection), should a thread cause a problem, you can still throw you hands in the air and exit just as is done now without causing problems for, or questioning the validity of, other backends. The cool thing about such a concept is that it still opens the door for things like parallel sorts and queries as it relates to a single backend. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Upgrading rant.
On Sat, 2003-01-04 at 09:53, Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: On Sat, 2003-01-04 at 02:17, Tom Lane wrote: There isn't any simple way to lock *everyone* out of the DB and still allow pg_upgrade to connect via the postmaster, and even if there were, the DBA could too easily forget to do it. I tackled this issue in the Debian upgrade scripts. I close the running postmaster and open a new postmaster using a different port, so that normal connection attempts will fail because there is no postmaster running on the normal port. That's a good kluge, but still a kluge: it doesn't completely guarantee that no one else connects while pg_upgrade is trying to do its thing. I am also concerned about the consequences of automatic background activities. Even the periodic auto-CHECKPOINT done by current code is not obviously safe to run behind pg_upgrade's back (it does make WAL entries). And the auto-VACUUM that we are currently thinking of is even less obviously safe. I think that someday, running pg_upgrade standalone will become *necessary*, not just a good safety feature. regards, tom lane I thought there was talk of adding a single user/admin only mode. That is, where only the administrator can connect to the database. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
msg resent because I incorrectly copied/pasted some addresses. Sorry. On 4 Jan 2003 at 11:08, Tom Lane wrote: Dan Langille [EMAIL PROTECTED] writes: On Sat, 4 Jan 2003, Peter Eisentraut wrote: There is a long tradition of systematically failing to tag releases in this project. Don't expect it to improve. It was I who suggested that a release team would be a good idea. We *have* a release team. I have a suggestion. Let us document who is the release team and who is responsible for each step of the release. Perhaps that is the problem: a lack of process. I'll add that to my list of things I've promised to do. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
msg resent because I incorrectly copied/pasted some addresses. Sorry. On 4 Jan 2003 at 11:08, Tom Lane wrote: Dan Langille [EMAIL PROTECTED] writes: On Sat, 4 Jan 2003, Peter Eisentraut wrote: There is a long tradition of systematically failing to tag releases in this project. Don't expect it to improve. It was I who suggested that a release team would be a good idea. We *have* a release team. Your problem is that Marc, who is the man who would need to do this, doesn't appear to consider it an important thing to do. Try to convince him to put it on his checklist. Marc? Is this true? You don't consider it important to tag the release? I'm quite sure that's not the case and that Marc does consider it important. It's just something which he forgot to do. A recent post by Greg Copeland implies this item is on his checklist. IMHO, it is vital that the tree is properly tagged for each release. AFAIK, a tag can be laid with with respect to timestamp value. So why don't we just do it? -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump.options.diff
Tom Lane writes: As long as we're spending time on this, why not just write our own version of getopt_long()? Seems like a fine idea to me ... who's volunteering? Doing it now... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] New Portal in Place, DNS switched ...
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 :) ---(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 ...
Marc G. Fournier [EMAIL PROTECTED] writes: 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 :) Have we dropped the notion of mirroring the website? www.postgresql.org now takes me right to the main page, not to a list of mirrors. It does look nice though ;-) 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, 4 Jan 2003, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: 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 :) Have we dropped the notion of mirroring the website? www.postgresql.org now takes me right to the main page, not to a list of mirrors. the portal itself is not mirrored, butif you go to, for instance UsersLounge or Downloads, it then gives you the option of which mirror to go to ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
Marc G. Fournier [EMAIL PROTECTED] writes: the portal itself is not mirrored, butif you go to, for instance UsersLounge or Downloads, it then gives you the option of which mirror to go to ... Ah. But if I do either, I see Warning: pg_exec(): supplied argument is not a valid PostgreSQL link resource in /usr/local/www/www.postgresql.org/mirrors.php on line 28 and Couldn't query the mirrors table! Might just be a transient problem till DNS updates ... or not ... 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] python interface
Let me know how it goes, and what the project is ... that way we can move
the current CVS over so that we don't lose the extensive logging history
...
On Fri, 3 Jan 2003, D'Arcy J.M. Cain wrote:
On Friday 03 January 2003 15:24, Tom Lane wrote:
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
I would love to add PyGreSQL to gborg but no matter how often I log in it
tells me that I need to be logged in to create a new project.
Weird. Maybe you're blocking cookies, or something like that?
Hmmm. I am using Opera and I have noticed cookie related strangeness before
but cookies do work. I use them with mailman all the time.
I'll try another browser tonight.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [GENERAL] [HACKERS] v7.3.1 Bundled and Released ...
On Sat, 4 Jan 2003, Tom Lane wrote: Dan Langille [EMAIL PROTECTED] writes: On Sat, 4 Jan 2003, Peter Eisentraut wrote: There is a long tradition of systematically failing to tag releases in this project. Don't expect it to improve. It was I who suggested that a release team would be a good idea. We *have* a release team. Your problem is that Marc, who is the man who would need to do this, doesn't appear to consider it an important thing to do. Try to convince him to put it on his checklist. 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? That said, I can back-tag the whole source tree for past releases if ppl do think it is important, its just a matter of knowing the 'timestamp' to base it on, which I can do based on the dates of the tar files ... Its not like tag'ng is hard to do ... ---(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 Saturday, January 04, 2003 21:04:32 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: On Sat, 4 Jan 2003, Tom Lane wrote: Dan Langille [EMAIL PROTECTED] writes: On Sat, 4 Jan 2003, Peter Eisentraut wrote: There is a long tradition of systematically failing to tag releases in this project. Don't expect it to improve. It was I who suggested that a release team would be a good idea. We *have* a release team. Your problem is that Marc, who is the man who would need to do this, doesn't appear to consider it an important thing to do. Try to convince him to put it on his checklist. 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? That said, I can back-tag the whole source tree for past releases if ppl do think it is important, its just a matter of knowing the 'timestamp' to base it on, which I can do based on the dates of the tar files ... It's useful for those using the CVS files to RECREATE a version based on the TAG to checkout something (without pulling the whole tarball). LER Its not like tag'ng is hard to do ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
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? 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 Sat, 4 Jan 2003, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: the portal itself is not mirrored, butif you go to, for instance UsersLounge or Downloads, it then gives you the option of which mirror to go to ... Ah. But if I do either, I see Warning: pg_exec(): supplied argument is not a valid PostgreSQL link resource in /usr/local/www/www.postgresql.org/mirrors.php on line 28 and Couldn't query the mirrors table! Might just be a transient problem till DNS updates ... or not ... 'K, let's hope ... I tried it here and the flags all came up :( Dave/Justin? ---(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 wrote: On Sat, 4 Jan 2003, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: the portal itself is not mirrored, butif you go to, for instance UsersLounge or Downloads, it then gives you the option of which mirror to go to ... Ah. But if I do either, I see Warning: pg_exec(): supplied argument is not a valid PostgreSQL link resource in /usr/local/www/www.postgresql.org/mirrors.php on line 28 and Couldn't query the mirrors table! Might just be a transient problem till DNS updates ... or not ... 'K, let's hope ... I tried it here and the flags all came up :( Dave/Justin? Ok, am online and DNS seems to be propagated out this way. Will take a look now. BTW - Should we do the redirects that the old postgresql.org used to do: i.e.: www.postgresql.org/doc - www.ca.postgresql.org/users-lounge/ and similar. :-) Regards and best wishes, Justin Clift -- 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 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, 5 Jan 2003, Justin Clift wrote: www.postgresql.org/doc - www.ca.postgresql.org/users-lounge/ If we can avoid it, let's ... if I recall correctly, we originally set that up in order to get around some issues we had with originally moving over to the new site way way back ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] next set of SSL - ideas?
Bear Giles writes: The server policy is easy to handle - it would probably go into a new text configuration file pg_ssl.conf. postgresql.conf should serve you fine. The client policy is much harder to handle, since the details need to be hidden in the libpg library. I know how to handle this on Unix systems, but what about clients on other platforms? E.g., on a Windows box I would expect this information to be maintained in the registry, not a config file For libpq, put the required files in the home directory or some directory under the home directory. That should be acceptable on Windows, too, for now. ODBC and JDBC have their own way of storing client side configuration, which you can discuss with their teams. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Upgrading rant.
Tom Lane writes: This would require a nontrivial amount of work (notably, we'd have to be able to get pg_dump to run against a standalone backend) but I don't think I'd trust pg_upgrade as a production-grade tool until its invocation method looks like the above. I would recommend requiring users to do the schema dump before upgrading the binaries, so they'd do pg_dumpall -s schemadump pg_ctl stop [upgrade binaries] pg_upgrade --option=schemadump pg_ctl start -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Upgrading rant.
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: This would require a nontrivial amount of work (notably, we'd have to be able to get pg_dump to run against a standalone backend) but I don't think I'd trust pg_upgrade as a production-grade tool until its invocation method looks like the above. I would recommend requiring users to do the schema dump before upgrading the binaries, so they'd do Hm. I think we'd need to have the new version's pg_upgrade (we cannot be sure that an older version would be aware of what information must be dumped), and the newer pg_dump is also likely to be a better bet than the old (we've seen several times in the past that this allows us to get around problems in a prior version of pg_dump). But we'd need access to the old version's postmaster/postgres executable, since by assumption the newer one will not run in the old data directory. I recall Lamar complaining often about the need for multiple executable versions to be available simultaneously. Can we perhaps alter the packaging to make this easier? I'm envisioning for example installing the postmaster/postgres executable as postgres.7.5, with symlinks from postmaster and postgres; then we need not overwrite postgres.7.4 and that could be invoked by pg_upgrade. (I'm just brainstorming here, this isn't necessarily a serious proposal. Better ideas anyone?) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
Hi Tom, Sorry about that. Was a combo of two simple problems. It's fixed now. :-) Regards and best wishes, Justin Clift Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: the portal itself is not mirrored, butif you go to, for instance UsersLounge or Downloads, it then gives you the option of which mirror to go to ... Ah. But if I do either, I see Warning: pg_exec(): supplied argument is not a valid PostgreSQL link resource in /usr/local/www/www.postgresql.org/mirrors.php on line 28 and Couldn't query the mirrors table! Might just be a transient problem till DNS updates ... or not ... 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]) -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
Justin Clift [EMAIL PROTECTED] writes: It's fixed now. :-) Better, thanks. Minor suggestion: could we get ALT text for all the flags? Right now it's there for USA, UK, Italy, but not the rest ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] v7.3.1 Bundled and Released ...
Tom Lane wrote: Any other arguments out there? Per-release tags make it easier to see quickly if some code has changed in -current or not. As the CVS tree is available via anoymous CVS (I think?), CVSup, and via the web so there are many potential users who are not active developers and who probably run releases rather than -current. Regards, Giles ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Upgrading rant.
Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: On Sat, 2003-01-04 at 02:17, Tom Lane wrote: There isn't any simple way to lock *everyone* out of the DB and still allow pg_upgrade to connect via the postmaster, and even if there were, the DBA could too easily forget to do it. I tackled this issue in the Debian upgrade scripts. I close the running postmaster and open a new postmaster using a different port, so that normal connection attempts will fail because there is no postmaster running on the normal port. That's a good kluge, but still a kluge: it doesn't completely guarantee that no one else connects while pg_upgrade is trying to do its thing. I was thinking about using GUC: #max_connections = 32 #superuser_reserved_connections = 2 Set both of those to 1, and you lock out everyone but the super-user. In fact, we can specify those on postmaster start with -c max_connections=1, etc. I am also concerned about the consequences of automatic background activities. Even the periodic auto-CHECKPOINT done by current code is not obviously safe to run behind pg_upgrade's back (it does make WAL entries). And the auto-VACUUM that we are currently thinking of is even less obviously safe. I think that someday, running pg_upgrade standalone will become *necessary*, not just a good safety feature. Yes, certainly we are in major hack mode with pg_upgrade. -- 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] Upgrading rant.
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: That's a good kluge, but still a kluge: it doesn't completely guarantee that no one else connects while pg_upgrade is trying to do its thing. I was thinking about using GUC: #max_connections = 32 #superuser_reserved_connections = 2 Set both of those to 1, and you lock out everyone but the super-user. 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. $ regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] pgsql oid question
I have started experimenting with an access layer for pgsql and have a question. I had someone on this list tell me that the oid values that come back from the server are tag identifiers for that row/column combination and are not type indicators. Yet, when I create multiple tables/columns each having the same type (int32), the same oid keeps being returned. What am I not getting? Can someone point me to a good overview of the internals of PostgreSQL so that I can read up on this? I have scanned through the source but still do not have a clear picture. Thanks Reggie ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgsql oid question
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? I see that the Java driver uses select statements back into the db to determine the datatype for a given oid. I know for user-defined types that is required, but for base types is it required? And thanks for the reply! Reggie -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 05, 2003 12:42 AM To: Reggie Burnett Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] pgsql oid question Reggie Burnett [EMAIL PROTECTED] writes: I have started experimenting with an access layer for pgsql and have a question. I had someone on this list tell me that the oid values that come back from the server are tag identifiers for that row/column combination and are not type indicators. I think your someone is confused. There are no identifiers associated with row/column combinations. Yet, when I create multiple tables/columns each having the same type (int32), the same oid keeps being returned. The OIDs returned in RowDescription messages uniquely identify datatypes (more specifically, pg_type rows). They will be stable short of DROP TYPE/CREATE TYPE shenanigans. (However, user-defined types might not get the same OIDs assigned after a dump/reload cycle. It's probably reasonable to treat type OIDs as stable for the life of a connection, but not as constants of nature.) OIDs are also used for other purposes, so your confusion may stem from confusing pg_type OIDs with other OIDs. In the current system implementation, OIDs are unique row identifiers only within individual tables --- perhaps not even then, if the table doesn't have a unique index on its OID field. Thus, a pg_type OID uniquely identifies a datatype, but that doesn't mean that the same OID number could not appear in pg_class, pg_rewrite, or other system or user tables. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
