[HACKERS] version mismatch message
I get this in my logs from our backups. I ahve explicitly put -i in pg_dumpall. How about we totally suppress this message if -i is supplied, because obviously the person knows perfectly well it's proceeding despite version mismatch? Chris pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4; pg_dump version: 7.3.2 pg_dump: proceeding despite version mismatch pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4; pg_dump version: 7.3.2 pg_dump: proceeding despite version mismatch pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4; pg_dump version: 7.3.2 pg_dump: proceeding despite version mismatch pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4; pg_dump version: 7.3.2 pg_dump: proceeding despite version mismatch pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4; pg_dump version: 7.3.2 pg_dump: proceeding despite version mismatch pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4; pg_dump version: 7.3.2 pg_dump: proceeding despite version mismatch pg_dump: server version: PostgreSQL 7.3.3 on i386-portbld-freebsd4.7, compiled by GCC 2.95.4; pg_dump version: 7.3.2 pg_dump: proceeding despite version mismatch ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] pgsql 7.3.4 (bz2 format)
Hi When will the bz2 (cygwin package release) be available? Pieter == Download ringtones, logos and picture messages at Ananzi Mobile Fun. http://www.ananzi.co.za/cgi-bin/goto.pl?mobile ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] patch queue
Bruce Momjian writes: I see all submitted patches as applied, except from Gavin's WHERE CURRENT OF patch, and I am asking for opinions on that one. I think it's too late for that one. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] version mismatch message
Christopher Kings-Lynne writes: I get this in my logs from our backups. I ahve explicitly put -i in pg_dumpall. How about we totally suppress this message if -i is supplied, because obviously the person knows perfectly well it's proceeding despite version mismatch? I think if we did that, then people would become inclined to use pg_dump -i automatically. The reason that the version mismatch check exists is that we *know* that pg_dump is unable to dump a reasonably complex database from certain versions correctly. Nonetheless, I think a pg_dump 7.3.2 dumping a 7.3.3 database should not raise a version mismatch message at all. (In general, pg_dump x.y.z1 ought to be able to dump a server x.y.z2 for any z1 and z2.) Check out _check_database_version in pg_backup_db.c if you like to fix it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Sean Chittenden writes: At the very least, it's an easier way of guaranteeing a READ ONLY database. Securing a database with GRANT/REVOKE can be tedious and error prone. A database is already secure from a new user by default: He cannot read or write or create anything except temporary tables and possibly the public schema. Setting him read only isn't going to change anything, because he still can't actually read anything. Before he can do that, the administrator needs to grant him SELECT privileges. And after that, there is still no difference between read only and read write, because the user still can't write anything. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pkglibdir versus libdir?
Tom Lane writes: Peter, I'm a little confused about the difference between the libdir and pkglibdir settings created by configure. What's supposed to go where? libdir is for build-time linkable libraries, anything that you might want to pass as -lxxx. So typical locations are /usr/lib, /usr/local/lib, or /usr/local/pgsql/lib. pkglibdir is for dynamically loadable libraries, or in general any architecture-specific files that don't need to be in a particular place, the intent being to keep them out of shared directories like /usr/lib. Typical locations are /usr/lib/postgresql or /usr/local/lib/postgresql. There is the additional trick that if libdir already contains the string postgres, that is, you have already configured libdir to be a private directory, then pkglibdir is equal to libdir. This was mainly meant as a transition scheme (from formerly having everything in libdir); if it's too confusing we can take it out. I got a complaint from a Red Hat person that the regression tests failed on a 64-bit machine. Some investigation revealed that the problem was that plpgsql.so got installed into $libdir while pg_regress.sh expected to find it in $pkglibdir. Umm... from src/pl/plpgsql/src/Makefile: install: installdirs all ifeq ($(enable_shared), yes) $(INSTALL_SHLIB) $(shlib) $(DESTDIR)$(pkglibdir)/plpgsql$(DLSUFFIX) else @echo *; \ echo * PL/pgSQL was not installed due to lack of shared library support.; \ echo * endif (The fact that they were different was an RPM configuration bug, but if we are going to have two variables we certainly ought to support their being different...) I don't know how to decide which one is wrong. In an RPM installation they certainly should be different. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] how to dump all tables with pg_dump ?
Hi there, I'm confused with pg_dump -t '*', it doesn't works as expected from pg_dump --help: -t, --table=TABLEdump this table only (* for all) I tried any combinations but never succeeded. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Bruce Momjian writes: If we change default_transaction_read_only to PGC_USERLIMIT, the administrator can turn it on and off, but an ordinary user can only turn it on, but not off. Would that help? No, it would break the SQL standard. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proof-of-concept for initdb-time shared_buffers selection
On Fri, 04 Jul 2003 15:29:37 -0400, Tom Lane [EMAIL PROTECTED] wrote: The attached patch shows how initdb can dynamically determine reasonable shared_buffers and max_connections settings that will work on the current machine. Can't this be done on postmaster startup? I think of two GUC variables where there is only one today: min_shared_buffers and max_shared_buffers. If allocation for the max_ values fails, the numbers are decreased in a loop of, say, 10 steps until allocation succeeds, or even fails at the min_ values. The actual values chosen are reported as a NOTICE and can be inspected as readonly GUC variables. This would make the lives easier for the folks trying to come up with default .conf files, e.g. min_shared_buffers = 64 max_shared_buffers = 2000 could cover a fairly large range of low level to mid level machines. A paranoid dba, who doesn't want the postmaster to do unpredictable things on startup, can always set min_xxx == max_xxx to get the current behaviour. Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] followup on previous
We wouldn't like to have it called Ingres too... Spoken language is different from written, so docs should be precise. PostgreSQL is a mark, and should be used as careful as it deserves. Regards, Andreas Christopher Kings-Lynne wrote: I just seem to recall a discussion where we decided to 'standardise' on PostgreSQL...I'm not fussed tho. Chris - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Christopher Kings-Lynne [EMAIL PROTECTED] Cc: Hackers [EMAIL PROTECTED] Sent: Thursday, July 31, 2003 12:53 PM Subject: Re: [HACKERS] followup on previous Thomas liked Postgres rather than PostgreSQL in the docs, and I think that's where it came from. I use Postgres in speaking, and PostgreSQL in writing, so I guess either is OK. ---(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] autocommit in 7.4
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The issue I have is that every interface that relies on libpq is going to have to code it itself. Is that OK? So? Most interfaces have to adhere to their own notions of transaction semantics and control API anyway. libpq should stay out of their way rather than try to be helpful. I see this as not different from the lesson we learned that doing it in the backend isn't the right place. I know Perl and jdbc do, but things like c++ and libpgeasy don't really have a specification to follow. With the ability to check the transaction status, it might now be easy enough to do autocommit that having it happen in every interfaces will be ok. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] how to dump all tables with pg_dump ?
Oleg Bartunov [EMAIL PROTECTED] writes: I'm confused with pg_dump -t '*', it doesn't works as expected from pg_dump --help: -t, --table=TABLEdump this table only (* for all) The help is mistaken --- that is not a working feature. Leave out the -t if you want all tables. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pkglibdir versus libdir?
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Peter, I'm a little confused about the difference between the libdir and pkglibdir settings created by configure. What's supposed to go where? libdir is for build-time linkable libraries, anything that you might want to pass as -lxxx. So typical locations are /usr/lib, /usr/local/lib, or /usr/local/pgsql/lib. pkglibdir is for dynamically loadable libraries, Okay, so anything meant to be loaded by the backend goes in pkglibdir? I got a complaint from a Red Hat person that the regression tests failed on a 64-bit machine. Some investigation revealed that the problem was that plpgsql.so got installed into $libdir while pg_regress.sh expected to find it in $pkglibdir. Umm... from src/pl/plpgsql/src/Makefile: Actually, further investigation revealed that there is brain damage in the rpm patches: some places have been hacked to have hard-wired paths. As soon as $libdir is not /usr/lib, the rpm patches roll over and die. We mistakenly blamed this on a libdir-vs-pkglibdir discrepancy, until we noticed what was actually getting executed ... Thanks for the response. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] version mismatch message
Peter Eisentraut [EMAIL PROTECTED] writes: Nonetheless, I think a pg_dump 7.3.2 dumping a 7.3.3 database should not raise a version mismatch message at all. I'm unconvinced; at best, you are assuming zero bugs. I think the warning message is reasonable as it stands, and that what Chris ought to be spending his time on is updating his pg_dump. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Another nasty pg_dump problem
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
On my 7.3 server:
REVOKE ALL ON TABLE exercise_activities FROM PUBLIC;
GRANT ALL ON TABLE exercise_activities TO chriskl;
GRANT SELECT ON TABLE exercise_activities TO au-diary;
GRANT SELECT ON TABLE exercise_activities TO au-php;
Now if you load that into 7.4CVS, you get:
REVOKE ALL ON TABLE exercise_activities FROM PUBLIC;
GRANT ALL ON TABLE exercise_activities TO chriskl;
GRANT SELECT ON TABLE exercise_activities TO \au-diary\;
GRANT SELECT ON TABLE exercise_activities TO \au-php\;
I've repaired this in CVS tip. While testing it, though, I notice that
CVS-tip pg_dump puts out useless commands
REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT ALL ON SCHEMA public TO PUBLIC;
which are not generated when dumping from 7.3. The reason evidently is
that this check in pg_dump.c no longer works:
/*
* If it's the PUBLIC namespace, don't emit a CREATE SCHEMA record
* for it, since we expect PUBLIC to exist already in the
* destination database. And emit ACL info only if the ACL isn't
* the standard value for PUBLIC.
*/
if (strcmp(nspinfo-nspname, public) == 0)
{
if (!aclsSkip strcmp(nspinfo-nspacl, {=UC}) != 0)
dumpACL(fout, SCHEMA, qnspname, nspinfo-nspname, NULL,
nspinfo-usename, nspinfo-nspacl,
nspinfo-oid);
}
since the default ACL for public no longer looks like that. Can we fix
this?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] followup on previous
Chris, I just seem to recall a discussion where we decided to 'standardise' on PostgreSQL...I'm not fussed tho. Putting on marketing hat: While branding is important, unlike other projects the shortened version of our name is still distinctive and unique ... Postgres is unlikely to be mistaken for anything else. So we should use PostgreSQL whenever we can remember, and correct the abbreviated form where we see it in the documentation, but it's probably not worth a global search-and-replace in the docs. -- Josh Berkus Aglio Database Solutions San Francisco ---(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] version mismatch message
Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: Nonetheless, I think a pg_dump 7.3.2 dumping a 7.3.3 database should not raise a version mismatch message at all. I'm unconvinced; at best, you are assuming zero bugs. Yes. The version mismatch message wasn't created because we are assuming bugs, but because we know that pg_dump cannot handle the catalogs, which is not the case when you use 7.3.2 to dump 7.3.3. If we want to take bugs into account, then we can't let pg_dump work with any other version, possibly not even its own. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] Proof-of-concept for initdb-time shared_buffers selection
Manfred, Can't this be done on postmaster startup? I think of two GUC variables where there is only one today: min_shared_buffers and max_shared_buffers. If allocation for the max_ values fails, the numbers are decreased in a loop of, say, 10 steps until allocation succeeds, or even fails at the min_ values. I think the archives are back up. Take a look at this thread; we already had this discussion at some length, and decided that a max of 1000 was reasonable in advance of user tuning. And, I believe, Tom has already written the code. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Error messages --- now that we've got it, do you like
Alvaro Herrera Munoz wrote: Well, if this needs a vote, I'm for something like maximum/default/minimum rather than the way it currently is. Saying verbosity verbose or verbosity terse doesn't feel right, while verbosity maximum makes sense, to me anyway. max would work for the verbose mode, since that corresponds to all available fields. It's quite unclear what min is though; the fields included by terse are more of a judgment call (wasn't there someone asking for only the SQLSTATE?). off/full would have the same problem. That was my feeling. Also, I was concerned that non-native English speakers might not have heard of 'terse', while max/min or off/full would be more common. Non-native speakers would probably have to consult the man page to remember the correct spelling of VERBOSITY anyway :-( regards, tom lane ---(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] Error messages --- now that we've got it, do you like
Alvaro Herrera Munoz wrote: On Wed, Jul 30, 2003 at 10:33:55PM -0400, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom, you saw this suggestion, right? I didn't hear anyone else agreeing with it ... Well, if this needs a vote, I'm for something like maximum/default/minimum rather than the way it currently is. Saying verbosity verbose or verbosity terse doesn't feel right, while verbosity maximum makes sense, to me anyway. That was my feeling. Also, I was concerned that non-native English speakers might not have heard of 'terse', while max/min or off/full would be more common. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4 Pkgconfig
Does anyone know anything about pkgconfig? --- John Huttley wrote: On Thu, 2003-07-31 at 16:36, Bruce Momjian wrote: I have no idea what that is. This is the home page. If you have modern distribution with development tools, you likely already have it. http://www.freedesktop.org/software/pkgconfig/ The man page is very good. From your (the pgsql developers) point of view, it is not too hard. With make install, construct a postgresql.pc file and drop it in prefix/lib/pkgconfig directory. From the application developers POV, there is one less thing to worry about. Regards John -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 7: don't forget to increase your free space map settings
Re: [HACKERS] Error messages --- now that we've got it, do you like
On Wed, Jul 30, 2003 at 10:33:55PM -0400, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom, you saw this suggestion, right? I didn't hear anyone else agreeing with it ... Well, if this needs a vote, I'm for something like maximum/default/minimum rather than the way it currently is. Saying verbosity verbose or verbosity terse doesn't feel right, while verbosity maximum makes sense, to me anyway. -- Alvaro Herrera ([EMAIL PROTECTED]) Thou shalt study thy libraries and strive not to reinvent them without cause, that thy code may be short and readable and thy days pleasant and productive. (7th Commandment for C Programmers) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upgrading my BSDI box, again
On Wed, Jul 30, 2003 at 04:18:39PM -0400, Lamar Owen wrote: What Andrew is saying is that on some IDE drives it doesn't matter what the OS tells the drive to do. According to the Linux hdparm Right. In other words, you can't really trust IDE drives, until the manufacturers start guaranteeing that their drives will respond to the commands you send. I suspect that some manufacturers are better than others, but I haven't been able to find any reliable data about this. The failure to obey commands to turn off write caching is something I have both seen reported by others and experienced myself, so I am sure that it happens. But who does it (or doesn't do it), I've no idea. The case I saw was, I believe, a Maxtor drive, and it happened about 2 years ago, IIRC. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] patch queue
I thought so too, but I had to ask. --- Peter Eisentraut wrote: Bruce Momjian writes: I see all submitted patches as applied, except from Gavin's WHERE CURRENT OF patch, and I am asking for opinions on that one. I think it's too late for that one. -- Peter Eisentraut [EMAIL PROTECTED] ---(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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] followup on previous
Josh Berkus [EMAIL PROTECTED] writes: Putting on marketing hat: While branding is important, unlike other projects the shortened version of our name is still distinctive and unique ... Postgres is unlikely to be mistaken for anything else. Also, we should continue to use it reasonably frequently to help keep newbies from falling into the supposition that the shortened version is Postgre ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Error messages --- now that we've got it, do you like
Bruce Momjian wrote: That was my feeling. Also, I was concerned that non-native English speakers might not have heard of 'terse', while max/min or off/full would be more common. Possibly plenty of English speakers, too ;-) andrew ---(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] now about psql and one function
Why postgres should be using only for standard ways ? I need to protect pg how its possible . Every single informacion which user dont need to know he can not know . Each user is like enemy . :-) I worry more about this cache , i dont know how to reset it. Beca use i (in one transaction) make copy of table, drop it, create new version and restore rows, but i can not do it because relcache remember relid of this old table :( its any way to turn it off (for only replaceing moment) or clien cache list any idea ? (samole function is above) PS. Whato do you thing about \I in psql . Its will be like \i but befor starting read file will be BEGIN; and if everythink will be ok will be END; . ? I know that i can do it manualy , but why i should do this when i have soft as my help : On Wed, 30 Jul 2003, Bruce Momjian wrote: Why would someone not have the ability to read pg_user? The query is gone in 7.4 anyway. --- ivan wrote: in psql , file command.c : 1473 there is a query to check state for superuser, and this query is in begin/end transaction. When user dont have perm to read pg_user its fail but transation is never end, and ist make some confusion because user have to write END; or ROLLBACK; themself. I just removed BEGIN and END from this query. ok, and this function : create or replace func () returns INT as ' DECLARE cnt INT; BEGIN CREATE TEMP TABLE ble (i INT); SELECT INTO cnt count(*) FROM ble; DROP TABLE ble; RETURN cnt; END; ' LANGUAGE 'plpgsql'; and at first time everythink is ok, but in next time is error like this : pg_class_aclcheck : relation nr not found . (This function is only example , and i know that it doesnt sens) I think its by SysCache, how can i reset it ? or turn off ? or reload ? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend ---(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
[HACKERS] two buglets: createlang and pg_get_triggerdef
Hackers, Two buglets: The first one is in createlang, trying to create a language without enough permission: $ createlang -d alvherre plpgsql createlang: language installation failed: ERROR: c: permission denied What's the c it's complaning about? The second one is in pg_get_triggerdef(): alvherre= create table test (foo int); CREATE TABLE alvherre= create function foofun() returns trigger as 'select 1' language plpgsql; CREATE FUNCTION alvherre= create trigger my_little_trigger before update on test execute procedure foofun(); CREATE TRIGGER alvherre= \d test Table public.test Column | Type | Modifiers +-+--- foo| integer | Triggers: my_little^trigger BEFORE UPDATE ON test FOR EACH STATEMENT EXECUTE PROCEDURE foofun() Note that the 9th character has been changed to ^. I've seen the 9th character change in all triggers here. If I look at pg_trigger the name is fine: alvherre= select tgname from pg_trigger where tgname='my_little_trigger'; tgname --- my_little_trigger (1 row) This is not on latest CVS, but I haven't seem them reported nor fixed. -- Alvaro Herrera ([EMAIL PROTECTED]) El sentido de las cosas no viene de las cosas, sino de las inteligencias que las aplican a sus problemas diarios en busca del progreso. (Ernesto Hernández-Novich) ---(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] two buglets: createlang and pg_get_triggerdef
Alvaro Herrera Munoz [EMAIL PROTECTED] writes: $ createlang -d alvherre plpgsql createlang: language installation failed: ERROR: c: permission denied What's the c it's complaning about? The C procedural language, presumably. This message is not up to our new message standards I suppose ... it ought to mention what kind of object c is. The second one is in pg_get_triggerdef(): Triggers: my_little^trigger BEFORE UPDATE ON test FOR EACH STATEMENT EXECUTE PROCEDURE foofun() Bizarre. It looks fine here. What platform are you on? Anyone else see this? This is not on latest CVS, but I haven't seem them reported nor fixed. Please pull latest CVS and do a full rebuild (make distclean etc). If you still see it after that, I'll pursue further. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] php with postgres
Hello Bruce, Thursday, July 24, 2003, 11:57:39 PM, you wrote: BM Jan Wieck wrote: Marcus B?rger wrote: ATM i have a patch doing the following: Connect: If PQprotocolVersion() is available and = 3 PQparameterStatus() is available then i check the server version. Else i check the lib version (*). If the version to check is = 7.2 ido one of the following: - If one of PQprotocolVersion() and PQtransactionStatus() is unavailable or protocol version 3: BEGIN;COMMIT;RESET ALL; - If protocol version = 3 and transaction status == PQTRANS_IDLE: RESET ALL; - If protocol version = 3 and transaction status != PQTRANS_IDLE: COMMIT;RESET ALL; Shouldn't that be ROLLBACK; RESET ALL; and the other one BEGIN; ROLLBACK; RESET ALL; ? I don't want to have the possibly partial transaction from a crashed PHP script to be committed by default. At least it would be a significant difference between persistent and non-persistent connections, because we rollback if we loose the connection. BM Right, as I just emailed. I wonder if we made the mistake of BM recommending BEGIN;COMMIT; to the PHP folks a while back, or whether they BM just did it themselves. BM I remember telling them they couldn't just do ROLLBACK because that BM would fill the logs, but I am not sure how they got BEGIN;COMMIT; BM rather than BEGIN;ROLLBACK. It just shows we need better communication BM between the communities. Ok, i'd of course appreciate more eyes before my commit then (i need to become more familiar with the whole postgres source). I've put three files online: - the diff against current php haed http://marcus-boerger.de/php/ext/pgsql/pgsql-persistent-20030725.diff.txt - the complete new file http://marcus-boerger.de/php/ext/pgsql/pgsql.c - the parts relevant (request start/stop) http://marcus-boerger.de/php/ext/pgsql/pgsql-request-start-stop.c Best regards, Marcusmailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] php with postgres
Hello Bruce, Wednesday, July 23, 2003, 6:18:13 AM, you wrote: BM Marcus B?rger wrote: However it may be very usefull to terminate any open transaction before reusing a persisten connection. Typically this happens when the same script runs again. But anyway using transactions together with persistent conenctions in a multithreaded environment isn't the best thing you could do. So our options are 1) tell the users to do 'auto commit mode' 2) nested transactions 3) locking From my perspective 2) and 3) are bad ideas for the web environment. In other words i guess we should leave it as is with transaction rollback only when the client terminates (e.g. the webserver stops). BM I don't see why you wouldn't just do BEGIN;COMMIT;RESET ALL; when you BM pass the connection to a new client. Bruce you said RESET ALL is available since 7.2. I am currently checking for the lib version but it would be more correct to check something on the server. So the question what do i check? BM We usually use SELECT version(). ATM i have a patch doing the following: Connect: If PQprotocolVersion() is available and = 3 PQparameterStatus() is available then i check the server version. Else i check the lib version (*). If the version to check is = 7.2 ido one of the following: - If one of PQprotocolVersion() and PQtransactionStatus() is unavailable or protocol version 3: BEGIN;COMMIT;RESET ALL; - If protocol version = 3 and transaction status == PQTRANS_IDLE: RESET ALL; - If protocol version = 3 and transaction status != PQTRANS_IDLE: COMMIT;RESET ALL; Disconnect: - When PQprotocolVersion() And PQtransactionStatus() are available then i check whether status is PQTRANS_IDLE. If so i do: ROLLBACK; - If the functions are not available in the client libs i do: BEGIN;ROLLBACK; Does this sound the correct behavior? And would select split_part(version(), ' ', 2); be too much of a slowdown to do the version detection in the startup sequence completely correct? -- Best regards, Marcusmailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] php with postgres
Hello Bruce, Thursday, July 24, 2003, 11:05:21 PM, you wrote: BM Marcus B?rger wrote: BM I don't see why you wouldn't just do BEGIN;COMMIT;RESET ALL; when you BM pass the connection to a new client. Bruce you said RESET ALL is available since 7.2. I am currently checking for the lib version but it would be more correct to check something on the server. So the question what do i check? BM We usually use SELECT version(). ATM i have a patch doing the following: Connect: If PQprotocolVersion() is available and = 3 PQparameterStatus() is available then i check the server version. Else i check the lib version (*). If the version to check is = 7.2 ido one of the following: - If one of PQprotocolVersion() and PQtransactionStatus() is unavailable or protocol version 3: BEGIN;COMMIT;RESET ALL; BM I believe this should be BEGIN;ROLLBACK;RESET ALL; because our default BM for a client that disconnects is to abort the transaction. - If protocol version = 3 and transaction status == PQTRANS_IDLE: RESET ALL; - If protocol version = 3 and transaction status != PQTRANS_IDLE: COMMIT;RESET ALL; BM Should be ROLLBACK;RESET ALL;. Because of above mentioned default? The problem i have is that now we do the COMMIT - so this behavior change can only go into php 5 with a big notice. BM Nice version test code, sounds good. Disconnect: - When PQprotocolVersion() And PQtransactionStatus() are available then i check whether status is PQTRANS_IDLE. If so i do: ROLLBACK; - If the functions are not available in the client libs i do: BEGIN;ROLLBACK; Does this sound the correct behavior? BM I am confused why you are doing stuff on connect and disconnect. Seems BM it should all be done on disconnect so you don't leave open transactions BM in the pooled connections --- it will keep locks around too long and BM reduce the usefulness of vacuum. If we clean up everything on BM disconnect, aren't we sure that the connection status will be fine? And would select split_part(version(), ' ', 2); be too much of a slowdown to do the version detection in the startup sequence completely correct? BM Seems fine. Since you are doing pooled connections, you shouldn't be BM doing this too often anyway. I believe the point was RESET ALL;. But maybe i can move all but that into shutdown. I mean for me that sounds good. Only someone must enlighten me if there could be a problem with that reset. -- Best regards, Marcusmailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] best way to determine start of new statement within
The semantics of this conceptually is not too bad. The implementation could be tricky. For any given DML or sub-DML (select, eg) the scope should be for that DML. The DML is the parent of the function. The DML is the statement context and the function is the function context. statement -- function | + -- statement -- function | + -- statement statement -- function1, function2 | | | +-- statement - function3 | | | +-- statement | | | + -- statement -- function4 | + -- statement For example: select myfunc() from foo; -- 1 statement select myfunc() from (select myfunc2() from foo); -- subselect ( select ): both actually have the same memory duration, but have different statement contexts and different function contexts. -- the scope of each matches its select select myfunc() from foo; --where myfunc invokes select myfunc2() from bar; The scope of myfunc is the parent select. The scope of myfunc2 resets at each iteration of myfunc(), but is available for each iteration of itself. Note that these things can nest very deeply. select myfunc() from foo where myfunc3() = 't'; -- both myfunc() and myfunc3() have the same statement parent. -- if myfunc3() invoked select * from myfunc4() then each iteration of myfunc3() resets the statement context of that select. The new statement corresponds to a single invocation of one DML. Memory should last through the whole invocation loop. Am I making sense here? Where does the function context info memory get available for allocation and where does it get deallocated? (It does get deallocated via garbage collection, right?) I think the scope of this is correct. We implemented this at informix and got a lot of stuff wrong. Memory pool hell, but we had to deal with a multi-threaded server. Illustra did it right so I think postgres already has the handles to the hook the memory into the right scope. Do you want me to try to write this up into more formal definitions? elein On Fri, Jul 25, 2003 at 08:31:14AM -0700, Joe Conway wrote: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: Specifically I'd like to reset a variable within my PL/R interpreter each time a new SQL statement begins. Define new SQL statement. In particular, what of a PL function executing multiple SQL statements inside an outer SQL statement that invoked the function? Unless you've got a clear idea of the semantics you want, it's not going to be very profitable to discuss implementations ... Well, I guess in a situation like this: a) SELECT * FROM myfunc1()... where myfunc1() executes via spi b) SELECT * FROM myfunc2()... I'd be interested in being able to detect when outer statement (a) starts, as well as the fact that it is at nesting level 0. And similarly it would be nice to be able to detect when statement (b) starts along with the fact that it is at nesting level 1. But for the moment, I'd be happy with just the former. Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] SELECT FOR UPDATE question
When a SELECT FOR UPDATE query is executed, are the row level locks on a table acquired in any specific order such as to enhance deadlock prevention? ( primary key, oid, etc. ) ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] ACCESSING POST GRESQL DATABASE THRU MFCOBOL
HI I am running MFcobol on a linux machine which is having Postgresql. can I access pgsql database thru mfcobol. If it is possible where can I get odbc drivers and what is the procedure help me chakravarthi Send free SMS using the Yahoo! Messenger. Go to http://in.mobile.yahoo.com/new/pc/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] dblink_ora - a first shot on Oracle ...
There seems to be some disagreement on whether the Oracle lib checks should be in configure for a /contrib module, and I don't know how far Hans is. I will say we are probably looking at 7/28 for beta. I am afraid I won't make it until 7.4beta1. The problem is that I have not managed to have more than just one connection to oracle at the same time. For some Oracle reason I don't know what went wrong. I will have a closer look at that. However, named connections don't make too much sense with just one connection ;). I have troubles testing it as long as the connect fails ... There is some other Oracle specific stuff which seems to be more painful than I have expected. Have I already told you that I hate Oracle? Let's wait for the next major release and prepare something really useful. I am still not quite satisfied with what we have at the moment. Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] best way to determine start of new statement within a function? (resend)
I was starting to wonder if my message got there. Tom had asked for a clear definition of what is a statement hence the wide description. If I wrote this up more formally where would I put it so we could talk about it when the various issues come up? Maybe a friend-of-the-court unapproved functional spec in the dev docs? Noting, of course, that this is functional not implementation specifications. I'm surprised these issues did not come up with who ever is working on nested transactions since that is in the same realm. elein On Mon, Jul 28, 2003 at 09:58:42AM -0700, Joe Conway wrote: elein wrote: Do you want me to try to write this up into more formal definitions? I think it would be a useful starting point for future discussions, but it goes way beyond what I was looking for at the moment. Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] two buglets: createlang and pg_get_triggerdef
I said: Alvaro Herrera Munoz [EMAIL PROTECTED] writes: $ createlang -d alvherre plpgsql createlang: language installation failed: ERROR: c: permission denied What's the c it's complaning about? The C procedural language, presumably. This message is not up to our new message standards I suppose ... it ought to mention what kind of object c is. Okay, now it says $ createlang plpgsql test createlang: language installation failed: ERROR: permission denied for language c $ Let me know about the pg_get_triggerdef() thing ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] two buglets: createlang and pg_get_triggerdef
Triggers: my_little^trigger BEFORE UPDATE ON test FOR EACH STATEMENT EXECUTE PROCEDURE foofun() Bizarre. It looks fine here. What platform are you on? Anyone else see this? I actually had this while I was developing the feature. I had thought I had fixed it. It's basically total weirdness in the behaviour of appendStringInfo function IIRC. Basically, I _think_ it was caused by having two %s's in this: appendStringInfo(buf, CREATE %sTRIGGER %s , trigrec-tgisconstraint ? CONSTRAINT : , quote_identifier(tgname)); I managed to get rid of the bug on my development machine, but it's obviously cropped up again :( Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] two buglets: createlang and pg_get_triggerdef
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Bizarre. It looks fine here. What platform are you on? Anyone else see this? I actually had this while I was developing the feature. And what platform are *you* on? It seems a really hard-to-believe bug... regards, tom lane ---(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] contrib compilation probs
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I just tried compiling all contribs on freebsd/alpha, and I saw these issues: Fixed, I think. Give it another try. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] two buglets: createlang and pg_get_triggerdef
I actually had this while I was developing the feature. And what platform are *you* on? It seems a really hard-to-believe bug... FreeBSD/i386 I developed it on. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pg_dump ordering
Hi, Can someone tell me know what has to be done to pg_dump to make it dump things in the right order? Where should I start. The most important thing is getting types dumped before tables that use the type. Chris ---(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] name of configure threading option
Actually, I never made the change until now. I thought I had already did it. Sorry. --- pgman wrote: Change made. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Should the new threading configure option be called: --enable-thread-safeness or --enable-thread-safety safety is a common word, safeness isn't. (The OED has entries for both, but the entry for safety is about 10x longer; a smaller dictionary I consulted doesn't list safeness at all.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [HACKERS] pg_dump ordering
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Can someone tell me know what has to be done to pg_dump to make it dump things in the right order? Where should I start. The most important thing is getting types dumped before tables that use the type. What I'd like to see it do is grab the dependency data in pg_depend and do a topological sort using that. This leaves some issues still to be resolved ... like what to do when dumping a pre-7.3 database ... but I think it's the core of a maintainable solution. IIRC, you can find some further discussion in the archives. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib compilation probs
Fixed, I think. Give it another try. I didn't see any probs with the ones you fixed, but I see this: gmake[1]: Entering directory `/home/chriskl/pgsql-temp/contrib/tsearch2' sed 's,DATA_PATH,/home/chriskl/local/share/postgresql,g' tsearch.sql._in tsearch2.sql.in sed 's,MODULE_PATHNAME,$libdir/tsearch2,g' tsearch2.sql.in tsearch2.sql cp untsearch.sql.in untsearch2.sql gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o dict_ex.o dict_ex.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o dict.o dict.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o snmap.o snmap.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o stopword.o stopword.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o common.o common.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o prs_dcfg.o prs_dcfg.c -MMD prs_dcfg.c: In function `parse_cfgdict': prs_dcfg.c:65: warning: int format, different type arg (arg 2) prs_dcfg.c:78: warning: int format, different type arg (arg 2) prs_dcfg.c:87: warning: int format, different type arg (arg 2) prs_dcfg.c:118: warning: int format, different type arg (arg 2) prs_dcfg.c:128: warning: int format, different type arg (arg 3) gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o snowball/english_stem.o snowball/english_stem.c -MMD cp: snowball/english_stem.d: No such file or directory gmake[1]: *** [snowball/english_stem.o] Error 1 gmake[1]: *** Deleting file `snowball/english_stem.o' gmake[1]: Leaving directory `/home/chriskl/pgsql-temp/contrib/tsearch2' gmake: *** [all] Error 2 Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump ordering
What I'd like to see it do is grab the dependency data in pg_depend and do a topological sort using that. At the end though, we'd need to dump stuff not caught be the topsort, for cases where pg_depend has been messed with. This leaves some issues still to be resolved ... like what to do when dumping a pre-7.3 database ... but I think it's the core of a maintainable solution. Problem is you'd need to sort tables by the youngest column in the table, which is a pain. Because the main problem is this: CREATE TABLE... CREATE TYPE newtype ALTER TABLE ADD COLUMN newtype That always breaks... CHris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump ordering
Christopher Kings-Lynne [EMAIL PROTECTED] writes: This leaves some issues still to be resolved ... like what to do when dumping a pre-7.3 database ... but I think it's the core of a maintainable solution. Problem is you'd need to sort tables by the youngest column in the table, which is a pain. Because the main problem is this: CREATE TABLE... CREATE TYPE newtype ALTER TABLE ADD COLUMN newtype That always breaks... And it will continue to break, for dumps from pre-7.3 databases. I think it's a mistake to spend much time on trying to solve that problem; it'll just distract you from solving the presently-useful case. I don't want to see the behavior get a lot worse for old databases, mind you; I'm just saying it doesn't have to get magically better. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] python interface
I still see the python interface in src/interfaces. Marc, I thought you moved that to gborg? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib compilation probs
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I didn't see any probs with the ones you fixed, but I see this: prs_dcfg.c: In function `parse_cfgdict': prs_dcfg.c:65: warning: int format, different type arg (arg 2) prs_dcfg.c:78: warning: int format, different type arg (arg 2) prs_dcfg.c:87: warning: int format, different type arg (arg 2) prs_dcfg.c:118: warning: int format, different type arg (arg 2) prs_dcfg.c:128: warning: int format, different type arg (arg 3) Fixed those. gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o snowball/english_stem.o snowball/english_stem.c -MMD cp: snowball/english_stem.d: No such file or directory gmake[1]: *** [snowball/english_stem.o] Error 1 No idea about this; it doesn't happen here. Anyone? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib compilation probs
gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o snowball/english_stem.o snowball/english_stem.c -MMD cp: snowball/english_stem.d: No such file or directory gmake[1]: *** [snowball/english_stem.o] Error 1 Hmmm...looks like on my system english_stem.d is created in the tsearch2 dir, NOT in the snowball subdir. Chris ---(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] python interface
OK, any idea why I see it in my CVS? It was recently completely checked out. --- Marc G. Fournier wrote: actually, the whole python interface was moved over to http://www.pygresql.org ... On Thu, 31 Jul 2003, Bruce Momjian wrote: I still see the python interface in src/interfaces. Marc, I thought you moved that to gborg? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 7: don't forget to increase your free space map settings
Re: [HACKERS] contrib compilation probs
Christopher Kings-Lynne [EMAIL PROTECTED] writes: gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI -I. -I. -I./snowball -I./ispell -I./wordparser -I../../src/include -c -o snowball/english_stem.o snowball/english_stem.c -MMD cp: snowball/english_stem.d: No such file or directory gmake[1]: *** [snowball/english_stem.o] Error 1 Hmmm...looks like on my system english_stem.d is created in the tsearch2 dir, NOT in the snowball subdir. I see no english_stem.d at all. I speculate that this is a temp file created during the gcc run, and that your gcc driver is brain-damaged about compiling files that aren't in the current directory. 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])
Re: [HACKERS] python interface
actually, the whole python interface was moved over to http://www.pygresql.org ... On Thu, 31 Jul 2003, Bruce Momjian wrote: I still see the python interface in src/interfaces. Marc, I thought you moved that to gborg? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] python interface
I still see the python interface in src/interfaces. Marc, I thought you moved that to gborg? I still see it too ... and so does cvsweb: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/interfaces/python/ regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib compilation probs
Hmmm...looks like on my system english_stem.d is created in the tsearch2 dir, NOT in the snowball subdir. I see no english_stem.d at all. I speculate that this is a temp file created during the gcc run, and that your gcc driver is brain-damaged about compiling files that aren't in the current directory. It's just normal GNU CC... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] python removed ...
I haven't removed teh stuff out of configure.in, since there is still the plpython interface ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] python interface
On Fri, 1 Aug 2003, Bruce Momjian wrote: OK, any idea why I see it in my CVS? It was recently completely checked out. Somehow, when we moved it to gborg way back, the 'cvs remove' wasn't done on the mail repository ... there ... cvs remove'd now, so its still part of v7.3.x, but no longer part of v7.4 ... --- Marc G. Fournier wrote: actually, the whole python interface was moved over to http://www.pygresql.org ... On Thu, 31 Jul 2003, Bruce Momjian wrote: I still see the python interface in src/interfaces. Marc, I thought you moved that to gborg? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] two buglets: createlang and pg_get_triggerdef
I actually had this while I was developing the feature. And what platform are *you* on? It seems a really hard-to-believe bug... This will actually be a must-fix for 7.4, as pg_dump uses it now to dump triggers... Chris ---(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] python interface
Marc G. Fournier [EMAIL PROTECTED] writes: Somehow, when we moved it to gborg way back, the 'cvs remove' wasn't done on the mail repository ... there ... cvs remove'd now, so its still part of v7.3.x, but no longer part of v7.4 ... According to the CVS logs, there were several patches applied to src/interfaces/python in the last few months. Somebody should make sure that all of those got propagated to the gborg project (or at least considered and rejected...) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Problem generating release listing
Because 7.4 had more parallel CVS branch changes than previous releases, I decided to pull cvs logs based only on the CVS HEAD, so I didn't get commits to branches. I used this command: cvs log -d'2002-11-04 00:00:00 GMT' -rHEAD . I then ran it through tools/pgcvslog and started working on the release notes. About 75% through the list, I found that a Rendezvous commit was missing. Looking at the cvs output, I saw that 'cvs log -rHEAD' pulls only the HEAD (most recent) log commit for each file, rather than taking the HEAD CVS branch. I am going to have to start again from scratch tomorrow. Looking at the rlog manual page, I now see the proper command is: cvs log -d'2002-11-04 00:00:00 GMT' -b . /bjm/log I have documented this in the pgcvslog script. This confusion is caused because cvs is built on top of rcs, which has a different way of doing things than CVS. Once I am done, I have to run pgindent, and Tom wants to remove recode. We just found that python shouldn't be in CVS. Let's look to Monday for beta. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Proof-of-concept for initdb-time shared_buffers selection
Manfred Koizar [EMAIL PROTECTED] writes: On Fri, 04 Jul 2003 15:29:37 -0400, Tom Lane [EMAIL PROTECTED] wrote: The attached patch shows how initdb can dynamically determine reasonable shared_buffers and max_connections settings that will work on the current machine. Can't this be done on postmaster startup? Why would that be a good idea? Seems to me it just offers a fresh opportunity to do the wrong thing at every startup. We'v had troubles enough with problems that appear only when the postmaster is started by hand rather than by boot script, or vice versa; this would just add another unknown to the equation. This would make the lives easier for the folks trying to come up with default .conf files, e.g. min_shared_buffers = 64 max_shared_buffers = 2000 could cover a fairly large range of low level to mid level machines. Not unless their notion of a default .conf file includes a preinstalled $PGDATA directory. Under ordinary circumstances, initdb will get run locally on the target machine, and should come up with a valid value. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] RPMs for 7.3.4, and a change.
There was an article about a LARGE storage network of linux boxes I saw recently. Absolutely stable. Wish I could tell you where it was, but I can't. Lamar Owen wrote: Good evening. RPMs for PostgreSQL 7.3.4, built on three architectures, are in the midst of uploading to ftp.postgresql.org, in /pub/binary/v7.3.4/RPMS. As usual, inside that directory is the directory SRPMS, which contains the source RPM, as well as the three binary RPM directories I am uploading. One minor thing; a source RPM suitable for rebuilding on Red Hat 7.3 is available in the aurora-1.0 subdirectory. Aurora 1.0 is basically Red Hat 7.3 for SPARC; there are also SPARC binaries there. Other than the version change, this RPMset includes the correct JDBC jars. There are a couple of fixes that have been e-mailed to me that are not in this update; I will address those as soon as I can. In other news, I have changed jobs. Previously, I worked full-time as a broadcast engineer/IT person for WGCR Radio. I still work part-time for them, amongst other radio stations, but my full-time position is now as Director of Information Technology for Pisgah Astronomical Research Institute (PARI), a radio/optical astronomical observatory located in Western North Carolina. You can find out more about PARI at our website, www.pari.edu. PARI is already using PostgreSQL for several applications, and soon will be looking at PostgreSQL for a large data warehousing application. And, in this case, I do mean large. I will be indexing and storing over three million astronomical photographic plates (if plans come together!), where each plate will scan in at roughly 650-750MB in size (uncompressed) (and this is 8-level grayscale scanning). Mass storage will be critical of this priceless data store, and PostgreSQL may very well fit the bill. I'm still in the planning phases, and we are still trying to secure funding for this project. But I am relatively confident that PostgreSQL will rise to the occassion. Some of the plates in question are over 100 years old. New challenges, new opportunities. But still the same PostgreSQL. ---(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] [GENERAL] concurrent writes
On Tue, 2003-07-29 at 13:02, Shridhar Daithankar wrote: On 29 Jul 2003 at 12:48, Andreas Jung wrote: On Tue, 2003-07-29 at 12:42, Shridhar Daithankar wrote: On 29 Jul 2003 at 12:33, Andreas Jung wrote: we are running Postgres 7.3.3 successfully on our portal sites under Solaris. For a new project we have the requirement that N processes need to write update/insert within the same time and within the same transaction data in one table. What does it mean by same transaction data? should read update/insert within the same time and within the same transaction in one table So you want to update same table more than once in a single transaction? That should work.. More detailed: every process opens its own connection, starts a transaction, updates *different* rows and then commits. According to our postgres adminstrator, Postgres seems to behave differently on Linux and Solaris. Any ideas on that? How it is different? It should be same, right? Our experience was that the complete table has been locked (Solaris) but row-level locking was working with Linux. Whoa!! That's something. How did you conclude it is locked. If you can produce some reproducible test case, this would be a big showstopper bug.. This problem appeard in 7.3.2 but it seems to have been fixed in 7.3.3. Our administrator complained that there has not been a notice in the CHANGELOG...so I am hestitating about choosing Postgres vs. Oracle :-) -aj ---(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] [GENERAL] concurrent writes
On Tue, 2003-07-29 at 13:16, Shridhar Daithankar wrote: On 29 Jul 2003 at 13:07, Andreas Jung wrote: On Tue, 2003-07-29 at 13:02, Shridhar Daithankar wrote: On 29 Jul 2003 at 12:48, Andreas Jung wrote: Our experience was that the complete table has been locked (Solaris) but row-level locking was working with Linux. Whoa!! That's something. How did you conclude it is locked. If you can produce some reproducible test case, this would be a big showstopper bug.. This problem appeard in 7.3.2 but it seems to have been fixed in 7.3.3. Our administrator complained that there has not been a notice in the CHANGELOG...so I am hestitating about choosing Postgres vs. Oracle :-) Even with 7.3.2, do you have a independently reproducible test case? It should help hackers to look into it. I need to ask our postgres god and let you know. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
