Re: [HACKERS] tsearch2 vs core?
Hello all, tsearch2 now doesn't support multibyte encoding and has problems with UTF :(. I read this url; http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/donate.shtml --- - UTF-8 support Currently, tsearch2's parser doesn't supports utf-8. This is very important if you want to search multilingual documents. --- But, there is another document; Tsearch2 and Unicode/UTF-8 http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/docs/tsearch2_german_utf8.html Which is true? The tsearch2 suppoort UTF or not? If we use simple parser, we can store UTF-8 text into tsearch2? Or, do we have to make own parser which can parse UTF-8 text? Japanese Mr. Junji TERAMOTO(NTT) is supporting it. http://www.oss.ecl.ntt.co.jp/tsearch2j/ However, It is EUC_JP. He will probably understand the problem. Though I don't understand the problem Sorry, I don't understand this problem exactly... -- Junji Teramoto ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Checkpoint cost, looks like it is WAL/CRC
Magnus Hagander [EMAIL PROTECTED] writes FWIW, MSSQL deals with this using Torn Page Detection. This is off by default (no check at all!), but can be abled on a per-database level. Note that it only *detects* torn pages. If it finds one, it won't start and tell you to recover from backup. It can't automatically recover. I would assume this greatly decreases the amount of data you have to save... After reading the long discussion on torn page detection and many related issues in doc/TODO.details/wal, I believe we need carefully analysis what the sequence of a partial write. case 1: if a partial write just write some sectors of a 8K page, then it is ok - assuming we will replay xlog in any ways without comparing page header LSN and xlog LSN (currently we do not do so); case 2: if a patial write destroied some old data of a page, which are not in our xlog, we will worry about this; So the main issue is case2. If OS could schedule atomic sector-wise write , so case2 could never happen? Regards, Qingqing ---(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] 2PC transaction id
On Fri, 1 Jul 2005, Oliver Jowett wrote: Ok, so how do we get XA working when a single global transaction involves two databases on the same cluster? The scenario is: - there are two independent resource managers participating in a single global transaction - each resource manager has a connection to the database it is managing, and a SQL-level transaction running against that database - the global TM tells both resource managers to prepare their part of the global transaction, passing the same XID to both If the TM does that, it's broken. The XID consists of three parts: format id: a constant. Not interesting. gtrid: Global Transaction Identifier. This identifies the global transaction in the TM. All XIDs that have the same gtrid should be completed atomically by the TM branch id: Branch Identifier. Every RM involved in the global transaction is given a *different* branch id. In the above case, the TM would give the two resource managers XIDs that have the same gtrid but different branch ids. From the RM point of view, those fields have no significance and the XID as whole is used to identify the transaction. So the RM should never see the same XID twice, except when the TM specifically uses the TMJOIN or the TMSUSPEND/TMRESUME flags. If the TM uses those flags, it'll only issue one prepare. - Heikki ---(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] [PATCHES] Dbsize backend integration
-Original Message- From: Dawid Kuroczko [mailto:[EMAIL PROTECTED] Sent: 30 June 2005 22:21 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration On 6/30/05, Dave Page dpage@vale-housing.co.uk wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 29 June 2005 12:46 To: Dave Page Cc: PostgreSQL-patches; PostgreSQL-development Subject: Re: [PATCHES] Dbsize backend integration I have a new idea --- pg_storage_size(). I'm not against that one, but I think Tom's point is vaild. I cannot think of anything better at the moment though (maybe pg_component_size, but that's equally random) :-( Anyone else? Please? Someone? Anyone? :-) pg_diskspace_size() pg_diskusage_size() pg_media_used_size() pg_allocated_size() pg_diskspace_used() Unfortunately I think those are too generic - we also have pg_database_size() and pg_tablespace_size() for which these would work. Regards, Dave ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Dear Stephen, I still think that removing groups and having per-cluster roles is not a good idea. The better way would be to keep user/group and add per-catalog roles. There is an opportunity which is being missed, and that won't show up later. I really disagree with you here. I feel it makes much more sense to do this in stages, first user/group - roles, then roles-per-catalog, which means you can then have both per-catalog 'users' and per-catalog 'groups', if you want to limit your view to that. I don't think that having two kinds of roles (per-cluster and per-catalog) would be a practical thing from the user perspective. From the implementation point of view, two tables will be needed. If you don't create roles directly in the right scope, it will create confusion later. The two concept need to have two different names so that they can be understood. Moreover, a working per-cluster grouping was already available. Changing the role scope will be much harder than creating a role directly in the good scope. From the implementation perspective, there is more work at adding per-cluster roles and removing per-cluster group and then later try to add per-catalog roles than adding per-catalog roles directly without touching the existing group stuff. So I'm afraid that the opportunity is missed and that per-catalog role will never get in. Well, at least you look more optimistic than me;-) -- Fabien. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Occupied port warning
Tom Lane wrote: I think we could also error out if we cannot create at least one listen socket for each entry in listen_addresses (instead of at least one overall). No; that will break cases that don't need to break. Which cases would that be? If you specify a host name and it doesn't get used at all, what sense could that possibly make? I was willing to hold still for the limited check you just applied, but I do not see that making it less error-tolerant than that is a good idea at all. It will just put obstacles in the path of newbies. Not ignoring errors is one of the staples of PostgreSQL. What you are proposing here sounds entirely like a MySQL design plan. Maybe that is newbie-friendly in your mind, but I really doubt that. I agree that we do not want to force people to change kernel or system libraries. But it is not acceptable to ignore misconfigurations where a simple change of a few configuration parameters would correct the situation, as in this case: (In fact, I'm not even convinced that the limited check will survive beta. I think we'll be taking it out again, or at least reducing it to a WARNING, when the complaints start coming in. As of CVS tip, a default postmaster configuration will refuse to start if there is anything wrong with your localhost DNS setup, and we already learned that there are way too many machines where that is true.) Here, you simply change the configuration to use numeric IP addresses. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] 2PC transaction id
On Fri, 1 Jul 2005, Oliver Jowett wrote: Heikki Linnakangas wrote: branch id: Branch Identifier. Every RM involved in the global transaction is given a *different* branch id. Hm, I am confused then -- the XA spec definitely talks about enlisting multiple RMs in a single transaction branch. Can you explain? I oversimplified a bit. The TM *can* enlist multiple threads of control (= connection in JTA) to the same transaction branch. That's called tightly-coupled threads, and they should then be treated as one local transaction in the RM. The calls will look like this: conn1.start(xid1, TMNOFLAGS); ... conn2.start(xid1, TMJOIN); ... conn1.end(xid1, TMSUCCESS); ... conn2.end(xid1, TMSUCCESS); connX.prepare(xid1); connX.commit(xid1, false); conn1 and conn2 must share locks and see each others changes. They mustn't deadlock each other. The JDBC driver can implement this in a very straight-forward way by using the same physical connection for both conn1 and conn2. Note that there's only one prepare, and it can be issued using any connection. The other possibility is called loosely-coupled threads. In this case the calls look like this: conn1.start(xid1, TMNOFLAGS); ... conn2.start(xid2, TMNOFLAGS); ... conn1.end(xid1, TMSUCCESS); ... conn2.end(xid2, TMSUCCESS); ... connX.prepare(xid1); connX.prepare(xid2); connX.commit(xid1, false); connX.commit(xid2, false); xid1 and xid2 can belong to the same global transaction, but different branches. The RM doesn't need to care both branches belong to the same global transactions, xid1 and xid2 can be treated just like any random two transactions. They can deadlock each other, and they won't see each others changes before commit. This can be implemented in the JDBC driver by using two physical connections. So the example given earlier in this thread, with one transaction branch but two prepare-calls makes no sense. The RM should throw an exception if the TM calls start twice with the same XID, and TMJOIN flag is not given. One transaction branch maps in 1:1 fashion to one RM local transaction. I hope this helps... - Heikki ---(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] 2PC transaction id
Heikki Linnakangas wrote: On Fri, 1 Jul 2005, Oliver Jowett wrote: Heikki Linnakangas wrote: branch id: Branch Identifier. Every RM involved in the global transaction is given a *different* branch id. Hm, I am confused then -- the XA spec definitely talks about enlisting multiple RMs in a single transaction branch. Can you explain? I oversimplified a bit. The TM *can* enlist multiple threads of control (= connection in JTA) to the same transaction branch. That's called tightly-coupled threads, and they should then be treated as one local transaction in the RM. Ok, I understand that case. What I'm confused about is, for example, 3.3.1 in the DTP:XA spec: 3.3.1 Registration of Resource Managers Normally, a TM involves all associated RMs in a transaction branch. (The TM’s set of RM switches, described in Section 4.3 on page 21 tells the TM which RMs are associated with it.) The TM calls all these RMs with xa_start(), xa_end(), and xa_prepare (), although an RM that is not active in a branch need not participate further (see Section 2.3.2 on page 8). A technique to reduce overhead for infrequently-used RMs is discussed below. That implies it's valid (in fact, normal!) to enlist many different RMs in the same transaction branch. Am I interpreting that correctly? -O ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pl/pgsql: END verbosity [patch]
Pavel Stehule wrote: this patch allows optional using label with END and END LOOP. Ending label has only informational value, but can enhance readability large block and enhance likeness with Oracle. mainLOOP ... ... END LOOPmain; Attached is a revised version of this patch. Changes / comments: - AFAICS Oracle's syntax is actually label LOOP ... END LOOP label; i.e. the ending block label isn't enclosed in . I've adjusted the patch accordingly. - your patch broke EXIT and CONTINUE, as running the regression tests would have made clear. - yyerror() will set plpgsql_error_lineno, so you needn't do it yourself. I changed it to use ereport(ERROR) anyway, as it seems a bit more appropriate. I'm not quite happy with the error message text: ERROR: end label outer_label differs from block's label inner_label CONTEXT: compile of PL/pgSQL function end_label3 near line 6 ERROR: end label outer_label specified for unlabelled block CONTEXT: compile of PL/pgSQL function end_label4 near line 5 suggestions for improvement are welcome. BTW, I notice that some but not all the call sites of ereport(ERROR) in PL/PgSQL's gram.y set plpgsql_error_lineno. Is there a reason for this? Barring any objections, I'll apply the attached patch to CVS tomorrow. -Neil Index: doc/src/sgml/plpgsql.sgml === RCS file: /Users/neilc/local/cvs/pgsql/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.74 diff -c -r1.74 plpgsql.sgml *** doc/src/sgml/plpgsql.sgml 22 Jun 2005 01:35:02 - 1.74 --- doc/src/sgml/plpgsql.sgml 1 Jul 2005 11:43:36 - *** *** 456,462 replaceabledeclarations/replaceable /optional BEGIN replaceablestatements/replaceable ! END; /synopsis /para --- 456,462 replaceabledeclarations/replaceable /optional BEGIN replaceablestatements/replaceable ! END optional replaceablelabel/replaceable /optional; /synopsis /para *** *** 1789,1806 titleliteralLOOP//title synopsis ! optionallt;lt;replaceablelabel/replaceablegt;gt;/optional LOOP replaceablestatements/replaceable ! END LOOP; /synopsis para ! literalLOOP/ defines an unconditional loop that is repeated indefinitely ! until terminated by an literalEXIT/ or commandRETURN/command ! statement. The optional label can be used by literalEXIT/ statements in ! nested loops to specify which level of nesting should be ! terminated. /para /sect3 --- 1789,1807 titleliteralLOOP//title synopsis ! optional lt;lt;replaceablelabel/replaceablegt;gt; /optional LOOP replaceablestatements/replaceable ! END LOOP optional replaceablelabel/replaceable /optional; /synopsis para ! literalLOOP/ defines an unconditional loop that is repeated ! indefinitely until terminated by an literalEXIT/ or ! commandRETURN/command statement. The optional ! replaceablelabel/replaceable can be used by literalEXIT/ ! and literalCONTINUE/literal statements in nested loops to ! specify which loop the statement should be applied to. /para /sect3 *** *** 1920,1929 /indexterm synopsis ! optionallt;lt;replaceablelabel/replaceablegt;gt;/optional WHILE replaceableexpression/replaceable LOOP replaceablestatements/replaceable ! END LOOP; /synopsis para --- 1921,1930 /indexterm synopsis ! optional lt;lt;replaceablelabel/replaceablegt;gt; /optional WHILE replaceableexpression/replaceable LOOP replaceablestatements/replaceable ! END LOOP optional replaceablelabel/replaceable /optional; /synopsis para *** *** 1951,1960 titleliteralFOR/ (integer variant)/title synopsis ! optionallt;lt;replaceablelabel/replaceablegt;gt;/optional FOR replaceablename/replaceable IN optional REVERSE /optional replaceableexpression/replaceable .. replaceableexpression/replaceable LOOP replaceablestatements/replaceable ! END LOOP; /synopsis para --- 1952,1961 titleliteralFOR/ (integer variant)/title synopsis ! optional lt;lt;replaceablelabel/replaceablegt;gt; /optional FOR replaceablename/replaceable IN optional REVERSE /optional replaceableexpression/replaceable .. replaceableexpression/replaceable LOOP replaceablestatements/replaceable ! END LOOP optional replaceablelabal/replaceable /optional; /synopsis para *** *** 1997,2006 the results of a query and manipulate that data accordingly. The syntax is: synopsis ! optionallt;lt;replaceablelabel/replaceablegt;gt;/optional FOR replaceablerecord_or_row/replaceable IN replaceablequery/replaceable LOOP replaceablestatements/replaceable ! END LOOP; /synopsis The record or row variable is successively assigned each row
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Fabien, * Fabien COELHO ([EMAIL PROTECTED]) wrote: I really disagree with you here. I feel it makes much more sense to do this in stages, first user/group - roles, then roles-per-catalog, which means you can then have both per-catalog 'users' and per-catalog 'groups', if you want to limit your view to that. I don't think that having two kinds of roles (per-cluster and per-catalog) would be a practical thing from the user perspective. From the implementation point of view, two tables will be needed. If you don't create roles directly in the right scope, it will create confusion later. The two concept need to have two different names so that they can be understood. Moreover, a working per-cluster grouping was already available. Changing the role scope will be much harder than creating a role directly in the good scope. The two concepts certainly don't need different names to distinguish them. A simple distinction such as superusers are per-cluster and all other roles are not would be sufficient. I expect that's the kind of thing people would be looking for anyway. From the implementation perspective, there is more work at adding per-cluster roles and removing per-cluster group and then later try to add per-catalog roles than adding per-catalog roles directly without touching the existing group stuff. Having just spent a fair bit of time on the implementation, I have to disagree with you here. So I'm afraid that the opportunity is missed and that per-catalog role will never get in. Well, at least you look more optimistic than me;-) Honestly, this comes across to me the same as saying that because we have databases we'd never have schemas. Please outline exactly what you're really looking for. Let's drop the idea of per-cluster users/groups/roles/whatever and instead consider what specific capabilities you're looking for. We can then decide if those capabilities are best provided through per-catalog roles, if they're already covered with the existing framework, or if there's some other, better solution. Thanks, Stephen signature.asc Description: Digital signature
[HACKERS] How to let more than one sessions work for same global transaction ?
In my application server, one db connection per thread. client may start a galobal transaction ,immediacy or indirect associate to a lot of app servers and more and more threads (db connections). ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Occupied port warning
Peter Eisentraut [EMAIL PROTECTED] writes: Not ignoring errors is one of the staples of PostgreSQL. What you are proposing here sounds entirely like a MySQL design plan. Maybe that is newbie-friendly in your mind, but I really doubt that. I agree that we do not want to force people to change kernel or system libraries. But it is not acceptable to ignore misconfigurations where a simple change of a few configuration parameters would correct the situation, My fundamental objection here is that I think you will be making error cases out of situations where a kernel update is the only solution; in particular the ones stemming from kernel and libc not being on the same page about whether IPv6 is supported. We must likewise not assume that a would-be Postgres user is in a position to fix his DNS infrastructure. Treating these problems as warnings instead of hard errors is hardly equivalent to risking data loss --- all it says is that you won't be able to connect from certain places until you fix it, which is certainly not worse than being unable to connect from anyplace because you cannot get the postmaster to start. 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] [PATCHES] Users/Groups - Roles
Fabien COELHO [EMAIL PROTECTED] writes: Moreover, a working per-cluster grouping was already available. Only for sufficiently small values of working. The lack of ability for groups to contain other groups and for groups to be the direct owners of objects were both pretty serious restrictions, which are now fixed. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] pl/pgsql: END verbosity [patch]
Neil Conway [EMAIL PROTECTED] writes: BTW, I notice that some but not all the call sites of ereport(ERROR) in PL/PgSQL's gram.y set plpgsql_error_lineno. Is there a reason for this? Without looking at the code, I think it may be that you only need to set the variable if you want the error to point someplace different than the last lno nonterminal. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TODO item done
Thanks. Updated. --- Christopher Kings-Lynne wrote: Bruce - this is done: o Add dumping and restoring of LOB comments Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Dear Stephen, Please outline exactly what you're really looking for. Let's drop the idea of per-cluster users/groups/roles/whatever and instead consider what specific capabilities you're looking for. I think from a conceptual point of view that the ability to manage permissions at the database level (per-catalog role) is a good thing (tm) for everybody. The privilege management is about a catalog, so it better to have it in the catalog. My personnal uses are two fold : - for teaching purposes, I can give every student his/her database and have her/him practice db privileges independently. They can create their own roles and do whatever with them... - for administration purposes, different databases have different requirements, and maybe different kind of role readonly, modifiable, fulladmin which could be attributed independently in each database. Basically, I want to be able to delegate to someone the right management for one database, including the creation of roles and so on, without interference from one database to another. So as to illustrate what I call an interference: say you have 2 databases which where on 2 clusters and you want to transfert them into the same cluster. If the same role name was used in both database, you may have interferences, people being given rights on one database and applying them to the other if they can connect to it. We can then decide if those capabilities are best provided through per-catalog roles, if they're already covered with the existing framework, or if there's some other, better solution. One inelegant solution is to prefix the role names with the database name, but that is just a discipline and cannot be inforced. I think we can do better. If you're right that having both per-catalog and per-cluster role with some flag would be accepted into postgresql, then that will be fine with me. I'll just argue for the per-catalog roles to be the default. Thanks for all your answers, have a nice day, -- Fabien. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Fabien, * Fabien COELHO ([EMAIL PROTECTED]) wrote: Please outline exactly what you're really looking for. Let's drop the idea of per-cluster users/groups/roles/whatever and instead consider what specific capabilities you're looking for. I think from a conceptual point of view that the ability to manage permissions at the database level (per-catalog role) is a good thing (tm) for everybody. The privilege management is about a catalog, so it better to have it in the catalog. Permissions are at a number of levels already: cluster, database, schema, table. Permissions at different levels hasn't got anything to do w/ per-catalog roles. My personnal uses are two fold : - for teaching purposes, I can give every student his/her database and have her/him practice db privileges independently. They can create their own roles and do whatever with them... Right, this can be done now. When you set up each student with his/her database create two roles: Role 1: Has createrole permissions and admin permissions on role 2. Role 2: Add into pg_hba.conf as a role with permission to access the db. When a student wants to create another role with access to the db they just have to log in as Role 1 and create the role and add that role to Role 2. That role can then log in to their database. - for administration purposes, different databases have different requirements, and maybe different kind of role readonly, modifiable, fulladmin which could be attributed independently in each database. I don't see how this has got anything to do w/ per-catalog roles either... Basically, I want to be able to delegate to someone the right management for one database, including the creation of roles and so on, without interference from one database to another. That's what createrole should let you do w/ current CVS HEAD. Don't thank me though, Tom did the heavy lifting wrt that. So as to illustrate what I call an interference: say you have 2 databases which where on 2 clusters and you want to transfert them into the same cluster. If the same role name was used in both database, you may have interferences, people being given rights on one database and applying them to the other if they can connect to it. Ah-hah, now here's something we can talk about: namespace collision. That's an issue which per-catalog roles would help with. I'm not so sure that'd make administration *easier* though, I'd think it'd make it harder, honestly, at least in the case where you've got multiple databases that you want to give a certain person access to. We can then decide if those capabilities are best provided through per-catalog roles, if they're already covered with the existing framework, or if there's some other, better solution. One inelegant solution is to prefix the role names with the database name, but that is just a discipline and cannot be inforced. I think we can do better. That's essentially all you're really asking for though, and is something which could be done in the current framework. It'd probably be more elegant to have a per-catalog pg_authid though. As long as we can identify the database trying to be connected to at the same time or before we get the username I don't think this would be too hard to support. Perhaps for 8.2 this could be done, though I'm still not convinced it's a definite win. If you're right that having both per-catalog and per-cluster role with some flag would be accepted into postgresql, then that will be fine with me. I'll just argue for the per-catalog roles to be the default. It'd really be a create-role option, 'create role abc GLOBAL' or some such. The resolution would then be check the per-catalog pg_authid first and if nothing is found there go to the system-wide pg_authid. That's kind of ugly, of course, and could slow things down for people who prefer to have global roles instead of per-catalog roles. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] Users/Groups - Roles
The privilege management is about a catalog, so it better to have it in the catalog. Permissions are at a number of levels already: cluster, database, schema, table. Permissions at different levels hasn't got anything to do w/ per-catalog roles. Sorry for not being very clear. I see two main levels: (1) the connection which is managed in pg_hba.conf. It is a sysadmin concern, where you decide who will be able to get into your system. This issue is *not* addressed by the SQL specs. (2) once you're connected to a catalog, the ability to adjust/organize privileges for accessing data within this catalog. This is a dbadmin concern, where you decide for a given user which can access the database, what data should be readable. This issue is addressed by the SQL specs. If you think unix, root decides the first, and each user decides the second for the files it owns. - for teaching purposes [...] Right, this can be done now. There is the namespace collision issue, and although I might grant a student the privilege to create simple roles, I would not allow them to create new users for a basic practice;-) - for administration purposes, different databases have different requirements, and maybe different kind of role readonly, modifiable, fulladmin which could be attributed independently in each database. I don't see how this has got anything to do w/ per-catalog roles either... Because of namespace collision. That what I mean by independently above. So as to illustrate what I call an interference [...] Ah-hah, now here's something we can talk about: namespace collision. That is just what I meant in the last 10 mails when I mention per-catalog roles as better than per-cluster roles. I just did not put in the right keywords to make myself clear:-( Sigh. That's an issue which per-catalog roles would help with. Indeed. I'm not so sure that'd make administration *easier* though, I'd think it'd make it harder, honestly, at least in the case where you've got multiple databases that you want to give a certain person access to. Sure, grouping at the cluster level is also useful. [...] As long as we can identify the database trying to be connected to at the same time or before we get the username I don't think this would be too hard to support. Yet, but this is not what I'm looking for. I want the grouping per-catalog, but the user (or connectable-role now) is fine enough for me at the cluster level. Perhaps for 8.2 this could be done, though I'm still not convinced it's a definite win. For the user per-catalog part, I agree with you. If you're right that having both per-catalog and per-cluster role with some flag would be accepted into postgresql, then that will be fine with me. I'll just argue for the per-catalog roles to be the default. It'd really be a create-role option, 'create role abc GLOBAL' There is also a problem of namespace collision if you have both global and local roles. When I create a global role, pg cannot check that this name is not used in ANY of the databases. If you can have two admin roles, one global and one local... I doubt Tom will let pass such an improvement. Also, I don't feel the upward compatibility constraint well with per-catalog roles once per-cluster roles are in place. or some such. The resolution would then be check the per-catalog pg_authid first and if nothing is found there go to the system-wide pg_authid. That's kind of ugly, of course, and could slow things down for people who prefer to have global roles instead of per-catalog roles. If the per-catalog role is empty, I guess an obvious optimisation could be implemented;-) Good night, -- Fabien. ---(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] Backend working directories and absolute file paths
Tom Lane wrote: You'd have to talk to your kernel provider about that one; we don't have any direct control over where or even whether core dumps occur. Apache used to have (still has?) a way to configure that. I think they must have done the chdir() in the SIGSEGV handler. Not that I'm proposing we do that... ;-) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Stupid question, but how do roles relate to our existing groups? --- Fabien COELHO wrote: The privilege management is about a catalog, so it better to have it in the catalog. Permissions are at a number of levels already: cluster, database, schema, table. Permissions at different levels hasn't got anything to do w/ per-catalog roles. Sorry for not being very clear. I see two main levels: (1) the connection which is managed in pg_hba.conf. It is a sysadmin concern, where you decide who will be able to get into your system. This issue is *not* addressed by the SQL specs. (2) once you're connected to a catalog, the ability to adjust/organize privileges for accessing data within this catalog. This is a dbadmin concern, where you decide for a given user which can access the database, what data should be readable. This issue is addressed by the SQL specs. If you think unix, root decides the first, and each user decides the second for the files it owns. - for teaching purposes [...] Right, this can be done now. There is the namespace collision issue, and although I might grant a student the privilege to create simple roles, I would not allow them to create new users for a basic practice;-) - for administration purposes, different databases have different requirements, and maybe different kind of role readonly, modifiable, fulladmin which could be attributed independently in each database. I don't see how this has got anything to do w/ per-catalog roles either... Because of namespace collision. That what I mean by independently above. So as to illustrate what I call an interference [...] Ah-hah, now here's something we can talk about: namespace collision. That is just what I meant in the last 10 mails when I mention per-catalog roles as better than per-cluster roles. I just did not put in the right keywords to make myself clear:-( Sigh. That's an issue which per-catalog roles would help with. Indeed. I'm not so sure that'd make administration *easier* though, I'd think it'd make it harder, honestly, at least in the case where you've got multiple databases that you want to give a certain person access to. Sure, grouping at the cluster level is also useful. [...] As long as we can identify the database trying to be connected to at the same time or before we get the username I don't think this would be too hard to support. Yet, but this is not what I'm looking for. I want the grouping per-catalog, but the user (or connectable-role now) is fine enough for me at the cluster level. Perhaps for 8.2 this could be done, though I'm still not convinced it's a definite win. For the user per-catalog part, I agree with you. If you're right that having both per-catalog and per-cluster role with some flag would be accepted into postgresql, then that will be fine with me. I'll just argue for the per-catalog roles to be the default. It'd really be a create-role option, 'create role abc GLOBAL' There is also a problem of namespace collision if you have both global and local roles. When I create a global role, pg cannot check that this name is not used in ANY of the databases. If you can have two admin roles, one global and one local... I doubt Tom will let pass such an improvement. Also, I don't feel the upward compatibility constraint well with per-catalog roles once per-cluster roles are in place. or some such. The resolution would then be check the per-catalog pg_authid first and if nothing is found there go to the system-wide pg_authid. That's kind of ugly, of course, and could slow things down for people who prefer to have global roles instead of per-catalog roles. If the per-catalog role is empty, I guess an obvious optimisation could be implemented;-) Good night, -- Fabien. ---(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 -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 7: don't forget to increase your free space map settings
Re: [HACKERS] 2PC transaction id
branch id: Branch Identifier. Every RM involved in the global transaction is given a *different* branch id. Hm, I am confused then -- the XA spec definitely talks about enlisting multiple RMs in a single transaction branch. Can you explain? I oversimplified a bit. The TM *can* enlist multiple threads of control (= connection in JTA) to the same transaction branch. That's called tightly-coupled threads, and they should then be treated as one local transaction in the RM. The calls will look like this: conn1.start(xid1, TMNOFLAGS); ... conn2.start(xid1, TMJOIN); ... conn1.end(xid1, TMSUCCESS); ... conn2.end(xid1, TMSUCCESS); connX.prepare(xid1); connX.commit(xid1, false); conn1 and conn2 must share locks and see each others changes. They mustn't deadlock each other. The JDBC driver can implement this in a very straight-forward way by using the same physical connection for both conn1 and conn2. Note that there's only one prepare, and it can be issued using any connection. In your example above couldn't conn1 and conn2 be running in two different JVMs? And thus your statement that 'the JDBC driver can implement this in a very straight-forward way by using the same physical connection' would not be true. I can't see a way for two JVMs (possibly on different client machines even) to share the same physical connection. --Barry ---(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] [PATCHES] Users/Groups - Roles
* Bruce Momjian (pgman@candle.pha.pa.us) wrote: Stupid question, but how do roles relate to our existing groups? Uhhh. There are no longer groups, they've been replaced with roles (which can have members). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Thanks, TODO updated. We still support CREATE GROUP? It translates to roles? --- Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Stupid question, but how do roles relate to our existing groups? As committed, roles subsume both users and groups: a role that permits login (rolcanlogin) acts as a user, and a role that has members is a group. It is possible for the same role to do both things, though I'm not sure that it's good security policy to set up a role that way. The advantage over what we had is exactly that there isn't any distinction, and thus groups can do everything users can and vice versa: * groups can own objects * groups can contain other groups (we forbid loops though) Also there is a notion of admin option for groups, which is like grant option for privileges: you can designate certain members of a group as being able to grant ownership in that group to others, without having to make them superusers. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Bruce Momjian pgman@candle.pha.pa.us writes: Stupid question, but how do roles relate to our existing groups? As committed, roles subsume both users and groups: a role that permits login (rolcanlogin) acts as a user, and a role that has members is a group. It is possible for the same role to do both things, though I'm not sure that it's good security policy to set up a role that way. The advantage over what we had is exactly that there isn't any distinction, and thus groups can do everything users can and vice versa: * groups can own objects * groups can contain other groups (we forbid loops though) Also there is a notion of admin option for groups, which is like grant option for privileges: you can designate certain members of a group as being able to grant ownership in that group to others, without having to make them superusers. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Users/Groups - Roles
* Bruce Momjian (pgman@candle.pha.pa.us) wrote: Thanks, TODO updated. We still support CREATE GROUP? It translates to roles? Yes, CREATE USER too. Stephen Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Stupid question, but how do roles relate to our existing groups? As committed, roles subsume both users and groups: a role that permits login (rolcanlogin) acts as a user, and a role that has members is a group. It is possible for the same role to do both things, though I'm not sure that it's good security policy to set up a role that way. The advantage over what we had is exactly that there isn't any distinction, and thus groups can do everything users can and vice versa: * groups can own objects * groups can contain other groups (we forbid loops though) Also there is a notion of admin option for groups, which is like grant option for privileges: you can designate certain members of a group as being able to grant ownership in that group to others, without having to make them superusers. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 signature.asc Description: Digital signature
Re: [HACKERS] 2PC transaction id
On Fri, 1 Jul 2005, Oliver Jowett wrote: What I'm confused about is, for example, 3.3.1 in the DTP:XA spec: 3.3.1 Registration of Resource Managers Normally, a TM involves all associated RMs in a transaction branch. (The TMs set of RM switches, described in Section 4.3 on page 21 tells the TM which RMs are associated with it.) The TM calls all these RMs with xa_start(), xa_end(), and xa_prepare (), although an RM that is not active in a branch need not participate further (see Section 2.3.2 on page 8). A technique to reduce overhead for infrequently-used RMs is discussed below. That implies it's valid (in fact, normal!) to enlist many different RMs in the same transaction branch. Am I interpreting that correctly? I see. No, I don't think that's the correct interpretation, though now that you point it out, that paragraph is a bit confusing. What it means, is that the TM always calls xa_start(), xa_end() and xa_prepare() for a RM, even if the transaction doesn't actually have any work to do for the RM. It has to be like that in the XA world, because the TM doesn't know which RMs the application really uses in the transaction. Chapter 3.3.1 talks about dynamic registration. In that scheme, the RM registers itself to the TM when the application calls the RM for the first time in the transaction. That's an optimization to avoid the overhead of the start/end/prepare cycle for RMs that aren't really involved. JTA works differently from XA on this matter. In JTA, the application server tells the TM which RMs are involved in the transaction, so the XA dynamic registration has not been included in JTA. Disclaimer: I've never used an XA implementation, and I have only little experience with JTA. - Heikki ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Regression test plpgsql vs. rangefuncs conflict
The regression test files plpgsql and rangefuncs both create a dup()
function, and as they are run in parallel this just caused an error for
me, as attached. This just happened once for me, but it still ought to
be corrected.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
*** ./expected/plpgsql.out Thu Jun 30 18:32:22 2005
--- ./results/plpgsql.out Fri Jul 1 19:39:51 2005
***
*** 1855,1860
--- 1855,1861
(1 row)
drop function dup(anyelement);
+ ERROR: function dup(anyelement) does not exist
--
-- test PERFORM
--
==
*** ./expected/rangefuncs.out Mon May 30 17:35:15 2005
--- ./results/rangefuncs.out Fri Jul 1 19:39:48 2005
***
*** 493,498
--- 493,499
--
CREATE FUNCTION dup (f1 anyelement, f2 out anyelement, f3 out anyarray)
AS 'select $1, array[$1,$1]' LANGUAGE sql;
+ ERROR: function dup already exists with same argument types
SELECT dup(22);
dup
***
*** 508,514
(1 row)
SELECT * FROM dup('xyz'::text);
! f2 |f3
-+---
xyz | {xyz,xyz}
(1 row)
--- 509,515
(1 row)
SELECT * FROM dup('xyz'::text);
! j | k
-+---
xyz | {xyz,xyz}
(1 row)
***
*** 516,521
--- 517,525
-- equivalent specification
CREATE OR REPLACE FUNCTION dup (inout f2 anyelement, out f3 anyarray)
AS 'select $1, array[$1,$1]' LANGUAGE sql;
+ ERROR: cannot change return type of existing function
+ DETAIL: Row type defined by OUT parameters is different.
+ HINT: Use DROP FUNCTION first.
SELECT dup(22);
dup
==
---(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] 2PC transaction id
Heikki Linnakangas wrote: On Fri, 1 Jul 2005, Oliver Jowett wrote: PS: noticed in passing: psql's help doesn't seem to know about the 2PC command syntax yet. True. Should we add support for it? 2PC is not something you normally do interactively... Yes, we should add psql support for it. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 2PC transaction id
On Fri, 1 Jul 2005, Oliver Jowett wrote: PS: noticed in passing: psql's help doesn't seem to know about the 2PC command syntax yet. True. Should we add support for it? 2PC is not something you normally do interactively... - Heikki ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Autotools update
As previously announced I have committed the update to Autoconf 2.59 as well as updates of mkinstalldirs, install-sh, as well as config.guess and config.sub. This shouldn't have any immediate functional impact, except that you can now turn off the autom4te.cache directory (using ~/.autom4te.cfg). Also, someone forgot to update pg_config.h.in after the Kerberos 4 removal patch (I think), so I fixed that, too. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Autotools update
Peter Eisentraut [EMAIL PROTECTED] writes: As previously announced I have committed the update to Autoconf 2.59 as well as updates of mkinstalldirs, install-sh, as well as config.guess and config.sub. Are the correct tools also installed on cvs.postgresql.org (ie, will the right things happen when Marc tries to build a tarball)? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 2PC transaction id
Heikki Linnakangas [EMAIL PROTECTED] writes: On Fri, 1 Jul 2005, Oliver Jowett wrote: PS: noticed in passing: psql's help doesn't seem to know about the 2PC command syntax yet. True. Really? regression=# \h commit prepared Command: COMMIT PREPARED Description: commit a transaction that was earlier prepared for two-phase commit Syntax: COMMIT PREPARED transaction_id regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Autotools update
Tom Lane wrote: Are the correct tools also installed on cvs.postgresql.org (ie, will the right things happen when Marc tries to build a tarball)? I don't see any autoconf installed there, so the wrong thing would happen either way. :-) But gnu-autoconf-2.59 is in the FreeBSD ports, if it's required. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Users/Groups - Roles
On Friday 01 July 2005 13:07, Stephen Frost wrote:
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Thanks, TODO updated. We still support CREATE GROUP? It translates to
roles?
Yes,
snip
However On Friday 01 July 2005 13:02, Stephen Frost wrote:
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Stupid question, but how do roles relate to our existing groups?
Uhhh. There are no longer groups, they've been replaced with roles
(which can have members).
Was following this conversation up till now, because these two statement seem
to contradict each other. Do we really support groups still, are is CREATE
GROUP now syntactical sugar for some for of CREATE ROLE.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Robert Treat [EMAIL PROTECTED] writes: Was following this conversation up till now, because these two statement seem to contradict each other. Do we really support groups still, are is CREATE GROUP now syntactical sugar for some for of CREATE ROLE. CREATE GROUP and CREATE USER are both now syntactic sugar for CREATE ROLE. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Users/Groups - Roles
* Robert Treat ([EMAIL PROTECTED]) wrote: On Friday 01 July 2005 13:07, Stephen Frost wrote: However On Friday 01 July 2005 13:02, Stephen Frost wrote: * Bruce Momjian (pgman@candle.pha.pa.us) wrote: Stupid question, but how do roles relate to our existing groups? Uhhh. There are no longer groups, they've been replaced with roles (which can have members). Was following this conversation up till now, because these two statement seem to contradict each other. Do we really support groups still, are is CREATE GROUP now syntactical sugar for some for of CREATE ROLE. CREATE GROUP just does a CREATE ROLE now, yeah. You can check gram.y for the details if you'd like. We do still support \du and \dg (pg_users and pg_groups respectively, iirc) for backwards compat. and to help folks get used to the new stuff. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Regression test plpgsql vs. rangefuncs conflict
Peter Eisentraut [EMAIL PROTECTED] writes: The regression test files plpgsql and rangefuncs both create a dup() function, and as they are run in parallel this just caused an error for me, as attached. This just happened once for me, but it still ought to be corrected. Wups, that's my fault. Fixed. 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] [PATCHES] Users/Groups - Roles
Fabien COELHO [EMAIL PROTECTED] writes: Right, this can be done now. There is the namespace collision issue, and although I might grant a student the privilege to create simple roles, I would not allow them to create new users for a basic practice;-) Why not? With the setup Stephen suggests, they could create only new users that could only get into their own database (since they'd not be able to grant connect rights to other databases). We probably need to think a bit harder about the meaning of CREATEROLE though. Right now it gives free license not only to create roles but to alter any property of existing roles. This seems appropriate if you think of it as a safer form of superuser, which is how I was thinking of it. It would be too powerful for Fabien's situation though. 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] HEAD: create index failure: firefly on buildfarm
My UnixWare 7.1.4 box started flunking with it's latest run.. See the firefly entry on the buildfarm. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Users/Groups - Roles
* Tom Lane ([EMAIL PROTECTED]) wrote: Fabien COELHO [EMAIL PROTECTED] writes: Right, this can be done now. There is the namespace collision issue, and although I might grant a student the privilege to create simple roles, I would not allow them to create new users for a basic practice;-) Why not? With the setup Stephen suggests, they could create only new users that could only get into their own database (since they'd not be able to grant connect rights to other databases). I'm curious why not too... One issue I can think of is that alter role ... rename, etc could be a problem. We probably need to think a bit harder about the meaning of CREATEROLE though. Right now it gives free license not only to create roles but to alter any property of existing roles. This seems appropriate if you think of it as a safer form of superuser, which is how I was thinking of it. It would be too powerful for Fabien's situation though. Well, what about it makes it 'too powerful'? I think that's pretty much the same question you're asking Fabien above. I agree that only certain properties should probably be modifiable though, one inparticular that comes to mind is 'LOGIN'; I can see why you might want to allow only roles which can't log in to be creatable by a given role. It strikes me that it'd make some sense to have independent grant control over each of the fields in pg_authid. It would also make sense to limit the power of alter role to certain roles based on who they were created by (superuser vs. createrole). It seems we probably need at least an association to either catalog or creator for each role which could then be used to limit alter role commands. catalog probably makes more sense in the long run, creator would be easier in the short-term. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] Users/Groups - Roles
Stephen Frost [EMAIL PROTECTED] writes: * Tom Lane ([EMAIL PROTECTED]) wrote: We probably need to think a bit harder about the meaning of CREATEROLE though. Right now it gives free license not only to create roles but to alter any property of existing roles. This seems appropriate if you think of it as a safer form of superuser, which is how I was thinking of it. It would be too powerful for Fabien's situation though. Well, what about it makes it 'too powerful'? The fact that you could alter roles that (in some sense) don't belong to you. In particular you could allow yourself into other people's databases, if you can alter the roles that they are using to define who can connect to those databases. Or cause denials of service by revoking other people's memberships in those roles. On the other hand, CREATEROLE as-is does exactly what it was intended to do, namely let the DBA do all normal admin maintenance of users/groups without taking the risks involved in doing stuff as superuser. If we restrict it more, then we'll be back to the situation where there are routine manual admin tasks that require superuserdom. So on reflection I don't think we should restrict it. If we need a more restrictive feature, then we need a different feature. I'm of the opinion that it's too late to do much about Fabien's use-case in this devel cycle. We could possibly have designed something rational if it had been brought up earlier in the discussion of roles (which I remind you has been going on for months). But now it's too late to do anything that wouldn't be a kluge, and probably a kluge we'd regret later. Possibly for 8.2 we could invent a notion of roles having owners. Offhand I don't see any harm in letting non-CREATEROLE users create non-login roles, and manipulate the membership of roles they have created (or that have been assigned to them by a superuser). On the other hand, it could be that the WITH ADMIN OPTION feature is already sufficient for this. This really needs some thought ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Open items
On Thu, Jun 30, 2005 at 10:11:56AM -0400, Rod Taylor wrote: On Thu, 2005-06-30 at 23:02 +0900, Satoshi Nagayasu wrote: The TODO item is about counting all temporary files, not sorts in particular. Or at least that's what I thought it meant. If the DBA have to improve the performance, DBA will need to know about: - Which SQL generate a disk sort? Good point. An EXPLAIN ANALYZE note about the disk usage for the sort would be really nice. Even nicer would be a way to log queries that generate on-disk sorts. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] rtree_gist merge breaks regression
A number of buildfarm platforms appear to be failing regression tests from ordering differences due to the rtree_gist merge. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] rtree_gist merge breaks regression
Andrew Dunstan [EMAIL PROTECTED] writes: A number of buildfarm platforms appear to be failing regression tests from ordering differences due to the rtree_gist merge. Fixed, thanks. BTW, could we get the owner of echidna/herring (I assume these are the same machine) to clean out the bogus /tmp/.s.PGSQL.65432.lock file that has been breaking its build for a couple weeks now? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] rtree_gist merge breaks regression
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: A number of buildfarm platforms appear to be failing regression tests from ordering differences due to the rtree_gist merge. Fixed, thanks. BTW, could we get the owner of echidna/herring (I assume these are the same machine) to clean out the bogus /tmp/.s.PGSQL.65432.lock file that has been breaking its build for a couple weeks now? I have forwarded this to him. Also note that log, history and members pages on the buildfarm web now contain owner email addresses in (what I hope is a) non-harvestable form. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 2PC transaction id
Tom Lane wrote: regression=# \h commit prepared Command: COMMIT PREPARED Description: commit a transaction that was earlier prepared for two-phase commit Syntax: COMMIT PREPARED transaction_id Ah, I was looking under '\h commit', '\h prepare' etc. -O ---(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] 2PC transaction id
Heikki Linnakangas wrote: On Fri, 1 Jul 2005, Oliver Jowett wrote: That implies it's valid (in fact, normal!) to enlist many different RMs in the same transaction branch. Am I interpreting that correctly? I see. No, I don't think that's the correct interpretation, though now that you point it out, that paragraph is a bit confusing. What it means, is that the TM always calls xa_start(), xa_end() and xa_prepare() for a RM, even if the transaction doesn't actually have any work to do for the RM. It has to be like that in the XA world, because the TM doesn't know which RMs the application really uses in the transaction. Sorry to keep beating on this, but I still don't see where the spec says that you must have only one RM per transaction branch. 2.2.6 says: 2.2.6 Transaction Branches A global transaction has one or more transaction branches (or branches). A branch is a part of the work in support of a global transaction for which the TM and the RM engage in a separate but coordinated transaction commitment protocol (see Section 2.3 on page 8). Each of the RM’s internal units of work in support of a global transaction is part of exactly one branch. A global transaction might have more than one branch when, for example, the AP uses multiple processes or is involved in the same global transaction by multiple remote APs. So it seems to me that branches are intended to allow independent processes / APs to each have an independent set of tightly coupled threads (as all work on a particular branch is tightly-coupled). There's no mention of having only one RM per branch, which I'd expect to see here if it was a requirement. One implication of the second paragraph is that a single-threaded AP can use a single transaction branch for all the work it does. Disclaimer: I've never used an XA implementation, and I have only little experience with JTA. Mostly the same here. It'd be useful to get input from someone who's actually written XA code.. -O ---(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] Autotools update
On Fri, 1 Jul 2005, Peter Eisentraut wrote: Tom Lane wrote: Are the correct tools also installed on cvs.postgresql.org (ie, will the right things happen when Marc tries to build a tarball)? I don't see any autoconf installed there, so the wrong thing would happen either way. :-) But gnu-autoconf-2.59 is in the FreeBSD ports, if it's required. Pick your version: # ls -lt /usr/local/bin/autoconf* -r-xr-xr-x 1 root wheel 7672 Aug 22 2004 /usr/local/bin/autoconf259 -r-xr-xr-x 1 root wheel 6194 Aug 22 2004 /usr/local/bin/autoconf253 -rwxr-xr-x 1 root wheel 5007 Jul 27 2003 /usr/local/bin/autoconf213 But, we only run those when modifying configure.in and such, and not as part of any scripts ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
