Re: [HACKERS] [GENERAL] Physical Database Configuration
On Wednesday 25 June 2003 21:21, Jonathan Bartlett wrote: My solution did not involve tablespaces, but was more of a quick solution to make it easier for admins to do _some_ sort of physical configuration. The idea is that the developer could do something like 'create alternate location ALTERNATE_LOCATION_NAME for DATABASE_OBJECT_NAME at /PATH/TO/PHYSICAL/FILE;' We would have a system table holding theses values. Then, all database commands which create a file for an object, call open_object(oid, object_name) or something to create the file object. This will first look in the new system table to see if there is a mapping for an object of this name. If so, it will create a symlink to /PATH/TO/PHYSICAL/FILE for the oid before opening the file. What you are describing is a subset of tablespace functionality we are discussing offline. There are few minor differences though. 1. There is no physical file but location would be a directory. 2. The location could also be assigned at the time of object creation. Otherwise it is exactly what is under consideration..:-) Shridhar ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Getting blocked when receinving response from a Parse
Hello: Uhmmm, if you don't mind... are you implementing something like a data provider for Postgresql, or it is just an ad hoc program? Well i start making a simple library for 3.0 protocol for curiosity only :), the protocol have a great documentation, but after some some days i decide to try to make a Data Provider for protocol 3.0 only (I already have made a Data Provider for other RDMBMS :)), -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: CVS tip compile failure (was Re: [HACKERS] Missing array support)
I tried readding the files now, I seems it got them now. Possibly cvs was confused because those files already existed in the 7.3 branch so it found dead revisions in the head branch. Joe Conway writes: Hmmm, I just updated to cvs tip (so I could try this), did `configure`, `make clean`, and `make all` and I'm getting this failure: make[2]: Leaving directory `/opt/src/pgsql/src/port' make -C backend all make[2]: Entering directory `/opt/src/pgsql/src/backend' msgfmt -o po/cs.mo po/cs.po msgfmt -o po/de.mo po/de.po msgfmt -o po/es.mo po/es.po make[2]: *** No rule to make target `po/hr.po', needed by `po/hr.mo'. Stop. make[2]: Leaving directory `/opt/src/pgsql/src/backend' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/src/pgsql/src' make: *** [all] Error 2 Any ideas? Joe -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] IPv6 datatype patch
On Wed, Jun 25, 2003 at 06:26:10PM +0900, [EMAIL PROTECTED] wrote: ftp://ftp.kame.net/pub/kame/misc/ has IPv6 datatype patch (makes inet type handle both IPv4 and IPv6) for 7.3.2. let me know how i can proceed/help. There already is a patch in cvs head that does the same except it doesn't handle the scope. It would probably be useful to look at the other differences. Kurt ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Urgent : Regarding Submission of Code
Hi! We have written two new files by name datacube.c in tcop directory and datacube.h in include directory. We have even changed some exsisting files. We have made a patch of the files that have been changed. But how should we send the new files datacube.c, and datacube.h along with the patch. Is there any specific procedure to send the files we have written. Please tell the procedure of submitting a new file along with the patch. bye Srikanth. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Urgent : Regarding Submission of Code
On 29 Jun 2003 at 19:25, Srikanth M wrote: Please tell the procedure of submitting a new file along with the patch. subscribe to patches list and send the patch there along with descriptions of changes you have made. HTH Bye Shridhar -- COBOL: An exercise in Artificial Inelegance. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] persistant psql feature suggestion
OK, worked out the wrinkle. psql is behaving perfectly well, but the shim
doesn't get a SIGPIPE until it tries to write to it after psql has exited.
A slightly hackish fix for this would be to put this line after the print
$_ line:
if ($_ eq \\q\n) { sleep 1; print ; } # get SIGPIPE if client gone
cheers
andrew
- Original Message -
From: Andrew Dunstan [EMAIL PROTECTED]
To: Matthew T. O'Connor [EMAIL PROTECTED]; James Pye [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, June 28, 2003 5:44 PM
Subject: Re: [HACKERS] persistant psql feature suggestion
Another way is to put a little shim between the fifo and psql. Here's one
I
quickly whipped up in perl (code stolen shamelessly from the perl man
pages). To run in background, invoke thus
( perl myperlfile myfifo | psql gatabase )
The only wrinkle I found was that I had to send the \q twice to make it
quit - I have no idea why.
andrew
--
use strict;
my $curpos;
my $fifofile = shift || usage();
$|=1;
open(FILE,$fifofile) || die $!;
for (;;)
{
for ($curpos = tell(FILE); $_ = FILE; $curpos = tell(FILE))
{
print $_;
}
sleep(1);
seek(FILE, $curpos, 0);
}
sub usage
{
print STDERR usage: ,$0, fifofile\n;
exit 1;
}
- Original Message -
From: Matthew T. O'Connor [EMAIL PROTECTED]
To: James Pye [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 27, 2003 1:44 PM
Subject: Re: [HACKERS] persistant psql feature suggestion
On Fri, 2003-06-27 at 03:21, James Pye wrote:
Greets,
Just a thought for a psql enhancement, afiak, it is not easily
possible
for persistent connections to a database in a shell script..
The ability for psql to remain in the background reading from stdin
and
writing to stdout until explicitly killed. More specifically, so a shell
scriptor can have persistent connections to the database by calling psql
once(leaving it in the bg), and redirecting stdio through a
fifo(mkfifo)(sending queries by echo fifo, and fetching results by cat
fifo).
When I have tried this in the past it will read the query, execute it,
and exit when the results are cat'd from the fifo.
Not sure if it's exactly what you are looking for, nor how well it's
still maintained, but
I believe there is a took out there called pgbash which is a modified
version of bash that understands database queries natively. I think
it's just what you are looking for.
Check out: http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html
Looks like it was updated for 7.3
Matthew
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Week numbers and years
On Wed, Jun 25, 2003 at 14:05:10 +0200, Brage [EMAIL PROTECTED] wrote: A minor feature request: PostgreSQL supports ISO-8601 week numbers with the syntax EXTRACT(WEEK FROM timestamp) or TO_CHAR(timestamp,'IW'). There is, however, no easy way to extract the year corresponding to the week number. Since ISO weeks may overlap year boundaries, this makes the week number functionality nearly unusable in aggregate queries. (e.g. both EXTRACT(WEEK FROM timestamp '2002-01-01') and EXTRACT(WEEK FROM timestamp '2002-12-31') returns 1.) A way to extract the year-of-week would make the extract(week from date)-functionality a lot more useful. While it would probably be nice to have a simple way to do it, you should still be able to get the year of the week. Using the day of the week and the date of the day of interest, you should be able to get the date of the Thursday in the week and the year of that date is the year of the week. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] persistant psql feature suggestion
On Sun, Jun 29, 2003 at 10:22:49AM -0400, Andrew Dunstan wrote:
OK, worked out the wrinkle. psql is behaving perfectly well, but the shim
doesn't get a SIGPIPE until it tries to write to it after psql has exited.
A slightly hackish fix for this would be to put this line after the print
$_ line:
if ($_ eq \\q\n) { sleep 1; print ; } # get SIGPIPE if client gone
cheers
andrew
NAME
IPC::Open2, open2 - open a process for both reading and writing
http://www.perl.com/doc/manual/html/lib/IPC/Open2.html
Would this help?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] join_references: variable not in subplan target lists
I said: While I now need to burrow into the IN-as-join code and find out where it's dropping the ball, I don't think this need stop you from making progress on the information schema. The reason the problem is appearing seems to be the implied cast that's getting introduced in the IN comparison, This theory turns out to be mistaken, or at least only marginally relevant; it's possible to make the problem happen with no casts at all. I think the reason that adding or removing a cast made the problem appear/disappear for me was just that it changed which plan got selected (since the estimation routines are not very bright about coping with joins on expressions). The failure occurs when the planner chooses to implement an IN by unique-ifying the result of the sub-select and then using that as the outer side of a join. If that join is not the topmost join of the whole plan, we fail --- because the unique-ified plan node only emits the variables that are supposed to be used in the IN comparison, but the upper join generates a targetlist that includes every variable used anywhere in the query. If you hit the problem again, you might find that turning off enable_hashagg lets you make progress. A real solution seems to require some honest accounting for which variables need to appear in join targetlists and which don't; I'm off to look at that now ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting blocked when receinving response from a Parse
Carlos Guzman Alvarez wrote: Hello: Uhmmm, if you don't mind... are you implementing something like a data provider for Postgresql, or it is just an ad hoc program? Well i start making a simple library for 3.0 protocol for curiosity only :), the protocol have a great documentation, but after some some days i decide to try to make a Data Provider for protocol 3.0 only (I already have made a Data Provider for other RDMBMS :)), That's very good! Do you know about Npgsql? Please, have a look at gborg.postgresql.org/project/npgsql. It is a Postgresql .net data provider written 100% in C#. Maybe you could give some tips, suggestions, improvements, bug fixes... :) I'm right now implementing the extended query mode and as you and Tom Lane said, the Flush message worked very well. Thanks again. -- Regards, Francisco Figueiredo Jr. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: CVS tip compile failure (was Re: [HACKERS] Missing array support)
Peter Eisentraut wrote: I tried readding the files now, I seems it got them now. Possibly cvs was confused because those files already existed in the 7.3 branch so it found dead revisions in the head branch. Thanks, this fixed it for me. Joe ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Problem when running initdb with latest cvs code
Hi all, I'm getting the following error when trying to do an initdb: This user must also own the server process. The database cluster will be initialized with locale C. Fixing permissions on existing directory /var/pgsqlcvs2... ok creating directory /var/pgsqlcvs2/base... ok creating directory /var/pgsqlcvs2/global... ok creating directory /var/pgsqlcvs2/pg_xlog... ok creating directory /var/pgsqlcvs2/pg_clog... ok creating template1 database in /var/pgsqlcvs2/base/1... ok creating configuration files... ok initializing pg_shadow... ok enabling unlimited row size for system tables... ok initializing pg_depend... ERROR: expression_tree_walker: Unexpected node type 601 IN: expression_tree_walker (clauses.c:2320) initdb failed. Am I missing something?? I have a previous cvs version which works well. I'm using cygwin on windows xp. P.S.: btw, Tom Lane, your fixes for super user name with spaces problem are working very well. Thanks. -- Regards, Francisco Figueiredo Jr. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Problem when running initdb with latest cvs code
Francisco Figueiredo Jr. [EMAIL PROTECTED] writes: initializing pg_depend... ERROR: expression_tree_walker: Unexpected node type 601 IN: expression_tree_walker (clauses.c:2320) Did you do a make clean and full recompile after your last cvs update? This looks like some modules are out of sync about internal node type numbers. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Problem when running initdb with latest cvs code
Francisco Figueiredo Jr. wrote: Hi all, I'm getting the following error when trying to do an initdb: This user must also own the server process. initializing pg_depend... ERROR: expression_tree_walker: Unexpected node type 601 IN: expression_tree_walker (clauses.c:2320) Hi Francisco, I had the same problem. Perform a make clean and then the normal make; make install, and hopefully it will be solved just as it was on my machine. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] persistant psql feature suggestion
We don't need to read and write on the same fd.
The real right way is to detect when the psql client exits - possible when
the perl program spawns it, like shown below.
As always, TIMTOWTDI
andrew
--
use strict;
use IO::Handle;
use POSIX :sys_wait_h;
my $curpos;
my $fifofile = shift || usage();
my $database = shift || usage();
open(FILE,$fifofile) || die $!;
my $psqlpid = open(OUTPIPE,|-);
unless (defined($psqlpid)) { die $!; }
if ($psqlpid == 0)
{
exec(psql -a $database) || die $!;
}
# must be parent here
sub REAPER
{
my $waitedpid;
while (($waitedpid = waitpid(-1,WNOHANG)) 0)
{
if ($waitedpid == $psqlpid) { exit 0; }
}
$SIG{CHLD} = \REAPER; # loathe sysV
}
$SIG{CHLD} = \REAPER;
OUTPIPE-autoflush();
for (;;)
{
for ($curpos = tell(FILE); $_ = FILE; $curpos = tell(FILE))
{
print OUTPIPE $_;
}
sleep(1);
seek(FILE, $curpos, 0);
}
sub usage
{
print STDERR usage: ,$0, fifofile database\n;
exit 1;
}
- Original Message -
From: PeterKorman [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, June 29, 2003 11:40 AM
Subject: Re: [HACKERS] persistant psql feature suggestion
On Sun, Jun 29, 2003 at 10:22:49AM -0400, Andrew Dunstan wrote:
OK, worked out the wrinkle. psql is behaving perfectly well, but the
shim
doesn't get a SIGPIPE until it tries to write to it after psql has
exited.
A slightly hackish fix for this would be to put this line after the
print
$_ line:
if ($_ eq \\q\n) { sleep 1; print ; } # get SIGPIPE if client
gone
cheers
andrew
NAME
IPC::Open2, open2 - open a process for both reading and writing
http://www.perl.com/doc/manual/html/lib/IPC/Open2.html
Would this help?
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Problem when running initdb with latest cvs code
Andreas Pflug wrote: Francisco Figueiredo Jr. wrote: Hi all, I'm getting the following error when trying to do an initdb: This user must also own the server process. initializing pg_depend... ERROR: expression_tree_walker: Unexpected node type 601 IN: expression_tree_walker (clauses.c:2320) Hi Francisco, I had the same problem. Perform a make clean and then the normal make; make install, and hopefully it will be solved just as it was on my machine. Thanks. It worked! Thank you too, Tom Lane. Sorry for bothering you with this :) I will be more carefull next time. -- Regards, Francisco Figueiredo Jr. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Getting blocked when receinving response from a Parse
Hello: That's very good! Do you know about Npgsql? Yes i know about it, but i have no see it in deep ( i use Firebird as RDBMS at this moment ), i decide to take a glance at the 3.0 protocol using C# when i know about the plans for a native Windows version in 7.4 version :) , but i'm not sure if i'm going to finish the .NET data provider implementation. Please, have a look at gborg.postgresql.org/project/npgsql. It is a Postgresql .net data provider written 100% in C#. Maybe you could give some tips, suggestions, improvements, bug fixes... :) :) -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Question about array read using protocol 3.0 implementation in C#
Hello: I'm trying to read an array, using binary format code and my own implementation of the 3.0 protocol in C#, at this moment i have made test with arrays of int2 and float4, seems that the server sends a header of 24 bytes before the data in the buffer, i need to know what these 24 bytes mean :), i think that: 00-03 - ?? 04-07 - ?? 08-11 - typelem 12-15 - ?? 16-19 - ?? 20-23 - typlen Can anybody tell me what these 24 means or where to see it in the PostgreSQL documentation Thanks in advance. -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] persistant psql feature suggestion
On Sun, Jun 29, 2003 at 02:15:26PM -0400, Andrew Dunstan wrote:
We don't need to read and write on the same fd.
The real right way is to detect when the psql client exits - possible when
the perl program spawns it, like shown below.
As always, TIMTOWTDI
andrew
--
use strict;
use IO::Handle;
use POSIX :sys_wait_h;
my $curpos;
my $fifofile = shift || usage();
my $database = shift || usage();
open(FILE,$fifofile) || die $!;
my $psqlpid = open(OUTPIPE,|-);
unless (defined($psqlpid)) { die $!; }
if ($psqlpid == 0)
{
exec(psql -a $database) || die $!;
}
# must be parent here
sub REAPER
{
my $waitedpid;
while (($waitedpid = waitpid(-1,WNOHANG)) 0)
{
if ($waitedpid == $psqlpid) { exit 0; }
}
$SIG{CHLD} = \REAPER; # loathe sysV
}
$SIG{CHLD} = \REAPER;
OUTPIPE-autoflush();
for (;;)
{
for ($curpos = tell(FILE); $_ = FILE; $curpos = tell(FILE))
{
print OUTPIPE $_;
}
sleep(1);
seek(FILE, $curpos, 0);
}
sub usage
{
print STDERR usage: ,$0, fifofile database\n;
exit 1;
}
I dropped into autopilot without considering James Pye's
original phrase:
The ability for psql to remain in the background reading
from stdin and writing to stdout until explicitly killed
I went straight to thinking about handling the psql output
which matched /ERROR/ differently from other output.
I like your solution. But I think I'd code it:
my $psqlpid = open(OUTPIPE,|-) || die qq(cant fork: $!);
Sometimes I'm too stupid to remember that that perl gives
you the fork (the knife and the kitchen sink) even if you
dont realize you asked for it;-)
Cheers,
JPK
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Question about array read using protocol 3.0 implementation in C#
Carlos Guzman Alvarez [EMAIL PROTECTED] writes:
I'm trying to read an array, using binary format code and my own
implementation of the 3.0 protocol in C#, at this moment i have made
test with arrays of int2 and float4, seems that the server sends a
header of 24 bytes before the data in the buffer, i need to know what
these 24 bytes mean :),
Use the source Luke ... array_send, in backend/utils/adt/arrayfuncs.c,
does this:
/* Send the array header information */
pq_sendint(buf, ndim, 4);
pq_sendint(buf, v-flags, 4);
pq_sendint(buf, element_type, sizeof(Oid));
for (i = 0; i ndim; i++)
{
pq_sendint(buf, ARR_DIMS(v)[i], 4);
pq_sendint(buf, ARR_LBOUND(v)[i], 4);
}
I believe flags is always 0 at the moment; it might be a good idea
to punt if you see a nonzero there.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] pgsql-hackers@postgresql.org
On Sun, Jun 22, 2003 at 09:01:35PM -0700, Sean Chittenden wrote: As things stand, because O_DIRECT is an execution fast path through the vfs subsystem, I expect the speed difference to be greater on faster HDDs with high RPMs than on slower IDE machines at only 5400RPM... thus trivializing any benchmark I'll do on my laptop. And actually, if the app can't keep up with the disk, I bet the fs cache case will be faster. If the read()'s are able to keep up at the rate of the HDD, however, this could be a big win in the speed dept, but if things lag for an instant, the platter will have to make another rotation before the call comes back to the userland. If it would help, I have a quad xeon-550 with a 4 drive raid5 and 2 drive mirror (all SCSI, 7200RPM I think) available. -- Jim C. Nasby (aka Decibel!)[EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PlPython
Tom Lane kirjutas E, 23.06.2003 kell 01:29: Kevin Jacobs [EMAIL PROTECTED] writes: Attached is a patch that removes all of the RExec code from plpython from the current PostgreSQL CVS. In addition, plpython needs to be changed to an untrusted language in createlang. I am inclined to rename plpython to plpythonu, by analogy to pltclu. ... Comments? could we not just make sure that plpython uses python ver 2.x and use plpythonu for python versions = 2.x until a secure regex solution comes from Guido and folks ? I guess most plpython users would be much happier with plpython with some minor limitations due to older version than with being forced to use an untrusted pl altogether. IIRC python 1.5.2 has a perfectly good RExec. Or is there a requirement that only latest language versions are used in pg 74 ;) -- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PlPython
Hannu Krosing [EMAIL PROTECTED] writes: could we not just make sure that plpython uses python ver 2.x and use plpythonu for python versions = 2.x until a secure regex solution comes from Guido and folks ? We'd still have to mark it untrusted, so what's the point? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PlPython
Tom Lane kirjutas E, 30.06.2003 kell 00:18: Hannu Krosing [EMAIL PROTECTED] writes: could we not just make sure that plpython uses python ver 2.x and use plpythonu for python versions = 2.x until a secure regex solution comes from Guido and folks ? We'd still have to mark it untrusted, so what's the point? No we don't! The old version of plpython was perfectly OK when used with python 1.5.x and will be so. The RExec security holes were only introduced with new class mechanisms in python 2.x. The version with patch which removes RExec (as Python 2.x is not supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is no reason to remove safe execution when using python 1.5.x. Thus my proposition for using the old version as plpython and the new version as plpython-u, but allowing the non-u version to be compuled only for python v 2.x. - Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PlPython
Hannu Krosing [EMAIL PROTECTED] writes: The version with patch which removes RExec (as Python 2.x is not supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is no reason to remove safe execution when using python 1.5.x. Who's still using 1.5, I guess is the question? And are they likely to be updating their PG installation when they're not updating Python? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PlPython
Tom Lane kirjutas E, 30.06.2003 kell 01:21: Hannu Krosing [EMAIL PROTECTED] writes: The version with patch which removes RExec (as Python 2.x is not supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is no reason to remove safe execution when using python 1.5.x. Who's still using 1.5, I guess is the question? And are they likely to be updating their PG installation when they're not updating Python? Python is designed such that one can install and use different versions in parallel - for example the deafult directopries for libraries are /usr/lib/python1.5/ and /usr/lib/python2.2/ if you have installed python 1.5.x and 2.2.x, also executables are python2, python2.2 and python1.5, with plain python being a link to one of these. I guess that anyone who needs safe Restricted Execution will be using 1.5 at least for that purpose until RExec is fixed in 2.x. -- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] persistant psql feature suggestion
On Sun, Jun 29, 2003 at 05:24:18PM -0400, Andrew Dunstan wrote:
- Original Message -
From: PeterKorman [EMAIL PROTECTED]
I like your solution. But I think I'd code it:
my $psqlpid = open(OUTPIPE,|-) || die qq(cant fork: $!);
Won't that cause the child to die because it will have 0 in $psqlpid?
Doh!!
A rhetorical question, no doubt.
--
#!/usr/bin/perl
#except for sigchld, This is better.
my $pid;
defined($pid=open(X, |-)) || die qq(cant fork: $!\n);
if ($pid){
system(qq(touch parent));
}
else{
system(qq(touch child));
};
--
I wrongly guessed that control would resume at the line
following:
my $psqlpid = open(OUTPIPE,|-) || die qq(cant fork: $!);
There are, evidently, many things I'm too stupid to remember;-\
Cheers,
JPK
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PlPython
Hannu Krosing [EMAIL PROTECTED] writes: Tom Lane kirjutas E, 30.06.2003 kell 01:21: Who's still using 1.5, I guess is the question? And are they likely to be updating their PG installation when they're not updating Python? I guess that anyone who needs safe Restricted Execution will be using 1.5 at least for that purpose until RExec is fixed in 2.x. I don't find that real compelling ... The bottom line is that this has to get done. I have the time to convert plpython to untrusted status tomorrow. I do not have the time, the infrastructure, nor the interest to build a conditional setup. Unless someone else wants to volunteer to make it happen in a timely fashion, untrusted is what it will be. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PlPython
Hannu Krosing wrote: could we not just make sure that plpython uses python ver 2.x and use plpythonu for python versions = 2.x until a secure regex solution comes from Guido and folks ? I guess most plpython users would be much happier with plpython with some minor limitations due to older version than with being forced to use an untrusted pl altogether. But if rexec isn't safe they're just fooling themselves. There's only two kinds of safety for restricted environments: absolute and not. That's why the Python developers were honest and disabled rexec for now. If you want to fool yourself, that's easy enough: ship a modified rexec.py with the 'raise RuntimeError, This code is not secure ...' removed ;-) IIRC python 1.5.2 has a perfectly good RExec. You are likely mistaken. Because I was interested in getting this problem solved for plpython and because most rexec problems are because of the new-style classes in Python 2.2 and later, I asked on comp.lang.python wether it was safe with 2.1 and earlier. Martin von Löwis told me it probably wasn't in http://groups.google.com/groups?selm=m3y8ztib79.fsf%40mira.informatik.hu-berlin.de Or is there a requirement that only latest language versions are used in pg 74 ;) No, but I find it hard to believe that PL/python is used by untrusted users at all, so making it untrusted might not really be a problem in real life. -- Gerhard PS: Thanks Kevin for submitting the PL/Python patch. I intended to make it available at least as an untrusted language, but you beat me :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [INTERFACES] libpgtcl and pgtclsh
Marc, libpgtcl is already over at gborg, but pgtclsh is not: http://gborg.postgresql.org/project/pgtcl/projdisplay.php Karl Lehenbauer started the project, and I have helped out along the way. Currently, my time is short, but I probably would have time down the road to look into moving pgtclsh over there as well. --brett --- The Hermit Hacker [EMAIL PROTECTED] wrote: I'm looking to move both of these over to GBorg, like we did with the C++ interfaces and ODBC ... the problem is, unlike those, I can't find anyone that is actually working with it ... Is anyone using these? Anyone willing to step up and act as maintainer for it? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PlPython
=?ISO-8859-1?Q?Gerhard_H=E4ring?= [EMAIL PROTECTED] writes: ... because most rexec problems are because of the new-style classes in Python 2.2 and later, I asked on comp.lang.python wether it was safe with 2.1 and earlier. Martin von Löwis told me it probably wasn't in http://groups.google.com/groups?selm=m3y8ztib79.fsf%40mira.informatik.hu-berlin.de Hmm. I don't think the second bug mentioned there applies to us (if our use of rexec allows the Python code to write any file anywhere, it's already lost its right to trusted status IMHO). But the first one looks like a killer: http://sourceforge.net/tracker/?group_id=5470atid=105470func=detailaid=577530 According to that discussion, this bug does exist in Python 1.5 :-( ... so Hannu's argument rests on a false premise anyway. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
