[HACKERS] how to link an external lib on Windows
Hi, I build PG on VS2005, which files should I change to use a external lib in my own contrib, for example, Berkeley DB 4.8.26? Until now, I have tried the following 2 ways, but both failed. 1. Add the target include and lib 1). src/tools/msvc/config.pl add a new line: db48='C:\Program Files\Oracle\Berkeley DB 4.8.26' 2). src/Makefile.global.in Add a new line after line 435 LIBS := -lpgport $(LIBS) (maybe not exactly same with different versions): LIBS := -ldb48 $(LIBS) 3). contrib/mycontrib/Makefile SHLIB_LINK += $(filter -ldb48, ($LIBS)) Then I build DEBUG in Visual Studio 2005 Command Prompt, it reports db.h not found. 2. The first error report shows that the include file is not accessed I changed the congiture option --with-libxml to yes, and add the files of include and lib under Berkeley DB 4.8.26 to libxml folder. When I build, it reports: fatal error LNK1120: 2 unresolved externals Then I check the single project on VS2005, there is no libdb48.lib in the Linker input, after I added BDB_DIR\lib\libdb48.lib to it. It build successfully. But I want to build the whole PG source with mycontrib, Had someone ever encounter a problem like this? Thanks~ Best Regards Chaoyong Wang _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969
Re: [HACKERS] C libpq frontend library fetchsize
Robert Haas wrote: This seems pretty reasonable to me, especially considering that JDBC is apparently already doing it. I suppose there will always be projects that want to reimplement the backend protocol so that they can be pure some-language, but chipping away at the list of other reasons why someone might not want to use libpq still seems like a good idea. ...Robert Hello Robert, Thank you for your support, but am unsure if it is wise to put time in it due to the other reactions. regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: access control jails (and introduction as aspiring GSoC student)
Joseph Adams wrote: Hello, I'm Joey Adams, and I'm interested in applying for Google Summer of Code to work on PostgreSQL. I'm a former GSoC student (I worked on CCAN last year), and a strong C programmer, though I am still new to working with large, established communities. I apologize if this is the wrong place to send GSoC student introductions. Hi Joey, you're in the right place! * Views only apply to SELECTs Views can be made updateable by defining suitable rules for them, that is usually the way people solve this problem. See chapters http://www.postgresql.org/docs/8.4/interactive/rules-views.html and http://www.postgresql.org/docs/8.4/interactive/rules-update.html in the user manual. You should also take a look at Veil (http://veil.projects.postgresql.org/), which uses views to implement something that sounds much like what you're proposing. You should also be aware of an issue with this approach: http://archives.postgresql.org/message-id/4ae02df0.40...@enterprisedb.com. Some ideas on plugging that hole were discussed, but unfortunately there was no clear consensus and no progress since. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] how to link an external lib on Windows
2010/3/22 chaoyong wang catcher_w...@hotmail.com Hi, I build PG on VS2005, which files should I change to use a external lib in my own contrib, for example, Berkeley DB 4.8.26? Until now, I have tried the following 2 ways, but both failed. 1. Add the target include and lib 1). src/tools/msvc/config.pl add a new line: db48='C:\Program Files\Oracle\Berkeley DB 4.8.26' 2). src/Makefile.global.in Add a new line after line 435 LIBS := -lpgport $(LIBS) (maybe not exactly same with different versions): LIBS := -ldb48 $(LIBS) 3). contrib/mycontrib/Makefile SHLIB_LINK += $(filter -ldb48, ($LIBS)) Then I build DEBUG in Visual Studio 2005 Command Prompt, it reports db.h not found. 2. The first error report shows that the include file is not accessed I changed the congiture option --with-libxml to yes, and add the files of include and lib under Berkeley DB 4.8.26 to libxml folder. When I build, it reports: fatal error LNK1120: 2 unresolved externals Then I check the single project on VS2005, there is no libdb48.lib in the Linker input, after I added BDB_DIR\lib\libdb48.lib to it. It build successfully. But I want to build the whole PG source with mycontrib, Had someone ever encounter a problem like this? Thanks~ Makefile and Makefile.global aren't used when building with MSVC. You probably want to edit src/tools/msvc/Mkvcbuild.pm, specifically you are probably looking for $contrib_extrainclude and $contrib_extralibs. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
[HACKERS] Updated Turkish stopwords list for Tsearch2
Hi, Attached is updated Turkish stopword list for Tsearch2, against 8.4 and HEAD. Please apply. Regards, -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz Index: src/backend/snowball/stopwords/turkish.stop === RCS file: /projects/cvsroot/pgsql/src/backend/snowball/stopwords/turkish.stop,v retrieving revision 1.1 diff -u -r1.1 turkish.stop --- src/backend/snowball/stopwords/turkish.stop 7 Sep 2007 14:46:43 - 1.1 +++ src/backend/snowball/stopwords/turkish.stop 22 Mar 2010 12:20:33 - @@ -1,53 +1,224 @@ +a acaba +altı ama +ancak +artık +asla aslında az +b +bana +bazen bazı +bazıları +bazısı belki +ben +beni +benim +beş +bile +bir +birçoğu +birçok +birçokları biri +birisi birkaç +birkaçı birşey +birşeyi biz +bize +bizi +bizim +böyle +böylece bu +buna +bunda +bundan +bunu +bunun +burada +bütün +c +ç +çoğu +çoğuna +çoğunu çok çünkü +d da daha de -defa +değil +demek +diğer +diğeri +diğerleri diye -eğer +dokuz +dolayı +dört +e +elbette en +f +fakat +falan +felan +filan +g +gene gibi +ğ +h +hâlâ +hangi +hangisi +hani +hatta hem +henüz hep hepsi +hepsine +hepsini her +her biri +herkes +herkese +herkesi hiç +hiç kimse +hiçbiri +hiçbirine +hiçbirini +ı +i için +içinde +iki ile ise -kez +işte +j +k +kaç +kadar +kendi +kendine +kendini ki kim +kime +kimi +kimin +kimisi +l +m +madem mı +mı +mi +mu mu mü +mü +n nasıl ne +ne kadar +ne zaman neden +nedir nerde nerede +nereden nereye +nesi +neyse niçin niye o -sanki -şey +on +ona +ondan +onlar +onlara +onlardan +onların +onların +onu +onun +orada +oysa +oysaki +ö +öbürü +ön +önce +ötürü +öyle +p +r +rağmen +s +sana +sekiz +sen +senden +seni +senin siz +sizden +size +sizi +sizin +son +sonra +ş +şayet +şey +şeyden +şeye +şeyi +şeyler +şimdi +şöyle şu +şuna +şunda +şundan +şunlar +şunu +şunun +t +tabi +tamam tüm +tümü +u +ü +üç +üzere +v +var ve veya +veyahut +y ya +ya da yani +yedi +yerine +yine +yoksa +z +zaten +zira signature.asc Description: This is a digitally signed message part
Re: [HACKERS] proposal: more practical view on function's source code
Dimitri Fontaine dfonta...@hi-media.com writes: Sure, I should go and write a complete pgsql emacs mode with a linum-mode like feature counting lines the way PG does it, … Ok maybe just using the current SQL mode and linum mode is enough if we teach this latter one to count PostgreSQL function lines the same way as the server does. I think the attached just does that. With it activated in your emacs, M-x linum-mode on a sql-mode buffer will show two counts when in a function, first one is the function line number. Regards, -- dim dim-pgsql.el Description: pgsql.el -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updated Turkish stopwords list for Tsearch2
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org writes: Attached is updated Turkish stopword list for Tsearch2, against 8.4 and HEAD. It would be a good idea to submit this upstream at the snowball project, else it might get lost in future updates. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Updated Turkish stopwords list for Tsearch2
On Mon, 2010-03-22 at 08:55 -0400, Tom Lane wrote: It would be a good idea to submit this upstream at the snowball project, else it might get lost in future updates. Ok, will do. -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Proposal: access control jails (and introduction as aspiring GSoC student)
* Joseph Adams (joeyadams3.14...@gmail.com) wrote: I propose adding application-level access control to PostgreSQL via a jails concept. In a nutshell, a jail is created as part of the database definition (typically exposing a free variable for the current user). When a jail is activated for a session, the only accesses allowed are those indicated in the jail itself. A jail cannot be exited without closing the session. If used properly, jails make it possible to safely execute untrusted SQL code (though one may not want to, citing the principle of least privilege). I guess my initial reaction to this is that you can use roles, views, and pl/pgsql (security definer) functions to achieve this. This does have an interesting intersection with row-level security concepts and that's definitely a project that I'd like to see happen at some point in PG. Not sure if you've considered this, but you can do a 'set role' at the start of a session and then use CURRENT_ROLE in view definitions and in other places. You can also make it so that the user who is logging in (eg 'www-data') doesn't have any rights to anything, except the ability to 'set role' to other roles. Note that, with any of this, you need to consider pooled database connections. Unfortunately, it's still pretty expensive to establish a new database connection to PG. Thanks, Stephen signature.asc Description: Digital signature
[HACKERS] Comments on Exclusion Constraints and related datatypes
Exclusion constraints are good. There's a few annoyances around them, that are minor but feel should be addressed for 9.0. * Exclusion indexes are created with the suffix _exclusion. That's a very long suffix and will overflow most defined reports/screens. It would be much better to use just _excl, so that the number of characters for index suffixes is always 4 or less characters, whatever type of index they are. * Circles, Boxes and other geometric datatypes defined overlaps to include touching shapes. So SELECT circle '((0,0), 1)' circle '((2,0),1)'; is true, which is fairly strange and makes those datatypes very counter intuitive. Considering they are instructional aids, this is bad. * inet datatypes don't have a commutative operator on which a unique index can be built. There is no overlaps equivalent, which again is a shame because that stops them being used with the new feature. That leaves me thinking that we're shipping Postgres 9.0 with a new feature that isn't real-world usable with built-in datatypes. It's not even easily usable for demo applications either with the noddy datatypes. I do appreciate that the main use case is with add-in datatypes but this is a shame for such a great feature. Also, if the only common sense usage of exclusion constraints is GIST, why does the syntax default to btree? This means that alter table boxes add exclude using gist (position with ); is required, to avoid this ERROR alter table boxes add exclude (position with ); ERROR: data type box has no default operator class for access method btree HINT: You must specify an operator class for the index or define a default operator class for the data type. Surely in the absence of a relevant btree operator class we should automatically check for GIST operator classes? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ALTER TABLE .... make constraint DEFERRABLE
Deferrable unique constraints seem an interesting feature, though I have either some questions or some issues, not sure which. I don't seem to be able to find any way to do an ALTER TABLE that adds this new capability to an existing table. There is no way to add a constraint via a CREATE TABLE AS SELECT, so that means there is no way to use the feature at all in that case. Also, foreign keys can't be defined that refer to a deferrable primary key. That isn't mentioned at all in the manual with regard to the DEFERRABLE clause, though it is mentioned in the FK section. You get this error message ERROR: cannot use a deferrable unique constraint for referenced table The use case for this feature looks a little narrow at present. Can we do something about usability? Am I missing something? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: access control jails (and introduction as aspiring GSoC student)
On Mon, Mar 22, 2010 at 9:39 AM, Stephen Frost sfr...@snowman.net wrote:
* Joseph Adams (joeyadams3.14...@gmail.com) wrote:
I propose adding application-level access control to PostgreSQL via a
jails concept. In a nutshell, a jail is created as part of the
database definition (typically exposing a free variable for the
current user). When a jail is activated for a session, the only
accesses allowed are those indicated in the jail itself. A jail
cannot be exited without closing the session. If used properly, jails
make it possible to safely execute untrusted SQL code (though one may
not want to, citing the principle of least privilege).
I guess my initial reaction to this is that you can use roles, views,
and pl/pgsql (security definer) functions to achieve this. This does
have an interesting intersection with row-level security concepts and
that's definitely a project that I'd like to see happen at some point in
PG. Not sure if you've considered this, but you can do a 'set role' at
the start of a session and then use CURRENT_ROLE in view definitions and
in other places. You can also make it so that the user who is logging
in (eg 'www-data') doesn't have any rights to anything, except the
ability to 'set role' to other roles.
Sometimes it would be nice to conditionalize queries on a value other
than the authenticated role. I really wish we had some kind of SQL
variable support. Talking out of my rear end:
CREATE VARIABLE name AS type [GLOBAL | LOCAL]; -- local variables are
per-backend
SET VARIABLE name = value;
SELECT * FROM foo WHERE col = ${name};
We have had one previous request for the ability to limit the list of
queries that the user can issue to a fixed set, but it's not clear to
me that that's really all that useful. If that's what you want, you
might be better off putting an intermediate layer between the client
and the database - e.g. this kind of restriction could be implemented
in the connection pooler...
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, Mar 22, 2010 at 9:15 AM, Simon Riggs si...@2ndquadrant.com wrote: Exclusion constraints are good. There's a few annoyances around them, that are minor but feel should be addressed for 9.0. * Exclusion indexes are created with the suffix _exclusion. That's a very long suffix and will overflow most defined reports/screens. It would be much better to use just _excl, so that the number of characters for index suffixes is always 4 or less characters, whatever type of index they are. I'd be OK with that. * Circles, Boxes and other geometric datatypes defined overlaps to include touching shapes. So SELECT circle '((0,0), 1)' circle '((2,0),1)'; is true, which is fairly strange and makes those datatypes very counter intuitive. Considering they are instructional aids, this is bad. As a non-user of geometric datatypes, I have no opinion on this one way or the other. * inet datatypes don't have a commutative operator on which a unique index can be built. There is no overlaps equivalent, which again is a shame because that stops them being used with the new feature. This would be a nice thing to fix, and I was thinking about doing it, but I just ran out of time. I think it can be left for 9.1. I have not infrequently wanted to build an IP allocation database, and this would be perfect for that. That leaves me thinking that we're shipping Postgres 9.0 with a new feature that isn't real-world usable with built-in datatypes. It's not even easily usable for demo applications either with the noddy datatypes. I do appreciate that the main use case is with add-in datatypes but this is a shame for such a great feature. Also, if the only common sense usage of exclusion constraints is GIST, why does the syntax default to btree? This means that alter table boxes add exclude using gist (position with ); is required, to avoid this ERROR alter table boxes add exclude (position with ); ERROR: data type box has no default operator class for access method btree HINT: You must specify an operator class for the index or define a default operator class for the data type. Surely in the absence of a relevant btree operator class we should automatically check for GIST operator classes? That doesn't seem particularly consistent with what we've done elsewhere. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: access control jails (and introduction as aspiring GSoC student)
* Robert Haas (robertmh...@gmail.com) wrote: Sometimes it would be nice to conditionalize queries on a value other than the authenticated role. I really wish we had some kind of SQL variable support. Talking out of my rear end: I certainly agree- having variable support in the backend would definitely be nice. I'd want it to be explicit and distinct from GUCs though, unlike the situation we have w/ psql right now. All that said, I'm not really a huge fan of write-your-own-authorization-system in general. If the existing authorization system isn't sufficient for what you want, then let's improve it. There may be specific cases where what's needed is particularly complex, but that's what security definer functions are for.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
Simon Riggs si...@2ndquadrant.com writes: * Exclusion indexes are created with the suffix _exclusion. That's a very long suffix and will overflow most defined reports/screens. It would be much better to use just _excl, No particular objection here. * Circles, Boxes and other geometric datatypes defined overlaps to include touching shapes. So SELECT circle '((0,0), 1)' circle '((2,0),1)'; is true, which is fairly strange and makes those datatypes very counter intuitive. Considering they are instructional aids, this is bad. You're approximately twenty years too late to propose changing that, even if it were clearly a good idea which I doubt. Also, if the only common sense usage of exclusion constraints is GIST, why does the syntax default to btree? Since your if isn't a correct statement, the complaint doesn't follow. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ALTER TABLE .... make constraint DEFERRABLE
Simon Riggs si...@2ndquadrant.com writes: Am I missing something? That we're long past feature freeze? Some of these might be reasonable TODO items. None of them are happening for 9.0. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: * Exclusion indexes are created with the suffix _exclusion. That's a very long suffix and will overflow most defined reports/screens. It would be much better to use just _excl, No particular objection here. OK, will change. * Circles, Boxes and other geometric datatypes defined overlaps to include touching shapes. So SELECT circle '((0,0), 1)' circle '((2,0),1)'; is true, which is fairly strange and makes those datatypes very counter intuitive. Considering they are instructional aids, this is bad. You're approximately twenty years too late to propose changing that, even if it were clearly a good idea which I doubt. Possibly. We should at least document that. Also, if the only common sense usage of exclusion constraints is GIST, why does the syntax default to btree? Since your if isn't a correct statement, the complaint doesn't follow. Docs say The access method must support amgettuple (see Chapter 51); at present this means GIN cannot be used. Although it's allowed, there is little point in using btree or hash indexes with an exclusion constraint, because this does nothing that an ordinary unique constraint doesn't do better. So in practice the access method will always be GiST. Hence my comment. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: more practical view on function's source code
2010/3/22 Dimitri Fontaine dfonta...@hi-media.com: Dimitri Fontaine dfonta...@hi-media.com writes: Sure, I should go and write a complete pgsql emacs mode with a linum-mode like feature counting lines the way PG does it, … Ok maybe just using the current SQL mode and linum mode is enough if we teach this latter one to count PostgreSQL function lines the same way as the server does. I think the attached just does that. With it activated in your emacs, M-x linum-mode on a sql-mode buffer will show two counts when in a function, first one is the function line number. great - I am looking somebody who can hack emacs sql-mode :). I'll have a few questions and request. Back to my problem - I dislike to start emacs every when I would to like source code ;) Pavel Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
Simon Riggs si...@2ndquadrant.com writes: On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote: Also, if the only common sense usage of exclusion constraints is GIST, why does the syntax default to btree? Since your if isn't a correct statement, the complaint doesn't follow. Docs say The access method must support amgettuple (see Chapter 51); at present this means GIN cannot be used. Although it's allowed, there is little point in using btree or hash indexes with an exclusion constraint, because this does nothing that an ordinary unique constraint doesn't do better. So in practice the access method will always be GiST. Well, I would hope that the lack of GIN support will be cured someday. I see the above as a statement of what's true in 9.0, not what will always be true; so it's pretty weak as a justification for introducing a confusing default behavior. Actually the statement might be overly strong even now. If you want uniqueness checks with a hash index, exclusion is the only way to get that. I'm not sure that that's actually useful versus a standard btree unique constraint, but it's at least arguably another use case. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On mån, 2010-03-22 at 13:15 +, Simon Riggs wrote: * inet datatypes don't have a commutative operator on which a unique index can be built. There is no overlaps equivalent, which again is a shame because that stops them being used with the new feature. http://pgfoundry.org/projects/ip4r/ provides an overlap operator. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Josh Berkus wrote: In hindsight I could have loaded the ASCII release notes into a wiki and people could have modified, them, and later I could have converted them to SGML, That was, in fact, *exactly* what you said you'd do 3 months ago when we discussed this. I now remember discussing it but I don't remember many of the details. Yeah, I don't think that would have been better. Thing is, doing things like rearranging items for clarity is prohibitively painful in SGML. And while I know a professional copy-editor who would be willing to fix grammar, etc, she's not going anywhere near SGML. I think we're back at having two sets of feature information: one for the general public, one for the technically inclined. Or, to put it another way: I do the feature list for the general public. I'm not doing it in SGML. It's too freaking hard to edit. If someone else wants to take up doing that work, they can do it in any format they want. I can accept diffs in any format and merge them into the SGML. That's the way the proofreaders are working: http://wiki.postgresql.org/wiki/Documentation_Proofreading I do not require them to submit SGML; just some format where I can identify the lines that changed. I can do the same for the release notes. I have to check the diffs anyway so manually merging in the changes isn't a problem. It is certainly easy to put the information on a wiki for a week and allow it to be proofread before adding the SGML markup. However, there will still be adjustments after that and I am still going to be merging stuff into SGML, just not as much. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: access control jails (and introduction as aspiring GSoC student)
On Mon, Mar 22, 2010 at 10:03 AM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: Sometimes it would be nice to conditionalize queries on a value other than the authenticated role. I really wish we had some kind of SQL variable support. Talking out of my rear end: I certainly agree- having variable support in the backend would definitely be nice. I'd want it to be explicit and distinct from GUCs though, unlike the situation we have w/ psql right now. Agreed. All that said, I'm not really a huge fan of write-your-own-authorization-system in general. If the existing authorization system isn't sufficient for what you want, then let's improve it. There may be specific cases where what's needed is particularly complex, but that's what security definer functions are for.. Fortunately this functionality also has other uses, so I don't know that we really need to decide which of those uses we approve of more or less. Does the SQL standard specify anything in this area? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, 2010-03-22 at 16:40 +0200, Peter Eisentraut wrote: On mån, 2010-03-22 at 13:15 +, Simon Riggs wrote: * inet datatypes don't have a commutative operator on which a unique index can be built. There is no overlaps equivalent, which again is a shame because that stops them being used with the new feature. http://pgfoundry.org/projects/ip4r/ provides an overlap operator. Like I said, nothing in the base server. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
Simon Riggs si...@2ndquadrant.com wrote: On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: * Circles, Boxes and other geometric datatypes defined overlaps to include touching shapes. So SELECT circle '((0,0), 1)' circle '((2,0),1)'; is true, which is fairly strange and makes those datatypes very counter intuitive. Considering they are instructional aids, this is bad. You're approximately twenty years too late to propose changing that, even if it were clearly a good idea which I doubt. Possibly. We should at least document that. Basically, what you feel is missing is documentation that if two shapes share one or more points they are considered to overlap; there is no requirement that they share an area? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: access control jails (and introduction as aspiring GSoC student)
2010/3/22 Robert Haas robertmh...@gmail.com:
On Mon, Mar 22, 2010 at 9:39 AM, Stephen Frost sfr...@snowman.net wrote:
* Joseph Adams (joeyadams3.14...@gmail.com) wrote:
I propose adding application-level access control to PostgreSQL via a
jails concept. In a nutshell, a jail is created as part of the
database definition (typically exposing a free variable for the
current user). When a jail is activated for a session, the only
accesses allowed are those indicated in the jail itself. A jail
cannot be exited without closing the session. If used properly, jails
make it possible to safely execute untrusted SQL code (though one may
not want to, citing the principle of least privilege).
I guess my initial reaction to this is that you can use roles, views,
and pl/pgsql (security definer) functions to achieve this. This does
have an interesting intersection with row-level security concepts and
that's definitely a project that I'd like to see happen at some point in
PG. Not sure if you've considered this, but you can do a 'set role' at
the start of a session and then use CURRENT_ROLE in view definitions and
in other places. You can also make it so that the user who is logging
in (eg 'www-data') doesn't have any rights to anything, except the
ability to 'set role' to other roles.
Sometimes it would be nice to conditionalize queries on a value other
than the authenticated role. I really wish we had some kind of SQL
variable support. Talking out of my rear end:
CREATE VARIABLE name AS type [GLOBAL | LOCAL]; -- local variables are
per-backend
SET VARIABLE name = value;
SELECT * FROM foo WHERE col = ${name};
I though about it two, three years ago as lighter solution without
packages. Now we have more almost all what we need. Variables are
supported by parser (with last changes related to integration of main
parser to plpgsql).
just you can write
select * from tab where col = var;
there are not necessary some special syntax. And it is available from
all environments. Implementation for scalar type cannot be dificult
(maybe).
Regards
Pavel Stehule
We have had one previous request for the ability to limit the list of
queries that the user can issue to a fixed set, but it's not clear to
me that that's really all that useful. If that's what you want, you
might be better off putting an intermediate layer between the client
and the database - e.g. this kind of restriction could be implemented
in the connection pooler...
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, 2010-03-22 at 10:32 -0500, Kevin Grittner wrote: Simon Riggs si...@2ndquadrant.com wrote: On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: * Circles, Boxes and other geometric datatypes defined overlaps to include touching shapes. So SELECT circle '((0,0), 1)' circle '((2,0),1)'; is true, which is fairly strange and makes those datatypes very counter intuitive. Considering they are instructional aids, this is bad. You're approximately twenty years too late to propose changing that, even if it were clearly a good idea which I doubt. Possibly. We should at least document that. Basically, what you feel is missing is documentation that if two shapes share one or more points they are considered to overlap; there is no requirement that they share an area? Yes, for most people touching != overlap. So it just looks like a bug. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: access control jails (and introduction as aspiring GSoC student)
Robert Haas robertmh...@gmail.com wrote: Does the SQL standard specify anything in this area? The only thing that comes to mind for me is the SQL/PSM SQL variable declaration. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command to prune archive at restartpoints
On Thu, Mar 18, 2010 at 9:43 AM, Simon Riggs si...@2ndquadrant.com wrote: On Wed, 2010-03-17 at 11:37 +0200, Heikki Linnakangas wrote: One awkward omission in the new built-in standby mode, mainly used for streaming replication, is that there is no easy way to delete old archived files like you do with the %r parameter to restore_command. Would it be better to call this archive_cleanup_command? That might help people understand the need for and the use of this parameter. This is bikeshedding but fwiw I like Simon's suggestion. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, Mar 22, 2010 at 03:42:39PM +, Simon Riggs wrote: On Mon, 2010-03-22 at 10:32 -0500, Kevin Grittner wrote: Simon Riggs si...@2ndquadrant.com wrote: On Mon, 2010-03-22 at 10:13 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: * Circles, Boxes and other geometric datatypes defined overlaps to include touching shapes. So SELECT circle '((0,0), 1)' circle '((2,0),1)'; is true, which is fairly strange and makes those datatypes very counter intuitive. Considering they are instructional aids, this is bad. You're approximately twenty years too late to propose changing that, even if it were clearly a good idea which I doubt. Possibly. We should at least document that. Basically, what you feel is missing is documentation that if two shapes share one or more points they are considered to overlap; there is no requirement that they share an area? Yes, for most people touching != overlap. So it just looks like a bug. I don't know which people you've surveyed, but at least in my math classes, one point in common was sufficient for an overlap. I'd be happy to write up something that makes this clear. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
Simon Riggs si...@2ndquadrant.com wrote: Yes, for most people touching != overlap. So it just looks like a bug. A quick search of the web turned up a definition of overlap in geometry as meaning that two polygons share at least one *internal* point, which would be consistent with your interpretation; but there is the issue of breaking existing code. Perhaps people are now accustomed to following the existing overlaps test with a test that the area of intersection is non-zero? Anyway, based on what I found, we should document the current behavior, as the term in PostgreSQL doesn't seem to match the conventional definition in geometry. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
Simon Riggs wrote: Basically, what you feel is missing is documentation that if two shapes share one or more points they are considered to overlap; there is no requirement that they share an area? Yes, for most people touching != overlap. So it just looks like a bug. I guess I must be strange, then, it doesn't strike me as particularly unnatural. By all means document it, though, if the docs are not clear on the point. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, 2010-03-22 at 09:00 -0700, David Fetter wrote: Yes, for most people touching != overlap. So it just looks like a bug. I don't know which people you've surveyed, but at least in my math classes, one point in common was sufficient for an overlap. I'd be happy to write up something that makes this clear. If you're happy to document it, good, thanks. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, Mar 22, 2010 at 04:47:37PM +, Simon Riggs wrote: On Mon, 2010-03-22 at 09:00 -0700, David Fetter wrote: Yes, for most people touching != overlap. So it just looks like a bug. I don't know which people you've surveyed, but at least in my math classes, one point in common was sufficient for an overlap. I'd be happy to write up something that makes this clear. If you're happy to document it, good, thanks. I'm seeing a lot of places where this might be documented. Any ideas as to which ones are appropriate? Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
David Fetter da...@fetter.org writes: I'm seeing a lot of places where this might be documented. Any ideas as to which ones are appropriate? I would think Geometric Functions and Operators would be the most appropriate spot ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, Mar 22, 2010 at 01:46:51PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org writes:
I'm seeing a lot of places where this might be documented. Any ideas
as to which ones are appropriate?
I would think Geometric Functions and Operators would be the most
appropriate spot ...
Please find patch enclosed. :)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 9881ff4..9313112 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -7134,7 +7134,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow',
'green', 'blue', 'purple
/row
row
entry literalamp;amp;/literal /entry
-entryOverlaps?/entry
+entryOverlaps? One point in common makes this true./entry
entryliteralbox '((0,0),(1,1))' amp;amp; box
'((0,0),(2,2))'/literal/entry
/row
row
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
David Fetter wrote:
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 9881ff4..9313112 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -7134,7 +7134,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow',
'green', 'blue', 'purple
/row
row
entry literalamp;amp;/literal /entry
-entryOverlaps?/entry
+entryOverlaps? One point in common makes this true./entry
entryliteralbox '((0,0),(1,1))' amp;amp; box
'((0,0),(2,2))'/literal/entry
/row
row
Hmm, how does this look in horizontal space? (The row makes me think
it's a table.)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, Mar 22, 2010 at 04:04:16PM -0300, Alvaro Herrera wrote:
David Fetter wrote:
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 9881ff4..9313112 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -7134,7 +7134,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange',
'yellow', 'green', 'blue', 'purple
/row
row
entry literalamp;amp;/literal /entry
-entryOverlaps?/entry
+entryOverlaps? One point in common makes this true./entry
entryliteralbox '((0,0),(1,1))' amp;amp; box
'((0,0),(2,2))'/literal/entry
/row
row
Hmm, how does this look in horizontal space? (The row makes me think
it's a table.)
Looks OK to me. The entry above, Closest point to first operand on
second operand is actually wider.
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, Mar 22, 2010 at 1:15 PM, Simon Riggs si...@2ndquadrant.com wrote: * Circles, Boxes and other geometric datatypes defined overlaps to include touching shapes. So * inet datatypes don't have a commutative operator on which a unique index can be built. There is no overlaps equivalent, which again is a shame because that stops them being used with the new feature. I think our unusual data types are one of the strong points of Postgres but they're missing a lot of operators and opclasses to make them really useful. There's no reason we couldn't have separate overlaps and overlaps-internally operators just like we have =,= and ,. And it would be nice to flesh out the network data type more fully, perhaps merging in as much of ip4r as makes sense. I remember when I tried to use geometric data types I was stymied by missing operators. In particular I was surprised that point in box wasn't a gist indexable method. I think that particular case has been addressed but I think there are many more like it. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
On Mon, 2010-03-22 at 10:55 -0700, David Fetter wrote: On Mon, Mar 22, 2010 at 01:46:51PM -0400, Tom Lane wrote: David Fetter da...@fetter.org writes: I'm seeing a lot of places where this might be documented. Any ideas as to which ones are appropriate? I would think Geometric Functions and Operators would be the most appropriate spot ... Please find patch enclosed. :) I think you've missed my point. I don't suppose anybody would disagree that box '((0,0),(1,1))' box '((0,0),(2,2))' is true. The fact that these two boxes share the point (0,0) has nothing to do with the obvious fact that the larger box completely contains the smaller one. What I was talking about was that box '((0,0),(1,1))' box '((1,1),(2,2))' returns true, even though they touch at only a single point, and share zero area. Perhaps the end result here is the realisation that a normal search operator like overlaps () might not be the right operator to use for exclusion constraints. For the latter, we might want something that defines the left and bottom edges of a box to belong to the box (=), whereas the top edges are the boundary but do not belong to the box itself (). In a timerange that might be easier to visualise: the start timestamp is inclusive, the end timestamp is exclusive, so that each timestamp exists in only one timerange when the timeranges are overlapping with no gaps. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comments on Exclusion Constraints and related datatypes
Simon Riggs si...@2ndquadrant.com wrote: I think you've missed my point. What I was talking about was that box '((0,0),(1,1))' box '((1,1),(2,2))' returns true, even though they touch at only a single point, and share zero area. FWIW, that's what I would take away from one point in common -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] trouble with to_char('L')
Takahiro Itagaki wrote: Bruce Momjian br...@momjian.us wrote: Takahiro Itagaki wrote: Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify db_encoding_strdup() with the function. Like this: OK, I don't have any Win32 people testing this patch so if we want this fixed for 9.0 someone is going to have to test my patch to see that it works. Can you make the adjustments suggested above to my patch and test it to see that it works so we can apply it for 9.0? Here is a full patch that can be applied cleanly to HEAD. Can anyone test it on Windows? I'm not sure why temporary changes of lc_ctype was required in the original patch. The codes are not included in my patch, but please notice me it is still needed. Sorry for the delay in replying to you. I considered your idea of using the existing Postgres encoding conversion routines to do the conversion of localenv() strings, but found two problems. First, GetPlatformEncoding() caches its result, so it assumes the LC_CTYPE never changes for the server, while fixing this issue actually requires us to change LC_CTYPE. We could avoid the caching but that then involves complex table lookups, etc, which seems overly complex: + /* convert the string to the database encoding */ + pstr = (char *) pg_do_encoding_conversion( + (unsigned char *) str, strlen(str), + GetPlatformEncoding(), GetDatabaseEncoding()); Second, having our backend routines do the conversion seems wrong because it is possible for someone to set LC_MONETARY to an encoding that our database does not understand, e.g. UTF16, but one that WIN32 can convert to a valid encoding. The reason we are doing all this is because of this updated comment in my patch: ftp://momjian.us/pub/postgresql/mypatches/pg_locale +* Ideally, monetary and numeric local symbols could be returned in +* any server encoding. Unfortunately, the WIN32 API does not allow +* setlocale() to return values in a codepage/CTYPE that uses more +* than two bytes per character, like UTF-8: +* +* http://msdn.microsoft.com/en-us/library/x99tb11d.aspx +* +* Evidently, LC_CTYPE allows us to control the encoding used +* for strings returned by localeconv(). The Open Group +* standard, mentioned at the top of this C file, doesn't +* explicitly state this. +* +* Therefore, we set LC_CTYPE to match LC_NUMERIC and +* LC_MONETARY, call localeconv(), and use mbstowcs() to +* convert the locale-aware string, e.g. Euro symbol (which +* is not in UTF-8), to the server encoding. One new idea would be to set LC_CTYPE to UTF16/widechars unconditionally on Win32 and then just convert that always to the server encoding with win32_wchar_to_db_encoding(), instead of using the encoding from LC_MONETARY to set LC_CTYPE and having to do double-conversion. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [postgis-users] ERROR: array size exceeds themaximumallowed(134217727)
On Mon, Mar 22, 2010 at 4:45 PM, Paul Ramsey pram...@cleverelephant.ca wrote: Did you already try replacing your postgis functions with array_agg calls to see if we can push the problem back over the fence to pgsql land? On Sat, Mar 20, 2010 at 9:17 AM, Mike Leahy mgle...@alumni.uwaterloo.ca wrote: Running this query on various data will produce one of two results. One is the error mentioned in the subject (ERROR: array size exceeds the maximum allowed (134217727)). I can find very little information on this error. The other outcome is that it often causes the PostgreSQL backend to segfault (see gdboutput.txt). gdboutput.txt: Program terminated with signal 11, Segmentation fault. #0 0x7fa4be23615b in pfree () from /usr/lib/postgresql/8.4/bin/postgres #1 0x7fa4be18091b in makeMdArrayResult () from /usr/lib/postgresql/8.4/bin/postgres #2 0x7fa4b7f038bc in pgis_accum_finalfn () from /usr/lib/postgresql/8.4/lib/postgis-1.5.so #3 0x7fa4b7f039ee in pgis_geometry_union_finalfn () from /usr/lib/postgresql/8.4/lib/postgis-1.5.so Any chance you can generate one of these seg faults from a build with symbols and with assertions enabled? It might catch the problem earlier and provide more info. IIRC there were some memory management changes which required changes to array_agg() and which had some risk of causing problems for other sites with similar coding. Is it possible your'e missing some of these changes? I'm having trouble tracking them all down but at least there's these: commit 3d332de2eab8a01c0ef3f58ea69de2010fe8a1e1 Author: Tom Lane t...@sss.pgh.pa.us Date: Thu Jul 23 20:45:27 2009 + In a non-hashed Agg node, reset the aggcontext at group boundaries, instead of individually pfree'ing pass-by-reference transition values. This should be at least as fast as the prior coding, and it has the major advantage of clearing out any working data an aggregate function may have stored in or underneath the aggcontext. This avoids memory leakage when an aggregate such as array_agg() is used in GROUP BY mode. Per report from Chris Spotts. Back-patch to 8.4. In principle the problem could arise in prior versions, but since they didn't have array_agg the issue seems not critical. commit 7f83b61cc26eeac0c5a09add49f6cf899f87fc0b Author: Tom Lane t...@sss.pgh.pa.us Date: Sat Jun 20 18:45:28 2009 + Fix things so that array_agg_finalfn does not modify or free its input ArrayBuildState, per trouble report from Merlin Moncure. By adopting this fix, we are essentially deciding that aggregate final-functions should not modify their inputs ever. Adjust documentation and comments to match that conclusion. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] An idle thought
Jeff Davis wrote: On Tue, 2010-03-16 at 15:29 +, Greg Stark wrote: I'm picturing storing a bit in the visibility map indicating that *no* records are visible in a given page. I've been thinking for a while that we could store the visibility information in a structure separate from the heap -- sort of like the visibility map, but per-tuple and authoritative rather than a per-page hint. There are all kinds of challenges there, but it might be worth thinking about. Visibility information is highly compressible, and requires constant maintenance (updates, deletes, freezing, etc.). It also might make it possible to move to 64-bit xids, if we wanted to. I don't think we want to move to 64-bit xids becasue we would still need to do vacuum freeze to trim the clog. In fact we do vacuum freeze much more frequently than required for 32-bit xids for this very reason. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
On 3/22/10 7:46 AM, Bruce Momjian wrote: I do not require them to submit SGML; just some format where I can identify the lines that changed. I can do the same for the release notes. I have to check the diffs anyway so manually merging in the changes isn't a problem. So there are 2 large problems I have with the SGML version, let's see if we can deal with them separately: (1) re-arranging and regrouping the items: the stuff in the release notes should end up in 7-8 clear categories, with items arranged in descending order by importance. SGML+CVS makes this a task which cannot be done collaboratively. (2) Seeing my edits. There's no edit--view--edit cycle with the SGML, and it's really hard to check grammar and languge ... let alone compare stuff to the alphas ... in raw SGML. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: more practical view on function's source code
On sön, 2010-03-21 at 20:40 -0400, Robert Haas wrote: \ef function-name line-number with suitable magic to get the editor to place the cursor at that line. I suspect this wouldn't be too hard to do with emacs --- what do you think about vi? Well, in vi you can just do vi +linenum filename. I think that's a pretty widely spread convention. A quick test shows that all of emacs, vi, joe, and nano support this. Of course there are editors that don't support it, so we'll have to distinguish that somehow, but it won't be too complicated to support a few of the common editors. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: xmlconcat (was [HACKERS] 9.0 release notes done)
On sön, 2010-03-21 at 13:07 -0400, Andrew Dunstan wrote: Yeah, maybe. According to http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html the only legal child of an XML Document node that is not also a legal child of a DocumentFragment node is a DocumentType node. So we could probably just look for one of those in each argument node and strip it out. That should be fairly lightweight in the common case where it's not present - we'd just be searching for a fixed string. Removing it if found would be more complex. We'd have to parse the node to remove it, since a legal DocumentType node string could appear legally inside a CDATA node. According to the SQL/XML standard, the document type declaration should apparently be stripped when doing a concatenation. (This makes sense because the result of a concatenation can never be valid according to a DTD.) But if we are not comfortable about being able to do that safely, I would be OK with just raising an error if a concatenation is attempted where one value contains a DTD. The impact in practice should be low. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
On mån, 2010-03-22 at 14:18 -0700, Josh Berkus wrote: So there are 2 large problems I have with the SGML version, let's see if we can deal with them separately: (1) re-arranging and regrouping the items: the stuff in the release notes should end up in 7-8 clear categories, with items arranged in descending order by importance. SGML+CVS makes this a task which cannot be done collaboratively. Uh why? Open the file with a text editor, cut and paste the lines elsewhere. davidfetterYou can also use Git if you like./davidfetter (2) Seeing my edits. There's no edit--view--edit cycle with the SGML, and it's really hard to check grammar and languge ... let alone compare stuff to the alphas ... in raw SGML. Are you having trouble building the docs? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
On Mon, Mar 22, 2010 at 02:18:04PM -0700, Josh Berkus wrote: On 3/22/10 7:46 AM, Bruce Momjian wrote: I do not require them to submit SGML; just some format where I can identify the lines that changed. I can do the same for the release notes. I have to check the diffs anyway so manually merging in the changes isn't a problem. So there are 2 large problems I have with the SGML version, let's see if we can deal with them separately: (1) re-arranging and regrouping the items: the stuff in the release notes should end up in 7-8 clear categories, with items arranged in descending order by importance. SGML+CVS makes this a task which cannot be done collaboratively. We could throw this on a one of the git mirrors. (2) Seeing my edits. There's no edit--view--edit cycle with the SGML, and it's really hard to check grammar and languge ... let alone compare stuff to the alphas ... in raw SGML. While not a WYSIWYG, shelling out to make after each disk write should do what you want. Which editor(s) do you like to use? Emacs and vim both have ways to do this. :) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: more practical view on function's source code
On Mar 22, 2010, at 2:23 PM, Peter Eisentraut wrote: On sön, 2010-03-21 at 20:40 -0400, Robert Haas wrote: \ef function-name line-number with suitable magic to get the editor to place the cursor at that line. I suspect this wouldn't be too hard to do with emacs --- what do you think about vi? Well, in vi you can just do vi +linenum filename. I think that's a pretty widely spread convention. A quick test shows that all of emacs, vi, joe, and nano support this. Of course there are editors that don't support it, so we'll have to distinguish that somehow, but it won't be too complicated to support a few of the common editors. Would an environment variable be the general purpose answer? Much the same as TEXEDIT or LESSEDIT. export PSQLEDIT='mate -w -l %d %s' or export PSQLEDIT='emacs +%d %s' Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] An idle thought
On Mon, 2010-03-22 at 16:48 -0400, Bruce Momjian wrote: I don't think we want to move to 64-bit xids becasue we would still need to do vacuum freeze to trim the clog. In fact we do vacuum freeze much more frequently than required for 32-bit xids for this very reason. Good point. I think there are a lot of issues like this, which would make storing the visibility information separate from the heap a huge undertaking. Still worth thinking about, though. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Uh why? Open the file with a text editor, cut and paste the lines elsewhere. ... because even one edit by anyone else is a merge conflict. And CVS isn't too good with merge conflicts. Also few of the people whom I'd want to ask for help are committers -- the release notes are as much about advocacy as they are about code. If I can use git, it's quite a bit better. Thing is, if I start a git branch for this, are we going to be able to merge it back to the main repo? (2) Seeing my edits. There's no edit--view--edit cycle with the SGML, and it's really hard to check grammar and languge ... let alone compare stuff to the alphas ... in raw SGML. Are you having trouble building the docs? Of course. I'm mostly on a Mac. It's several minutes every time I make doc. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
On Mon, Mar 22, 2010 at 23:18, Josh Berkus j...@agliodbs.com wrote: Uh why? Open the file with a text editor, cut and paste the lines elsewhere. ... because even one edit by anyone else is a merge conflict. And CVS isn't too good with merge conflicts. Also few of the people whom I'd want to ask for help are committers -- the release notes are as much about advocacy as they are about code. If I can use git, it's quite a bit better. Thing is, if I start a git branch for this, are we going to be able to merge it back to the main repo? Pretty easily. The obvious way is that you merge *your* branch with the main repo as often as possible. Git does a pretty good job of helping you there - a lot better than cvs - but there may still be some conflicts of course. But there will always be conflicts if two people edit the same thing, regardless of tools. Once that is done, the only chokepoint for conflicts is between you generating a diff from that branch and said diff being applied, which would be a very short time. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
On Sat, Mar 20, 2010 at 5:02 AM, Bruce Momjian br...@momjian.us wrote: Interestingly the 9.0 release notes contain 201 items, while the 8.4 release notes contained 314 items. Is the following pg_dump change covered by the release notes? I couldn't find it. It was the last committed patch from the 2010-01 commitfest... http://archives.postgresql.org/pgsql-committers/2010-02/msg00233.php https://commitfest.postgresql.org/action/patch_view?id=247 Joachim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal: access control jails (and introduction as aspiring GSoC student)
On mån, 2010-03-22 at 09:54 -0400, Robert Haas wrote: We have had one previous request for the ability to limit the list of queries that the user can issue to a fixed set, but it's not clear to me that that's really all that useful. Well, sudo is pretty useful, and this would be quite similar. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication status
Simon Riggs wrote: On Thu, 2010-01-14 at 17:33 +0900, Fujii Masao wrote: I added two new functions; (1) pg_last_xlog_receive_location() reports the last WAL location received and synced by walreceiver. If streaming replication is still in progress this will increase monotonically. If streaming replication has completed then this value will remain static at the value of the last WAL record received and synced. When the server has been started without a streaming replication then the return value will be InvalidXLogRecPtr (0/0). (2) pg_last_xlog_replay_location() reports the last WAL location replayed during recovery. If recovery is still in progress this will increase monotonically. If recovery has completed then this value will remain static at the value of the last WAL record applied. When the server has been started normally without a recovery then the return value will be InvalidXLogRecPtr (0/0). I just noticed that these functions have almost the same name as functions I wrote for Hot Standby and Heikki removed from that patch. The function code and docs are 99% identical. I'm happy that the code was used and it is BSD, though it does seem strange to have this credited to others in the release notes. Sorry, release notes updated: Add link linkend=functions-recovery-info-tablefunctionpg_last_xlog_receive_location()//link and functionpg_last_xlog_replay_location()/, which can be used to monitor standby server acronymWAL/ activity (Simon) -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Joachim Wieland wrote: On Sat, Mar 20, 2010 at 5:02 AM, Bruce Momjian br...@momjian.us wrote: Interestingly the 9.0 release notes contain 201 items, while the 8.4 release notes contained 314 items. Is the following pg_dump change covered by the release notes? I couldn't find it. It was the last committed patch from the 2010-01 commitfest... http://archives.postgresql.org/pgsql-committers/2010-02/msg00233.php https://commitfest.postgresql.org/action/patch_view?id=247 pg_dump support is part of the larger release item: Add the ability to control large object permissions with GRANT/REVOKE(KaiGai Kohei) -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Josh Berkus wrote: On 3/22/10 7:46 AM, Bruce Momjian wrote: I do not require them to submit SGML; just some format where I can identify the lines that changed. I can do the same for the release notes. I have to check the diffs anyway so manually merging in the changes isn't a problem. So there are 2 large problems I have with the SGML version, let's see if we can deal with them separately: (1) re-arranging and regrouping the items: the stuff in the release notes should end up in 7-8 clear categories, with items arranged in descending order by importance. SGML+CVS makes this a task which cannot be done collaboratively. Uh, are you saying you want to remove the exiting release note subcategories and put everything into 7-8 long lists? That hardly seems like an improvement, or are you talking about make a user-focused list that is shorter with 7-8 categories? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Uh, are you saying you want to remove the exiting release note subcategories and put everything into 7-8 long lists? That hardly seems like an improvement, or are you talking about make a user-focused list that is shorter with 7-8 categories? I'm talking about adjusting which subcategories we use based on what we actually have for 9.0., or possibly adding sub-subcategories, where warranted. Also, within each subcategory, items should be arranged in descending order according to how much impact we expect them to have on users. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Bruce, BTW, I didn't say it before, but thanks for getting this draft out *now*. It's a lot more time than we've had in the past. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Josh Berkus wrote: Uh, are you saying you want to remove the exiting release note subcategories and put everything into 7-8 long lists? That hardly seems like an improvement, or are you talking about make a user-focused list that is shorter with 7-8 categories? I'm talking about adjusting which subcategories we use based on what we actually have for 9.0., or possibly adding sub-subcategories, where Uh, I did adjust the subcategories based on what we completed for 9.0. You will find many added/removed ones compared to 8.4 warranted. Also, within each subcategory, items should be arranged in descending order according to how much impact we expect them to have on users. I think I did that but I welcome others to change what I did. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Prevent the injection of invalidly encoded strings by PL/Python
On fre, 2010-03-19 at 11:50 -0400, Andrew Dunstan wrote: Peter Eisentraut wrote: Log Message: --- Prevent the injection of invalidly encoded strings by PL/Python into PostgreSQL with a few strategically placed pg_verifymbstr calls. Awesome. Do we need to fix pltcl too? Short answer: yes I have never used Tcl before just now, and the documentation is sketchy, but it looks like the behavior of Tcl is kind of mixed in this area. Escapes such as \xd0 are apparently converted to Unicode code points rather than bytes when the appropriate OS locale is set. So that is safe. Except that it doesn't work in some locale/charset setups, such as EUC_JP. To adapt Hannu's original example: CREATE TABLE utf_test ( id serial PRIMARY KEY, data character varying ); CREATE OR REPLACE FUNCTION invalid_utf_seq() RETURNS character varying AS $BODY$ return \xd0; $BODY$ LANGUAGE 'pltclu' VOLATILE STRICT; insert into utf_test(data) values(invalid_utf_seq()); -- This works in UTF8 and LATIN1 with the right locales, but ... select invalid_utf_seq(); ERROR: 22021: invalid byte sequence for encoding EUC_JP: 0xc390 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Josh Berkus wrote: Bruce, BTW, I didn't say it before, but thanks for getting this draft out *now*. It's a lot more time than we've had in the past. Sure. For some reason it was easier/faster this time; possible causes: o I am getting better because I have done it before o The commit messages were of higher quality o I watched development more for 9.0 o I am more focused because I am better rested (not doing it just before/after travel) I welcome others to take ownership of it and make improvements. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Prevent the injection of invalidly encoded strings by PL/Python
Peter Eisentraut pete...@gmx.net writes: I have never used Tcl before just now, and the documentation is sketchy, but it looks like the behavior of Tcl is kind of mixed in this area. Escapes such as \xd0 are apparently converted to Unicode code points rather than bytes when the appropriate OS locale is set. So that is safe. Except that it doesn't work in some locale/charset setups, such as EUC_JP. To adapt Hannu's original example: The pltcl code special-cases Unicode IIRC. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: xmlconcat (was [HACKERS] 9.0 release notes done)
Peter Eisentraut wrote: On sön, 2010-03-21 at 13:07 -0400, Andrew Dunstan wrote: Yeah, maybe. According to http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html the only legal child of an XML Document node that is not also a legal child of a DocumentFragment node is a DocumentType node. So we could probably just look for one of those in each argument node and strip it out. That should be fairly lightweight in the common case where it's not present - we'd just be searching for a fixed string. Removing it if found would be more complex. We'd have to parse the node to remove it, since a legal DocumentType node string could appear legally inside a CDATA node. According to the SQL/XML standard, the document type declaration should apparently be stripped when doing a concatenation. (This makes sense because the result of a concatenation can never be valid according to a DTD.) But if we are not comfortable about being able to do that safely, I would be OK with just raising an error if a concatenation is attempted where one value contains a DTD. The impact in practice should be low. Right. Can you find a way to do that using the libxml API? I haven't managed to, and I'm pretty sure I can construct XML that fails every simple string search test I can think of, either with a false negative or a false positive. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Uh, I did adjust the subcategories based on what we completed for 9.0. You will find many added/removed ones compared to 8.4 warranted. Also, within each subcategory, items should be arranged in descending order according to how much impact we expect them to have on users. I think I did that but I welcome others to change what I did. Then maybe I shouldn't make assumptions about how much of a hatchet job I'm going to need to do. Working on creating a git branch now. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Prevent the injection of invalidly encoded strings by PL/Python
On mån, 2010-03-22 at 19:29 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: I have never used Tcl before just now, and the documentation is sketchy, but it looks like the behavior of Tcl is kind of mixed in this area. Escapes such as \xd0 are apparently converted to Unicode code points rather than bytes when the appropriate OS locale is set. So that is safe. Except that it doesn't work in some locale/charset setups, such as EUC_JP. To adapt Hannu's original example: The pltcl code special-cases Unicode IIRC. You can observe the equivalent behavior in tclsh, so this isn't pltcl at work here. One might argue that the leak is really somewhere in Tcl, since it allows this kind of thing while claiming to use Unicode. But that doesn't really help us ... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: preloading of ispell dictionary
Pavel Stehule pavel.steh...@gmail.com wrote: I wrote some small patch, that allow preloading of selected ispell dictionary. It solve the problem with slow tsearch initialisation with some language configuration. I afraid so this module doesn't help on MS Windows. I think it should work on all platforms if we include it into the core. We should continue to research shared memory or mmap approaches. The fundamental issue seems to be in the slow initialization of dictionaries. If so, how about adding a pre-complile tool to convert a dictionary into a binary file, and each backend simply mmap it? BTW, SimpleAllocContextCreate() is not used at all in the patch. Do you still need it? Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Standalone backends run StartupXLOG in an incorrect environment
Simon Riggs wrote: On Sat, 2009-09-19 at 13:21 -0400, Tom Lane wrote: I realized the truth of $SUBJECT while reading this report: http://archives.postgresql.org/pgsql-general/2009-09/msg00712.php ... Also, does this have any impact on the Hot Standby stuff? It could potentially, but there is not much HS-related code in the early boot sequence. It's mostly StartupXLog() or later. HS won't work in standalone backends, by definition, so I don't see too much to worry me. [This is an open item for 9.0, hence the response to an apparently old hackers thread] Thanks for the reply; 9.0 open item removed. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Standalone backends run StartupXLOG in an incorrect environment
Bruce Momjian br...@momjian.us writes: [This is an open item for 9.0, hence the response to an apparently old hackers thread] Thanks for the reply; 9.0 open item removed. I think you misread his reply. Please put that back. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Standalone backends run StartupXLOG in an incorrect environment
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: [This is an open item for 9.0, hence the response to an apparently old hackers thread] Thanks for the reply; 9.0 open item removed. I think you misread his reply. Please put that back. OK, I re-read it and still don't understand, but I don't have to. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication status
On Tue, Mar 23, 2010 at 7:56 AM, Bruce Momjian br...@momjian.us wrote: Sorry, release notes updated: Add link linkend=functions-recovery-info-tablefunctionpg_last_xlog_receive_location()//link and functionpg_last_xlog_replay_location()/, which can be used to monitor standby server acronymWAL/ activity (Simon) Umm... though I'm not sure the policy about credit, I think that three names should be put down with. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Ragged latency log data in multi-threaded pgbench
Greg Smith g...@2ndquadrant.com wrote: Attached is an updated version that I think is ready to commit. Only changes are docs--I rewrote those to improve the wording some. Thanks for the correction. Applied. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUG] SECURITY DEFINER on call handler makes daemon crash
(2010/03/20 13:37), Tom Lane wrote: KaiGai Koheikai...@kaigai.gr.jp writes: Is it an expected behavior that PostgreSQL tries to execute foo() with privileges of the owner of language call handler because of its security definer property? This server crash is just a result. A language call handler has no function properties of its own --- which is why attaching SECURITY DEFINER to it is both useless and meaningless. The appropriate function properties for any call are those of the user function being called, which the handler is merely a support for. OK, I also think the call handlers should work transparently like air. You could argue that we should put call handlers into their own table instead of pg_proc, since they aren't really user-callable functions; that would prevent people from thinking that something like this is sane. However, they share just enough infrastructure with real functions that it didn't seem worth doing it that way. I see no value whatsoever in making the world safe for people to attach SECURITY DEFINER to handlers. It's an incorrect declaration, and superusers need to know better than to declare C functions with incorrect properties. I basically agree that this matter does not happen unless user intend to assign SECURITY DEFINER attribute on the language call handlers, although it is nonsense. The reason why I reported it is that it was not clear for me whether the development team knows this matter, and I doubted the design we can assign this nonsense attribute from the perspective of fool-proof. Fool-proof is a term from human-interface. It tells us manufactured-product should work safely, even if user tries to abuse it. A microwave-oven does not work without closing its door, for example. In my sense, we should care about known matters at least. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication status
Fujii Masao wrote: On Tue, Mar 23, 2010 at 7:56 AM, Bruce Momjian br...@momjian.us wrote: Sorry, release notes updated: ? ? ? ? ? ? ?Add link ? ? ? ? ? ? ?linkend=functions-recovery-info-tablefunctionpg_last_xlog_receive_location()//link ? ? ? ? ? ? ?and functionpg_last_xlog_replay_location()/, which ? ? ? ? ? ? ?can be used to monitor standby server acronymWAL/ ? ? ? ? ? ? ?activity (Simon) Umm... though I'm not sure the policy about credit, I think that three names should be put down with. OK, all three are there now: Add link linkend=functions-recovery-info-tablefunctionpg_last_xlog_receive_location()//link and functionpg_last_xlog_replay_location()/, which can be used to monitor standby server acronymWAL/ activity (Simon, Fujii Masao, Heikki) -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.0 release notes done
Bruce Momjian br...@momjian.us wrote: I have completed the 9.0 release notes: http://developer.postgresql.org/pgdocs/postgres/release-9-0.html There is an additional incompatibilitiy in pg_largeobject catalog. We need to rewrite queries to test existences of large objests from SELECT DISTINCT(loid) FROM pg_largeobject to SELECT oid FROM pg_largeobject_metadata because an empty large object doesn't have rows in pg_largeobject. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Ragged latency log data in multi-threaded pgbench
Takahiro Itagaki wrote: Greg Smith g...@2ndquadrant.com wrote: Attached is an updated version that I think is ready to commit. Only changes are docs--I rewrote those to improve the wording some. Thanks for the correction. Applied. By the way: the pgbench.sgml that you committed looks like it passed through a system that added a CR to every line in it. Probably not the way you intended to commit that. So far I've done over 40 hours of pgbench runtime worth of testing (500 runs) using the patched version without any issues, the code itself continues to act fine. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Ragged latency log data in multi-threaded pgbench
Greg Smith g...@2ndquadrant.com wrote: By the way: the pgbench.sgml that you committed looks like it passed through a system that added a CR to every line in it. Probably not the way you intended to commit that. Oops, fixed. Thanks. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
