Re: [PATCHES] [GENERAL] ISO week dates
Peter Eisentraut wrote: Bruce Momjian wrote: On these questions, we have to find out how Oracle handles it, but your approach seems appropriate. I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. What do we do with other invalid pattern combinations in to_char() now? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [GENERAL] ISO week dates
Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. What do we do with other invalid pattern combinations in to_char() now? Mostly, we return bogus results :-(. The formatting.c code in general doesn't seem very robust. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [GENERAL] ISO week dates
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. What do we do with other invalid pattern combinations in to_char() now? Mostly, we return bogus results :-(. The formatting.c code in general doesn't seem very robust. Yep, seems every release I am in there cleaning up some mistake repeated multiple times in the code. It needs a good cleaning. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [GENERAL] ISO week dates
On 2/15/07, Bruce Momjian [EMAIL PROTECTED] wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. What do we do with other invalid pattern combinations in to_char() now? Mostly, we return bogus results :-(. The formatting.c code in general doesn't seem very robust. Yep, seems every release I am in there cleaning up some mistake repeated multiple times in the code. It needs a good cleaning. I'm happy to volunteer to do something about the invalid field combinations, but I suspect an overhaul of formatting.c is more than I can currently chew. I figure it would be a bit misguided of me to put together a patch for invalid field combinations if somebody is about to do a rewrite of much of the code? ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [GENERAL] ISO week dates
Brendan Jurd wrote: On 2/15/07, Bruce Momjian [EMAIL PROTECTED] wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. What do we do with other invalid pattern combinations in to_char() now? Mostly, we return bogus results :-(. The formatting.c code in general doesn't seem very robust. Yep, seems every release I am in there cleaning up some mistake repeated multiple times in the code. It needs a good cleaning. I'm happy to volunteer to do something about the invalid field combinations, but I suspect an overhaul of formatting.c is more than I can currently chew. I figure it would be a bit misguided of me to put together a patch for invalid field combinations if somebody is about to do a rewrite of much of the code? Yea, I was just throwing out a note that someday if someone has time, that file need a good sweeping. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [GENERAL] ISO week dates
Bruce Momjian wrote: Brendan Jurd wrote: On 2/15/07, Bruce Momjian [EMAIL PROTECTED] wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. What do we do with other invalid pattern combinations in to_char() now? Mostly, we return bogus results :-(. The formatting.c code in general doesn't seem very robust. Yep, seems every release I am in there cleaning up some mistake repeated multiple times in the code. It needs a good cleaning. I'm happy to volunteer to do something about the invalid field combinations, but I suspect an overhaul of formatting.c is more than I can currently chew. I figure it would be a bit misguided of me to put together a patch for invalid field combinations if somebody is about to do a rewrite of much of the code? Yea, I was just throwing out a note that someday if someone has time, that file need a good sweeping. Sorry, I wasn't clear. No one is currently working on overhauling formatting.c, so if you want to submit _any_ patch to improve the file, please do. :-) -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [GENERAL] ISO week dates
On 2/15/07, Bruce Momjian [EMAIL PROTECTED] wrote: Bruce Momjian wrote: Brendan Jurd wrote: On 2/15/07, Bruce Momjian [EMAIL PROTECTED] wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. What do we do with other invalid pattern combinations in to_char() now? Mostly, we return bogus results :-(. The formatting.c code in general doesn't seem very robust. Yep, seems every release I am in there cleaning up some mistake repeated multiple times in the code. It needs a good cleaning. I'm happy to volunteer to do something about the invalid field combinations, but I suspect an overhaul of formatting.c is more than I can currently chew. I figure it would be a bit misguided of me to put together a patch for invalid field combinations if somebody is about to do a rewrite of much of the code? Yea, I was just throwing out a note that someday if someone has time, that file need a good sweeping. Sorry, I wasn't clear. No one is currently working on overhauling formatting.c, so if you want to submit _any_ patch to improve the file, please do. :-) It'll be a pleasure Bruce. I think it would be best to wait until the existing ISO week date patch has gone through before working on it though. Perhaps a TODO item is in order? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [GENERAL] ISO week dates
Brendan Jurd wrote: On 2/15/07, Bruce Momjian [EMAIL PROTECTED] wrote: Bruce Momjian wrote: Brendan Jurd wrote: On 2/15/07, Bruce Momjian [EMAIL PROTECTED] wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. What do we do with other invalid pattern combinations in to_char() now? Mostly, we return bogus results :-(. The formatting.c code in general doesn't seem very robust. Yep, seems every release I am in there cleaning up some mistake repeated multiple times in the code. It needs a good cleaning. I'm happy to volunteer to do something about the invalid field combinations, but I suspect an overhaul of formatting.c is more than I can currently chew. I figure it would be a bit misguided of me to put together a patch for invalid field combinations if somebody is about to do a rewrite of much of the code? Yea, I was just throwing out a note that someday if someone has time, that file need a good sweeping. Sorry, I wasn't clear. No one is currently working on overhauling formatting.c, so if you want to submit _any_ patch to improve the file, please do. :-) It'll be a pleasure Bruce. I think it would be best to wait until the existing ISO week date patch has gone through before working on it though. OK. Perhaps a TODO item is in order? Sure, good suggestion. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: 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: [PATCHES] SSL enhancement patch ver.2
Never mind, I found the answer: http://archives.postgresql.org/pgsql-hackers/2006-08/msg01931.php Working on the patch now. --- Bruce Momjian wrote: Victor B. Wagner wrote: This patch adds following functionality to PostgreSQL 1. If PostgreSQL is compiled with OpenSSL version 0.9.7 and above, both backend and libpq read site-wide OpenSSL configuration file as described in OPENSSL_config functon manual page. This allows to use hardware crypto acceleration modules (engines) and, in future version 0.9.9 would allow to use additional cryptoalgorithms (i.e. national standards) which are not included in core OpenSSL. All other configuration parameters which are supported by OpenSSL library also are taken into account. 2. New configuration option ssl_ciphers is added to postgresql.conf. This option allows to change list of ciphers, acceptable by backend during SSL connection. Changing list of ciphers can be desirable to tighten or relax security of particular installation, and allows quick fix on configuration file level in case if vulnerability is discovered in one of cryptoalgorithms or their OpenSSL implementation - cipher suites which use such algorithm can be easily disabled. Why are you adding ssl_ciphers to postgresql.conf? Can't you control that from the site-wide OpenSSL configuration file added above? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] patch adding new regexp functions
What was the status of this? Was there anything else I needed to do with this patch, or is it ready to be applied? Let me know if there is anything else I need to do on this... -- What this country needs is a good five cent nickel. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Autovacuum launcher
[resending, with the patch gzipped, as the previous one seems to be lost -- I mistakenly sent it to -hackers instead of -patches] Hi, Here's the autovacuum launcher patch I'm considering for inclusion. Possibly controversial stuff: 1. I changed InitPostgres to be able to get a database by OID. This is better than having to convert the OID to name in the launcher by reading the pg_database flat file, and then back to OID in InitPostgres by reading same. I had to add a FindMyDatabaseByOid to this effect. In autovacuum mode, InitPostgres() passes the database name back, so that the autovacuum worker process doesn't have to compute it separately. 2. I treat autovac workers as backends in Postmaster, and put them in the regular list of backends. This makes them respond to SignalChildren() cleanly; and it means they don't need any special code in case of shutdown, etc, because they are managed just like any other backend. I intended to add an is_autovacuum flag to the Backend struct, but it turns out to be unnecessary. Not so controversial, but maybe of note: 1. I removed all frammishes to slow down in case of failure (start_time, stop_time, etc). 2. Autovacuum launcher is a dummy process, so it's treated specially in postmaster. 3. Autovacuum now has a shared memory area. Currently it's fairly small and contains a single OID and a PID, but the idea is to extend it to pass more info to the workers in future patches. Other than that it seems fairly vanilla to me. One thing I noticed is that when autovac is off, it may take up to 60 seconds to process a signal passed down via SendPostmasterSignal(). I assume this is due to our system calls being restartable, i.e. it's restarted by the operating system after the signal is received (if this is not the case please let me know). This should not be much of a problem, except if the postmaster is idle for a long time (for example because all connections are served from a pool) and a lot of transactions are consumed in the 60 sec period. Not sure if I should worry too much about this. Comments are much appreciated. I intend to apply this in a couple of days unless there are objections. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support autovac-launcher.patch.gz Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Autovacuum launcher
Alvaro Herrera [EMAIL PROTECTED] writes: Here's the autovacuum launcher patch I'm considering for inclusion. This part is very seriously broken: diff -c -p -r1.33 lwlock.h *** src/include/storage/lwlock.h5 Jan 2007 22:19:58 - 1.33 --- src/include/storage/lwlock.h13 Feb 2007 16:58:41 - *** typedef enum LWLockId *** 62,67 --- 62,68 BtreeVacuumLock, AddinShmemInitLock, FirstBufMappingLock, + AutovacuumLock, FirstLockMgrLock = FirstBufMappingLock + NUM_BUFFER_PARTITIONS, /* must be last except for MaxDynamicLWLock: */ I'm surprised it got through your testing at all, with the autovacuum lock conflicting with bufmgr. Making InitPostgres's call API vary depending on IsAutoVacuumWorkerProcess seems really ugly, and unnecessary. Why not just test for dbname == NULL or some other convention expressed by the arguments themselves? One thing I noticed is that when autovac is off, it may take up to 60 seconds to process a signal passed down via SendPostmasterSignal(). That's because if the signal arrives while postmaster has signals blocked, it'll be serviced at PG_SETMASK(UnBlockSig), and then (if no connection requests are arriving) the select() timeout delay will elapse before the main loop notices the flag. You probably want to reconsider the decision to not have sigusr1_handler() launch the child immediately. The current coding is the way it is because an autovac child can itself send the signal and we want that to be interpreted as start another one after the current one finishes. In the launcher-and-workers world, though, I'm not convinced we need any such behavior. One problem I see with this is you've removed the code that sent SIGINT to an active autovac process during smart shutdown. This seems a bad idea because now shutdown response will be limited by the slowest autovac, and that will tempt DBAs with itchy trigger fingers to do something stupid. It'd be a good idea to extend the Backend struct to mark which backends are autovacs, so that you can preserve the behavior of sending them SIGINTs at shutdown. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] patch adding new regexp functions
On Wed, 2007-02-14 at 16:49 -0800, Jeremy Drake wrote: What was the status of this? Was there anything else I needed to do with this patch, or is it ready to be applied? Let me know if there is anything else I need to do on this... Will do -- I'm planning to apply this as soon as I have the free cycles to do so, likely tomorrow or Friday. -Neil ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
