Re: [HACKERS] Upgrading my BSDI box, again
On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote: [ CC to Kurt and Steven on bsdi list.] Guys, I just replied to this email on the BSDi email list. The issue is that someone found that some(most?) IDE drives have write cache enabled, though the drives do not preserve the write cache data on power failure. I am surprised we have not heard of this failure before because I know most vendors who ship PostgreSQL test our crash recovery thoroughly. Are they testing only using SCSI drives? Below you will read that my Seagate SCSI drive has write cache disabled, but another guy has a Seagate IDE drive that has it enabled, though it loses data on power failure. Scarey! Does anyone have any more detailed information on this? Not really, just that I had data corruption on SCSI disks which had write cache enabled and tagged queueing. Disabling write cache has allowed them to function flawlessly since. The moral seems to be: write cache gives pretty performance figures, but you really want it swiched off. Cheers, Patrick ---(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] Feature request -- Log Database Name
On Mon, 28 Jul 2003, Tom Lane wrote: Date: Mon, 28 Jul 2003 21:39:23 -0400 From: Tom Lane [EMAIL PROTECTED] To: Robert Treat [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Larry Rosenman [EMAIL PROTECTED], Josh Berkus [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: [HACKERS] Feature request -- Log Database Name Robert Treat [EMAIL PROTECTED] writes: I think better would be a GUC log_to_table which wrote all standard out/err to a pg_log table. of course, I doubt you could make this foolproof (how to log startup errors in this table?) but it could be a start. How would a failed transaction make any entries in such a table? How would you handle maintenance operations on the table that require exclusive lock? (vacuum full, reindex, etc) It seems possible that you could make this work if you piped stderr to a buffering process that was itself a database client, and issued INSERTs to put the rows into the table, and could buffer pending data whenever someone else had the table locked (eg for vacuum). I'd not care to try to get backends to do it locally. regards, tom lane Not quite, my goal is to have a log per database, the stderr dosn't contain enough information to split it. As an ISP, I would like that each customer having one or more databases being able to see any error on their database. I imagine have a log file per database would be toot complicated... -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] using adbin, conbin, etc.
Rod Taylor [EMAIL PROTECTED] writes: On Tue, 2003-07-29 at 21:45, Christopher Kings-Lynne wrote: I hear that we're supposed to use the 'bin' versions of the 'src' columns where possible. I would like then to use them in phpPgAdmin for displaying defaults and stuff. Is there some way to use them from SQL? Cos it all looks like garbage to me :) Use the various pg_get_...() functions wherever you can. And if you can't find one that does what you want, ask for it. The last thing we want is client-side code digging into those internal representations --- we change 'em frequently. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] bug in current_timestamp(1)
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Going from precision 3 down to 0 - note the bug in (1). It always displays a trailing zero. It's not a bug, it's a feature, or at least Tom Lockhart once thought so. See TrimTrailingZeros() in datetime.c: /* chop off trailing zeros... but leave at least 2 fractional digits */ I don't recall the history behind that choice, and I'm disinclined to mess with it without knowing why it was set up to do that. I have a feeling it might have something to do with compatibility with some non-Postgres code. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Feature request -- Log Database Name
There seem to be 2 orthogonal issues here - in effect how to log and where to log. I had a brief look and providing an option to log the dbname where appropriate seems to be quite easy - unless someone else is already doing it I will look at it on the weekend. Assuming that were done you could split the log based on dbname. For the reasons Tom gives, logging to a table looks much harder and possibly undesirable - I would normally want my log table(s) in a different database, possibly even on a different machine, from my production transactional database. However, an ISP might want to provide the logs for each client in their designated db. It therefore seems to me far more sensible to do load logs into tables out of band as Tom suggests, possibly with some helper tools in contrib to parse the logs, or even to load them in more or less real time (many tools exist to do this sort of thing for web logs, so it is hardly rocket science - classic case for a perl script ;-). cheers andrew [EMAIL PROTECTED] wrote: On Mon, 28 Jul 2003, Tom Lane wrote: Date: Mon, 28 Jul 2003 21:39:23 -0400 From: Tom Lane [EMAIL PROTECTED] To: Robert Treat [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Larry Rosenman [EMAIL PROTECTED], Josh Berkus [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: [HACKERS] Feature request -- Log Database Name Robert Treat [EMAIL PROTECTED] writes: I think better would be a GUC log_to_table which wrote all standard out/err to a pg_log table. of course, I doubt you could make this foolproof (how to log startup errors in this table?) but it could be a start. How would a failed transaction make any entries in such a table? How would you handle maintenance operations on the table that require exclusive lock? (vacuum full, reindex, etc) It seems possible that you could make this work if you piped stderr to a buffering process that was itself a database client, and issued INSERTs to put the rows into the table, and could buffer pending data whenever someone else had the table locked (eg for vacuum). I'd not care to try to get backends to do it locally. regards, tom lane Not quite, my goal is to have a log per database, the stderr dosn't contain enough information to split it. As an ISP, I would like that each customer having one or more databases being able to see any error on their database. I imagine have a log file per database would be toot complicated... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] concurrent writes
On Tue, Jul 29, 2003 at 01:07:57PM +0200, Andreas Jung wrote: 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 :-) I think your administrator is talking out of his hat. We switch back and forth between Linux and Solaris all the time here, and PostgreSQL works the same all the time. 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] psql no longer handles fatal/panic errors well
The following test cases were created by modifying int4div and int2div to produce FATAL and PANIC, respectively, instead of plain ERROR for division-by-zero. Using an older psql, all is well: template1=# select 2/0; FATAL: division by zero server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Succeeded. template1=# select 1::int2/0::int2; PANIC: division by zero server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !# Using CVS-tip psql, things are weird: template1=# select 2/0; The connection to the server was lost. Attempting reset: Succeeded. FATAL: division by zero server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. template1=# select 1::int2/0::int2; The connection to the server was lost. Attempting reset: Failed. connection pointer is NULL ! It seems odd that the FATAL error is reported after, rather than before, the reconnection attempt; and it's really not acceptable to lose the PANIC message entirely. I checked that the server does still fflush the message before dying, so the problem is on the client side. It's possible that my recent libpq hacks have something to do with it, but I don't think libpq is at fault for the connection retry occuring before the message is printed. Any idea what was changed? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] psql no longer handles fatal/panic errors well
I said: It seems odd that the FATAL error is reported after, rather than before, the reconnection attempt; and it's really not acceptable to lose the PANIC message entirely. Also, both classes of messages seem to be dropped if psql is not running interactively (probably since it exits without trying to reconnect). If I run the regression tests against my hacked backend, the errors test fails with: --- 241,244 -- Check that division-by-zero is properly caught. -- select 1/0; ! connection to server was lost == regards, tom lane ---(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 12:38:54AM -0400, Bruce Momjian wrote: Guys, I just replied to this email on the BSDi email list. The issue is that someone found that some(most?) IDE drives have write cache enabled, though the drives do not preserve the write cache data on power failure. It's yet worse than this. Some IDE drives will respond to the command to turn off write cacheing, but they _don't actually turn it off_. In other words, you think you've done the right thing, and you haven't anyway. 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] pkglibdir versus libdir?
Peter, I'm a little confused about the difference between the libdir and pkglibdir settings created by configure. What's supposed to go where? 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. (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. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature request -- Log Database Name
One idea would be to output log information as INSERT statements, so we could log connection/dbname/username to one table, and per-session information to another table, and server-level info in a third table. If you want to analyze the logs, you could load the data into a database via inserts, and even do joins and analyze the output using SQL! This would solve the problem of failed transactions exporting information, would not be extra overhead for every log message, and would handle the problem of analyzing the log tables while the system was running and continuing to emit more log output. --- Andrew Dunstan wrote: There seem to be 2 orthogonal issues here - in effect how to log and where to log. I had a brief look and providing an option to log the dbname where appropriate seems to be quite easy - unless someone else is already doing it I will look at it on the weekend. Assuming that were done you could split the log based on dbname. For the reasons Tom gives, logging to a table looks much harder and possibly undesirable - I would normally want my log table(s) in a different database, possibly even on a different machine, from my production transactional database. However, an ISP might want to provide the logs for each client in their designated db. It therefore seems to me far more sensible to do load logs into tables out of band as Tom suggests, possibly with some helper tools in contrib to parse the logs, or even to load them in more or less real time (many tools exist to do this sort of thing for web logs, so it is hardly rocket science - classic case for a perl script ;-). cheers andrew [EMAIL PROTECTED] wrote: On Mon, 28 Jul 2003, Tom Lane wrote: Date: Mon, 28 Jul 2003 21:39:23 -0400 From: Tom Lane [EMAIL PROTECTED] To: Robert Treat [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Larry Rosenman [EMAIL PROTECTED], Josh Berkus [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: [HACKERS] Feature request -- Log Database Name Robert Treat [EMAIL PROTECTED] writes: I think better would be a GUC log_to_table which wrote all standard out/err to a pg_log table. of course, I doubt you could make this foolproof (how to log startup errors in this table?) but it could be a start. How would a failed transaction make any entries in such a table? How would you handle maintenance operations on the table that require exclusive lock? (vacuum full, reindex, etc) It seems possible that you could make this work if you piped stderr to a buffering process that was itself a database client, and issued INSERTs to put the rows into the table, and could buffer pending data whenever someone else had the table locked (eg for vacuum). I'd not care to try to get backends to do it locally. regards, tom lane Not quite, my goal is to have a log per database, the stderr dosn't contain enough information to split it. As an ISP, I would like that each customer having one or more databases being able to see any error on their database. I imagine have a log file per database would be toot complicated... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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] Feature request -- Log Database Name
That assumes we know what the shape of the log tables will be, but this isn't quite clear to me - I can imagine it being different for different needs. Having an external program to parse the logs into INSERT statements would not be hard, anyway, so I'm not sure that this would buy us much. I'll think about it more. In any case, it should be done in stages, I think, with the first stage simply being what we do now with the optional dbname field added. cheers andrew Bruce Momjian wrote: One idea would be to output log information as INSERT statements, so we could log connection/dbname/username to one table, and per-session information to another table, and server-level info in a third table. If you want to analyze the logs, you could load the data into a database via inserts, and even do joins and analyze the output using SQL! This would solve the problem of failed transactions exporting information, would not be extra overhead for every log message, and would handle the problem of analyzing the log tables while the system was running and continuing to emit more log output. --- Andrew Dunstan wrote: There seem to be 2 orthogonal issues here - in effect how to log and where to log. I had a brief look and providing an option to log the dbname where appropriate seems to be quite easy - unless someone else is already doing it I will look at it on the weekend. Assuming that were done you could split the log based on dbname. For the reasons Tom gives, logging to a table looks much harder and possibly undesirable - I would normally want my log table(s) in a different database, possibly even on a different machine, from my production transactional database. However, an ISP might want to provide the logs for each client in their designated db. It therefore seems to me far more sensible to do load logs into tables out of band as Tom suggests, possibly with some helper tools in contrib to parse the logs, or even to load them in more or less real time (many tools exist to do this sort of thing for web logs, so it is hardly rocket science - classic case for a perl script ;-). cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Feature request -- Log Database Name
Guys: That assumes we know what the shape of the log tables will be, but this isn't quite clear to me - I can imagine it being different for different needs. Having an external program to parse the logs into INSERT statements would not be hard, anyway, so I'm not sure that this would buy us much. I'll think about it more. In any case, it should be done in My simple suggestion would be to have the option of outputting log entries as tab-delimited data. Then the admin could very easily write a script to load it into a table or tables; we could even supply a sample perl script on techdocs or somewhere. -- -Josh Berkus Aglio Database Solutions San Francisco ---(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] Feature request -- Log Database Name
I was thinking of outputing CREATE TABLE at the start of the log file. I see what you mean that the schemas could be different, so we would have to output the relevant fields all the time, like timestamp and username, but because the username would be joined, you would only output it on connection start, and not for each output line. --- Andrew Dunstan wrote: That assumes we know what the shape of the log tables will be, but this isn't quite clear to me - I can imagine it being different for different needs. Having an external program to parse the logs into INSERT statements would not be hard, anyway, so I'm not sure that this would buy us much. I'll think about it more. In any case, it should be done in stages, I think, with the first stage simply being what we do now with the optional dbname field added. cheers andrew Bruce Momjian wrote: One idea would be to output log information as INSERT statements, so we could log connection/dbname/username to one table, and per-session information to another table, and server-level info in a third table. If you want to analyze the logs, you could load the data into a database via inserts, and even do joins and analyze the output using SQL! This would solve the problem of failed transactions exporting information, would not be extra overhead for every log message, and would handle the problem of analyzing the log tables while the system was running and continuing to emit more log output. --- Andrew Dunstan wrote: There seem to be 2 orthogonal issues here - in effect how to log and where to log. I had a brief look and providing an option to log the dbname where appropriate seems to be quite easy - unless someone else is already doing it I will look at it on the weekend. Assuming that were done you could split the log based on dbname. For the reasons Tom gives, logging to a table looks much harder and possibly undesirable - I would normally want my log table(s) in a different database, possibly even on a different machine, from my production transactional database. However, an ISP might want to provide the logs for each client in their designated db. It therefore seems to me far more sensible to do load logs into tables out of band as Tom suggests, possibly with some helper tools in contrib to parse the logs, or even to load them in more or less real time (many tools exist to do this sort of thing for web logs, so it is hardly rocket science - classic case for a perl script ;-). cheers andrew ---(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 ---(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] Feature request -- Log Database Name
Josh Berkus wrote: Guys: That assumes we know what the shape of the log tables will be, but this isn't quite clear to me - I can imagine it being different for different needs. Having an external program to parse the logs into INSERT statements would not be hard, anyway, so I'm not sure that this would buy us much. I'll think about it more. In any case, it should be done in My simple suggestion would be to have the option of outputting log entries as tab-delimited data. Then the admin could very easily write a script to load it into a table or tables; we could even supply a sample perl script on techdocs or somewhere. The problem with that is needing to output to multiple tables --- session-level, query-level, and server-level tables. -- 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 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] Upgrading my BSDI box, again
Andrew Sullivan wrote: On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote: Guys, I just replied to this email on the BSDi email list. The issue is that someone found that some(most?) IDE drives have write cache enabled, though the drives do not preserve the write cache data on power failure. It's yet worse than this. Some IDE drives will respond to the command to turn off write cacheing, but they _don't actually turn it off_. In other words, you think you've done the right thing, and you haven't anyway. Is there an interface to control this with IDE drives? I know there is scsicmd for SCSI, but I didn't think IDE had any similar interface to control the drive. -- 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] Upgrading my BSDI box, again
Bruce Momjian wrote: Andrew Sullivan wrote: On Wed, Jul 30, 2003 at 12:38:54AM -0400, Bruce Momjian wrote: Guys, I just replied to this email on the BSDi email list. The issue is that someone found that some(most?) IDE drives have write cache enabled, though the drives do not preserve the write cache data on power failure. It's yet worse than this. Some IDE drives will respond to the command to turn off write cacheing, but they _don't actually turn it off_. In other words, you think you've done the right thing, and you haven't anyway. Is there an interface to control this with IDE drives? I know there is scsicmd for SCSI, but I didn't think IDE had any similar interface to control the drive. On Linux, there's something called hdparm. There could be something analogous, but that misses Andrew's point. The point is that even if you have a utility that can modify caching parameters, this is increasingly unlikely to do you any good, because the hard drive may be lying to you. The drive happily reports back Yup! I shut the cache off for you! But then proceeds to cache writes anyways, because it was lying when it said it shut it off. What OS you're using is irrelevant if the hardware is lying to you. -- (format nil [EMAIL PROTECTED] cbbrowne libertyrms.info) http://dev6.int.libertyrms.com/ Christopher Browne (416) 646 3304 x124 (land) ---(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] now about psql and one function
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
Re: [HACKERS] using adbin, conbin, etc.
Use the various pg_get_...() functions wherever you can. And if you can't find one that does what you want, ask for it. The last thing we want is client-side code digging into those internal representations --- we change 'em frequently. I want pg_get_* functions for every PostgreSQL object :P Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] using adbin, conbin, etc.
And if you can't find one that does what you want, ask for it. The last thing we want is client-side code digging into those internal representations --- we change 'em frequently. I want pg_get_* functions for every PostgreSQL object :P And I want an easy way of parsing aclitem[]'s so I don't have to do it manually in PHP, trying to handle usernames and grantors that have commas, spaces, backslashes and double quotes in them... Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] compile failure
Are we removing recode before going into beta? --- Greg Stark wrote: Is recode a feature that's normally enabled? ./configure '--enable-recode' '--enable-integer-datetimes' '--enable-debug' '--with-perl' '--with-pam' '--with-openssl' '--with-gnu-ld' '--with-maxbackends=64' '--with-pgport=5432' 'CFLAGS=-O0 -g -pg -DLINUX_PROFILE' ... gcc -O0 -g -pg -DLINUX_PROFILE -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -c -o miscinit.o miscinit.c miscinit.c: In function `SetCharSet': miscinit.c:205: structure has no member named `in' make[4]: *** [miscinit.o] Error 1 make[4]: Leaving directory `/u6/src/postgres/cvs/pgsql/src/backend/utils/init' -- greg ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- 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 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] Error messages --- now that we've got it, do you like
Tom, you saw this suggestion, right? --- Bruce Momjian wrote: Bruce Momjian wrote: VERBOSE doesn't seem like the right name for the \set parameter. I consider VERBOSE to be a possible value for error verbosity. Saying '\set VERBOSE terse' seems like an contradiction. Should we call it VERBOSITY, or something else? Seems 'error' or 'err' or 'message' should be in there somewhere too. Here is a good example of the problem: regression=# \set VERBOSE verbose regression=# \set VERBOSE default regression=# \set VERBOSE terse That is just confusing. It is the parameter name and a possible value. How about MESSOUTPUT or ERROUTPUT? Both look ugly, though. OK, if people like VERBOSITY, I wonder if the values should be more like a tunable parameter, rather than a behavior, meaning VERBOSITY would have values like off/default/full, or minimum/default/maximum. -- 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 -- 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
[HACKERS] Win32 for 7.5... how to help?
Hi all, This probably more than a little premature/ill-timed, but I was hoping to start a groundswell of support for Win32 port. I, and I imagine quite a number of capable lurkers on the list, would love to get involved. Is there a way that work can be doled out now/soon, so that we can make the next release (and with more stability than we might have expected had the port squeezed into 7.4). How do we help? No doubt this'll be shelved until some time after 7.4 is pushed out, but it would be great if one of the Postgres heavies (figuratively :-) would pro-actively lead this... Best of all, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(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] Error messages --- now that we've got it, do you like
Bruce Momjian [EMAIL PROTECTED] writes: Tom, you saw this suggestion, right? I didn't hear anyone else agreeing with it ... 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] Any unapplied patches out there?
Does anyone have any outstanding patches they expected would be applied for 7.4? I think everything in my inbox has been dealt with, but I might have missed something. Bruce is not done generating release notes, so we probably will not have a formal beta package ready until Friday. However, CVS tip or a nightly snapshot tarball should be pretty-durn-close-to-the-beta. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 for 7.5... how to help?
I am already leading it, I think. --- Claudio Natoli wrote: Hi all, This probably more than a little premature/ill-timed, but I was hoping to start a groundswell of support for Win32 port. I, and I imagine quite a number of capable lurkers on the list, would love to get involved. Is there a way that work can be doled out now/soon, so that we can make the next release (and with more stability than we might have expected had the port squeezed into 7.4). How do we help? No doubt this'll be shelved until some time after 7.4 is pushed out, but it would be great if one of the Postgres heavies (figuratively :-) would pro-actively lead this... Best of all, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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] Error messages --- now that we've got it, do you like
That's what I thought... just checking. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom, you saw this suggestion, right? I didn't hear anyone else agreeing with it ... regards, tom lane -- 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] compile failure
Bruce Momjian [EMAIL PROTECTED] writes: Are we removing recode before going into beta? I was waiting for someone to holler that they really want it, but so far the silence is deafening ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] compile failure
Someone at LinuxTag said they liked it because you can do the conversion in a text file, rather than compiling a conversion C file. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Are we removing recode before going into beta? I was waiting for someone to holler that they really want it, but so far the silence is deafening ... regards, tom lane ---(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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] autocommit in 7.4
Is there a reason autocommit is implemented in psql and not in libpq via a C function call? --- Bruce Momjian wrote: I see autocommit as implemented only in psql, not in libpq. Is that what we want to do for 7.4? -- 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] this is in plain text (row level locks)
I was thinking of adding to TODO: * Allow shared row locks for referential integrity but how is that different from: * Implement dirty reads and use them in RI triggers --- Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: It may be best to have a locking manager run as a separate process. That way it could store locks in ram or spill over to disk. Hmm, that might be workable. We could imagine that in place of the HEAP_MARKED_FOR_UPDATE status bit, we have a this row is possibly locked hint bit. Only if you see the bit set do you need to query the lock manager. If the answer comes back that no lock is held, you can clear the bit --- so no need for any painful undo stuff after a crash, and no communication overhead in the normal case. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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] Win32 for 7.5... how to help?
I am already leading it, I think. Ok. How do the willing get involved? Cheers, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] this is in plain text (row level locks)
Bruce Momjian [EMAIL PROTECTED] writes: I was thinking of adding to TODO: * Allow shared row locks for referential integrity but how is that different from: * Implement dirty reads and use them in RI triggers It'd be a completely different approach to solving the FK locking problem. I wouldn't think we'd do both. Personally I'd feel more comfortable with a shared-lock approach, if we could work out the scalability issues. Dirty reads seem ... well ... dirty. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] php with postgres
Are you all done with the PHP persistent connection changes? Need any help? --- Marcus B?rger wrote: Hello Christopher, Wednesday, July 23, 2003, 6:49:05 AM, you wrote: Surely PHP can be modified so as to use the new 3.0 protocol feature to detect whether it's in a transaction or not, so as to avoid unnecssary querying? Yes, you could, but it hardly seems worth it because they have to support old and new protocols. Eventually, yes, they could use that to eliminate the BEGIN;COMMIT. CKL Just use a configure test to see if you have the appropriate function call CKL in your libpq... I've put that already into PHP yesturday so i could add the necessary check now too. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- 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] php with postgres
OK, I checked the URL's, and I am a little confused. I don't understand why the conditional transaction abort isn't in the same place as the RESET ALL. Seems they should be done at the same time, though there is an advantage to doing the RESET ALL during connect, because if someone changes the postgres.conf setting between the disconnect and the connect, you would then see the new values, which seems correct. Is that what is happening? If it is, this line is wrong: pg_result = PQexec(pgsql, BEGIN;ROLLBACK;RESET ALL;); because you have already rolled back the connection during the disconnect. This is the code for old servers. --- Marcus B?rger wrote: 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] -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] name of configure threading option
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Win32 for 7.5... how to help?
Uh, the two big items are Win32 signal code, and reordering the startup code to allow exec without fork. Both are pretty complicated, but I do ask for assistance on the hackers list. --- Claudio Natoli wrote: I am already leading it, I think. Ok. How do the willing get involved? Cheers, Claudio --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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] Win32 for 7.5... how to help?
Uh, the two big items are Win32 signal code, and reordering the startup code to allow exec without fork. Both are pretty complicated, but I do ask for assistance on the hackers list. Ok. I guess we'll just keep our eyes peeled for the next time we can help out. Thanks for the replies... --- WE HAVE MOVED - PLEASE NOTE OUR NEW CONTACT DETAILS: THE BASEMENT, 33 EWELL STREET, BALMAIN NSW 2041 TEL: +61 2 9555 1544 FAX: +61 2 9555 6911 Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] autocommit in 7.4
Bruce Momjian [EMAIL PROTECTED] writes: Is there a reason autocommit is implemented in psql and not in libpq via a C function call? One reason is that PQexec accepts multiple-query strings (possibly with embedded BEGIN/END), so it's not immediately obvious what the semantics ought to be. We could probably work out some reasonable definition if we wanted to put effort into it, but seeing that libpq clients aren't historically expecting any autocommit support, I didn't find it a high priority task for 7.4. At this point it's definitely too late for 7.4, anyway. Put it on the TODO list if you feel strongly about it. 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] this is in plain text (row level locks)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I was thinking of adding to TODO: * Allow shared row locks for referential integrity but how is that different from: * Implement dirty reads and use them in RI triggers It'd be a completely different approach to solving the FK locking problem. I wouldn't think we'd do both. Personally I'd feel more comfortable with a shared-lock approach, if we could work out the scalability issues. Dirty reads seem ... well ... dirty. TODO updated: * Implement dirty reads or shared locks and use them in RI triggers -- 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] autocommit in 7.4
The issue I have is that every interface that relies on libpq is going to have to code it itself. Is that OK? --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Is there a reason autocommit is implemented in psql and not in libpq via a C function call? One reason is that PQexec accepts multiple-query strings (possibly with embedded BEGIN/END), so it's not immediately obvious what the semantics ought to be. We could probably work out some reasonable definition if we wanted to put effort into it, but seeing that libpq clients aren't historically expecting any autocommit support, I didn't find it a high priority task for 7.4. At this point it's definitely too late for 7.4, anyway. Put it on the TODO list if you feel strongly about it. regards, tom lane -- 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] 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. --- Christopher Kings-Lynne wrote: Just a slight nitpick, shouldn't this line: # - Previous Postgres Versions - Be this: # - Previous PostgreSQL Versions - 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 -- 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
[HACKERS] patch queue
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 will complete the release changes by Friday. -- 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] followup on previous
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. -- - Christopher Kings-Lynne wrote: Just a slight nitpick, shouldn't this line: # - Previous Postgres Versions - Be this: # - Previous PostgreSQL Versions - 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 -- 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 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] autocommit in 7.4
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. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] this is in plain text (row level locks)
Tom == Tom Lane [EMAIL PROTECTED] writes: Tom Personally I'd feel more comfortable with a shared-lock Tom approach, if we could work out the scalability issues. Dirty Tom reads seem ... well ... dirty. Tom I was going to do some experiments to measure the costs of our shared memory MemoryContext. Is there something specific you'd be interested in ? My first goal is mainly to measure the amount of time it takes to allocate and deallocate shared memory in the contested and uncontested cases. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 8: explain analyze is your friend
