Re: [HACKERS] [COMMITTERS] pgsql: Basic documentation for ROLEs.
On Sat, Jul 30, 2005 at 12:19:41AM -0400, Bruce Momjian wrote: I have just loaded the patches list with all outstanding patches that need consideration, and updated the open items list: http://momjian.postgresql.org/cgi-bin/pgpatches http://momjian.postgresql.org/cgi-bin/pgopenitems The main shared dependency patch is applied. I still owe a patch to implement DROP OWNED and REASSIGN OWNED, to drop or give away objects owned by a list of roles. -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) Crear es tan difícil como ser libre (Elsa Triolet) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Buildfarm's opsrey goes green...
Hi, My buildfarm member opsrey has turned green, thanks to the following two things: * the removal of the contrib module tsearch (that was miscompiling) * the removal from my config of plperl and pltcl. My installations of perl and tcl link to pthread, and postgresql does not, hence the crash in the tests. NetBSD 2.0 does not have all the necessary threadsafe calls to pass the thread safety test made during configure. Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Chocked
They usually claim to be the world's most POPULAR open source database... Chris ohp@pyrenet.fr wrote: Who copied? I've been to mysql site 2 mn ago (did'nt occur since at least 6 months) title says : Mysql: The world most advanced opensource database. Isn't it the title for postgresql? It seems weird for both projects to have the same claim (although it's true for postgreql...) Regards ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Chocked
Christopher Kings-Lynne wrote: They usually claim to be the world's most POPULAR open source database... Zillions of flies can't be wrong :o) Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Win32 build broken by recent changes to xlog.c
Seems it's dead on the buildfarm box as well: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snakedt=2005-07-30%20 01:00:01 From what I can tell, the recent patch for O_DIRECT broke it. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/Perl list value return causes segfault
David Fetter wrote: *** 716,724 listitem para ! In the current implementation, if you are fetching or returning ! very large data sets, you should be aware that these will all go ! into memory. /para /listitem /itemizedlist --- 766,776 listitem para ! If you are fetching or returning very large data sets using ! literalspi_exec_query/literal, you should be aware that ! these will all go into memory. You can avoid this by using ! literalspi_query/literal/literalspi_fetchrow/literal as ! illustrated earlier. /para /listitem /itemizedlist You have rolled 2 problems into one - spi_query+spi_fetchrow does not address the issue of returning large data sets. Suggest instead: para If you are fetching very large data sets using literalspi_exec_query/literal, you should be aware that these will all go into memory. You can avoid this by using literalspi_query/literal and literalspi_fetchrow/literal as illustrated earlier. /para para A similar problem occurs if a set-returning function passes a large set of rows back to postgres via literalreturn/literal. You can avoid this problem too by instead using literalreturn_next/literal for each row returned, as shown previously. /para cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Updated open items
Andrew Dunstan wrote: Bruce, some of the items on your patches list don't seem to contain patches ... Right, some are open items, but the patches list is a central place to put everything. In particular, . the thread multibyte regression tests - If you like you can put a TODO on the list and put my name against it, but I won't be getting to it any time soon, and nobody else has done any work on it AFAIK. OK, I will move that entire thread to the 8.2 queue. . the thread windows regression failure - prepared xacts - in another thread here: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00621.php Tom proposed a possible cause for the problem seen (race conditions in is_visible() and friends) and several possible solutions, but I am not sure we ever resolved the issue, did we? No idea. Once we have more information we can remove it and either fix it or document it as a TODO. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Updated open items
Bruce, some of the items on your patches list don't seem to contain patches ... In particular, . the thread multibyte regression tests - If you like you can put a TODO on the list and put my name against it, but I won't be getting to it any time soon, and nobody else has done any work on it AFAIK. . the thread windows regression failure - prepared xacts - in another thread here: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00621.php Tom proposed a possible cause for the problem seen (race conditions in is_visible() and friends) and several possible solutions, but I am not sure we ever resolved the issue, did we? cheers andrew Bruce Momjian wrote: I have just loaded the patches list with all outstanding patches that need consideration, and updated the open items list: http://momjian.postgresql.org/cgi-bin/pgpatches http://momjian.postgresql.org/cgi-bin/pgopenitems We will need to make some decisions on that goes into 8.1. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] multibyte regression tests
This has been saved for the 8.2 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Andrew Dunstan wrote: Luke Lonergan wrote: Andrew, Good. So should we roll this up into the standard regression suite? Why are these tests separate? Is it just that they need a UTF8 encoded db rather than an SQL-ASCII encoded db? I think that was the idea - the src/test/mb kit was already there and was designed to create the UTF8 database and controlled circumstances for a conversion test, so we used it for the similar testing for COPY. It could possibly be moved into the make check regression suite, if the regression DB is always created with UTF8. Ayush may be able to add to this. It isn't. But we now have support in pg_regress for specifying the database explicitly, and we have just adapted the PL regression sets to use the standard infrastructure that the core and contrib regression sets use. Moreover, pg_regress.sh already has some support for multibyte encodings. So I think rolling up the mb tests at least to use a (possibly enhanced) pg_regress.sh would be a GoodThing (tm). Having a single and adequately featured regression harness should make adding specialised test sets easier - I imagine that would appeal to you guys at GreenPlum :-) cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Updated open items
Andrew Dunstan [EMAIL PROTECTED] writes: . the thread windows regression failure - prepared xacts - in another thread here: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00621.php Tom proposed a possible cause for the problem seen (race conditions in is_visible() and friends) and several possible solutions, but I am not sure we ever resolved the issue, did we? AFAIK the regression test failure has not recurred since I tweaked the \d query issued by psql, but the question of whether we want to make a semantic change in is_visible() is still open. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Updated open items
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: . the thread windows regression failure - prepared xacts - in another thread here: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00621.php Tom proposed a possible cause for the problem seen (race conditions in is_visible() and friends) and several possible solutions, but I am not sure we ever resolved the issue, did we? AFAIK the regression test failure has not recurred since I tweaked the \d query issued by psql, but the question of whether we want to make a semantic change in is_visible() is still open. OK, thread removed. If there is a TODO, let me know. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] Interval-day docs and regression tests
Michael Glaesemann [EMAIL PROTECTED] writes: Please find attached diffs for documentation and simple regression tests for the new interval-day changes. The buildfarm results suggest that justify_days is broken in the integer-datetimes case, eg from panda: *** ./expected/interval.out Sat Jul 30 16:20:48 2005 --- ./results/interval.out Sat Jul 30 16:24:31 2005 *** *** 238,243 SELECT justify_days(interval '6 months 36 days 5 hours 4 minutes 3 seconds') as 7 mons 6 days 5 hours 4 mins 3 seconds; 7 mons 6 days 5 hours 4 mins 3 seconds ! @ 7 mons 6 days 5 hours 4 mins 3 secs (1 row) --- 238,243 SELECT justify_days(interval '6 months 36 days 5 hours 4 minutes 3 seconds') as 7 mons 6 days 5 hours 4 mins 3 seconds; 7 mons 6 days 5 hours 4 mins 3 seconds ! @ 1 mon 186 days 5 hours 4 mins 3 secs (1 row) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Write past chunk end?
I'm testing out the latest version of Palles ICU patch on win32, and I got the build syste mworking. But it no longer works when built - it used to... When initdb:ing with this version and -E UNICODE, I get: WARNING: detected write past chunk end in Analyze Column 01472ED0 Search for a AllocSetContextCreate whose name is Analyze Column; somebody is writing more memory than allocated. Any ideas on how to debug this? The problem is that it's detected in MemoryContextCheck, long after the clobber occured. You could set a watchpoint in gdb, I think. That's what I was afraid of. Well, some shotgun-debugging later, I found the problem. A +1 that should be +2 because UTF-16 is two-byte... As the data is freed very soon afterwards this didn't cause a crash, but I bet it would've given the same warning if it was run on FreeBSD with debugging and asserts enabled. Anyway. Thanks, got it sorted. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Add GUC variables to control keep-alive times for idle, interval,
This broke the build on AIX. AIX does not have SOL_TCP as a defined symbol in any of the system header files. -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: Saturday, July 30, 2005 11:17 AM To: pgsql-committers@postgresql.org Subject: [COMMITTERS] pgsql: Add GUC variables to control keep-alive times for idle, interval, Log Message: --- Add GUC variables to control keep-alive times for idle, interval, and count. Oliver Jowett Modified Files: -- pgsql/doc/src/sgml: runtime.sgml (r1.339 - r1.340) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml /runtime.sgml.diff?r1=1.339r2=1.340) pgsql/src/backend/libpq: pqcomm.c (r1.176 - r1.177) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/libpq/pqco mm.c.diff?r1=1.176r2=1.177) pgsql/src/backend/utils/misc: guc.c (r1.279 - r1.280) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc /guc.c.diff?r1=1.279r2=1.280) postgresql.conf.sample (r1.154 - r1.155) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc /postgresql.conf.sample.diff?r1=1.154r2=1.155) pgsql/src/bin/psql: tab-complete.c (r1.135 - r1.136) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/tab-compl ete.c.diff?r1=1.135r2=1.136) pgsql/src/include/libpq: libpq-be.h (r1.49 - r1.50) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/libpq/libp q-be.h.diff?r1=1.49r2=1.50) pgsql/src/include/utils: guc.h (r1.61 - r1.62) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/guc. h.diff?r1=1.61r2=1.62) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Add GUC variables to control keep-alive times
Rocco Altier wrote: This broke the build on AIX. AIX does not have SOL_TCP as a defined symbol in any of the system header files. OK, is there any way of setting the keepalive values on AIX? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Add GUC variables to control keep-alive
Bruce Momjian wrote: Rocco Altier wrote: This broke the build on AIX. AIX does not have SOL_TCP as a defined symbol in any of the system header files. OK, is there any way of setting the keepalive values on AIX? Looks like Unixware is broken too, cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Add GUC variables to control keep-alive
Andrew Dunstan wrote: Looks like Unixware is broken too, cheers andrew I think Tom's fix to use IPPROTO_TCP will fix firefly. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Add GUC variables to control keep-alive
Larry Rosenman wrote: I think Tom's fix to use IPPROTO_TCP will fix firefly. Ah, I forgot about the we'll just use IP protocol numbers as socket option levels behaviour (BSD-derived?). My Linux man page only talks about SOL_TCP, but I have run into this before and should have remembered.. my bad. per my linux/socket.h: /* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */ #define SOL_IP 0 /* #define SOL_ICMP 1 No-no-no! Due to Linux :-) we cannot use SOL_ICMP=1 */ #define SOL_TCP 6 (I won't get into why using wire-level-protocol constants for syscall option numbering is a bad idea.. :) -O ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PL/Perl list value return causes segfault
On Sat, Jul 30, 2005 at 09:47:58AM -0400, Andrew Dunstan wrote:
David Fetter wrote:
You have rolled 2 problems into one - spi_query+spi_fetchrow does not
address the issue of returning large data sets.
Suggest instead:
[suggestion]
Revised patch attached. Thanks for catching this :)
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
Index: doc/src/sgml/plperl.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plperl.sgml,v
retrieving revision 2.42
diff -c -r2.42 plperl.sgml
*** doc/src/sgml/plperl.sgml13 Jul 2005 02:10:42 - 2.42
--- doc/src/sgml/plperl.sgml31 Jul 2005 00:33:00 -
***
*** 46,52
para
To create a function in the PL/Perl language, use the standard
xref linkend=sql-createfunction endterm=sql-createfunction-title
!syntax:
programlisting
CREATE FUNCTION replaceablefuncname/replaceable
(replaceableargument-types/replaceable) RETURNS
replaceablereturn-type/replaceable AS $$
# PL/Perl function body
--- 46,57
para
To create a function in the PL/Perl language, use the standard
xref linkend=sql-createfunction endterm=sql-createfunction-title
!syntax. A PL/Perl function must always return a scalar value. You
!can return more complex structures (arrays, records, and sets)
!in the appropriate context by returning a reference.
!Never return a list. Here follows an example of a PL/Perl
!function.
!
programlisting
CREATE FUNCTION replaceablefuncname/replaceable
(replaceableargument-types/replaceable) RETURNS
replaceablereturn-type/replaceable AS $$
# PL/Perl function body
***
*** 282,288
/para
para
!PL/Perl provides two additional Perl commands:
variablelist
varlistentry
--- 287,293
/para
para
!PL/Perl provides three additional Perl commands:
variablelist
varlistentry
***
*** 293,303
termliteralfunctionspi_exec_query/(replaceablequery/replaceable [,
replaceablemax-rows/replaceable])/literal/term
termliteralfunctionspi_exec_query/(replaceablecommand/replaceable)/literal/term
listitem
para
!Executes an SQL command. Here is an example of a query
!(commandSELECT/command command) with the optional maximum
!number of rows:
programlisting
$rv = spi_exec_query('SELECT * FROM my_table', 5);
/programlisting
--- 298,315
termliteralfunctionspi_exec_query/(replaceablequery/replaceable [,
replaceablemax-rows/replaceable])/literal/term
termliteralfunctionspi_exec_query/(replaceablecommand/replaceable)/literal/term
+
termliteralfunctionspi_query/(replaceablecommand/replaceable)/literal/term
+
termliteralfunctionspi_fetchrow/(replaceablecommand/replaceable)/literal/term
+
listitem
para
!literalspi_exec_query/literal executes an SQL command and
! returns the entire rowset as a reference to an array of hash
! references. emphasisYou should only use this command when you know
! that the result set will be relatively small./emphasis Here is an
! example of a query (commandSELECT/command command) with the
! optional maximum number of rows:
!
programlisting
$rv = spi_exec_query('SELECT * FROM my_table', 5);
/programlisting
***
*** 345,351
INSERT INTO test (i, v) VALUES (3, 'third line');
INSERT INTO test (i, v) VALUES (4, 'immortal');
! CREATE FUNCTION test_munge() RETURNS SETOF test AS $$
my $rv = spi_exec_query('select i, v from test;');
my $status = $rv-gt;{status};
my $nrows = $rv-gt;{processed};
--- 357,363
INSERT INTO test (i, v) VALUES (3, 'third line');
INSERT INTO test (i, v) VALUES (4, 'immortal');
! CREATE OR REPLACE FUNCTION test_munge() RETURNS SETOF test AS $$
my $rv = spi_exec_query('select i, v from test;');
my $status = $rv-gt;{status};
my $nrows = $rv-gt;{processed};
***
*** 360,366
SELECT * FROM test_munge();
/programlisting
! /para
/listitem
/varlistentry
--- 372,416
SELECT * FROM test_munge();
/programlisting
! /para
! para
! literalspi_query/literal and literalspi_fetchrow/literal
! work together as a pair for rowsets which may be large, or for cases
! where you wish to return rows as they arrive.
! literalspi_fetchrow/literal works emphasisonly/emphasis with
! literalspi_query/literal. The following example illustrates how
! you use them together:
!
! programlisting
! CREATE TYPE foo_type AS (the_num INTEGER, the_text TEXT);
!
! CREATE OR REPLACE FUNCTION lotsa_md5 (INTEGER) RETURNS SETOF foo_type AS $$
! use Digest::MD5 qw(md5_hex);
! my $file = '/usr/share/dict/words';
! my $t = localtime;
! elog(NOTICE, opening
Re: [HACKERS] MySQL to PostgreSQL for SugarCRM
Title: Re: MySQL to PostgreSQL for SugarCRM Thanks, I'll check it out. I didn't see much evidence on the SugarCRM site that they are interested in an DB besides MySQL. But, it is also my hope that the core SugarCRM project will come around to supporting EDB/PostgreSQL (once we have done the port for them and committed to testing and maintaining it). --Luss From: Sergio A. Kessler [mailto:[EMAIL PROTECTED]Sent: Sat 7/30/2005 9:05 PMTo: Denis LussierCc: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]Subject: Re: MySQL to PostgreSQL for SugarCRM dennis, look at vtiger crm (http://www.vtiger.com) vtiger is a fork of sugarcrm and are 100% commited to open source. (unlike sugar, who offer the full version only for purchase) and they actively want to support more databases. regards, /sak Denis Lussier wrote: At EnterpriseDB we're doing a little project along these lines. In our lab, and soon for our company, we are running SugarCRM on EDB-Postgres. Alas you say, but SugarCRM only supports MySQL: EDB ships a nifty java based ETL tool with our product that is 99.5% based on the Enhydra Octopus LGPL project. This allows for easily converting schema and data from a populated MySQL SugarCRM database into Postgres. Then we hacked the PHP code of SugarCRM for a couple days and it is now working just fine on EDB-Postgres. I think that whenever we come across an Open Source (or even a commercial\proprietary product) out there that supports MySQL, but not PostgreSQL... We need to work collectively as a group to make it shamefully simple for the project to work with PostgreSQL also. SugarCRM has 250,000 downloads and every single one of those customers is guaranteed to be introduced to MySQL and only MySQL. --Luss PS1 Yes, we are going to try and work with the SugarCRM folks and get Postgres supported natively without customers having to hack the way we did to get it working. PS2 I've hired many interns for summer and/or co-op jobs over the years. The trick is to give them something interesting to do AND pay them a little more than they can make flipping burgers.
Re: [HACKERS] [COMMITTERS] pgsql: Add GUC variables to control keep-alive
Larry Rosenman wrote: I think Tom's fix to use IPPROTO_TCP will fix firefly. LER And based on the last run, it did. Thanks, Tom! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Remote administration functionality
Let me try to outline where I think our goals are for remote administration. I will not comment on Dave's analysis of the patch review process, but I think he has some valid points that this patch was not treated properly. Basically, I think everyone wants remote administration. Remote administration requires several things: o edit postgresql.conf o edit pg_hba.conf o reload the config files o restart the server (for config variables requiring restart) o view log files o recycle log files o rename/remove log files All these items are on the TODO list already. The idea of the patch was to give applications the full unix I/O capabilities, allowing them to program these functions into administration applications. I think the group generally would like a higher-level API that allows something like: SET GLOBAL log_statement = 'mod'; that would modify postgresql.conf and signal all backends to-read the file, or a way to control pg_hba.conf using SQL queries. While the Unix API works, it isn't really what we finally want for remote administration. I thought this was discussed back in the 8.0 beta period, and was surprised to see the file I/O patch resurface, but because no one objected to it, I moved forward to getting it into the queue and applied. Later, others did object, some to the too-general API, others based on security concerns. I probably should have stated more clearly that the high-level API was the proper approach, rather than moving forward with a patch I knew untimately would lead to concerns. However, I try to refrain from pre-judging a patch lest I become too unbiased toward patch submissions. I try to be the advocate for patches, rather than cast judgement. (What surprised me is that the concerns didn't surfaced so late.) So, where does this leave us for 8.1? I don't think we have time to implement many of the bulleted items listed above, and I don't think the file API patch would pass a vote, but I will support a vote if people want that. I think it might be possible to do a few of the bulleted items while we clean out the patches queue. In fact, I think the reload the config file functionality was already in the file I/O patch, so we can easily apply that. (It is a TODO item.) Given the confusion about the patch, I think we can give folks some time to work on any additional remote administration bulleted items while we clean out the patches queue. Does that sound like a plan? [ FYI, I think some of the bulleted items can be done now via COPY.] --- Dave Page wrote: None of these functions are getting into 8.1 anyway; we should be designing the long-term solution not making up short-lived hacks. So, going back to pre 8.0, we fixed them so they don't work outside of the data directory as requested, yet they were not included for unknown reasons. We revisited some weeks before prior to feature freeze, and I researched all issues raised and ask for clarification on what you weren't happy with as all I'd found in the archives was a sentence along the lines of I really don't see any value in these. I found no outstanding issues in the archives, nor did I receive any in response to my questions. Having received no further objections, the patch was added to the queue. As soon as Bruce starts to look at it, presumably to apply it, you decide it's an unacceptable security problem, and say you'd be perfectly happy if there was a GUC to disable the potentially dangerous functions. This info would have been nice before feature freeze, but, OK, I appreciate you're busy. Magnus updates the patch because he's yet another one of us that thinks this is useful functionality and adds the GUC you said would make you happy with these functions. You then state, with no discussion at all, that they're not going into 8.1 anyway, despite us doing everything you have asked. I have two questions if I may: 1) Is there any point us working on any kind of enhanced API for remote admin in the future, or will the same treatment be given to that? 2) Do you now have sole say over what does and doesn't go into the project? I don't mean to be disrespectful - your hard work and skills are hugely appreciated by the whole community, but I know for a fact that a number of them, who between them have contributed thousands of hours and lines of code to the project (and I'm talking about the core project, never mind pgAdmin et al) cannot understand your apparent insistence on us not providing remote admin capabilities. I think we simply need clarification on how the project works these days. Regards, Dave ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so
Re: [HACKERS] Remote administration functionality
On Sat, Jul 30, 2005 at 11:39:20PM -0400, Bruce Momjian wrote: Let me try to outline where I think our goals are for remote administration. I will not comment on Dave's analysis of the patch review process, but I think he has some valid points that this patch was not treated properly. Basically, I think everyone wants remote administration. Remote administration requires several things: o edit postgresql.conf o edit pg_hba.conf o reload the config files o restart the server (for config variables requiring restart) o view log files o recycle log files o rename/remove log files All these items are on the TODO list already. My security spider-sense tingles when I see the ability for a remote attacker to not only completely override password, certificate and IP absed authentication but also to easily remove logfiles. So, while I can see the attraction of being able to futz with the database security configuration through a PHP web interface running on an unpatched Apache build somewhere out on the open internet (and would like to be able to do so myself, sometimes) I'd really, really like to see the ability to disable as much of this at compile time as is convenient. Cheers, Steve ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Remote administration functionality
On Sat, Jul 30, 2005 at 09:35:16PM -0700, Steve Atkins wrote: On Sat, Jul 30, 2005 at 11:39:20PM -0400, Bruce Momjian wrote: Let me try to outline where I think our goals are for remote administration. I will not comment on Dave's analysis of the patch review process, but I think he has some valid points that this patch was not treated properly. Basically, I think everyone wants remote administration. Remote administration requires several things: o edit postgresql.conf o edit pg_hba.conf o reload the config files o restart the server (for config variables requiring restart) o view log files o recycle log files o rename/remove log files All these items are on the TODO list already. My security spider-sense tingles when I see the ability for a remote attacker to not only completely override password, certificate and IP absed authentication but also to easily remove logfiles. Yes, I'd trim that part to support only rename of log files, and constrain the destination to the log directory. (I guess I don't need to mention that all log file operations are already constrained to files inside the log directory.) For the edit postgresql.conf part I guess it would be important to have some settings that would not be changeable via this interface. -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) La primera ley de las demostraciones en vivo es: no trate de usar el sistema. Escriba un guión que no toque nada para no causar daños. (Jakob Nielsen) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
