Re: [HACKERS] Per-column collation, proof of concept
On Mon, Aug 16, 2010 at 10:56 PM, Peter Eisentraut pete...@gmx.net wrote: On lör, 2010-08-14 at 02:05 -0500, Jaime Casanova wrote: BTW, why the double quotes? Because the name contains upper case letters? why everything seems so obvious once someone else state it? :) sorry to state the obvious but this doesn't work on windows, does it? Probably not, but hopefully there is some similar API that could be used on Windows. good luck with that! ;) seriously, maybe this helps http://msdn.microsoft.com/en-us/library/system.windows.forms.inputlanguage.installedinputlanguages.aspx but probably you will need to write the code yourself... at least i don't think there is something like locale -a and for some reason it also didn't work on a centos 5 (this error ocurred when initdb'ing) loading system objects' descriptions ... ok creating collations ...FATAL: invalid byte sequence for encoding UTF8: 0xe56c09 CONTEXT: COPY tmp_pg_collation, line 86 STATEMENT: COPY tmp_pg_collation FROM E'/usr/local/pgsql/9.1/share/locales.txt'; Hmm, what is in that file on that line? bokmål ISO-8859-1 (i'm attaching the locales.txt just in case) -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL aa_DJ ISO-8859-1 aa_DJ.iso88591 ISO-8859-1 aa_DJ.utf8 UTF-8 aa_ER UTF-8 aa...@saaho UTF-8 aa_ER.utf8 UTF-8 aa_er.u...@saahoUTF-8 aa_ET UTF-8 aa_ET.utf8 UTF-8 af_ZA ISO-8859-1 af_ZA.iso88591 ISO-8859-1 af_ZA.utf8 UTF-8 am_ET UTF-8 am_ET.utf8 UTF-8 an_ES ISO-8859-15 an_ES.iso885915 ISO-8859-15 an_ES.utf8 UTF-8 ar_AE ISO-8859-6 ar_AE.iso88596 ISO-8859-6 ar_AE.utf8 UTF-8 ar_BH ISO-8859-6 ar_BH.iso88596 ISO-8859-6 ar_BH.utf8 UTF-8 ar_DZ ISO-8859-6 ar_DZ.iso88596 ISO-8859-6 ar_DZ.utf8 UTF-8 ar_EG ISO-8859-6 ar_EG.iso88596 ISO-8859-6 ar_EG.utf8 UTF-8 ar_IN UTF-8 ar_IN.utf8 UTF-8 ar_IQ ISO-8859-6 ar_IQ.iso88596 ISO-8859-6 ar_IQ.utf8 UTF-8 ar_JO ISO-8859-6 ar_JO.iso88596 ISO-8859-6 ar_JO.utf8 UTF-8 ar_KW ISO-8859-6 ar_KW.iso88596 ISO-8859-6 ar_KW.utf8 UTF-8 ar_LB ISO-8859-6 ar_LB.iso88596 ISO-8859-6 ar_LB.utf8 UTF-8 ar_LY ISO-8859-6 ar_LY.iso88596 ISO-8859-6 ar_LY.utf8 UTF-8 ar_MA ISO-8859-6 ar_MA.iso88596 ISO-8859-6 ar_MA.utf8 UTF-8 ar_OM ISO-8859-6 ar_OM.iso88596 ISO-8859-6 ar_OM.utf8 UTF-8 ar_QA ISO-8859-6 ar_QA.iso88596 ISO-8859-6 ar_QA.utf8 UTF-8 ar_SA ISO-8859-6 ar_SA.iso88596 ISO-8859-6 ar_SA.utf8 UTF-8 ar_SD ISO-8859-6 ar_SD.iso88596 ISO-8859-6 ar_SD.utf8 UTF-8 ar_SY ISO-8859-6 ar_SY.iso88596 ISO-8859-6 ar_SY.utf8 UTF-8 ar_TN ISO-8859-6 ar_TN.iso88596 ISO-8859-6 ar_TN.utf8 UTF-8 ar_YE ISO-8859-6 ar_YE.iso88596 ISO-8859-6 ar_YE.utf8 UTF-8 as_IN.utf8 UTF-8 az_AZ.utf8 UTF-8 be_BY CP1251 be_BY.cp1251CP1251 be...@latin UTF-8 be_BY.utf8 UTF-8 be_by.u...@latinUTF-8 bg_BG CP1251 bg_BG.cp1251CP1251 bg_BG.utf8 UTF-8 bn_BD UTF-8 bn_BD.utf8 UTF-8 bn_IN UTF-8 bn_IN.utf8 UTF-8 bokmal ISO-8859-1 bokmål ISO-8859-1 br_FR ISO-8859-1 br...@euro ISO-8859-15 br_FR.iso88591 ISO-8859-1 br_fr.iso885...@euroISO-8859-15 br_FR.utf8 UTF-8 bs_BA ISO-8859-2 bs_BA.iso88592 ISO-8859-2 bs_BA.utf8 UTF-8 byn_ER UTF-8 byn_ER.utf8 UTF-8 C ANSI_X3.4-1968 ca_AD ISO-8859-15 ca_AD.iso885915 ISO-8859-15 ca_AD.utf8 UTF-8 ca_ES ISO-8859-1 ca...@euro ISO-8859-15 ca_ES.iso88591 ISO-8859-1 ca_es.iso885...@euroISO-8859-15 ca_ES.utf8 UTF-8 ca_FR ISO-8859-15 ca_FR.iso885915 ISO-8859-15 ca_FR.utf8 UTF-8 ca_IT ISO-8859-15 ca_IT.iso885915 ISO-8859-15 ca_IT.utf8 UTF-8 catalan ISO-8859-1 croatianISO-8859-2 csb_PL UTF-8 csb_PL.utf8 UTF-8 cs_CZ ISO-8859-2 cs_CZ.iso88592 ISO-8859-2 cs_CZ.utf8 UTF-8 cy_GB ISO-8859-14 cy_GB.iso885914 ISO-8859-14 cy_GB.utf8 UTF-8 czech ISO-8859-2 da_DK ISO-8859-1 da_DK.iso88591 ISO-8859-1 da_DK.iso885915 ISO-8859-15 da_DK.utf8 UTF-8 danish ISO-8859-1 dansk ISO-8859-1 de_AT ISO-8859-1 de...@euro ISO-8859-15 de_AT.iso88591 ISO-8859-1 de_at.iso885...@euroISO-8859-15 de_AT.utf8 UTF-8 de_BE ISO-8859-1 de...@euro ISO-8859-15 de_BE.iso88591 ISO-8859-1 de_be.iso885...@euroISO-8859-15 de_BE.utf8 UTF-8 de_CH ISO-8859-1 de_CH.iso88591 ISO-8859-1 de_CH.utf8 UTF-8 de_DE ISO-8859-1 de...@euro ISO-8859-15 de_DE.iso88591 ISO-8859-1 de_de.iso885...@euroISO-8859-15 de_DE.utf8 UTF-8 de_LU ISO-8859-1 de...@euro ISO-8859-15 de_LU.iso88591 ISO-8859-1 de_lu.iso885...@euroISO-8859-15 de_LU.utf8 UTF-8 deutsch ISO-8859-1 dutch ISO-8859-1 dz_BT UTF-8 dz_BT.utf8 UTF-8 eesti ISO-8859-1 el_CY ISO-8859-7 el_CY.iso88597 ISO-8859-7 el_CY.utf8 UTF-8 el_GR ISO-8859-7 el_GR.iso88597 ISO-8859-7 el_GR.utf8 UTF-8 en_AU ISO-8859-1 en_AU.iso88591 ISO-8859-1 en_AU.utf8
Re: [HACKERS] Writeable CTEs Desgin Doc on Wiki
On 2010-08-17 6:41 AM +0300, Hitoshi Harada wrote: 2010/8/17 Robert Haasrobertmh...@gmail.com: There are really two separate features here, and it might be worth giving them separate names and separate designs (and separate patches). Allowing the main query to be an insert, update, or delete seems easier than allowing the toplevel CTEs to contain those constructs, although I might be wrong about that. Under features, what is DCL? There has been previous talk of allowing WITH (COPY ...) and I am personally of the opinion that it would be nice to be able to do WITH (EXPLAIN ...). DDL seems like a poor idea. So, there are three? One for allowing the main query to be an insert, update, or delete, one for the main subject of writeable CTE with insert, update, delete and one for allowing COPY to return rows. I am attracted by such COPY functionality. And the first part seems easier to be committed separately. Is it possible to get it in by only adding syntax and little parser/planner modification, or more executor code? It's not that simple, see: http://archives.postgresql.org/pgsql-hackers/2010-02/msg01065.php Regards, Marko Tiikkaja -- 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] Git migration timeline
On Tue, Aug 17, 2010 at 1:59 AM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: According to the decision at the developer meeting, the migration to git should happen 17-20 Aug. Here's my proposed timeline. This will obviously affect development work some, and since the original timeline called for us having already released 9.0 buy then ;) 1. Tuesday evening, around 19:00 central european time, which is 17:00 GMT or 12:00 EST, I will freeze the current cvs repository. I will do this by disabling committer login on that box, so please note that this will also make it impossible for committers to do a cvs update from the authenticated repository. So, per discussion, I'd like to suggest that we have a quiet time for say three hours before the repository is closed off, to give interested committers a chance to capture final snapshots of the current repository. IOW, please no more CVS commits after 14:00 GMT tomorrow, Tuesday 8/17. Works for me. I'll send out status reports as I change things, so be sure to check the latest on -hackers if something you thought would work doesn't ;) -- 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] Git migration timeline
On Mon, Aug 16, 2010 at 02:50:35PM -0400, Tom Lane wrote: Better a memory leak than broken ecpg ;-). Nobody except Michael is terribly comfortable with that code, so we'd all rather wait for him to review and apply the patch. This patch was small enough that I felt good about it without having a chance to test it. Anyway, I applied Zoltan's memleak patch to HEAD and 8.4. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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] Git migration timeline
On Tue, Aug 17, 2010 at 11:46 AM, Michael Meskes mes...@postgresql.org wrote: On Mon, Aug 16, 2010 at 02:50:35PM -0400, Tom Lane wrote: Better a memory leak than broken ecpg ;-). Nobody except Michael is terribly comfortable with that code, so we'd all rather wait for him to review and apply the patch. This patch was small enough that I felt good about it without having a chance to test it. Anyway, I applied Zoltan's memleak patch to HEAD and 8.4. What about 9.0? -- 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] PL/pgSQL EXECUTE '..' USING with unknown
2010/8/16 Tom Lane t...@sss.pgh.pa.us: =?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: Yes, and you point out another thing. EXECUTE is a way to bypass the named prepare statement, to be sure query is replanned each time. Unfortunely the current implementation of EXECUTE USING is not working this way. Uh ... what do you base that statement on? About the planning behavior ? With USING, I get a seqscan (cost and long), without USING I have an indexscan(short and costless). And the pg_stat* views confirm that the index is not used. I think that the relevant code is in exec_dynquery_with_params(...). The SPI_cursor_open_with_args receive a complete string, or a string + params. My use case is very simple: EXECUTE 'SELECT status FROM ' || l_partname::regclass || ' WHERE uid = ' || quote_literal(p_uid) INTO r.flag; vs EXECUTE 'SELECT status FROM ' || l_partname::regclass || ' WHERE uid = $1' USING p_uid INTO r.flag; (here it is not bad, but I was very happy to be able to do a safe uid = ANY ($1), with p_uid an array in another context.) regards, tom lane -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- 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] Git migration timeline
On Tue, Aug 17, 2010 at 11:50:20AM +0200, Magnus Hagander wrote: What about 9.0? Will come in a few minutes. I didn't have a checked out version of the 9.0 branch handy in my development environment. Regression test is currently running. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] outPlannedStmt missing transientPlan
This message is probably in the top 10 of 2010's most insignificant messages, but: _outPlannedStmt does not write the bool field transientPlan and it is not accompanied by the comment /* NB: this isn't a complete set of fields */ that exist at other places. 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] Progress indication prototype
* Peter Eisentraut (pete...@gmx.net) wrote: Other comments? Will we be able to use it for psql while keeping just one database connection? I assume the answer is 'no', but it sure would be nice.. Perhaps psql could do something for \copy commands, anyway, but it'd be independent. Thanks, Stephen signature.asc Description: Digital signature
[HACKERS] Fw: patch for pg_ctl.c to add windows service start-type
Sorry. I forget to attach the patch file. Begin forwarded message: Date: Mon, 16 Aug 2010 19:49:20 +0800 From: Quan Zongliang quanzongli...@gmail.com To: pgsql-hackers@postgresql.org Subject: patch for pg_ctl.c to add windows service start-type Hi, all I modified pg_ctl.c to add a new option for Windows service start-type. new option is -S [auto|demand] For example, the command can be used under Windows: pg_ctl register -N s-name -S auto or pg_ctl register -N s-name -S demand The created service will be SERVICE_AUTO_START or SERVICE_DEMAND_START respectively. regards -- Quan Zongliang quanzongli...@gmail.com -- Quan Zongliang quanzongli...@gmail.com pg_ctl.patch Description: Binary data -- 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] Todays git migration results
On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com wrote: OK, try this. It takes about 14 seconds on my machine on my copy of Magnus's test repository. Output looks like this: 14 seconds! That sound much too slow :-) -- 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] Progress indication prototype
On Tue, August 17, 2010 07:19, Peter Eisentraut wrote: Here is a small prototype for a query progress indicator. The patch applies to cvs HEAD (9.1devel) and compiles OK, but make check fails. ./configure --prefix=/var/data1/pg_stuff/pg_installations/pgsql.progress_indicator --with-pgport=6548 --quiet --enable-depend --enable-cassert --enable-debug --with-openssl --with-perl --with-libxml Running initdb manually gives the following error: $ /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/bin/initdb -U rijkers -D /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data -E UTF8 -A md5 --pwfile=/var/data1/pg_stuff/.90devel The files belonging to this database system will be owned by user rijkers. This user must also own the server process. The database cluster will be initialized with locale en_US.UTF-8. The default text search configuration will be set to english. creating directory /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1 ... FATAL: could not create unique index pg_proc_oid_index DETAIL: Key (oid)=(2614) is duplicated. child process exited with exit code 1 initdb: removing data directory /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data this is on centos 5.4 - x86_64 GNU/Linux (2.6.18-164.el5) Erik Rijkers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CVS to GIT conversion - repository freeze
Hello! Here's a reminder, as requested: As of now (14:00 GMT), the cvs repository is frozen. This means that no new commits may be made to the cvs repository anymore! It is still possible to do a cvs update or log or such operations, but please - no more commits until we have the git stuff up and running! -- 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
[HACKERS] Attention committers: no more CVS commits, please!
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: IOW, please no more CVS commits after 14:00 GMT tomorrow, Tuesday 8/17. OK, would someone please send an email to hackers at that time as a reminder? I might not be available then. Here you go. Per yesterday's discussion, access to the master PG CVS repository will be shut off at approximately 17:00 GMT, three hours from now, to begin the conversion to git. So that all interested people can capture final snapshots of the repository for archival purposes, please do not make any further commits into the CVS repository. Development will resume once the git repository is up and validated. 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] Todays git migration results
On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker bada...@gmail.com wrote: On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com wrote: OK, try this. It takes about 14 seconds on my machine on my copy of Magnus's test repository. Output looks like this: 14 seconds! That sound much too slow :-) /me is very sorry master. Please beat your unworthy servant only lightly... or alternatively, buy me a faster machine. It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N years. Also, it could possibly be rewritten to be faster still if it started N simultaneous copies of git log simultaneously instead of in sequence, and processed them incrementally rather than throwing them into a giant hash table, which would also probably cut down memory usage quite a bit. However, I'm not really inclined to spend a lot of time on it unless it's actually bugging Tom. Despite the fact that I wrote this basically in response to Tom's complaint, I do think that it's generally useful, and will likely use it myself from time to time. So I think we should consider checking it into src/tools. Perhaps someone will feel an urge to hack on it further. Another useful enhancement would be to allow it to run on just those commits whose log message includes a certain string. This would be useful for answering the question which branches was this patch committed to?. Of course, you can find that out using the existing implementation also by searching the output, but this would be more convenient (and faster). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] Fw: patch for pg_ctl.c to add windows service start-type
On Tue, Aug 17, 2010 at 2:58 PM, Quan Zongliang quanzongli...@gmail.com wrote: Sorry. I forget to attach the patch file. Without looking at the details of this patch, it looks reasonable - so please put it on the commitfest page, if you haven't already. It does, however, lack documentation updates - that needs to be done before it can get applied. -- 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] Todays git migration results
On Tue, Aug 17, 2010 at 4:17 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker bada...@gmail.com wrote: On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com wrote: OK, try this. It takes about 14 seconds on my machine on my copy of Magnus's test repository. Output looks like this: 14 seconds! That sound much too slow :-) /me is very sorry master. Please beat your unworthy servant only lightly... or alternatively, buy me a faster machine. It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N years. Also, it could possibly be rewritten to be faster still if it started N simultaneous copies of git log simultaneously instead of in sequence, and processed them incrementally rather than throwing them into a giant hash table, which would also probably cut down memory usage quite a bit. However, I'm not really inclined to spend a lot of time on it unless it's actually bugging Tom. Despite the fact that I wrote this basically in response to Tom's complaint, I do think that it's generally useful, and will likely use it myself from time to time. So I think we should consider checking it into src/tools. Perhaps someone will feel an urge to hack on it further. Another useful enhancement would be to allow it to run on +1 for putting this in src/tools. -- 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] PL/pgSQL EXECUTE '..' USING with unknown
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: 2010/8/16 Tom Lane t...@sss.pgh.pa.us: =?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: Unfortunely the current implementation of EXECUTE USING is not working this way. Uh ... what do you base that statement on? About the planning behavior ? With USING, I get a seqscan (cost and long), without USING I have an indexscan(short and costless). It works as expected for me. What PG version are you using exactly? Could you provide a self-contained example? 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] Todays git migration results
Robert Haas robertmh...@gmail.com writes: It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N years. Also, it could possibly be rewritten to be faster still if it started N simultaneous copies of git log simultaneously instead of in sequence, and processed them incrementally rather than throwing them into a giant hash table, which would also probably cut down memory usage quite a bit. However, I'm not really inclined to spend a lot of time on it unless it's actually bugging Tom. FWIW, I would find a --since option useful (since I use the equivalent option of cvs2cl), but those other refinements don't seem of interest. 14 seconds is already an order of magnitude or two faster than cvs2cl. So I think we should consider checking it into src/tools. +1 ... but not today ;-) 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] Todays git migration results
On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N years. Also, it could possibly be rewritten to be faster still if it started N simultaneous copies of git log simultaneously instead of in sequence, and processed them incrementally rather than throwing them into a giant hash table, which would also probably cut down memory usage quite a bit. However, I'm not really inclined to spend a lot of time on it unless it's actually bugging Tom. FWIW, I would find a --since option useful (since I use the equivalent option of cvs2cl), but those other refinements don't seem of interest. 14 seconds is already an order of magnitude or two faster than cvs2cl. I'm pretty sure that with such an option, you'd be down to sub-second speed. So I think we should consider checking it into src/tools. +1 ... but not today ;-) :-) -- 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] Todays git migration results
On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com wrote: On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker bada...@gmail.com wrote: On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com wrote: OK, try this. It takes about 14 seconds on my machine on my copy of Magnus's test repository. Output looks like this: 14 seconds! That sound much too slow :-) /me is very sorry master. Please beat your unworthy servant only lightly... or alternatively, buy me a faster machine. Well, I might be able to afford a beer. I do think 14 seconds is quite amazing. It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N years. Presumably that could even be from the last point release to HEAD. Despite the fact that I wrote this basically in response to Tom's complaint, I do think that it's generally useful, and will likely use it myself from time to time. Yeah, I might find it useful as well which is why I chimed in. -- 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] Todays git migration results
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote: On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com wrote: /me is very sorry master. Please beat your unworthy servant only lightly... or alternatively, buy me a faster machine. Well, I might be able to afford a beer. Done! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] refactoring comment.c
I wrote: Maybe so, but the parser is expected to put out a representation that will still be valid when the command is executed some time later. Rereading this, I see I didn't make my point very clearly. The reason this code doesn't belong in parser/ is that there's no prospect the parser itself would ever use it. ObjectAddress is an execution-time creature because we don't want utility statement representations to be resolved to OID-level detail before they execute. 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] outPlannedStmt missing transientPlan
Yeb Havinga yebhavi...@gmail.com writes: This message is probably in the top 10 of 2010's most insignificant messages, but: _outPlannedStmt does not write the bool field transientPlan and it is not accompanied by the comment /* NB: this isn't a complete set of fields */ that exist at other places. [ squint... ] That's weird. copyfuncs.c is missing the field too, which might be a less insignificant bug. Will fix once we have a working SCM again. 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] Todays git migration results
On Tue, Aug 17, 2010 at 09:21, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com wrote:
/me is very sorry master. Please beat your unworthy servant only
lightly... or alternatively, buy me a faster machine.
Well, I might be able to afford a beer.
Done!
Well on 2nd thought, maybe not... If people start collecting I'll be
broke (notably I owe tom quite a few :-).
Anyway find below version that passes any arguments through to git-log.
Now you can do git-topo-order --since='1 year', takes a whopping
0.430s for me :-)
--
--- git-topo-order (1) 2010-08-17 09:44:18.069517261 -0600
+++ git-topo-order 2010-08-17 09:45:34.109812004 -0600
@@ -26,6 +26,7 @@
use strict;
use warnings;
require Date::Calc;
+use IPC::Open2;
my @BRANCHES = qw(master REL9_0_STABLE REL8_4_STABLE REL8_3_STABLE
REL8_2_STABLE REL8_1_STABLE REL8_0_STABLE REL7_4_STABLE);
@@ -34,11 +35,13 @@
my %all_commits_by_branch;
my %commit;
+my %position;
for my $branch (@BRANCHES) {
my $commitnum = 0;
- open(GITLOG, git log --date=iso origin/$branch |)
+ $position{$branch} = 0;
+ open2(my $git_out, my $git_in, qw(git log --date=iso), @ARGV,
origin/$branch)
|| die can't run git log origin/$branch: $!;
- while (my $line = GITLOG) {
+ while (my $line = $git_out) {
if ($line =~ /^commit\s+(.*)/) {
push_commit(\%commit) if %commit;
%commit = (
@@ -60,10 +63,6 @@
}
}
-my %position;
-for my $branch (@BRANCHES) {
- $position{$branch} = 0;
-}
while (1) {
my $best_branch;
my $best_inversions;
--
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] PL/pgSQL EXECUTE '..' USING with unknown
2010/8/17 Tom Lane t...@sss.pgh.pa.us: =?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: 2010/8/16 Tom Lane t...@sss.pgh.pa.us: =?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: Unfortunely the current implementation of EXECUTE USING is not working this way. Uh ... what do you base that statement on? About the planning behavior ? With USING, I get a seqscan (cost and long), without USING I have an indexscan(short and costless). It works as expected for me. What PG version are you using exactly? Could you provide a self-contained example? postgresql 8.4.4. Yes I'll work one out this evening. more or less : table foo (uid char(32) PK, flag boolean), uids are md5sum. +-6M rows. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- 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] security label support, part.2
Stephen Frost sfr...@snowman.net wrote: Let's not build the complication of dealing with inheiritance/ child relations into the external security system when we're in the middle of trying to get rid of that distinction in core PG though. I didn't realize we were trying to do that. I know we're working on making partitioning easier, but there hasn't been a decision to stop supporting other uses of inheritance, has there? -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] Progress indication prototype
On tis, 2010-08-17 at 08:31 -0400, Stephen Frost wrote: Will we be able to use it for psql while keeping just one database connection? I assume the answer is 'no', but it sure would be nice.. How do you expect that to behave? I suppose the backend could send NOTICE-like messages every 1% or so, and then psql could try to display that in some way (which?), but then I suspect that a) it will annoy some people, so b) it will have to be off by default, and then c) it won't be enabled when you need it. -- 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] PL/pgSQL EXECUTE '..' USING with unknown
2010/8/17 Cédric Villemain cedric.villemain.deb...@gmail.com: 2010/8/17 Tom Lane t...@sss.pgh.pa.us: =?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: 2010/8/16 Tom Lane t...@sss.pgh.pa.us: =?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: Unfortunely the current implementation of EXECUTE USING is not working this way. Uh ... what do you base that statement on? About the planning behavior ? With USING, I get a seqscan (cost and long), without USING I have an indexscan(short and costless). It works as expected for me. What PG version are you using exactly? Could you provide a self-contained example? postgresql 8.4.4. Yes I'll work one out this evening. more or less : table foo (uid char(32) PK, flag boolean), uids are md5sum. +-6M rows. Here we are. A simple usecase. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support usecase_exec_using.sql Description: Binary data -- 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] Progress indication prototype
On tis, 2010-08-17 at 15:59 +0200, Erik Rijkers wrote: creating template1 database in /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1 ... FATAL: could not create unique index pg_proc_oid_index DETAIL: Key (oid)=(2614) is duplicated. Probably merge conflict with parallel developments. Try changing the OID. -- 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] PL/pgSQL EXECUTE '..' USING with unknown
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: Here we are. A simple usecase. The reason you have an issue here is that the column is char(n) while the parameter is text. So the non-USING execute is equivalent to regression=# explain SELECT flag FROM foo where uid = 'cfcd208495d565ef66e7dff9f98764da'; QUERY PLAN Index Scan using foo_pkey on foo (cost=0.00..8.27 rows=1 width=1) Index Cond: (uid = 'cfcd208495d565ef66e7dff9f98764da'::bpchar) (2 rows) while the EXECUTE USING is equivalent to regression=# explain SELECT flag FROM foo where uid = 'cfcd208495d565ef66e7dff9f98764da'::text; QUERY PLAN Seq Scan on foo (cost=0.00..24.02 rows=5 width=1) Filter: ((uid)::text = 'cfcd208495d565ef66e7dff9f98764da'::text) (2 rows) and the reason you don't get an indexscan on the latter is that it's a TEXT comparison not a BPCHAR comparison; which is different because of the rules about ignoring trailing blanks. char(n) sucks. Avoid it if possible. If you insist on using it, be very very careful about which comparison semantics you're asking for. 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] Progress indication prototype
On Tue, Aug 17, 2010 at 06:31, Stephen Frost sfr...@snowman.net wrote: * Peter Eisentraut (pete...@gmx.net) wrote: Other comments? Will we be able to use it for psql while keeping just one database connection? I assume the answer is 'no', but it sure would be nice.. I think thats something that could be worked out in libpq after this patch. Although I'd bump your nice to an awesome. -- 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] Todays git migration results
Robert Haas wrote: On Tue, Aug 17, 2010 at 9:55 AM, Alex Hunsaker bada...@gmail.com wrote: On Mon, Aug 16, 2010 at 18:48, Robert Haas robertmh...@gmail.com wrote: OK, try this. ?It takes about 14 seconds on my machine on my copy of Magnus's test repository. ?Output looks like this: 14 seconds! ?That sound much too slow :-) /me is very sorry master. Please beat your unworthy servant only lightly... or alternatively, buy me a faster machine. It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N Yes, I will definately need a --since argument like cvs log -d which restricts by date. I usually find the data of the previous release and use that to pull cvs logs to create the release notes. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Todays git migration results
Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N years. Also, it could possibly be rewritten to be faster still if it started N simultaneous copies of git log simultaneously instead of in sequence, and processed them incrementally rather than throwing them into a giant hash table, which would also probably cut down memory usage quite a bit. However, I'm not really inclined to spend a lot of time on it unless it's actually bugging Tom. FWIW, I would find a --since option useful (since I use the equivalent option of cvs2cl), but those other refinements don't seem of interest. 14 seconds is already an order of magnitude or two faster than cvs2cl. Yes, my operation on a year's worth of logs can take a few minutes. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Todays git migration results
Magnus Hagander wrote: On Tue, Aug 17, 2010 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: It should get a bit faster if we reduce the number of branches it examines, which I assume is something we can do once we desupport 7.4 and 8.0. ?We could also add a --since argument which would doubtless speed things up a lot, by truncating the history to, say, the last N years. ?Also, it could possibly be rewritten to be faster still if it started N simultaneous copies of git log simultaneously instead of in sequence, and processed them incrementally rather than throwing them into a giant hash table, which would also probably cut down memory usage quite a bit. ?However, I'm not really inclined to spend a lot of time on it unless it's actually bugging Tom. FWIW, I would find a --since option useful (since I use the equivalent option of cvs2cl), but those other refinements don't seem of interest. 14 seconds is already an order of magnitude or two faster than cvs2cl. I'm pretty sure that with such an option, you'd be down to sub-second speed. I assumed you would say git would produce the results before we asked for them. ;-) -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Todays git migration results
On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker bada...@gmail.com wrote: On Tue, Aug 17, 2010 at 09:21, Robert Haas robertmh...@gmail.com wrote: On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote: On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com wrote: /me is very sorry master. Please beat your unworthy servant only lightly... or alternatively, buy me a faster machine. Well, I might be able to afford a beer. Done! Well on 2nd thought, maybe not... If people start collecting I'll be broke (notably I owe tom quite a few :-). Cheapskate. Anyway find below version that passes any arguments through to git-log. Yeah, I don't think I want to go that route. Arbitrary user-specified arguments to git-log might not be (probably aren't) sane in this context, and there's also a chance that might want to have arguments that are handled internally by the script, rather than passed through. But I do agree that passing --since through is sensible. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] Python 2.7 deprecated the PyCObject API?
On fre, 2010-08-13 at 20:20 -0400, Tom Lane wrote: According to a discussion over in Fedora-land, $subject is true: http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html I see several calls in plpython.c that seem to refer to PyCObject stuff. Anybody have any idea if we need to do something about this? Some exception handling might be good, but I think we don't need to abandon the API yet. It's only pending deprecation. -- 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] security label support, part.2
Stephen Frost sfr...@snowman.net wrote: No.. and I'm not sure we ever would. What we *have* done is removed all permissions checking on child tables when a parent is being queried.. OK, that clarifies things. Thanks. So, essentially that means that you need to set all ancestor levels to something at least as strict as the intersection of all the permissions on lower levels to avoid exposing something through an ancestor which is restricted in a descendant. And you'd better trust the owner of any table you extend, because they can bypass any attempt to restrict access to the table you create which extends theirs. I hope those security implications are well documented. -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] security label support, part.2
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote: Stephen Frost sfr...@snowman.net wrote: Let's not build the complication of dealing with inheiritance/ child relations into the external security system when we're in the middle of trying to get rid of that distinction in core PG though. I didn't realize we were trying to do that. I know we're working on making partitioning easier, but there hasn't been a decision to stop supporting other uses of inheritance, has there? No.. and I'm not sure we ever would. What we *have* done is removed all permissions checking on child tables when a parent is being queried.. Stephen signature.asc Description: Digital signature
Re: [HACKERS] Progress indication prototype
* Alex Hunsaker (bada...@gmail.com) wrote: On Tue, Aug 17, 2010 at 06:31, Stephen Frost sfr...@snowman.net wrote: * Peter Eisentraut (pete...@gmx.net) wrote: Other comments? Will we be able to use it for psql while keeping just one database connection? I assume the answer is 'no', but it sure would be nice.. I think thats something that could be worked out in libpq after this patch. Although I'd bump your nice to an awesome. If it was configurable via \set and I could drop it in my .psqlrc, and it knew not to only do it after a few seconds (otherwise it'd be far too much)... I don't like how the backend would have to send something NOTICE-like, I had originally been thinking gee, it'd be nice if psql could query pg_stat while doing something else, but that's not really possible... So, I guess NOTICE-like messages would work, if the backend could be taught to do it. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] security label support, part.2
On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net wrote: No.. and I'm not sure we ever would. What we *have* done is removed all permissions checking on child tables when a parent is being queried.. Yeah. I'm not totally sure that is sensible for a MAC environment. Heck, it's arguably incorrect (though perhaps quite convenient) in a DAC environment. Anyway, I wonder if it would be sensible to try to adjust the structure of the DAC permissions checks so enhanced security providers can make their own decision about how to handle this case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] Progress indication prototype
On Tue, August 17, 2010 19:13, Peter Eisentraut wrote: On tis, 2010-08-17 at 15:59 +0200, Erik Rijkers wrote: creating template1 database in /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1 ... FATAL: could not create unique index pg_proc_oid_index DETAIL: Key (oid)=(2614) is duplicated. Probably merge conflict with parallel developments. Try changing the OID. Could you elaborate? What is a 'merge conflict'? Or 'parallel developments'? Do you mean the current git conversion? (I get source from a local rsync'ed cvs repository) How can I 'change OID'? This error comes out of an initial initdb run. (There are several other test-instances on this machine (several running), but with their own $PGDATA, $PGPORT. - they can't interfere with each other, can they?) thanks, Erik Rijkers -- 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] refactoring comment.c
On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: Maybe so, but the parser is expected to put out a representation that will still be valid when the command is executed some time later. Rereading this, I see I didn't make my point very clearly. The reason this code doesn't belong in parser/ is that there's no prospect the parser itself would ever use it. ObjectAddress is an execution-time creature because we don't want utility statement representations to be resolved to OID-level detail before they execute. Well, that is a good reason for doing it your way, but I'm slightly fuzzy on why we need a crisp separation between parse-time and execution-time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] Todays git migration results
On Tue, Aug 17, 2010 at 11:54, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 11:46 AM, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Aug 17, 2010 at 09:21, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 17, 2010 at 10:51 AM, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Aug 17, 2010 at 08:17, Robert Haas robertmh...@gmail.com wrote:
/me is very sorry master. Please beat your unworthy servant only
lightly... or alternatively, buy me a faster machine.
Well, I might be able to afford a beer.
Done!
Well on 2nd thought, maybe not... If people start collecting I'll be
broke (notably I owe tom quite a few :-).
Cheapskate.
Its because i'm thinking of getting everyone on -hackers a pony instead!
Anyway find below version that passes any arguments through to git-log.
Yeah, I don't think I want to go that route. Arbitrary user-specified
arguments to git-log might not be (probably aren't) sane in this
context, and there's also a chance that might want to have arguments
that are handled internally by the script, rather than passed through.
Yeah, I originally was just going to do --since. After seeing how
many args git-log can have-- It looked like people might request new
args into the foreseeable future.
Find --since below FWIW:
--
--- git-topo-order (1) 2010-08-17 09:44:18.069517261 -0600
+++ git-topo-order 2010-08-17 12:10:07.312355246 -0600
@@ -26,6 +26,12 @@
use strict;
use warnings;
require Date::Calc;
+use IPC::Open2;
+use Getopt::Long;
+
+# since gets passed through to git-log
+my $since;
+GetOptions('since=s'=\$since);
my @BRANCHES = qw(master REL9_0_STABLE REL8_4_STABLE REL8_3_STABLE
REL8_2_STABLE REL8_1_STABLE REL8_0_STABLE REL7_4_STABLE);
@@ -34,11 +40,19 @@
my %all_commits_by_branch;
my %commit;
+my %position;
for my $branch (@BRANCHES) {
my $commitnum = 0;
- open(GITLOG, git log --date=iso origin/$branch |)
+ $position{$branch} = 0;
+
+ my @args = qw(git log --date=iso);
+ push @args, --since=$since if($since);
+ push @args, origin/$branch;
+
+ open2(my $git_out, my $git_in, @args)
|| die can't run git log origin/$branch: $!;
- while (my $line = GITLOG) {
+
+ while (my $line = $git_out) {
if ($line =~ /^commit\s+(.*)/) {
push_commit(\%commit) if %commit;
%commit = (
@@ -60,10 +74,6 @@
}
}
-my %position;
-for my $branch (@BRANCHES) {
- $position{$branch} = 0;
-}
while (1) {
my $best_branch;
my $best_inversions;
--
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] Writeable CTEs Desgin Doc on Wiki
On Mon, Aug 16, 2010 at 11:41 PM, Hitoshi Harada umi.tan...@gmail.com wrote: 2010/8/17 Robert Haas robertmh...@gmail.com: On Sun, Aug 15, 2010 at 7:44 AM, Hitoshi Harada umi.tan...@gmail.com wrote: We (Marko, David Fetter and I) discussed on IRC about design of writeable CTEs. It does and will contain not only syntax but also miscellaneous specifications, general rules and restrictions. I hope this will help the patch reviews and stop dangerous design at the early stage. If you find something wrong, or have request, please notify. http://wiki.postgresql.org/wiki/WriteableCTEs We will keep to add details. Any comments are welcome. There are really two separate features here, and it might be worth giving them separate names and separate designs (and separate patches). Allowing the main query to be an insert, update, or delete seems easier than allowing the toplevel CTEs to contain those constructs, although I might be wrong about that. Under features, what is DCL? There has been previous talk of allowing WITH (COPY ...) and I am personally of the opinion that it would be nice to be able to do WITH (EXPLAIN ...). DDL seems like a poor idea. So, there are three? One for allowing the main query to be an insert, update, or delete, one for the main subject of writeable CTE with insert, update, delete and one for allowing COPY to return rows. I am attracted by such COPY functionality. Yeah, I'd say there are at least three. Maybe more than three. And the first part seems easier to be committed separately. Is it possible to get it in by only adding syntax and little parser/planner modification, or more executor code? I'm not sure exactly what is involved, but it seems to me that breaking large features into moderately-sized, self-contained chunks tends to drastically shorten the time to commit. Of course, this is only true if each patch is really an independent feature with independent utility, but in this case it seems fairly easy to draw a clean line. P.S. Call me a prude, but your choice of shorthand for insert-update-delete may not be the best. I think so, too :(. But there's no good expression in my mind. Suggestions? DML? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Additional git conversion steps
There are a couple of things I think should happen ASAP once the git repository is up, but weren't mentioned in Magnus' plans: 1. The various .cvsignore files need to be replaced by .gitignore files. I am not sure though whether this is a trivial conversion --- does git have similar default rules about ignoring .o, etc? 2. One thing I will miss from the removal of $PostgreSQL$ tags is that they guaranteed that every file contained its own full pathname within the source tree. I found myself using that an awful lot, mainly as a source for copying-and-pasting file paths. To substitute for the tags, I would like to propose a project standard that every file contain its pathname in the header comment, not just the bare filename which is the de facto standard at the moment. For example, instead of /*- * * plancache.c *Plan cache management. we should have /*- * * src/backend/utils/cache/plancache.c *Plan cache management. Whatever we do with the .cvsignore files will need to be back-patched into all active branches, but I am not so anal-retentive as to wish to back-patch the pathname comment changes. Comments? 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] refactoring comment.c
Robert Haas robertmh...@gmail.com writes: On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Rereading this, I see I didn't make my point very clearly. The reason this code doesn't belong in parser/ is that there's no prospect the parser itself would ever use it. ObjectAddress is an execution-time creature because we don't want utility statement representations to be resolved to OID-level detail before they execute. Well, that is a good reason for doing it your way, but I'm slightly fuzzy on why we need a crisp separation between parse-time and execution-time. I don't insist that the separation has to be crisp. I'm merely saying that putting a large chunk of useful-only-at-execution-time code into backend/parser is the Wrong Thing. 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] security label support, part.2
* Robert Haas (robertmh...@gmail.com) wrote: On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net wrote: No.. and I'm not sure we ever would. What we *have* done is removed all permissions checking on child tables when a parent is being queried.. Yeah. I'm not totally sure that is sensible for a MAC environment. Heck, it's arguably incorrect (though perhaps quite convenient) in a DAC environment. Anyway, I wonder if it would be sensible to try to adjust the structure of the DAC permissions checks so enhanced security providers can make their own decision about how to handle this case. To be honest, I don't really like the way this is done at all. I'd rather have it such that if and when a table is made a child of another table, it should inherit the permissions of the parent and be kept that way, or it should be completely independent (which is the situation we used to have), or, last resort, we should complain when they don't match. Or we could just not error when we hit a child table that the caller doesn't have access to (but also not return the records). The problem is that we've got different users that want to use inheiritance for very different purposes and we havn't got a way to address all of them. I do worry that we're going to regret making the change to not check permissions on child tables, but at the same time, any query which would have been impacted by that would have failed, so that really begs the question of do people really use/want different permissions on child tables than the parent?. I tend to think 'no', and would rather force them and keep them the same, but maybe that's just me.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Additional git conversion steps
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: There are a couple of things I think should happen ASAP once the git repository is up, but weren't mentioned in Magnus' plans: 1. The various .cvsignore files need to be replaced by .gitignore files. I am not sure though whether this is a trivial conversion --- does git have similar default rules about ignoring .o, etc? No, it doesn't. There are some policy decisions to be made here, too, about what we wish to actually ignore. Personally, my preference would be to arrange to ignore all and only *build products*, but not things like *.rej files that CVS helpfully fails to mention. Also, I think we should consider having just one .gitignore file at the top level rather than a file in every individual directory (you can include relative pathnames). I think that might be significantly easier to manage. 2. One thing I will miss from the removal of $PostgreSQL$ tags is that they guaranteed that every file contained its own full pathname within the source tree. I found myself using that an awful lot, mainly as a source for copying-and-pasting file paths. To substitute for the tags, I would like to propose a project standard that every file contain its pathname in the header comment, not just the bare filename which is the de facto standard at the moment. For example, instead of This seems totally useless to me. However, I suppose you can do it if it makes you happy... Whatever we do with the .cvsignore files will need to be back-patched into all active branches, but I am not so anal-retentive as to wish to back-patch the pathname comment changes. Yes, we should DEFINITELY back-patch the .cvsignore stuff. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] refactoring comment.c
On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Tue, Aug 17, 2010 at 11:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Rereading this, I see I didn't make my point very clearly. The reason this code doesn't belong in parser/ is that there's no prospect the parser itself would ever use it. ObjectAddress is an execution-time creature because we don't want utility statement representations to be resolved to OID-level detail before they execute. Well, that is a good reason for doing it your way, but I'm slightly fuzzy on why we need a crisp separation between parse-time and execution-time. I don't insist that the separation has to be crisp. I'm merely saying that putting a large chunk of useful-only-at-execution-time code into backend/parser is the Wrong Thing. OK, but there should be a reason for that. For example, if there are circumstances when we parse a statement, and then time passes, and then we execute it later, that's a good argument for what you're saying here. But otherwise, the fact that these bits of barely-parsed stuff get passed all over the backend seems like an inconvenient wart. I was actually thinking of proposing that we make more things happen during the parsing process and postpone less to the execution phase, and I need to make sure that I understand why you don't want to do that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] Additional git conversion steps
Tom Lane t...@sss.pgh.pa.us wrote: 1. The various .cvsignore files need to be replaced by .gitignore files. I could post my .gitignore file if you like. I'm sure it can be improved upon by others, but it gives me a clean `git status` result when it should. Probably better than nothing as a start. * src/backend/utils/cache/plancache.c * Plan cache management. Sounds good to me. -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] Additional git conversion steps
Robert Haas robertmh...@gmail.com writes: On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: 1. The various .cvsignore files need to be replaced by .gitignore files. I am not sure though whether this is a trivial conversion --- does git have similar default rules about ignoring .o, etc? No, it doesn't. There are some policy decisions to be made here, too, about what we wish to actually ignore. Personally, my preference would be to arrange to ignore all and only *build products*, but not things like *.rej files that CVS helpfully fails to mention. My understanding of the point of an ignore file is to make sure that the SCM doesn't decide to commit junk into the repository. So *.rej, and editor backup files (*~) should be in the ignore files IMO. I'm not totally clear on what CVS' default list is, though. Also, I think we should consider having just one .gitignore file at the top level rather than a file in every individual directory (you can include relative pathnames). I think that might be significantly easier to manage. Well, the per-directory files are that way because CVS insists, but we could certainly consider alternative layouts if git can do better. I'm not convinced that one big file is better though. Can we use a single file at the top level for policy (*.o, *.so, etc) and additional files lower down for specific exceptions (parser/gram.c)? 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] PL/pgSQL EXECUTE '..' USING with unknown
2010/8/17 Tom Lane t...@sss.pgh.pa.us: =?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes: Here we are. A simple usecase. The reason you have an issue here is that the column is char(n) while the parameter is text. So the non-USING execute is equivalent to regression=# explain SELECT flag FROM foo where uid = 'cfcd208495d565ef66e7dff9f98764da'; QUERY PLAN Index Scan using foo_pkey on foo (cost=0.00..8.27 rows=1 width=1) Index Cond: (uid = 'cfcd208495d565ef66e7dff9f98764da'::bpchar) (2 rows) while the EXECUTE USING is equivalent to regression=# explain SELECT flag FROM foo where uid = 'cfcd208495d565ef66e7dff9f98764da'::text; QUERY PLAN Seq Scan on foo (cost=0.00..24.02 rows=5 width=1) Filter: ((uid)::text = 'cfcd208495d565ef66e7dff9f98764da'::text) (2 rows) and the reason you don't get an indexscan on the latter is that it's a TEXT comparison not a BPCHAR comparison; which is different because of the rules about ignoring trailing blanks. char(n) sucks. Avoid it if possible. If you insist on using it, be very very careful about which comparison semantics you're asking for. Oh! Thank you very much for those clarifications. ... and I am sorry for the noisy report ... -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- 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] Additional git conversion steps
Tom Lane t...@sss.pgh.pa.us wrote: Can we use a single file at the top level for policy (*.o, *.so, etc) and additional files lower down for specific exceptions (parser/gram.c)? Yes. Just as a start, done on a rather ad hoc basis, mine is attached. If you put that at the top, current HEAD is clean, at least for the builds I do. -Kevin .gitignore Description: Binary data -- 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] Additional git conversion steps
On 18 August 2010 04:42, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: No, it doesn't. There are some policy decisions to be made here, too, about what we wish to actually ignore. Personally, my preference would be to arrange to ignore all and only *build products*, but not things like *.rej files that CVS helpfully fails to mention. My understanding of the point of an ignore file is to make sure that the SCM doesn't decide to commit junk into the repository. So *.rej, and editor backup files (*~) should be in the ignore files IMO. Things are subtly different with git. git will never decide to add a file to the index unless you explicitly tell it to, with `git add`. So the idea with a .gitignore file is to tune it so that when you type `git status` it only tells you about things that you might want to either a) commit, or b) clean up. With .rej files and other such items, it's nice that `git status` pipes up about them, because it reminds you to get rid of them when you're done hacking. Well, the per-directory files are that way because CVS insists, but we could certainly consider alternative layouts if git can do better. I'm not convinced that one big file is better though. Can we use a single file at the top level for policy (*.o, *.so, etc) and additional files lower down for specific exceptions (parser/gram.c)? You sure can! Cheers, BJ -- 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] Python 2.7 deprecated the PyCObject API?
On tis, 2010-08-17 at 20:55 +0300, Peter Eisentraut wrote: On fre, 2010-08-13 at 20:20 -0400, Tom Lane wrote: According to a discussion over in Fedora-land, $subject is true: http://lists.fedoraproject.org/pipermail/devel/2010-August/140995.html I see several calls in plpython.c that seem to refer to PyCObject stuff. Anybody have any idea if we need to do something about this? Some exception handling might be good, but I think we don't need to abandon the API yet. It's only pending deprecation. Here is a patch. The crash is reproducible, if warnings are turned into errors. Index: plpython.c === RCS file: /cvsroot/pgsql/src/pl/plpython/plpython.c,v retrieving revision 1.148 diff -u -3 -p -r1.148 plpython.c --- plpython.c 8 Jul 2010 19:00:11 - 1.148 +++ plpython.c 17 Aug 2010 18:45:49 - @@ -1315,6 +1315,8 @@ PLy_procedure_get(FunctionCallInfo fcinf elog(FATAL, expected a PyCObject, didn't get one); proc = PyCObject_AsVoidPtr(plproc); + if (!proc) + PLy_elog(ERROR, PyCObject_AsVoidPtr() failed); if (proc-me != plproc) elog(FATAL, proc-me != plproc); /* did we find an up-to-date cache entry? */ @@ -1539,8 +1541,11 @@ PLy_procedure_create(HeapTuple procTup, PLy_procedure_compile(proc, procSource); pfree(procSource); + procSource = NULL; proc-me = PyCObject_FromVoidPtr(proc, NULL); + if (!proc-me) + PLy_elog(ERROR, PyCObject_FromVoidPtr() failed); PyDict_SetItemString(PLy_procedure_cache, key, proc-me); } PG_CATCH(); -- 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] refactoring comment.c
Robert Haas robertmh...@gmail.com writes: On Tue, Aug 17, 2010 at 2:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: I don't insist that the separation has to be crisp. I'm merely saying that putting a large chunk of useful-only-at-execution-time code into backend/parser is the Wrong Thing. OK, but there should be a reason for that. For example, if there are circumstances when we parse a statement, and then time passes, and then we execute it later, that's a good argument for what you're saying here. Yeah, and that's exactly what happens with utility statements that (for example) get into the plan cache. I was actually thinking of proposing that we make more things happen during the parsing process and postpone less to the execution phase, and I need to make sure that I understand why you don't want to do that. The reason to not do that is that you'd have to hold more locks, and do more management of those locks, in order to protect the more-thoroughly-analyzed statements from parsing to execution. In the case of utility statements, particularly ones that affect a lot of objects, I think that would be a seriously bad idea. In fact it would fly in the face of lessons we learned the hard way. The whole of parser/parse_utilcmd.c is code that we used to execute at parse time, and had to rearrange to postpone to execution time, in order to avoid nasty bugs. It's still in backend/parser because it fits well there and uses a lot of parser infrastructure that's shared with parse-time analysis of DML statements. But neither of those statements hold for the ObjectAddress resolution code. 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] Additional git conversion steps
Kevin Grittner kevin.gritt...@wicourts.gov writes: I could post my .gitignore file if you like. Yeah, let's see it. 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] Progress indication prototype
--On 17. August 2010 20:08:51 +0200 Erik Rijkers e...@xs4all.nl wrote: How can I 'change OID'? This error comes out of an initial initdb run. (There are several other test-instances on this machine (several running), but with their own $PGDATA, $PGPORT. - they can't interfere with each other, can they?) I assume Peter means an OID conflict, resulting from concurrent patches or drifting code. Looks like pg_stat_get_backend_progress() has a conflict in current HEAD with xmlexists() (both will get 2614 in my current version of pg_proc.h). You need to resolve this to have initdb succeed. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] git: uh-oh
It appears that the git conversion of the CVS repository is seriously screwed up. For example, if you look at this: http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=shortlog;h=refs/tags/REL8_3_10 The first few revs look OK, but the you get to this: 2010-02-28 PostgreSQL... This commit was manufactured by cvs2svn to create branch REL8_3_STABLE Prior to that commit, this history is nonsense - it appears to be the history of our 9.0 development prior to that date. I would say we're going back to good old CVS. It's too bad that nobody noticed this sooner, but I'm glad I noticed today rather than tomorrow. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
Robert Haas robertmh...@gmail.com writes: It appears that the git conversion of the CVS repository is seriously screwed up. For example, if you look at this: Um ... Magnus has not given any report that he's finished running the conversion. What exactly are you looking at? It's too bad that nobody noticed this sooner, but I'm glad I noticed today rather than tomorrow. We're not going to start using the git repository until everyone is satisfied it's OK, both as to current contents and history. 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] git: uh-oh
On Tue, Aug 17, 2010 at 21:16, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: It appears that the git conversion of the CVS repository is seriously screwed up. For example, if you look at this: Um ... Magnus has not given any report that he's finished running the conversion. What exactly are you looking at? That's the previous conversion. The one that we used to verify that things looked ok. Seems nobody caught this :S The new migration looks similarly weird. Does anybody with some more git-fu have any clue how this can be? The tip of every branch, and every single tag, all have the correct data in them, but some revisions in between seem majorly confused. It's too bad that nobody noticed this sooner, but I'm glad I noticed today rather than tomorrow. We're not going to start using the git repository until everyone is satisfied it's OK, both as to current contents and history. Yeah.. -- 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] Additional git conversion steps
On Tue, Aug 17, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote: There are a couple of things I think should happen ASAP once the git repository is up, but weren't mentioned in Magnus' plans: 1. The various .cvsignore files need to be replaced by .gitignore files. I am not sure though whether this is a trivial conversion --- does git have similar default rules about ignoring .o, etc? Certainly, with two variations: 1. If you don't want to hear about *.rej or *.orig files, you could put relevant patterns into $GIT_DIR/.git/info/exclude That's not checked in - that's configuration for one particular repo, and that repo alone. 2. You can create a .gitignore file in any directory, and check it in; it'll indicate patterns to ignore in this directory and those below. So, you'd presumably do something like: echo *.o $GIT_DIR/.gitignore to deal with .o files echo *~ $GIT_DIR/.gitignore so Emacs deteriorata gets ignored and some other set of additions for typical cruft that is normally safe to ignore. The existing .cvsignore files can simply get renamed to .gitignore, and that'll just work. I had the entertaining case where, with Slony-I, I did, within the same commit: git rm .cvsignore git add .gitignore (where I had copied data from one to the other) and discovered that Git discovered that this was actually a mv request. I frequently find myself doing a build of things, and then running: git status .gitignore which stows *all* the generated files, commented, so that they aren't yet ignored. Then, edit .gitignore, stripping off leading # for things that should be ignored, and drop out anything that shouldn't be ignored. git commit .gitignore -m Populate all generated files that should be ignored by Git This is one of the first things worth committing once Git gets turned on. -- http://linuxfinances.info/info/linuxdistributions.html -- 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] git: uh-oh
On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander mag...@hagander.net wrote: The tip of every branch, and every single tag, all have the correct data in them, but some revisions in between seem majorly confused. It seems to me that what we'll need to do here is write a script to look through the CVS history of each file and make sure that the versions of that file which appear on each branch match the revs in CVS in content, order, and the commit message associated with any changes. However, that's not going to do get done today. It's too bad that nobody noticed this sooner, but I'm glad I noticed today rather than tomorrow. We're not going to start using the git repository until everyone is satisfied it's OK, both as to current contents and history. Duh. But obviously no one's checked that carefully enough up until now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Tue, Aug 17, 2010 at 21:16, Tom Lane t...@sss.pgh.pa.us wrote: Um ... Magnus has not given any report that he's finished running the conversion. What exactly are you looking at? That's the previous conversion. The one that we used to verify that things looked ok. Seems nobody caught this :S The new migration looks similarly weird. Does anybody with some more git-fu have any clue how this can be? I lack git-fu pretty completely, but I do have the CVS logs ;-). It looks like some of these commits that are being ascribed to the REL8_3_STABLE branch were actually only committed on HEAD. For instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was only in HEAD. It was back-patched a few hours later (1 Mar 3:41), and that's also shown here, but the HEAD commit shouldn't be. I wonder whether the repository is completely OK and the problem is that this webpage isn't filtering the commits correctly. 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] git: uh-oh
On Tue, Aug 17, 2010 at 21:28, Robert Haas robertmh...@gmail.com wrote: On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander mag...@hagander.net wrote: The tip of every branch, and every single tag, all have the correct data in them, but some revisions in between seem majorly confused. It seems to me that what we'll need to do here is write a script to look through the CVS history of each file and make sure that the versions of that file which appear on each branch match the revs in CVS in content, order, and the commit message associated with any changes. However, that's not going to do get done today. Yeah. Unless someone comes up with a good way to fix this, or even better an explanation why it's actually ont broken and we're looking at things wrong :D, I think we have no choice but aborting the conversion for now and come back to it later. -- 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] git: uh-oh
On Aug 17, 2010, at 2:29 PM, Magnus Hagander wrote: On Tue, Aug 17, 2010 at 21:28, Robert Haas robertmh...@gmail.com wrote: On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander mag...@hagander.net wrote: The tip of every branch, and every single tag, all have the correct data in them, but some revisions in between seem majorly confused. It seems to me that what we'll need to do here is write a script to look through the CVS history of each file and make sure that the versions of that file which appear on each branch match the revs in CVS in content, order, and the commit message associated with any changes. However, that's not going to do get done today. Yeah. Unless someone comes up with a good way to fix this, or even better an explanation why it's actually ont broken and we're looking at things wrong :D, I think we have no choice but aborting the conversion for now and come back to it later. Can you post the cvs2svn command line used for conversion? Regards, David -- David Christensen End Point Corporation da...@endpoint.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] git: uh-oh
On Tue, Aug 17, 2010 at 3:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: I lack git-fu pretty completely, but I do have the CVS logs ;-). It looks like some of these commits that are being ascribed to the REL8_3_STABLE branch were actually only committed on HEAD. For instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was only in HEAD. It was back-patched a few hours later (1 Mar 3:41), and that's also shown here, but the HEAD commit shouldn't be. It looks to me like the commit I referenced in my original email is a manufactured merge commit that completely rewrites the tree while asserting that it doesn't do any such thing. I wonder whether the repository is completely OK and the problem is that this webpage isn't filtering the commits correctly. No. The repository itself has the same problem, or at least my clone of it does. I have to say I am totally underwhelmed by the quality of the CVS-to-git conversion tools I've seen so far. It's fine for Linus to say that CVS will eat your data, but these tools were evidently written with grossly inadequate error and sanity checks. Whatever we've been using for the incremental conversions doesn't seem to think it's a problem if the new commit it's pushing doesn't make the head of the tree match CVS HEAD, which seeems like a pretty darn obvious thing to check for, and this tool evidently can't follow branch history properly. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
* Tom Lane t...@sss.pgh.pa.us [100817 15:30]: I lack git-fu pretty completely, but I do have the CVS logs ;-). It looks like some of these commits that are being ascribed to the REL8_3_STABLE branch were actually only committed on HEAD. For instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was only in HEAD. It was back-patched a few hours later (1 Mar 3:41), and that's also shown here, but the HEAD commit shouldn't be. I wonder whether the repository is completely OK and the problem is that this webpage isn't filtering the commits correctly. No, that git branch is definately strange. The commit Robert pointed out is a merge commit. But looking at your explanation of when similar commits with the same message were committed, I'm guessng the timestamp fudge factor along with the look for same commit message behaviour of Magnus's cvs2git conversion is trying too hard to make atomic commits of non-atomic commits. If you use a git viewer that shows the fork/merge points, you can see that there are lots of these little common commits that have been unified onto multiple brances. Magnus, can you check if you can reduce the time fudge? a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] git: uh-oh
BTW, those two manufactured commits seem to directly follow commits into HEAD that added files that were later also added on the branch. I dunno exactly how git represents that type of event, but maybe an extra commit is needed? It'd be interesting to look into the cvs2git source code to see exactly what causes it to add a commit message like that. 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] git: uh-oh
On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane t...@sss.pgh.pa.us wrote: It'd be interesting to look into the cvs2git source code to see exactly what causes it to add a commit message like that. I vigorously agree. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
On Tue, Aug 17, 2010 at 21:35, David Christensen da...@endpoint.com wrote: On Aug 17, 2010, at 2:29 PM, Magnus Hagander wrote: On Tue, Aug 17, 2010 at 21:28, Robert Haas robertmh...@gmail.com wrote: On Tue, Aug 17, 2010 at 3:23 PM, Magnus Hagander mag...@hagander.net wrote: The tip of every branch, and every single tag, all have the correct data in them, but some revisions in between seem majorly confused. It seems to me that what we'll need to do here is write a script to look through the CVS history of each file and make sure that the versions of that file which appear on each branch match the revs in CVS in content, order, and the commit message associated with any changes. However, that's not going to do get done today. Yeah. Unless someone comes up with a good way to fix this, or even better an explanation why it's actually ont broken and we're looking at things wrong :D, I think we have no choice but aborting the conversion for now and come back to it later. Can you post the cvs2svn command line used for conversion? Sure: cvs2git --options=/root/cvs2git.options Attached is the options file. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ cvs2git.options Description: Binary data -- 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] git: uh-oh
On Tue, Aug 17, 2010 at 13:43, Robert Haas robertmh...@gmail.com wrote: On Tue, Aug 17, 2010 at 3:40 PM, Tom Lane t...@sss.pgh.pa.us wrote: It'd be interesting to look into the cvs2git source code to see exactly what causes it to add a commit message like that. I vigorously agree. How sure are we that its not the cvs2svn step that is screwing it up? I know way back when I tried to convert a cvs tree to svn it fell over horribly. Course the same was true when we went from svn to git... (due to how we organized things in svn mainly) -- 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] git: uh-oh
On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker bada...@gmail.com wrote:
How sure are we that its not the cvs2svn step that is screwing it up?
urp, I jumped to a conclusion while skimming the cvs2git.options file
Magnus posted. With all the references to svn and things like
GitRevisionRecorder('cvs2svn-tmp/git-blob.dat'). It sure sounded
like it converts to svn first and then to git... im not sure what it
does.
--
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] git: uh-oh
Robert Haas robertmh...@gmail.com writes: It looks to me like the commit I referenced in my original email is a manufactured merge commit that completely rewrites the tree while asserting that it doesn't do any such thing. AFAICS, the commits in the 8.3 history *after* that point are sane; at least there's one for each actual 8.3 commit in the CVS logs. Before that point, though, the history shown for 8.3 seems to include all HEAD commits as well. The merge commit is probably cleaning up those incorrectly included HEAD commits. I concur that we gotta abort the git conversion. This looks like it might be a pretty simple bug in the converter, but we can't block Postgres development while we look for it. 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
[HACKERS] Git migration aborted
Hello! We've aborted the git migration due to the issues Robert Haas found. This means that the cvs repository is once again open for commits, and we'll just restart the whole process wen ready. -- 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] security label support, part.2
Robert Haas robertmh...@gmail.com writes: On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost sfr...@snowman.net wrote: No.. and I'm not sure we ever would. What we *have* done is removed all permissions checking on child tables when a parent is being queried.. Yeah. I'm not totally sure that is sensible for a MAC environment. Heck, it's arguably incorrect (though perhaps quite convenient) in a DAC environment. IIRC, the reason we did it was that we decided the SQL spec requires it. So there's not a lot of point in debating the issue, unless you can convince us we misread the spec. 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] Progress indication prototype
(Sorry for top posting and for any typos -- typing on my phone) In my earlier patch to do progress indicators for arbitrary SQL queries I had envisioned a setup similar to how we handle query cancellation. Psql could support a key like SIGINFO which would make it request an update. Clients like pgadmin would either do that periodically or set some guc or protocol option to request periodic updates in advance. greg On 17 Aug 2010 19:07, Stephen Frost sfr...@snowman.net wrote: * Alex Hunsaker (bada...@gmail.com) wrote: On Tue, Aug 17, 2010 at 06:31, Stephen Frost sfr...@sn... If it was configurable via \set and I could drop it in my .psqlrc, and it knew not to only do it after a few seconds (otherwise it'd be far too much)... I don't like how the backend would have to send something NOTICE-like, I had originally been thinking gee, it'd be nice if psql could query pg_stat while doing something else, but that's not really possible... So, I guess NOTICE-like messages would work, if the backend could be taught to do it. Thanks, Stephen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkxqzFwACgkQrzgMPqB3kijVbACfWkUc/A5+6NaViTf8f9yrN/vT Y3AAn1eDvj4meqxlr05r0L51j+OypNqs =f+ya -END PGP SIGNATURE-
Re: [HACKERS] git: uh-oh
On Tue, Aug 17, 2010 at 01:57:02PM -0600 I heard the voice of
Alex Hunsaker, and lo! it spake thus:
On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker bada...@gmail.com wrote:
How sure are we that its not the cvs2svn step that is screwing it up?
urp, I jumped to a conclusion while skimming the cvs2git.options
file Magnus posted. With all the references to svn and things like
GitRevisionRecorder('cvs2svn-tmp/git-blob.dat'). It sure sounded
like it converts to svn first and then to git... im not sure what
it does.
It's not that it converts to svn, but that it's built on (/part of)
cvs2svn, so presumably a lot of the figure out changesets and branch
membership logic and the get things in the shape svn wants logic
are intertwined.
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
--
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] Progress indication prototype
On Tue, Aug 17, 2010 at 10:53 PM, Greg Stark st...@mit.edu wrote: (Sorry for top posting and for any typos -- typing on my phone) In my earlier patch to do progress indicators for arbitrary SQL queries I had envisioned a setup similar to how we handle query cancellation. Psql could support a key like SIGINFO which would make it request an update. Clients like pgadmin would either do that periodically or set some guc or protocol option to request periodic updates in advance. Which is ideal for monitoring your own connection - having the info in the pg_stat_activity is also valuable for monitoring and system administration. Both would be ideal :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] security label support, part.2
(2010/08/18 3:07), Robert Haas wrote: On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frostsfr...@snowman.net wrote: No.. and I'm not sure we ever would. What we *have* done is removed all permissions checking on child tables when a parent is being queried.. Yeah. I'm not totally sure that is sensible for a MAC environment. Heck, it's arguably incorrect (though perhaps quite convenient) in a DAC environment. Anyway, I wonder if it would be sensible to try to adjust the structure of the DAC permissions checks so enhanced security providers can make their own decision about how to handle this case. As long as we handle child tables in consistent way, here is no matter for a MAC environment also. As Stephen mentioned, the question was what is an object. So, I want child tables being either a part of parent table or an independent object from its parent. In the first case, child tables need to have same security properties (ownership, access privileges, security labels) with its parent. In the later case, we need to check permissions on child tables also when we query on the parent, but it is an old perspective now. 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] security label support, part.2
* Tom Lane (t...@sss.pgh.pa.us) wrote: Robert Haas robertmh...@gmail.com writes: Yeah. I'm not totally sure that is sensible for a MAC environment. Heck, it's arguably incorrect (though perhaps quite convenient) in a DAC environment. IIRC, the reason we did it was that we decided the SQL spec requires it. So there's not a lot of point in debating the issue, unless you can convince us we misread the spec. I've not gone through the spec with regard to this (yet..), but I think we need to consider the whole 'principle of least surprise' here, regardless of what the spec says. For one thing, this isn't how older versions of PG behaved and while I doubt anyone intended to rely on that behavior, it makes me nervous that someone, somewhere, unintentionally relies on it. What I'm thinking of is something like a warning if the permissions on the child don't match those of the parent when the relationship is created, or maybe forcibly setting the permissions on the child (with a NOTICE), so it's at least clear what is going on. Or perhaps, set the permissions on the child only if it doesn't have permissions (with the NOTICE), and issue a WARNING if the child already has permissions set. Perhaps also a WARNING if someone changes the permissions on a child after the relationship has been created too, but let it happen in case someone really wants it.. I dunno. None of the above makes me feel very comfortable from a security perspective because I'm concerned any of the above could too easily be overlooked by someone upgrading. It also doesn't really address the concern that, at some point, a child table could have different permissions than a parent table. If we forcibly set the permissions on the child, or ERROR'd if the permissions weren't either the same or empty on the child, and then ERROR'd if someone tried to change the child's permissions later, I'd be happier. I don't really want to force people doing routine partition additions to have to set the permissions on the child before adding it, but I also don't want to have to figure out are these two sets of permissions identical, since that's not really trivial to determine. We do have default permissions now though, so maybe requiring the permissions be the same from the get-go is the right idea. Of course, if we change the permissions on the child when the inheiritance relationship is created, we'll need to update those perms every time the parents perms are changed. Just my 2c. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] security label support, part.2
(2010/08/18 9:04), Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Robert Haasrobertmh...@gmail.com writes: Yeah. I'm not totally sure that is sensible for a MAC environment. Heck, it's arguably incorrect (though perhaps quite convenient) in a DAC environment. IIRC, the reason we did it was that we decided the SQL spec requires it. So there's not a lot of point in debating the issue, unless you can convince us we misread the spec. I've not gone through the spec with regard to this (yet..), but I think we need to consider the whole 'principle of least surprise' here, regardless of what the spec says. For one thing, this isn't how older versions of PG behaved and while I doubt anyone intended to rely on that behavior, it makes me nervous that someone, somewhere, unintentionally relies on it. I believed that table inheritance is a unique feature in PostgreSQL. Does the SQL spec really mention about whether a child table is an independent table object, or not? Or, are you talking about the behavior that parent's permission also controls accesses on child tables? If so, all of us already agreed. What I'm thinking of is something like a warning if the permissions on the child don't match those of the parent when the relationship is created, or maybe forcibly setting the permissions on the child (with a NOTICE), so it's at least clear what is going on. Or perhaps, set the permissions on the child only if it doesn't have permissions (with the NOTICE), and issue a WARNING if the child already has permissions set. Perhaps also a WARNING if someone changes the permissions on a child after the relationship has been created too, but let it happen in case someone really wants it.. I dunno. None of the above makes me feel very comfortable from a security perspective because I'm concerned any of the above could too easily be overlooked by someone upgrading. It also doesn't really address the concern that, at some point, a child table could have different permissions than a parent table. If we forcibly set the permissions on the child, or ERROR'd if the permissions weren't either the same or empty on the child, and then ERROR'd if someone tried to change the child's permissions later, I'd be happier. I also think ERROR should be raised when user tries to assign different security properties on child tables from its parent. At least, I think it should be configurable using a guc variable. If WARNING/NOTICE, we can easily break consistency of the permissions... I don't really want to force people doing routine partition additions to have to set the permissions on the child before adding it, but I also don't want to have to figure out are these two sets of permissions identical, since that's not really trivial to determine. We do have default permissions now though, so maybe requiring the permissions be the same from the get-go is the right idea. Of course, if we change the permissions on the child when the inheiritance relationship is created, we'll need to update those perms every time the parents perms are changed. I also think it is a good idea to copy permissions from the parent when we try to define an inheritance relationship. It obviously reduces user's routine task on defining many of child tables. It seems to me a case when we provide a NOTICE to users, if permissions of child table is overwritten. 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] security label support, part.2
KaiGai, * KaiGai Kohei (kai...@ak.jp.nec.com) wrote: I believed that table inheritance is a unique feature in PostgreSQL. It's actually not.. Does the SQL spec really mention about whether a child table is an independent table object, or not? The SQL spec does discuss 'subtables' and inheiritance. It also does describe some information under 'Access Rules' regarding these sub-tables (check the 'table definition' clause). I've been looking at them and trying to make some sense out of what I see. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] security label support, part.2
2010/8/17 KaiGai Kohei kai...@ak.jp.nec.com: I dunno. None of the above makes me feel very comfortable from a security perspective because I'm concerned any of the above could too easily be overlooked by someone upgrading. It also doesn't really address the concern that, at some point, a child table could have different permissions than a parent table. If we forcibly set the permissions on the child, or ERROR'd if the permissions weren't either the same or empty on the child, and then ERROR'd if someone tried to change the child's permissions later, I'd be happier. I also think ERROR should be raised when user tries to assign different security properties on child tables from its parent. At least, I think it should be configurable using a guc variable. If C1, C2, and C3 inherit from P, it's perfectly reasonable to grant permissions to X on C1 and C2, Y on C3, and Z on C1, C2, C3, and P. I don't think we should disallow that. Sure, it's possible to do things that are less sane, but if we put ourselves in the business of removing useful functionality because it might be misused, we'll put ourselves out of business. Having said that, I'm not sure that the same arguments really hold water in the world of label based security. Suppose we have compartmentalized security: P is a table of threats, with C1 containing data on nukes, C2 containing data on terrorists, and C3 containing data on foreign militaries. If we create a label for each of these threat types, we can apply that label to the corresponding table; but what label shall we assign P? Logically, the label for P should be set up in such a fashion that the only people who can read P are those who can read C1, C2, and C3 anyway, but who is to say that such a label exists? Even if KaiGai's intended implementation of SE-PostgreSQL supports construction of such a label, who is to say that EVERY conceivable labeling system will also do so? In fact, it seems to me that it might be far more reasonable, in a case like this, to ignore the *parent* label and look only at each *child* label, which to me is an argument that we should set this up so as to allow individual users of this hook to do as they like. It's also worth pointing out that the hook in ExecCheckRTPerms() does not presuppose label-based security. It could be used to implement some other policy altogether, which only strengthens the argument that we can't know how the user of the hook wants to handle these cases. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] security label support, part.2
(2010/08/18 12:02), Robert Haas wrote: 2010/8/17 KaiGai Koheikai...@ak.jp.nec.com: I dunno. None of the above makes me feel very comfortable from a security perspective because I'm concerned any of the above could too easily be overlooked by someone upgrading. It also doesn't really address the concern that, at some point, a child table could have different permissions than a parent table. If we forcibly set the permissions on the child, or ERROR'd if the permissions weren't either the same or empty on the child, and then ERROR'd if someone tried to change the child's permissions later, I'd be happier. I also think ERROR should be raised when user tries to assign different security properties on child tables from its parent. At least, I think it should be configurable using a guc variable. If C1, C2, and C3 inherit from P, it's perfectly reasonable to grant permissions to X on C1 and C2, Y on C3, and Z on C1, C2, C3, and P. I don't think we should disallow that. Sure, it's possible to do things that are less sane, but if we put ourselves in the business of removing useful functionality because it might be misused, we'll put ourselves out of business. Hmm. If C1, C2 and C3 are defined to store information for different categories, but shares common data structure, indeed, it is useful. Having said that, I'm not sure that the same arguments really hold water in the world of label based security. Suppose we have compartmentalized security: P is a table of threats, with C1 containing data on nukes, C2 containing data on terrorists, and C3 containing data on foreign militaries. If we create a label for each of these threat types, we can apply that label to the corresponding table; but what label shall we assign P? Logically, the label for P should be set up in such a fashion that the only people who can read P are those who can read C1, C2, and C3 anyway, but who is to say that such a label exists? Right. If access privileges on P implicitly allow accesses on children, the P must have a label that only allows people who can access both of the children. However, in SELinux at least, here is no guarantee that we can always find out such a label in the security policy installed. :( Even if KaiGai's intended implementation of SE-PostgreSQL supports construction of such a label, who is to say that EVERY conceivable labeling system will also do so? In fact, it seems to me that it might be far more reasonable, in a case like this, to ignore the *parent* label and look only at each *child* label, which to me is an argument that we should set this up so as to allow individual users of this hook to do as they like. It will be helpful. If we can check each children's label, no need to restrict an identical security label within a certain inheritance hierarchy. Of course, other security module may check permissions in different basic, but it seems to me characteristics. It's also worth pointing out that the hook in ExecCheckRTPerms() does not presuppose label-based security. It could be used to implement some other policy altogether, which only strengthens the argument that we can't know how the user of the hook wants to handle these cases. If rte-requiredPerms would not be cleared, the user of the hook will be able to check access rights on the child tables, as they like. How about an idea to add a new flag in RangeTblEntry which shows where the RangeTblEntry came from, instead of clearing requiredPerms? If the flag is true, I think ExecCheckRTEPerms() can simply skip checks on the child tables. 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] git: uh-oh
Alex Hunsaker wrote:
On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker bada...@gmail.com wrote:
How sure are we that its not the cvs2svn step that is screwing it up?
urp, I jumped to a conclusion while skimming the cvs2git.options file
Magnus posted. With all the references to svn and things like
GitRevisionRecorder('cvs2svn-tmp/git-blob.dat'). It sure sounded
like it converts to svn first and then to git... im not sure what it
does.
cvs2git converts directly from CVS to git. There is no intermediate SVN
step. However, given that cvs2git is built on top of cvs2svn, it is
true that some subversion terminology appears in the configuration file
and even in some of the manufactured commit messages.
Michael
the cvs2svn/cvs2git maintainer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
