Re: [HACKERS] v7.3 Branched ...

2002-10-22 Thread Sean Chittenden
Perhaps one could just create a PostgreSQL Powertools section on techdocs, naming the packages and where to get them. This would eliminate the need to maintain a package that just duplicates other packages... Let ye-old package managers make a shell package which simply points to the

[HACKERS] Multiple Key Clustering In Db2 8.1 - Interesting FYI

2002-10-22 Thread Mark Kirkwood
Dear hackers, I have recently been playing with DB2 8.1 Beta. It has introduced a feature to enable index clustering on more than one key. This reminded me of a previous thread on HACKERS about index access anding/bitmaps in Firebird. So anyway, here is a little snip from the 8.1 manual as a

[HACKERS] Current CVS is broken

2002-10-22 Thread Teodor Sigaev
%gmake bison -y -d preproc.y preproc.y:5560: fatal error: maximum table size (32767) exceeded gmake[4]: *** [preproc.h] Error 1 gmake[4]: Leaving directory `/spool/home/teodor/pgsql/src/interfaces/ecpg/preproc' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory

Re: [HACKERS] Current CVS is broken

2002-10-22 Thread Michael Paesold
Teodor Sigaev [EMAIL PROTECTED] wrote: %gmake bison -y -d preproc.y preproc.y:5560: fatal error: maximum table size (32767) exceeded gmake[4]: *** [preproc.h] Error 1 gmake[4]: Leaving directory `/spool/home/teodor/pgsql/src/interfaces/ecpg/preproc' gmake[3]: *** [all] Error 2

Re: [HACKERS] New SET/autocommit problem

2002-10-22 Thread Tom Lane
Sean Chittenden [EMAIL PROTECTED] writes: WARNING: COMMIT: no transaction in progress I've got tons of these warnings in my logs... is there a programmatic way of determining if the current session is in a transaction? Not at present: you have to track it for yourself. One of the

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Tom Lane
Philip Warner [EMAIL PROTECTED] writes: None, but it will be compatible with itself (the most we can hope for), and will work even if shifting is not supported for off_t (how likely is that?). I agree shift is definitely the way to go if it works on arbitrary data - ie. it does not rely on

Re: [HACKERS] Current CVS is broken

2002-10-22 Thread Tom Lane
Oleg Bartunov [EMAIL PROTECTED] writes: install bison 1.75 I've fixed the INSTALL and installation.sgml docs to say you need bison 1.50 or later (it used to say 1.28 or later). Is there anyplace else we should point this out? regards, tom lane

Re: [GENERAL] [HACKERS] Hot Backup

2002-10-22 Thread Andrew Sullivan
On Wed, Oct 09, 2002 at 09:42:56AM -0400, Sandeep Chadha wrote: I'd say yes replication can solve lot of issues, but is there a way to do replication in postgres(active-active or active-passive) Yes. Check out the rserv code in contrib/, the (?) dbmirror code in contrib/, or contact

Re: [HACKERS] autocommit vs TRUNCATE et al

2002-10-22 Thread Zeugswetter Andreas SB SD
What I just committed uses your idea of auto-committing TRUNCATE et al, but now that I review the thread I think that everyone else thought that that was a dangerous idea. How do you feel about simply throwing an error in autocommit-off mode, instead? (At least it's a localized change

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-10-22 Thread Andrew Sullivan
On Mon, Oct 14, 2002 at 12:04:14AM -0400, Tom Lane wrote: implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be happier with a local, temporary setting that only affects the current backend. Any thoughts

Re: [HACKERS] One 7.3 item left

2002-10-22 Thread Kaare Rasmussen
Schema handling - ready? interfaces? client apps? What is the state of the Perl interface? Will it work when 7.3 is released Will it work, but no schema support Will it pop up later on CPAN -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Data

Re: [HACKERS] CVS split problems

2002-10-22 Thread Peter Eisentraut
Marc G. Fournier writes: Okay, this is the only message(s) I have on this ... since merging earthdistance back into the tree will most likely cause more headaches, breakage and outcries, and since I see no reason why anyone would want to 'checkout' a module that has already been checked out

Re: [HACKERS] One 7.3 item left

2002-10-22 Thread Peter Eisentraut
Bruce Momjian writes: OK, we are down to one open item, related to pg_dumping on 64-bit off_t. We had discussion today on this so it should be completed shortly. I hate to spoil the fun, but we have at least the Linux + Perl 5.8.1 + _GNU_SOURCE and the AIX + Large File + Flex problems to fix.

Re: [HACKERS] One 7.3 item left

2002-10-22 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian writes: OK, we are down to one open item, related to pg_dumping on 64-bit off_t. We had discussion today on this so it should be completed shortly. I hate to spoil the fun, but we have at least the Linux + Perl 5.8.1 + _GNU_SOURCE and

[HACKERS] Silly little tool for making parallel_schedule variants

2002-10-22 Thread Tom Lane
I got tired of wondering what timing dependencies might still be lurking in the parallel regression tests, and wrote a little Perl script to find out by making variant versions of the parallel_schedule file. Essentially, the script forces each test in a parallel group to run before all the other

[HACKERS] Memory leaks

2002-10-22 Thread Greg Copeland
I've started playing a little with Postgres to determine if there were memory leaks running around. After some very brief checking, I'm starting[1] to think that the answer is yes. Has anyone already gone through a significant effort to locate and eradicate memory leaks? Is this done

Re: [HACKERS] Memory leaks

2002-10-22 Thread Petru Paler
On Tue, Oct 22, 2002 at 04:16:16PM -0500, Greg Copeland wrote: I've started playing a little with Postgres to determine if there were memory leaks running around. After some very brief checking, I'm starting[1] to think that the answer is yes. Has anyone already gone through a significant

Re: [HACKERS] Memory leaks

2002-10-22 Thread Tom Lane
Greg Copeland [EMAIL PROTECTED] writes: I've started playing a little with Postgres to determine if there were memory leaks running around. After some very brief checking, I'm starting[1] to think that the answer is yes. Has anyone already gone through a significant effort to locate and

[HACKERS] Thinking about IN/EXISTS optimization

2002-10-22 Thread Tom Lane
I've been thinking about how to convert x IN (subselect) and EXISTS constructs into join-like processing, and I've run into a small problem in getting the planner to do it nicely. The issue is that I need to take the subselect and push it into the jointree --- essentially, make it look like a

Re: [HACKERS] Memory leaks

2002-10-22 Thread Neil Conway
Petru Paler [EMAIL PROTECTED] writes: valgrind is a great tool I used -- didn't get the time to try it out on Postgres yet, though. Besides leaks, it also catches uninitialized variable access and stuff like that. I've used Valgrind with PostgreSQL a little bit, and it's been fairly useful (I

Re: [HACKERS] Memory leaks

2002-10-22 Thread Greg Copeland
On Tue, 2002-10-22 at 17:09, Tom Lane wrote: Greg Copeland [EMAIL PROTECTED] writes: I've started playing a little with Postgres to determine if there were memory leaks running around. After some very brief checking, I'm starting[1] to think that the answer is yes. Has anyone already gone

Re: [HACKERS] Memory leaks

2002-10-22 Thread Nigel J. Andrews
On 22 Oct 2002, Greg Copeland wrote: On Tue, 2002-10-22 at 17:09, Tom Lane wrote: plpgsql has some issues too, I suspect, but not as bad as pltcl etc. Possibly the best answer is to integrate the memory-context notion into those modules; if they did most of their work in a temp context

Re: [HACKERS] One 7.3 item left

2002-10-22 Thread Bruno Wolff III
On Tue, Oct 22, 2002 at 19:01:20 +0200, Kaare Rasmussen [EMAIL PROTECTED] wrote: Schema handling - ready? interfaces? client apps? What is the state of the Perl interface? Will it work when 7.3 is released Will it work, but no schema support Will it pop up later on CPAN I am using Pg

Re: [HACKERS] Memory leaks

2002-10-22 Thread Tom Lane
Nigel J. Andrews [EMAIL PROTECTED] writes: I saw use of a couple of malloc (or Python specific malloc) calls the other day but I also seem to recall that, after consideration, I decided the memory needed to survive for the duration of the backend. Should I have created a new child of the top

Re: [HACKERS] Memory leaks

2002-10-22 Thread Tom Lane
Greg Copeland [EMAIL PROTECTED] writes: On Tue, 2002-10-22 at 17:09, Tom Lane wrote: Yes, this has been dealt with before. What tools, aside from noggin v1.0, did they use? Do we know? s/they/me/ ... none. But I don't know of any that I think would be useful. I then moved on to psql,

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I wonder if any other platforms have this limitation. I think we need to add some type of test for no-fseeko()/ftello() and sizeof(off_t) sizeof(long). This fseeko/ftello/off_t is just too fluid, and the failure modes too serious. I am wondering why

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Philip Warner
At 12:32 AM 23/10/2002 -0400, Tom Lane wrote: I am wondering why pg_dump has to depend on either fseek or ftell. It doesn't - it just works better and has more features if they are available, much like zlib etc. Philip Warner

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Philip Warner
At 12:29 AM 23/10/2002 -0400, Bruce Momjian wrote: This fseeko/ftello/off_t is just too fluid, and the failure modes too serious. I agree. Can you think of a better solution than the one I suggested??? Philip Warner

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
OK, you are saying if we don't have fseeko(), there is no reason to use off_t, and we may as well use long. What limitations does that impose, and are the limitations clear to the user. What has me confused is that I only see two places that use a non-zero fseeko, and in those cases, there is a

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Philip Warner
At 01:02 AM 23/10/2002 -0400, Bruce Momjian wrote: OK, you are saying if we don't have fseeko(), there is no reason to use off_t, and we may as well use long. What limitations does that impose, and are the limitations clear to the user. What I'm saying is that if we have not got fseeko then

Re: [HACKERS] Memory leaks

2002-10-22 Thread Karel Zak
On Tue, Oct 22, 2002 at 11:28:23PM -0400, Tom Lane wrote: I then moved on to psql, again, just for fun. Here, I'm thinking that I started to find some other leaks...but again, I've not spent any real time on it. So again, I'm not really sure it they are meaningful at this point. psql

Re: [HACKERS] New SET/autocommit problem

2002-10-22 Thread Sean Chittenden
WARNING: COMMIT: no transaction in progress COMMIT The WARNING happens with SHOW and RESET too. I wonder if we should suppress the WARNING of a COMMIT with no statements when autocommit is off. I don't think so; that will make it quite hard to check whether a transaction

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Philip Warner
At 09:52 PM 21/10/2002 -0400, Bruce Momjian wrote: 4) pg_restore -Fc /tmp/x pg_restore /tmp/x is enough; it will determine the file type, and by avoiding the pipe, you allow it to do seeks which are not much use here, but are usefull when you only restore one table in a very large

Re: [HACKERS] integer array, push and pop

2002-10-22 Thread Teodor Sigaev
regression=# select '{124,567,66}'::int[] + 345; ?column? -- {124,567,66,345} (1 row) regression=# select '{124,567,66}'::int[] + '{345,1}'::int[]; ?column? {124,567,66,345,1} (1 row) select '{124,567,66}'::int[] - 567; ?column? --

Re: [HACKERS] Current CVS is broken

2002-10-22 Thread Oleg Bartunov
install bison 1.75 On Tue, 22 Oct 2002, Teodor Sigaev wrote: %gmake bison -y -d preproc.y preproc.y:5560: fatal error: maximum table size (32767) exceeded gmake[4]: *** [preproc.h] Error 1 gmake[4]: Leaving directory `/spool/home/teodor/pgsql/src/interfaces/ecpg/preproc' gmake[3]:

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Philip Warner
At 10:16 AM 21/10/2002 -0400, Tom Lane wrote: What are the odds that dumping the bytes in it, in either order, will produce something that's compatible with any other platform? None, but it will be compatible with itself (the most we can hope for), and will work even if shifting is not

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
Tom Lane wrote: Philip Warner [EMAIL PROTECTED] writes: None, but it will be compatible with itself (the most we can hope for), and will work even if shifting is not supported for off_t (how likely is that?). I agree shift is definitely the way to go if it works on arbitrary data - ie.

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Philip Warner
At 12:00 PM 22/10/2002 -0400, Bruce Momjian wrote: It does have the advantage of being more portable on systems that do have integral off_t I suspect it is no more portable than determining storage order by using 'int i = 256', then writing in storage order, and has the disadvantage that it

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: However, since we don't know if we support any non-integral off_t platforms, and because a configure test would require us to have two code paths for with/without integral off_t, I suggest we apply my version of Philip's patch and let's see if everyone

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
Philip Warner wrote: At 12:00 PM 22/10/2002 -0400, Bruce Momjian wrote: It does have the advantage of being more portable on systems that do have integral off_t I suspect it is no more portable than determining storage order by using 'int i = 256', then writing in storage order, and has

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: However, since we don't know if we support any non-integral off_t platforms, and because a configure test would require us to have two code paths for with/without integral off_t, I suggest we apply my version of Philip's patch and

Re: [HACKERS] autocommit vs TRUNCATE et al

2002-10-22 Thread Bruce Momjian
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I just noticed that this afternoon's changes cause dblink's regression test to fail due to: CREATE OR REPLACE FUNCTION conditional_drop() [...] IF FOUND THEN DROP DATABASE regression_slave; END IF; [...] '

Re: [HACKERS] One 7.3 item left

2002-10-22 Thread Bruce Momjian
Kaare Rasmussen wrote: Schema handling - ready? interfaces? client apps? What is the state of the Perl interface? Will it work when 7.3 is released Will it work, but no schema support Will it pop up later on CPAN We have a separate gborg project for the old perl5 in interface and

Re: [HACKERS] New SET/autocommit problem

2002-10-22 Thread Sean Chittenden
WARNING: COMMIT: no transaction in progress I've got tons of these warnings in my logs... is there a programmatic way of determining if the current session is in a transaction? Not at present: you have to track it for yourself. One of the suggestions on the list for the next

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Your version will break more often because we are assuming we can determine the endian-ness of the OS, _and_ for quad off_t types, assuming we know that is stored the same too. While we have ending for int's, I have no idea if quads are always stored

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
Patch applied with shift / changes by me. Thanks. --- Philip Warner wrote: I have put the latest patch at: http://downloads.rhyme.com.au/postgresql/pg_dump/ along with two dump files of the regression DB,

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
Bruce Momjian wrote: So I think we're wasting our time to debate whether we need to support non-integral off_t ... let's just apply Bruce's version and wait to see if anyone has a problem before doing more work. I am concerned about one more thing. On BSD/OS, we have off_t of quad (8

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Peter Eisentraut
Bruce Momjian writes: I am concerned about one more thing. On BSD/OS, we have off_t of quad (8 byte), but we don't have fseeko, so this call looks questionable: if (fseeko(AH-FH, tctx-dataPos, SEEK_SET) != 0) Maybe you want to ask your OS provider how the heck this is supposed to

Re: [HACKERS] Memory leaks

2002-10-22 Thread Hannu Krosing
On Wed, 2002-10-23 at 03:09, Tom Lane wrote: It's fairly difficult to get anywhere with standard leak-tracking tools, since they don't know anything about palloc. What's worse, it is *not* a bug for a routine to palloc space it never pfrees, if it knows that it's palloc'ing in a short-lived

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
Peter Eisentraut wrote: Bruce Momjian writes: I am concerned about one more thing. On BSD/OS, we have off_t of quad (8 byte), but we don't have fseeko, so this call looks questionable: if (fseeko(AH-FH, tctx-dataPos, SEEK_SET) != 0) Maybe you want to ask your OS provider how the

Re: [HACKERS] One 7.3 item left

2002-10-22 Thread Marc G. Fournier
On Tue, 22 Oct 2002, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian writes: OK, we are down to one open item, related to pg_dumping on 64-bit off_t. We had discussion today on this so it should be completed shortly. I hate to spoil the fun, but we have at least

Re: [HACKERS] One 7.3 item left

2002-10-22 Thread Bruce Momjian
Marc G. Fournier wrote: On Tue, 22 Oct 2002, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian writes: OK, we are down to one open item, related to pg_dumping on 64-bit off_t. We had discussion today on this so it should be completed shortly. I hate to

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Philip Warner
At 05:37 PM 22/10/2002 -0400, Bruce Momjian wrote: ! if (ctx-hasSeek ! #if !defined(HAVE_FSEEKO) !sizeof(off_t) = sizeof(long) ! #endif ! ) Just to clarify my understanding: - HAVE_FSEEKO is tested defined in configure - If it is not

Re: [HACKERS] Thinking about IN/EXISTS optimization

2002-10-22 Thread Bruce Momjian
This sounds like one of those classic optimizer problems we have had to deal with in the past. I suggest you go through the optimizer pass and set a boolean in Query whenever you do something that may require another loop through, then at the end, you check the boolean and loop if required. I

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
Philip Warner wrote: At 05:37 PM 22/10/2002 -0400, Bruce Momjian wrote: ! if (ctx-hasSeek ! #if !defined(HAVE_FSEEKO) !sizeof(off_t) = sizeof(long) ! #endif ! ) Just to clarify my understanding: - HAVE_FSEEKO is tested

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Philip Warner
At 10:46 PM 22/10/2002 -0400, Bruce Momjian wrote: Uh, not exactly. I have off_t as a quad, and I don't have fseeko, so the above conditional doesn't work. I want to use off_t, but can't use fseek(). Then when you create dumps, they will be invalid since I assume that ftello is also broken in

Re: [HACKERS] pg_dump and large files - is this a problem?

2002-10-22 Thread Bruce Momjian
Sounds messy. Let me see if I can code up an fseeko/ftello for BSD/OS and add that to /port. No reason to hold up beta for that, though. I wonder if any other platforms have this limitation. I think we need to add some type of test for no-fseeko()/ftello() and sizeof(off_t) sizeof(long).

[HACKERS] Brazilian Portuguese version of the PostgreSQL Advocacy and Marketing site is ready

2002-10-22 Thread Justin Clift
Hi everyone, Thanks to Diogo Biazus [EMAIL PROTECTED], the Brazilian Portuguese translation of the PostgreSQL Advocacy and Marketing site is now completed and ready for public use: http://advocacy.postgresql.org/?lang=br :-) Wow, that's 6 languages already, and more are coming along. Am very,

[HACKERS] Security question : Database access control

2002-10-22 Thread Igor Georgiev
Is there any way to prevent superuser to acces the database ? I mean something like "GRANT / REVOKE CONNECT" MECHANISM I have no idea how to prevent root from access data in one of this ways : root @ linux:~#su - postgres postgres @ linux:/usr/local/pgsql/bin$pg_dump or edit

Re: [HACKERS] [ADMIN] Security question : Database access control

2002-10-22 Thread Bruno Wolff III
On Tue, Oct 22, 2002 at 17:05:38 +0200, Igor Georgiev [EMAIL PROTECTED] wrote: Is there any way to prevent superuser to acces the database ? I mean something like GRANT / REVOKE CONNECT MECHANISM I have no idea how to prevent root from access data in one of this ways : root @

Re: [HACKERS] Security question : Database access control

2002-10-22 Thread Igor Georgiev
edit *pg_hba.conf * # Allow any user on the local system to connect to any # database under any username, but only via an IP connection: host all 127.0.0.1 255.255.255.255 trust # The same, over Unix-socket connections: local all trust what about reading pg_hba.conf

Re: [HACKERS] Security question : Database access control

2002-10-22 Thread scott.marlowe
On Tue, 22 Oct 2002, Igor Georgiev wrote: edit *pg_hba.conf * # Allow any user on the local system to connect to any # database under any username, but only via an IP connection: host all 127.0.0.1 255.255.255.255trust

Re: [HACKERS] [ADMIN] Security question : Database access control

2002-10-22 Thread Stephan Szabo
On Tue, 22 Oct 2002, Igor Georgiev wrote: edit *pg_hba.conf * # Allow any user on the local system to connect to any # database under any username, but only via an IP connection: host all 127.0.0.1 255.255.255.255trust #

Re: [HACKERS] [ADMIN] Security question : Database access control

2002-10-22 Thread Igor Georgiev
They can just read the raw database files as well. wow I'm not sure how about this edit pg_hba.conf # Allow any user on the local system to connect to any # database under any username local all trust su - posgres psql test -U dba or pg_dump test You have to be able to

Re: [HACKERS] [ADMIN] Security question : Database access control

2002-10-22 Thread Tom Lane
Igor Georgiev [EMAIL PROTECTED] writes: Ok, but my question actually isn't about pg_hba.conf comments, i read enough but what will stop root from adding this lines or doing su - postgres ?? As somebody already pointed out, you *must* trust the people with root access to your machine; there is

Re: [HACKERS] Security question : Database access control

2002-10-22 Thread Igor Georgiev
Next your going to ask what will stop root from stopping your PostgreSQL, compiling a second copy with authentication disabled and using your data directory as it's source :) He he i'm enough paranoic :)) If you want to prevent root from accomplishing these things, you're going to have