[HACKERS] pg_dumpall
Hi, In postgresql 7.3.1, if I do pg_dumpall -c, at the top of the dump file is this: ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS]
Hi, In postgresql 7.3.1, if I do pg_dumpall -c, at the top of the dump file is this: DROP DATABASE au_shipping ;CREATE DATABASE au_shipping WITH OWNER = auadmin TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE au_test ;CREATE DATABASE au_test WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE australia ;CREATE DATABASE australia WITH OWNER = auadmin TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE geeklog ;CREATE DATABASE geeklog WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE keystone ;CREATE DATABASE keystone WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; Why are all the CREATE DATABASE statements commented out? Surely that will make the restore fail? Chris ---(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]
Hi, On Thu, 2003-01-16 at 10:13, Christopher Kings-Lynne wrote: In postgresql 7.3.1, if I do pg_dumpall -c, at the top of the dump file is this: DROP DATABASE au_shipping ;CREATE DATABASE au_shipping WITH OWNER = auadmin TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE au_test ;CREATE DATABASE au_test WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE australia ;CREATE DATABASE australia WITH OWNER = auadmin TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE geeklog ;CREATE DATABASE geeklog WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE keystone ;CREATE DATABASE keystone WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; Why are all the CREATE DATABASE statements commented out? Surely that will make the restore fail? Just guessing: The first line does not have a ; at the end; so the first semicolon (at the beginning of second line) will end the first line; will not comment the CREATE DATABASE line... I mean, it might work as below: DROP DATABASE au_shipping; CREATE DATABASE au_shipping WITH OWNER = auadmin TEMPLATE = template0 ENCODING = 'SQL_ASCII'; ? Best regards, -- Devrim GUNDUZ TR.NET Sistem Destek Uzmani Tel : (312) 295 93 18 Fax : (312) 295 94 94 Tel : (216) 542 90 00 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS]
You're right. It's a type in pg_dumpall.c I have attached a fix for it. Chris ;CREATE DATABASE keystone WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; Why are all the CREATE DATABASE statements commented out? Surely that will make the restore fail? Just guessing: The first line does not have a ; at the end; so the first semicolon (at the beginning of second line) will end the first line; will not comment the CREATE DATABASE line... I mean, it might work as below: DROP DATABASE au_shipping; CREATE DATABASE au_shipping WITH OWNER = auadmin TEMPLATE = template0 ENCODING = 'SQL_ASCII'; Index: src/bin/pg_dump/pg_dumpall.c === RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dumpall.c,v retrieving revision 1.12 diff -c -r1.12 pg_dumpall.c *** src/bin/pg_dump/pg_dumpall.c2003/01/06 18:53:25 1.12 --- src/bin/pg_dump/pg_dumpall.c2003/01/16 08:41:49 *** *** 397,403 buf = createPQExpBuffer(); if (output_clean) ! appendPQExpBuffer(buf, DROP DATABASE %s\n;, fmtId(dbname)); appendPQExpBuffer(buf, CREATE DATABASE %s, fmtId(dbname)); appendPQExpBuffer(buf, WITH OWNER = %s TEMPLATE = template0, fmtId(dbowner)); --- 397,403 buf = createPQExpBuffer(); if (output_clean) ! appendPQExpBuffer(buf, DROP DATABASE %s;\n, fmtId(dbname)); appendPQExpBuffer(buf, CREATE DATABASE %s, fmtId(dbname)); appendPQExpBuffer(buf, WITH OWNER = %s TEMPLATE = template0, fmtId(dbowner)); ---(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] Oracle rant
On Thu, 2003-01-16 at 08:29, Mark Kirkwood wrote: Adrian 'Dagurashibanipal' von Bidder wrote: I'm just saying that there are *some* small arcane details in postgres, too (although, at least, they don't affect stability, just performance). Indeed you are right... Pg has its own collection of arcane details too, but hopefully the culture of Postgesql (in common with all open source projects) is to expose and educate rather than confine to a group of the initiated. Does that sound better ? ( i.e no so rabid Oracle bashing) Yes, sounds better. Seriously: I absolutely agree that Oracle is not inclined to make it easier to use their product - after all, as was said, they sell courses and certifications, while pg tries to be easy to use. I just got the impression from the first few messages that some people think that pg has no secret tricks you're supposed to know at all. Experience counts. With all systems. (And knowing the secret tricks is what experience comes down to, basically). cheers -- vbi -- signature virus v1.0 - please use me in your own mail. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Oracle rant
I work in an all Oracle shop, with server instances around the world. At least 20 servers are 400Gb+ and a couple are 4 Terabyte+. I tooks $15k worth of Oracle training, have set up my own instances and done Perl/CGI/Apache work along with setting up really big data warehousing apps for factories and engineers. I also am a Linux Nut and use Postgres whenever possible because I like the freedom of access to the HACKERS mailing list...something only a few highly renound DBA snobs have with Oracle. I have been impressed however, with the degree to which Oracle(synonymous with Ellison) has attempted to become Open. Oracle is getting into Linux almost as heavily as IBM, mostly prompted by their common rivalry with M$ and SQLServer. Oracle's licensing policy of download it if you want and we'll trust you to do the right thing and give us money if you meet the criteria does build a sense of trust with the technical world. And, their documentation is fairly open and detailed. What their docs don't cover, a search on Google or something else(like attending Oracle World events) will generally illuminate. So, as far as Openness goes, I would say that PostgreSQL is more open than Oracle, but Oracle is pretty good. The one thing I notice about PostgreSQL however, is this tendency to keep the DBA away from considerations of hardware...don't worry about the man behind the curtains folks mentality. With Oracle, you can screw around with files and tablespaces and extents and segments and partition striping and local and global indexing and block sizes and 400+ other tuning parameters to your heart's content. And, if you happened to put your data on separate server instances, you and use database links to join the data together. With Oracle's transaction logging and rollback segments, a paranoid DBA can do all sorts of replication schemes, backup schemes, and point in time recovery...to ANY POINT IN TIME, whether or not there was a crash or simple a user who issued a really dumb SQL statement. Perhaps this is a tremendous waste of time and leads to a lot of crashes with arcane error messages, but it gives the DBA control. I am a control freak and I think a lot of other people are too. Oracle is tremendously complex and has a steep learning curve, but it gives me control. With PG, a lot of effort has been made to simplify. This removes DBA control, but probably also contributes to the stability you guys think you have over Oracle. Perhaps Oracle's supposed instability is partially due to allowing DBAs to fiddle with too much. I know that some is sometimes due to Oracle releasing poorly coded features too soon, but I think a lot of it is also due to DBAs screwing with stuff too. Of course, if the boss just wanted me to get the DB running and quit screwing with coallescing free extents in tablespaces, then I would just run PG. If PostgreSQL were to open up all the internals of storage and become as complex as Oracle, there probably would be a lot of high profile crashes and PG would get a bad reputation. However, I think that having a mode of operation(controlled at compile time) where all the dirty details of storage was made accessible in the data dictionary, would be something good to pacify the control freaks. Food for thought. If you need someone play devils advocate in the Oracle vs. PG debates, I'll do it. I think that a little critique of PG Fred On 1/16/2003, Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] wrote: On Thu, 2003-01-16 at 08:29, Mark Kirkwood wrote: Adrian 'Dagurashibanipal' von Bidder wrote: I'm just saying that there are *some* small arcane details in postgres, too (although, at least, they don't affect stability, just performance). Indeed you are right... Pg has its own collection of arcane details too, but hopefully the culture of Postgesql (in common with all open source projects) is to expose and educate rather than confine to a group of the initiated. Does that sound better ? ( i.e no so rabid Oracle bashing) Yes, sounds better. Seriously: I absolutely agree that Oracle is not inclined to make it easier to use their product - after all, as was said, they sell courses and certifications, while pg tries to be easy to use. I just got the impression from the first few messages that some people think that pg has no secret tricks you're supposed to know at all. Experience counts. With all systems. (And knowing the secret tricks is what experience comes down to, basically). cheers -- vbi -- signature virus v1.0 - please use me in your own mail. ---(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] Indexes
Does anyone think it would be a good idea, or is it even practical, to have a 'indx' subdirectory along side of the 'base' directory? I was thinking that, if it were an easy modification, that it could be an easy way to separate data and indexes to different hard disks. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS]
Christopher Kings-Lynne [EMAIL PROTECTED] writes: You're right. It's a type in pg_dumpall.c A harmless typo --- the lines aren't commented out (I think your assembly-language background is showing ;-)). But it is pretty ugly output all the same. Have applied the patch. 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]
I don't think a semicolon is a comment. It causes the execution of the previous statement. Christopher Kings-Lynne wrote: Hi, In postgresql 7.3.1, if I do pg_dumpall -c, at the top of the dump file is this: DROP DATABASE au_shipping ;CREATE DATABASE au_shipping WITH OWNER = auadmin TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE au_test ;CREATE DATABASE au_test WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE australia ;CREATE DATABASE australia WITH OWNER = auadmin TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE geeklog ;CREATE DATABASE geeklog WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; DROP DATABASE keystone ;CREATE DATABASE keystone WITH OWNER = chriskl TEMPLATE = template0 ENCODING = 'SQL_ASCII'; Why are all the CREATE DATABASE statements commented out? Surely that will make the restore fail? Chris ---(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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Oracle rant
On Wed, 15 Jan 2003, mlw wrote: I just wanted to post this note. I have been in Oracle hell for four days now, and in between the 5 minutes of work and the hours of watings, dealing with table spaces, I've been in Informix hell for the month or so. At first, we were getting the message No more extents - so I look up the documentation and it says the only way to fix it is to either delete data or unload and reload the data. Ok. fine. I talked with a bunch of people and they agreed that is how to fix the problem. Unfortunatly, we cannot have much downtime and a reload would take days and days. So I went about writing a little appliation to do it (Since I could not use a lovely sql statement to do it because of a lack of logical log space - turning the logs off is also not something I want to do.. especially on a multi-day operation). So the thing runs. A week later the data is loaded, indexes built. We're about to switch the tables and I'm replaying my audit trail to make sure the new table is up to date when I get No more exents. Luckly I had a bottle of rum handy. After some searching around on newsgroups and message boards it turns out that the problem is not that there are not enough extents, but there are 16.7M pages of data in the table. The only fixes for THAT are to fragment the table (Kind of like an internal union view type thing - which I couldn't do because informix doesn't let you do union with a text blob). So after lots of testing and finding out the version of informix we run has a bug where max() doesn't work if your index is fragmented, we've finally started the copy again. A long time ago I managed to win a battle to get a PG system (7.0.1) for a thing I developed. That machine has NEVER knock knock had a problem. And since that time we've moved lots of stuff onto it... currently is only about 4GB in size. Someday I'll upgrade to a newer version, but if it ain't broke, don't fix it. So with all that, you gotta appreciate both sides - hte fact pg just works and the tunability of bigger db's (Oh yeah - and we've actually had informix on the horn about the problem - their solution was upgrade to 9.4 - it'll be out in march). Hopefully this last thing will complete and I'll be done with it. -- Jeff Trout [EMAIL PROTECTED] http://www.jefftrout.com/ Ronald McDonald, with the help of cheese soup, controls America from a secret volkswagon hidden in the past --- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Oracle rant
On Thu, Jan 16, 2003 at 11:17:42AM -0500, Jeff wrote: On Wed, 15 Jan 2003, mlw wrote: So with all that, you gotta appreciate both sides - hte fact pg just works and the tunability of bigger db's (Oh yeah - and we've actually had informix on the horn about the problem - their solution was upgrade to 9.4 - it'll be out in march). Here lies the real secret to why Open Source of all types keeps the techies (like us) maximally happy: I know I've seen Tom Lane (and others) often suggest an upgrade as the real fix for a problem, but the suggestion to upgrade to a not yet released version invariably includes the option of applying the patch yourself. Not something Oracle can offer. Ross ---(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] Options for growth
On Thu, 2003-01-16 at 17:42, D'Arcy J.M. Cain wrote: We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of memory. I know that memory will improve access if it prevents swapping but how well does PostgreSQL utilize multiple CPUs? At most one CPU is used for any single postgres backend (that means for any single database connection). So, if your load problem is single queries being too slow, thee's nothing you can do with adding more CPUs. If your problem is many connections maxing out the db, PostgreSQL can take full advantage of multiple CPUs. Of course, most db apps still are not cpu bound, so you'd have to do some careful benchmarking first or you'll be spending too much money. cheers -- vbi -- get my gpg key here: http://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Options for growth
On Thu, 2003-01-16 at 11:42, D'Arcy J.M. Cain wrote: Is [Oracle RAC] really as simple as it sounds or would we just be giving up the other two for a new set of problems. That's a question you should be asking to an authority on Oracle RAC (which pgsql-hackers is not). My idea is to create a new middleware layer that allows me to split things up based on various criteria without changing my application. Personally, I would not be very eager to use home-brew replication for a heavy-load, production-critical application (which is what your app sounds like). But YMMV... We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of memory. I know that memory will improve access if it prevents swapping but how well does PostgreSQL utilize multiple CPUs? The estimates I've heard from a couple parties are that PostgreSQL tends to scale well up to 4 CPUs. I've been meaning to take a look at improving that, but I haven't had a chance yet... Another option is to put some money toward the current development effort to get truly scalable replication for PostgreSQL. In the end, I'd think the cost of subsidizing some of that development would be a fraction of the license fees you'll end up paying Oracle over the years... 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
[HACKERS] Options for growth
Due to the fact that we are growing out of our current system (PostgreSQL on
PCs) we are looking for ways to expand and one of the suggestions has been to
toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC)
software. The theory is that you can just plug machines into the cluster if
the database appears to be straining and they automagically take over some of
the load. Not knowing much about it I can only argue about price and source
code availability. The first has some value but the second is harder to
argue without knowing about RAC. Is it really as simple as it sounds or
would we just be giving up the other two for a new set of problems.
My idea is to create a new middleware layer that allows me to split things up
based on various criteria without changing my application. RAC sounds like
it does that at the database/SQL level. Does it?
We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of
memory. I know that memory will improve access if it prevents swapping but
how well does PostgreSQL utilize multiple CPUs?
And finally, if you had your dream machine to run on, what would it be? We
are also looking outside of PC hardware but we are concerned about not having
access to that nice, cheap, generic hardware for when we need to grow again
or for redundant backup.
Thanks for any tips and suggestions.
--
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 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] Dropping OID column
On Thu, 2003-01-16 at 13:41, Rod Taylor wrote: ALTER TABLE .. SET WITHOUT OIDS; I'd prefer this, as it's more similar to the CREATE TABLE syntax. 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] Oracle rant
On Thu, Jan 16, 2003 at 10:50:49AM -0600, Ross J. Reedstrom wrote: suggestion to upgrade to a not yet released version invariably includes the option of applying the patch yourself. Not something Oracle can offer. Not for a sane price, I guess. I believe the high end support contracts include getting custom patched versions in a short period of time. Petru ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Dropping OID column
Rod Taylor [EMAIL PROTECTED] writes: What is the preferred syntax: ALTER TABLE .. DROP COLUMN oid; or ALTER TABLE .. SET WITHOUT OIDS; If we ever got around to supporting the inverse function (add oids), I do not think we'd want to spell it like ADD COLUMN oid --- that would interfere with making a plain user column named oid, which was one of the reasons why people wanted to be able to drop OIDs in the first place. So I lean towards the SET WITH/WITHOUT OIDS syntax. That keeps it clearly out of the domain of user columns. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Indexes
mlw said: Does anyone think it would be a good idea, or is it even practical, to have a 'indx' subdirectory along side of the 'base' directory? I was thinking that, if it were an easy modification, that it could be an easy way to separate data and indexes to different hard disks. This and other quick hacks have been discussed before. I think the consensus has been to do nothing until someone gets around to writing a general-purpose tablespace implementation. FWIW, I don't think it would be an easy modification. The low-level file access code doesn't even know whether a given relation is an index or not (... and I don't think it should know). By the time you get done implementing something reasonable at that level, you've got the infrastructure you need for tablespaces. 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])
[HACKERS] postgresql code
Hi, we're students seeking to make a visualization of postgresql locking system. We're currently clueless as where to find postgresql source codes. Any help? :) Thanks, Nat Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: [HACKERS] v7.3.1 psql against a v7.2.x database ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message Well, it is open source, so there's no reason why someone couldn't make these changes for 7.4 and also release a binary version in the mean time. I have a copy of a 7.2 psql binary for linux that that has some of the 7.3 psql improvments in it, sometimes it comes in very handy. I'd be interested in helping out with this, though Christopher would probably start throwing things at me if I volunteered :-) I have strongly considered doing this, and even started on the project some time ago. (I've stopped now). At first I wanted to add 7.3 and 7.4 features to a 7.2 psql. Then I considered writing a master psql that could handle any backend. In the end, however, I realized that with 7.3 well out the door, it was better to encourage people to upgrade to 7.3 and spend my energies on other things. If there is still a strong interest however, I can easily help out and share what I have already done. -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301161656 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+JyrzvJuQZxSWSsgRAmdUAJ4upWRFGKi1K5WYAwCVf36w1V4aAQCgvuD3 kCy+Q6EE/pum7Sojim+TJdM= =Tvn6 -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] Indexes
On Thu, 16 Jan 2003, Tom Lane wrote: mlw said: Does anyone think it would be a good idea, or is it even practical, to have a 'indx' subdirectory along side of the 'base' directory? I was thinking that, if it were an easy modification, that it could be an easy way to separate data and indexes to different hard disks. This and other quick hacks have been discussed before. I think the consensus has been to do nothing until someone gets around to writing a general-purpose tablespace implementation. Wasn't someone just about done with a tablespace implementation? I certainly remember some discussion on this subject a few months ago. -- Nigel J. Andrews ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Oracle rant
Peter Eisentraut wrote: Adrian 'Dagurashibanipal' von Bidder writes: - postgres should auto-tune itself - the *cost could perhaps be adjusted after some statistics have been collected, and there should be some sensible way to determine an optimal setting for the famous shared_buffers (and the default should be something that gets reasonable performance on common cases) Over the last couple of years PostgreSQL has transformed from hardly configurable to fully configurable. Currently we're in a mode where we add new configuration parameters whenever there's a degree of uncertainty. Sooner rather than later we need to shift to the next phase, which is as you say autoconfiguration, because ease of administration is one of the great advantages of PostgreSQL I think the idea of adding a parameter when ever you are not sure, is a great idea. That does preclude, however, the ability for a process within PostgreSQL from analyzing the metrics and updating the parameter file or table.
Re: [HACKERS] postgresql code
Take a look on the developers page for a few internals presentations. I have some on my home page as well, see URL in signature. --- Chandralaksana Natalia wrote: Hi, we're students seeking to make a visualization of postgresql locking system. We're currently clueless as where to find postgresql source codes. Any help? :) Thanks, Nat - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now -- 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 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] Dropping OID column
I guess I'd prefer the DROP COLUMN syntax. It means we don't have to add another non-standard command, and people can figure out how to drop the oid column just by trying... Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rod Taylor Sent: Friday, 17 January 2003 2:42 AM To: PostgreSQL-development Subject: [HACKERS] Dropping OID column What is the preferred syntax: ALTER TABLE .. DROP COLUMN oid; or ALTER TABLE .. SET WITHOUT OIDS; -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] PostgreSQL 7.4 and Microsoft's SMS
Hi guys, Just received a query through the Advocacy site's request form... Does anyone know if PostgreSQL 7.4's native windows version will/would be compatible with Microsoft's SMS (System Management Server)? Looks like some places will be considering it for Enterprise Deployment if it is. :-) 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Hi everyone, Over the last few days we've had patches submitted for 7.2.3 that address a couple of things, both the WAL Recovery Bug that Tom has developed a patch for, and a couple of buffer overflows that have been widely reported. Although we haven't wanted to release a 7.2.4, and have instead encouraged people to upgrade to 7.3.x, there are places out there who's applications aren't compatible with 7.3.x and would also need to upgrade them as well. It might be a really good idea if we re-visit the thought of 7.2.4 and have something that people running the 7.2.x series can use safely until they are able to move to 7.3.x or above. What would it take, and apart from patches for the buffer overflows and the WAL recovery bug, should anything else be included to ensure safety and stability? :-) 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 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Generate user/group sysids from a sequence?
Currently, the default sysid assigned to a user or group is computed as max(sysid)+1. We've seen a couple of complaints now from people who deleted their newest user, made another user, and found that permissions from the deleted user carried over to the new one. It seems to me that the easiest solution to this is to generate the default sysid from a sequence object, instead. Unless someone deliberately resets the sequence, there'd be no conflicts. A small difficulty is that explicitly-specified sysids could conflict with sysids generated later by the sequence. We could perhaps fix this by forcing up the sequence setting to be at least as large as an explicitly-given ID (compare the handling of explicitly loaded OIDs). Comments? 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] Generate user/group sysids from a sequence?
On 17 Jan 2003 at 1:16, Tom Lane wrote: Currently, the default sysid assigned to a user or group is computed as max(sysid)+1. We've seen a couple of complaints now from people who deleted their newest user, made another user, and found that permissions from the deleted user carried over to the new one. It seems to me that the easiest solution to this is to generate the default sysid from a sequence object, instead. Unless someone deliberately resets the sequence, there'd be no conflicts. A small difficulty is that explicitly-specified sysids could conflict with sysids generated later by the sequence. We could perhaps fix this by forcing up the sequence setting to be at least as large as an explicitly-given ID (compare the handling of explicitly loaded OIDs). I would say keep range of user specified ids and automatically generated ids exclusive to each other. Something like user can specify the id upto 64K, automatically generated ids are above that. Like unix ports. Below 1024, you need to be root to get it listening.. Of course one fine day, somebody is going to ask for a configuration option for this but a DBA can always set the sequence value to any range he wants. Just a thought.. Bye Shridhar -- telepression, n.: The deep-seated guilt which stems from knowing that you did not try hard enough to look up the number on your own and instead put the burden on the directory assistant. -- Sniglets, Rich Hall Friends ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Oracle rant
Fred Zellinger wrote: I also am a Linux Nut and use Postgres whenever possible because I like the freedom of access to the HACKERS mailing list...something only a few highly renound DBA snobs have with Oracle. Indeed, I think this is a significant component of the appeal of open source I have been impressed however, with the degree to which Oracle(synonymous with Ellison) has attempted to become Open. Oracle is getting into Linux almost as heavily as IBM, mostly prompted by their common rivalry with M$ and SQLServer. I wonder if the conversion to openness may more a mechanism to distinguish themselves from Microsoft, than a heart-felt belief in the principles themselves but its nice anyway ! regards Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Oracle rant
Adrian 'Dagurashibanipal' von Bidder writes: - postgres should auto-tune itself - the *cost could perhaps be adjusted after some statistics have been collected, and there should be some sensible way to determine an optimal setting for the famous shared_buffers (and the default should be something that gets reasonable performance on common cases) Over the last couple of years PostgreSQL has transformed from hardly configurable to fully configurable. Currently we're in a mode where we add new configuration parameters whenever there's a degree of uncertainty. Sooner rather than later we need to shift to the next phase, which is as you say autoconfiguration, because ease of administration is one of the great advantages of PostgreSQL. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] copying perms to another user
Bruce Momjian writes: I think the one missing item mentioned was for group ownership of an object. However, if we give group _permission_ to the object, I am not sure why ownership is an issue. Are there certain permission we can't give to the group? Privilege to rename or drop the object, and the right to grant privileges in the first place. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Dropping OID column
Peter Eisentraut [EMAIL PROTECTED] writes: Is there really a reason why OIDs can't be a pure user-space column? We'd need some kluge to keep SELECT * from including OID. Also I'd be a bit worried about the impact on the cost of HeapTupleGetOid --- it might not matter, or it might. 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] Dropping OID column
Tom Lane writes: If we ever got around to supporting the inverse function (add oids), I do not think we'd want to spell it like ADD COLUMN oid --- that would interfere with making a plain user column named oid, which was one of the reasons why people wanted to be able to drop OIDs in the first place. Is there really a reason why OIDs can't be a pure user-space column? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Options for growth
Due to the fact that we are growing out of our current system (PostgreSQL on PCs) we are looking for ways to expand and one of the suggestions has been to toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC) software. You mean Real Application Clusters? Chris ---(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] Translation of the PostgreSQL manuals to Spanish is under way
Hi everyone, Christian Kuroki [EMAIL PROTECTED] is a senior member of a team that is translating the PostgreSQL manuals to Spanish. There isn't a website for it yet (it will be created fairly soon) but the team is making good progress, and the manuals will be kept updated with the main PostgreSQL manuals. Does anyone out here who knows/writes Spanish have a bit of time to assist them with translation? These manuals will be available to all, just the same as with PostgreSQL itself, and will greatly assist in improving PostgreSQL for the Spanish Community. 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
