Re: [HACKERS] Per database users/admins, handy for database virtual hosting...
On Thu, Mar 25, 2004 at 08:24:59PM -0800, Sean Chittenden wrote: You can't think that allowing the same name to appear globally and locally is a good idea. Actually, I do think it is a good idea. If I say GRANT TO foo, who am I granting privileges to? SET username_precedence TO LOCAL,GLOBAL; -- I like GLOBAL more than CLUSTER GRANT TO foo; SET username_precedence TO GLOBAL,LOCAL; GRANT TO foo; Yes, it possible, but I not sure if this commands dependence is something wanted and nice. You can use GRANT TO LOCAL foo rather than connect more commands together. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Per database users/admins, handy for database virtual hosting...
Sean Chittenden [EMAIL PROTECTED] writes: You can't think that allowing the same name to appear globally and locally is a good idea. Actually, I do think it is a good idea. If I say GRANT TO foo, who am I granting privileges to? SET username_precedence TO LOCAL,GLOBAL; -- I like GLOBAL more than CLUSTER GRANT TO foo; SET username_precedence TO GLOBAL,LOCAL; GRANT TO foo; And I don't want to say that there is no difference because they are the same user. Agreed, they should be the same user. What? You are contradicting yourself. That precedence hack makes sense only if there is a difference. That will open up some nasty security holes, eg, being able to pretend that you are the global postgres superuser if you can set the password for a local user by the same name. Agreed, but if a cluster is using LOCAL USERs, I doubt highly that CLUSTER/GLOBAL users would be in use much beyond super users. -sc Exactly my point. I think that it might be possible for a locally-privileged DBA to give himself superuser privileges by skating on this confusion between who is whom. Once he creates a local user with the same name as the global superuser, the door is open to problems --- not only possible bugs in our own code, but plain old human error on the part of the real superuser. In short, I say it's a bad idea with no redeeming social value. I can't see any positive use-case for having local usernames that conflict with global ones. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Nested transaction proposal - take N (N 2)
Heikki Linnakangas wrote: I haven't seen your patch yet, but the proposal looks good to me. On Tue, 23 Mar 2004, Alvaro Herrera wrote: Let the currently unused fourth state in pg_clog indicate a committed subtransaction. In pg_clog there are two bits per transaction, commit and abort, with the following meaning: a c 0 0 transaction in progress, the owning backend knows whether it is a main- or a sub-transaction, other backends don't care 1 0 aborted, nobody cares whether main- or sub-transaction 0 1 committed main-transaction or - with shortcut 2 - a sub- transaction that's known committed to all active transactions 1 1 committed sub-transaction, have to look for parent in pg_subtrans This conflicts with my two-phase commit patch. I'm using the fourth state to mark transactions that have been prepared (1st. phase) but not yet committed. I think I can work around it in my code, so that you can have the fourth state. I have to keep a list of prepared transactions in memory anyway, I can use that instead. I think the big question is whether other backends have to see your status bits for the transaction. Nested transactions require global backend visibility. If your's doesn't, then you are better off doing it in local memory. I would like to get the nested transaction work already coded into CVS so you can continue on your 2-phase commit work and we get get that in too soon. -- 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])
[HACKERS] Bad timestamp external representation
Hi everyone: I am using Postgresql 7.3.4 and found a problem inserting "Timestamp" objects throughJDBC Prepared Statements when the time zone is set to Canada/Newfoundland (3 hours and30 minutes from MGT). I am trying to insert "new Timestamp(0L)" into one of the fields.The database replies with an error message: Bad timestamp external representation '1969-12-31 20:30:00.00-030-30' Most likely, the database doesn't understand the last part of the timestamp, which is'-30' (30 minutes). It works properly only with time zones that don't have that additional half hour difference. I could not find any useful information regarding that issue. Any help would be appreciated. Thanx
Re: [HACKERS] pg_advisor schema proof of concept
Hello, Both phpPgAdmin (me) and the pgAdmin team have added or have thought about adding some 'schema analysis' features to our products. If pg_advisor is available, I certainly won't bother and I will just recommend to people that they install it. Ok. A more precise question is: on the client side, whether PHP or anything else, can you take advantage of the information available and provide some usable somehow dedicated interface that would make it easy to access the available informations? What would help for that purpose? The current proposal is that the advices would be tables in a schema, so just by browsing the tables one can access advices. However, the tables contain the advice data, but explanations about what these advices mean are in another table. So maybe there is an interface job that would be welcome to show both the explanations and the data of interest for these explanations? Just like in psql \* shortcuts query about pg_tables to show informations. -- Fabien. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] subversion vs cvs
After a long battle with technology, [EMAIL PROTECTED] (Marc G. Fournier), an earthling, wrote: On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote: Which brings me to another question .. has anybody considered using subversion instead of CVS ? Why? not that I'm for a chance from something that isn't broken, but what advantages does subversion give us over what we already have? It's a newer design, offering some nice features: - Directories, renames, and file meta-data are versioned. - Commits are truly atomic. (DB guys should like that :-).) - Branching and tagging are cheap (constant time) operations - Costs are proportional to change size, not data size - Efficient handling of binary files - Parseable output (one of the things better about SCCS than RCS/CVS) Unfortunately, they have only just gotten to the point of having a stable version. Until very recently, different versions of Subversion couldn't expect to talk to one another, which is a Very Bad Thing. In another year, it might be worth holding a debate over whether there is value to considering Subversion or one of the Arch descendants as an alternative to CVS. I wouldn't think it's time yet. And it would be as wise to consider Arch as well; it has some pretty interesting repository features... -- let name=cbbrowne and tld=cbbrowne.com in name ^ @ ^ tld;; http://www3.sympatico.ca/cbbrowne/multiplexor.html Those who doubt the importance of a convenient notation should try writing a LISP interpreter in COBOL or doing long division with Roman numerals. -- Hal Fulton ---(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] Delphi
a wrote: Hi, Is it have any tools or control let delphi can direct connet to postgresql not only use odbc? Thank!! Gary take a look at www.zeoslib.net www.microolap.com/dac/postgresdac.htm dbexpress : www.vitavoom.com Daniel ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] A student research project on triggers
I'm currently working on a student research project that is supervised by a professor from my university. This project duration is 2 semesters. The topic is to implement the two missing SQL3 standard triggers functionalities in Postgresql, ¡®triggers on columns¡¯ and ¡®referencing old or new values alias list¡¯ in trigger definition. A short brief of me:I am a Computer Science master student in the 5th semester in Ottawa U, Canada. I have 10 years experiences in C/C++ programming; I am also working as a Unix system administrator for a large semiconductor Company. I would like to get some help about where to start, any ideas, suggestions or hints are appreciated. Mark [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Syntax error reporting (was Re: [PATCHES] syntax error
Maybe I missed something, but it seemed to me that strings are appended on to the other, and there is no way back. But the string list is not constructed until the error actually occurs. You don't need a pop at that point --- the call stack is what it is. I think you are imagining that outer-level context hooks should be able to editorialize on what inner-level ones said (or perhaps vice versa?) No. I just missed the error_context_stack by focussing on errcontext(), which does not managed a stack at all, so I was quite puzzled. Now it is clearer. Thanks, -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Per database users/admins, handy for database virtual hosting...
You can't think that allowing the same name to appear globally and locally is a good idea. Actually, I do think it is a good idea. If I say GRANT TO foo, who am I granting privileges to? SET username_precedence TO LOCAL,GLOBAL; -- I like GLOBAL more than CLUSTER GRANT TO foo; SET username_precedence TO GLOBAL,LOCAL; GRANT TO foo; And I don't want to say that there is no difference because they are the same user. Agreed, they should be the same user. ^ n't What? You are contradicting yourself. That precedence hack makes sense only if there is a difference. Ack, brain-o, you're right: what a difference an n't makes. That will open up some nasty security holes, eg, being able to pretend that you are the global postgres superuser if you can set the password for a local user by the same name. Agreed, but if a cluster is using LOCAL USERs, I doubt highly that CLUSTER/GLOBAL users would be in use much beyond super users. -sc Exactly my point. I think that it might be possible for a locally-privileged DBA to give himself superuser privileges by skating on this confusion between who is whom. I don't think that's possible though... let's say there are two databases, hostingco and customer1. That gives us two different pg_shadow_db tables. On top of that, there is a central pg_shadow_cluster table that is shared among all databases. Let's suppose there is: 1) a superuser 'dba' in pg_shadow_cluster (password 'foo'); 2) a superuser 'dba' in pg_shadow_db in the hostingco database (password 'bar'); and, 3) a normal user 'dba' in pg_shadow_db in the customer1 database (password 'baz'). Here are the scenarios with the UNION example I gave: pg_shadow_cluster 'dba' case: *) the 'dba' account in pg_shadow_cluster (dba/cluster) could log in to all of the databases. *) the dba/cluster account could only be logged into if someone had the right password. *) the UID for the dba/cluster account is irrelevant because any perms the UID has won't prevent him/her from walking through the entire database. *) if a database creates a user with the same UID as the dba/cluster, the local database admin doesn't gain anything if the dba/cluster account modifies the database/does work. If the dba/cluster account does do work in the local database with a shared UID, the UID will resolve to the local database first preventing the local account with the shared UID from gaining cluster wide privs (only accounts with cluster superuser privs should be able to change the resolution from LOCAL,GLOBAL to GLOBAL,LOCAL). hostingco 'dba' case: *) The 'dba' account in pg_shadow_db (dba/hostingco) could log in to only the local database housing the pg_shadow_db table. *) The dba/hostingco account behaves identically to the dba/cluster... I don't think there's a need to even prevent this account from changing the username resolution because changing databases requires a new connection where GUC settings are reset. *) The dba/hostingco account can't log into any other database because the dba/hostingco account only lives in the database specific pg_shadow_db table. *) If the dba/cluster admin logs into the hostingco database, the UID resolution would be GLOBAL,LOCAL instead of LOCAL,GLOBAL. If there is a shared UID, the local admin who created the shared UID account only stands to loose, but can't gain elevated privs. customer1 'dba' case: *) Identical to the dba/hostingco case except the account isn't a superuser. Have I missed a case? As for the reason for the usefulness of having shared usernames, the 'www', 'dba', 'admin', 'web', 'php', or [commoon_application_name] accounts are very popular names for logging in and I'd like to not deprive customers of ease of use because they're in a hosted environment instead of a dedicated environment. Another solution would be to have CREATE USER done by a local admin create users in the form of '[EMAIL PROTECTED]'. This prevents duplicate usernames and allows us to use the current hack of local database users. Once he creates a local user with the same name as the global superuser, the door is open to problems --- not only possible bugs in our own code, but plain old human error on the part of the real superuser. How so? Can you give a scenario where this'd make a difference? I think putting a trigger on pg_shadow_db to prevent users from mucking with the UID would be a sufficient anti-foot shooting measure. -sc -- Sean Chittenden ---(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] Per database users/admins, handy for database virtual hosting...
Richard Huxton [EMAIL PROTECTED] writes: Maybe it's me being slow, but are we not being over-complicated here? What's wrong with saying database D1 looks up users in local table, D2 in the global table. If you are connected to D1, then no-one can see the global userlist. Hmm. That would amount to saying that there are no global superusers for D1, which might be a bit of a problem --- if local DBA paints himself into a corner, you can't get him out. Backing up a cluster that has not got global superusers would be a PITA too. Still, I think you are right that we gotta think outside the box if we're going to find a way to do this. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Per database users/admins, handy for database virtual hosting...
On Friday 26 March 2004 15:09, Tom Lane wrote: Sean Chittenden [EMAIL PROTECTED] writes: Agreed, but if a cluster is using LOCAL USERs, I doubt highly that CLUSTER/GLOBAL users would be in use much beyond super users. -sc Exactly my point. I think that it might be possible for a locally-privileged DBA to give himself superuser privileges by skating on this confusion between who is whom. Once he creates a local user with the same name as the global superuser, the door is open to problems --- not only possible bugs in our own code, but plain old human error on the part of the real superuser. Maybe it's me being slow, but are we not being over-complicated here? What's wrong with saying database D1 looks up users in local table, D2 in the global table. If you are connected to D1, then no-one can see the global userlist. The global user richard cannot log into D1, and the local user richard can log only into D1. In short, I say it's a bad idea with no redeeming social value. I can't see any positive use-case for having local usernames that conflict with global ones. In a shared-hosting situation, I can see local super-users both wanting to create users called (e.g.) plone. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Per database users/admins, handy for database virtual hosting...
Sean Chittenden [EMAIL PROTECTED] writes: Another solution would be to have CREATE USER done by a local admin create users in the form of '[EMAIL PROTECTED]'. This prevents duplicate usernames and allows us to use the current hack of local database users. Yeah, I think it would be reasonable to leave that facility as-is and invent a category of user privileges that only allows creation/deletion of local usernames. We'd have to think about how that should interact with other superuser attributes such as the ability to bypass privileges. But breaking down superuserness into finer-grained privileges has been on the wish list for awhile. Once he creates a local user with the same name as the global superuser, the door is open to problems --- not only possible bugs in our own code, but plain old human error on the part of the real superuser. How so? Can you give a scenario where this'd make a difference? Well, it's the standard sort of attack where you try to trick a user with more privs than you into doing something he'd not do if he was aware of who/what he was really doing it to. Something like granting privileges to a local user when he thought he was granting to a global user, or vice versa. Or making the wrong user a member of a group. I'm not sure that this is actually very probable, if the usage scenario is that global users are always superusers --- there'd seldom be any reason to go granting them any additional privileges. But if we are also thinking of having multiple categories of user privileges then it's less far-fetched. Other possible problems include resetting the password of the wrong user. This would be particularly bad if a database's local superuser can choose the setting of the encrypt passwords by default GUC switch --- he might have the opportunity to see the cleartext password of some global user. Obviously that hole can be plugged now that I've pointed it out, but what other ones are there? 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
[HACKERS] PostgreSQL block size vs. LVM2 stripe width
I have some results from DBT-2 testing PostgreSQL with difference block sizes against different lvm stripe widths on Linux. I've found that iostat appears to report more erratic numbers as the block size of the database increases but I'm not able to see any reason for it. I have pg_xlog on a separate set of drives from the rest of the database and was wondering if having different block sizes for the log and the data has been discusses? Or does anyone have any tips for an optimal combination of settings? Here's a summary from an Itanium2 system, where bigger is better: Linux-2.6.3, LVM2 Stripe Width (going across) PostgreSQL BLCKSZ (going down)16 KB 32 KB 64 KB 128 KB 256 KB 512 KB 2 KB261726562652266426672642 4 KB439344864577455745114448 8 KB433744234471457641113642 16 KB 441244954532453629852312 32 KB 370537843886392529362362 Links to more data: http://developer.osdl.org/markw/lvm2/blocks.html Mark ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Per database users/admins,
Richard Huxton [EMAIL PROTECTED] writes: Maybe it's me being slow, but are we not being over-complicated here? What's wrong with saying database D1 looks up users in local table, D2 in the global table. If you are connected to D1, then no-one can see the global userlist. Hmm. That would amount to saying that there are no global superusers for D1, which might be a bit of a problem --- if local DBA paints himself into a corner, you can't get him out. Backing up a cluster that has not got global superusers would be a PITA too. So you write a script to add a local superuser when you create the database. Or, we could do it in the createdb/CREATE DATABASE code - just clone the postgres user. Last resort, I'm sure the files themselves could be hacked if you had to. If people are running a shared environment, it's fair to assume they know a little of what they're doing. Still, I think you are right that we gotta think outside the box if we're going to find a way to do this. More a case of thinking under the box here. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] GIST code doesn't build on strict 64-bit machines
I've just found out the hard way that Postgres doesn't even build on recent gcc releases for 64-bit HPPA. The reason is that the compiler now notices and complains about alignment errors that will lead to core dump at runtime, and GIST has got some. The particular code that fails to compile is in gist.c: gistentryinit(((GISTENTRY *) VARDATA(evec))[1], ((GISTENTRY *) VARDATA(evec))[0].key, r, NULL, (OffsetNumber) 0, ((GISTENTRY *) VARDATA(evec))[0].bytes, FALSE); Since VARDATA() is at a 4-byte offset from the start of the datum, this is trying to overlay a GISTENTRY struct at a 4-byte boundary. When compiling in 64-bit mode, Datum is 8 bytes, and so the GISTENTRY struct is not sufficiently well aligned. Unlike Intel machines, the HP chips *require* 8-byte loads and stores to be 8-byte-aligned. I suppose that a correct fix involves doing MAXALIGN(VARDATA(evec)), but I do not know what places need to change to support this. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bad timestamp external representation
On Fri, 19 Mar 2004, Denis Khabas wrote: Hi everyone: I am using Postgresql 7.3.4 and found a problem inserting Timestamp objects through JDBC Prepared Statements when the time zone is set to Canada/Newfoundland (3 hours and 30 minutes from MGT). I am trying to insert new Timestamp(0L) into one of the fields. The database replies with an error message: This has been fixed in the 7.4 driver which is compatible with 7.3 servers. Try downloading it from http://jdbc.postgresql.org/download.html Kris Jurka ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] database is shutting down
We have a customer who reports a weird problem. Too often the App. Server fails to connect to the database. Sometimes the scheduled vacuum fails as well. The error message is always the same: FATAL: The database system is shutting down But from what I see no one is trying to shut down the database at this time. I am still waiting for the database-log to see if I can find a clue there, but I wonder if someone knows what can make the database respond this way. This is Pg 7.3.2, on HP 11.0, using the Unix Domain Socket. Thank you, Mike ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Bad timestamp external representation
Denis, This is more appropriate for the jdbc mail list. --Barry Denis Khabas wrote: Hi everyone: I am using Postgresql 7.3.4 and found a problem inserting Timestamp objects through JDBC Prepared Statements when the time zone is set to Canada/Newfoundland (3 hours and 30 minutes from MGT). I am trying to insert new Timestamp(0L) into one of the fields. The database replies with an error message: Bad timestamp external representation '1969-12-31 20:30:00.00-030-30' Most likely, the database doesn't understand the last part of the timestamp, which is '-30' (30 minutes). It works properly only with time zones that don't have that additional half hour difference. I could not find any useful information regarding that issue. Any help would be appreciated. Thanx ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] database is shutting down
Michael Brusser [EMAIL PROTECTED] writes: The error message is always the same: FATAL: The database system is shutting down But from what I see no one is trying to shut down the database at this time. *Something* has sent the postmaster a shutdown signal --- either SIGINT or SIGTERM. Look around and find out what. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Timeline for 7.4.3?
Hey, We have many machines that run Solaris. I know that there are patches out there for some of the bugs in 7.4.2 for Solaris but I was wondering what the timeline for an official 7.4.3 was? Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timeline for 7.4.3?
Joshua D. Drake [EMAIL PROTECTED] writes: We have many machines that run Solaris. I know that there are patches out there for some of the bugs in 7.4.2 for Solaris but I was wondering what the timeline for an official 7.4.3 was? Don't hold your breath ... 7.4.2 was only a couple weeks ago, and there are no critical bugs in the CVS logs at this point. 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] Per database users/admins, handy for database virtual hosting...
Another solution would be to have CREATE USER done by a local admin create users in the form of '[EMAIL PROTECTED]'. This prevents duplicate usernames and allows us to use the current hack of local database users. Yeah, I think it would be reasonable to leave that facility as-is and invent a category of user privileges that only allows creation/deletion of local usernames. We'd have to think about how that should interact with other superuser attributes such as the ability to bypass privileges. But breaking down superuserness into finer-grained privileges has been on the wish list for awhile. How about splitting usesuper into just the following two privileges: *) createuser *) usesuper A normal user can be the owner of a database so there's no need for an admin like priv. createuser allows the user to create other users with the same or lesser privs, and usesuper is basically exactly what we've got now. How's that? It doesn't give us database local usernames, but it's a big first step toward virtual hosting. Once he creates a local user with the same name as the global superuser, the door is open to problems --- not only possible bugs in our own code, but plain old human error on the part of the real superuser. How so? Can you give a scenario where this'd make a difference? Well, it's the standard sort of attack where you try to trick a user with more privs than you into doing something he'd not do if he was aware of who/what he was really doing it to. Something like granting privileges to a local user when he thought he was granting to a global user, or vice versa. Or making the wrong user a member of a group. I'm not sure that this is actually very probable, if the usage scenario is that global users are always superusers --- there'd seldom be any reason to go granting them any additional privileges. But if we are also thinking of having multiple categories of user privileges then it's less far-fetched. Eh, yes and no. The cluster database admin is the last line of defense... the local dba is who users would talk to and even then, the cluster database admin should only restore local admin privs to the local dba. Beyond that, the cluster dba shouldn't be involved with much... separating the UID ranges for global vs local users wouldn't be a bad idea the more I think about it, even though I don't think there's much of a risk except for possibly to the local database integrity. Other possible problems include resetting the password of the wrong user. This would be particularly bad if a database's local superuser can choose the setting of the encrypt passwords by default GUC switch --- he might have the opportunity to see the cleartext password of some global user. Obviously that hole can be plugged now that I've pointed it out, but what other ones are there? Other holes... none that I can think of beyond: *) changing privs - accidentally elevating a global user's privs when thinking it was a local user that was getting its privs elevated. *) changing the wrong password - same prob as changing the privs *) granting privs to structures to the wrong UID because of incorrect username resolution Beyond leaving admins with possible land mines that needs to be well documented... but that's the trade off for the flexibility, IMHO. Proxy authentication has the same pit falls in kerberos or SASL but that hasn't stopped the security community from adopting kerberos in high security installations the pit falls just need to be documented. A lot of this could be subverted if pg_hba.conf was also stored in the database and could be used to limit what users could connect to what databases and from what IPs. :) BTW, has it been discussed to add a way in pg_hba.conf to limit the number of connections per IP address or per subnet mask? 2 connections per /32 or 4 connections per /30? -sc -- Sean Chittenden ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PERFORM] [HACKERS] fsync method checking
On 26 Mar, Bruce Momjian wrote: [EMAIL PROTECTED] wrote: On 26 Mar, Manfred Spraul wrote: [EMAIL PROTECTED] wrote: Compare file sync methods with one 8k write: (o_dsync unavailable) open o_sync, write 6.270724 write, fdatasync13.275225 write, fsync, 13.359847 Odd. Which filesystem, which kernel? It seems fdatasync is broken and syncs the inode, too. It's linux-2.6.5-rc1 with ext2 filesystems. Would you benchmark open_sync for wal_sync_method too? Oh yeah. Will try to get results later today. Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] [HACKERS] fsync method checking
[EMAIL PROTECTED] wrote: On 26 Mar, Manfred Spraul wrote: [EMAIL PROTECTED] wrote: Compare file sync methods with one 8k write: (o_dsync unavailable) open o_sync, write 6.270724 write, fdatasync13.275225 write, fsync, 13.359847 Odd. Which filesystem, which kernel? It seems fdatasync is broken and syncs the inode, too. It's linux-2.6.5-rc1 with ext2 filesystems. Would you benchmark open_sync for wal_sync_method too? -- 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])
Re: [PERFORM] [HACKERS] fsync method checking
On 26 Mar, Manfred Spraul wrote: [EMAIL PROTECTED] wrote: Compare file sync methods with one 8k write: (o_dsync unavailable) open o_sync, write 6.270724 write, fdatasync13.275225 write, fsync, 13.359847 Odd. Which filesystem, which kernel? It seems fdatasync is broken and syncs the inode, too. It's linux-2.6.5-rc1 with ext2 filesystems. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] [HACKERS] fsync method checking
On Fri, Mar 26, 2004 at 07:25:53AM +0100, Manfred Spraul wrote: Compare file sync methods with one 8k write: (o_dsync unavailable) open o_sync, write 6.270724 write, fdatasync13.275225 write, fsync, 13.359847 Odd. Which filesystem, which kernel? It seems fdatasync is broken and syncs the inode, too. This may be relevant. From the man page for fdatasync on a moderately recent RedHat installation: BUGS Currently (Linux 2.2) fdatasync is equivalent to fsync. Cheers, Steve ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
