Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
On Sun, 3 Jul 2005 03:32 pm, Michael Fuhr wrote: I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include a volatility category in its CREATE FUNCTION statements, so the functions are all created VOLATILE. Shouldn't most of them be IMMUTABLE? Or do the algorithms have side effects? So far I've found no discussion about this except for one person asking about it last year: http://archives.postgresql.org/pgsql-admin/2004-12/msg00065.php I know the salt functions MUST stay volatile, as they produce different output every time you call them. I've not looked at the pgcrypto code, so I can't make further comment than that. Regards Russell Smith. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
On Sun, Jul 03, 2005 at 04:24:31PM +1000, Russell Smith wrote: On Sun, 3 Jul 2005 03:32 pm, Michael Fuhr wrote: I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include a volatility category in its CREATE FUNCTION statements, so the functions are all created VOLATILE. Shouldn't most of them be IMMUTABLE? Or do the algorithms have side effects? I know the salt functions MUST stay volatile, as they produce different output every time you call them. I've not looked at the pgcrypto code, so I can't make further comment than that. Yeah, I see that gen_salt() needs to be volatile, but I was thinking about functions like digest(), encrypt(), decrypt(), etc., that would be expected to return the same output given the same input. For example, the core md5() function is immutable, but pgcrypto's digest() is volatile. I was wondering if that's intentional or just an oversight. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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
Re: [HACKERS] Checkpoint cost, looks like it is WAL/CRC
Bruce Momjian pgman@candle.pha.pa.us writes: I have an idea! Currently we write the backup pages (copies of pages modified since the last checkpoint) when we write the WAL changes as part of the commit. See the XLogCheckBuffer() call in XLogInsert(). Can someone explain exactly what the problem being defeated by writing whole pages to the WAL log? Like, if page is half flushed to disk and contains half the old data and half of the new data, what exactly would go wrong with recovery? When postgres sees the write why would it have trouble recovering the correct contents for the page based on the half-written page and the regular WAL entry? A further optimization would be to write the backup pages to the same 8k file over and over again rather than adding I/O to pg_xlog WAL files. This is an interesting idea. But it's not necessarily universally a win. For users with a battery backed cache it would be absolutely ideal and a huge win. It would avoid pushing other pages out of cache and avoid doing extra i/o syncing the no longer relevant data to the actual disk. But for users without a battery backed cache I don't think it would be a win. It would mean another data file that ideally would be on a segregated set of spindles to avoid any unnecessary seeks. Currently the ideal postgres setup has WAL on one set of spindles, data on another set of spindles, and OS writable partitions like /var on an entirely separate set of spindles. That takes at least 6 drives if you want mirrored drives. This would raise the minimum to 8 drives. -- greg ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 2PC transaction id
On Sat, 2 Jul 2005, Oliver Jowett wrote: Sorry to keep beating on this, but I still don't see where the spec says that you must have only one RM per transaction branch. Sure, it's important to get this right. 2.2.6 says: 2.2.6 Transaction Branches A global transaction has one or more transaction branches (or branches). A branch is a part of the work in support of a global transaction for which the TM and the RM engage in a separate but coordinated transaction commitment protocol (see Section 2.3 on page 8). Each of the RMs internal units of work in support of a global transaction is part of exactly one branch. A global transaction might have more than one branch when, for example, the AP uses multiple processes or is involved in the same global transaction by multiple remote APs. So it seems to me that branches are intended to allow independent processes / APs to each have an independent set of tightly coupled threads (as all work on a particular branch is tightly-coupled). There's no mention of having only one RM per branch, which I'd expect to see here if it was a requirement. They should have been explicit about it, I agree. The key is the clause A branch is a part of the work in support of a global transaction for which the TM and the RM engage in a separate but coordinated transaction commitment protocol. That means that for each branch, there's exactly one call to prepare and commit. If you have two RMs, you need two prepare/commit calls, so you need two branches. One implication of the second paragraph is that a single-threaded AP can use a single transaction branch for all the work it does. No, that paragraph says for example. The third example is the case where you have more than one RM :). As further, non-authoritative, evidence, see this DevX article on JTA: http://archive.devx.com/java/free/articles/dd_jta/jta-2.asp Search for branch in that article. It says explicitly Requests to three different RDBMSs, therefore, require three transaction branches. - Heikki ---(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
Re: [HACKERS] [PATCHES] Dbsize backend integration
Bruce Momjian wrote: Andreas Pflug wrote: Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 02 July 2005 21:30 To: Bruce Momjian Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development Subject: Re: [PATCHES] Dbsize backend integration Is a new version of this patch coming? Yup, attached. Per our earlier conversation, pg_dbfile_size() now returns the size of a table or index, and pg_relation_size() returns the total size of a relation and all associated indexes and toast tables etc. pg_relation_size's name is quite unfortunate, since the 8.0 contrib function does something different. And pg_dbfile_size sounds misleading, suggesting it takes a filename or relfilenode as parameter. Hmm. I don't see how we can call it pg_table_size because people think of tables and indexes, while relation has a more inclusive suggestion. We could, taking the same logic as GRANT which uses the keyword TABLE for sequences and Indexes too, but it's certainly not favourable. As far as pg_dbfile_size, do you have any other idea for a name? To me, it returns the size of the 'db file' associated with the heap/index/toast. How about pg_relation_size(oid, bool) with the second optional parameter to count all additional objects too (the 'total' flag). Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] Dbsize backend integration
On 7/3/05, Andreas Pflug [EMAIL PROTECTED] wrote: Yup, attached. Per our earlier conversation, pg_dbfile_size() now returns the size of a table or index, and pg_relation_size() returns the total size of a relation and all associated indexes and toast tables etc. pg_relation_size's name is quite unfortunate, since the 8.0 contrib function does something different. And pg_dbfile_size sounds misleading, suggesting it takes a filename or relfilenode as parameter. Oh, I think pg_dbfile_size is best so far. Assuming someone gives it a filename, she'll get an error message. So practically it cannot be used wrong by mistake. It is not so with other names proposed for that function. Their names suggest they'll happily accept table/index/whatever and return some size... But what size, that is the question. At least pg_dbfile_size states that clearly. :) As for pg_relation_size. I think its good enough, or at least I don't know any better. I think it is better than pg_table_size, since people tend to have personalized ideas what a table size is (a table with TOAST and TOAST's indexes; a table with PRIMARY KEY,UNIQUE constraint indexes, a table with all indexes involved,. etc/). pg_relation_size seems. at least to me, to imply that its greedy and will take not only the table, and also things the table is closely related to, like all the indexes. The fun will begin when we'll have full working table partitioning and multitable indexes. ; Regards, Dawid ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Checkpoint cost, looks like it is WAL/CRC
On Sun, 3 Jul 2005 04:47 pm, Greg Stark wrote: Bruce Momjian pgman@candle.pha.pa.us writes: I have an idea! Currently we write the backup pages (copies of pages modified since the last checkpoint) when we write the WAL changes as part of the commit. See the XLogCheckBuffer() call in XLogInsert(). Can someone explain exactly what the problem being defeated by writing whole pages to the WAL log? Like, if page is half flushed to disk and contains half the old data and half of the new data, what exactly would go wrong with recovery? When postgres sees the write why would it have trouble recovering the correct contents for the page based on the half-written page and the regular WAL entry? Problem we are solving. Checkpoint Happens. (Ensuring that ALL data make it to the disk) - This means we don't need the information in WAL before the checkpoint. We write some updates to the db, changing some pages. The Power is pulled and one page is half written. There is no way to know if the page is in a valid state. There is no way to recover the page from wal, becuase unless we wrote the full page into wal, we don't have a starting point for modification. That's probably very unclear but that is the idea. Regards Russell Smith ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
On Sun, Jul 03, 2005 at 12:43:32AM -0600, Michael Fuhr wrote: On Sun, Jul 03, 2005 at 04:24:31PM +1000, Russell Smith wrote: On Sun, 3 Jul 2005 03:32 pm, Michael Fuhr wrote: I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include a volatility category in its CREATE FUNCTION statements, so the functions are all created VOLATILE. Shouldn't most of them be IMMUTABLE? Or do the algorithms have side effects? I know the salt functions MUST stay volatile, as they produce different output every time you call them. I've not looked at the pgcrypto code, so I can't make further comment than that. Yeah, I see that gen_salt() needs to be volatile, but I was thinking about functions like digest(), encrypt(), decrypt(), etc., that would be expected to return the same output given the same input. For example, the core md5() function is immutable, but pgcrypto's digest() is volatile. I was wondering if that's intentional or just an oversight. Just an oversight. Could you send a patch to -patches that fixes it? It would take some time to do it myself, as I am coding an additional feature to the PGP functions, and all my free time goes to that. And if you decide to do it, please make them all STRICT too, _except_ encrypt/decrypt functions. Thats an additional change I have in the air for pgcrypto.sql.in. As for the encrypt/decrypt functions, I am increasingly favouring throwing error in case of NULL arguments. I'm fearing a scenario, where somebody sets a encrypted data field to NULL, and the change goes undetected. This may not be that relevant for encrypt/decrypt as their integrity protection is almost non-existant, but is very relevant for PGP functions, as they offer very strong guarantees. Does anybody see a scenario, where this would be unreasonable? -- marko ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Autotools update
On Sat, Jul 02, 2005 at 09:46:19PM +0200 I heard the voice of Peter Eisentraut, and lo! it spake thus: Bruce Momjian wrote: Does the FreeBSD one actually produce different output? If it did not, why would they bother making a separate package called gnu-autoconf with the note This port is specifically designed for developers that want to create cross-platform software distributions on FreeBSD.? Because the non-gnu- variants patch to stuff version numbers in all the filenames and invocations down the chain, so you can have different versions installed at once. Different packages might be written to different versions, and they tend to be non-cross-compatible. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ---(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] contrib/pgcrypto functions not IMMUTABLE?
On Sun, Jul 03, 2005 at 03:59:51PM +0300, Marko Kreen wrote: On Sun, Jul 03, 2005 at 12:43:32AM -0600, Michael Fuhr wrote: Yeah, I see that gen_salt() needs to be volatile, but I was thinking about functions like digest(), encrypt(), decrypt(), etc., that would be expected to return the same output given the same input. For example, the core md5() function is immutable, but pgcrypto's digest() is volatile. I was wondering if that's intentional or just an oversight. Just an oversight. Could you send a patch to -patches that fixes it? It would take some time to do it myself, as I am coding an additional feature to the PGP functions, and all my free time goes to that. And if you decide to do it, please make them all STRICT too, _except_ encrypt/decrypt functions. Thats an additional change I have in the air for pgcrypto.sql.in. I'll submit a patch. Does the following look right? digest IMMUTABLE STRICT digest_exists IMMUTABLE STRICT hmac IMMUTABLE STRICT hmac_existsIMMUTABLE STRICT crypt IMMUTABLE STRICT gen_salt VOLATILE STRICT encryptIMMUTABLE decryptIMMUTABLE encrypt_iv IMMUTABLE decrypt_iv IMMUTABLE cipher_exists IMMUTABLE STRICT In the functions marked STRICT, should I leave the PG_ARGISNULL() checks in place as a precaution? Removing those checks could cause problems if people use the new code but have old (non-STRICT) catalog entries. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
On Sun, Jul 03, 2005 at 07:54:47AM -0600, Michael Fuhr wrote: I'll submit a patch. Does the following look right? digest IMMUTABLE STRICT digest_exists IMMUTABLE STRICT hmac IMMUTABLE STRICT hmac_existsIMMUTABLE STRICT crypt IMMUTABLE STRICT gen_salt VOLATILE STRICT encryptIMMUTABLE decryptIMMUTABLE encrypt_iv IMMUTABLE decrypt_iv IMMUTABLE cipher_exists IMMUTABLE STRICT Nice overview. Now that I have them before me, I think crypt() should stay also non-strict, as it also has delicate security properties. Everything else is OK. In the functions marked STRICT, should I leave the PG_ARGISNULL() checks in place as a precaution? Removing those checks could cause problems if people use the new code but have old (non-STRICT) catalog entries. Good point. Let them be. Rather, could you make crypt, encrypt, decrypt return error for NULL input? With nice message, eg. NULL input... Then this topic would be solved in one go. -- marko ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Checkpoint cost, looks like it is WAL/CRC
Greg Stark [EMAIL PROTECTED] writes: Can someone explain exactly what the problem being defeated by writing whole pages to the WAL log? Partial writes. Without the full-page image, we do not have enough information in WAL to reconstruct the correct page contents. A further optimization would be to write the backup pages to the same 8k file over and over again rather than adding I/O to pg_xlog WAL files. How does that work, and why is it a win compared to doing the same amount of I/O to WAL? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
Marko Kreen marko@l-t.ee writes: And if you decide to do it, please make them all STRICT too, _except_ encrypt/decrypt functions. Thats an additional change I have in the air for pgcrypto.sql.in. As for the encrypt/decrypt functions, I am increasingly favouring throwing error in case of NULL arguments. That doesn't seem like a good idea at all. Why shouldn't an encryptable value be NULL? I think you should just make 'em strict. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] Dbsize backend integration
Dawid Kuroczko [EMAIL PROTECTED] writes: Oh, I think pg_dbfile_size is best so far. I think it's by far the ugliest suggestion yet :-( Andreas's suggestion of having just one function with a bool parameter might be a workable compromise. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote: Marko Kreen marko@l-t.ee writes: And if you decide to do it, please make them all STRICT too, _except_ encrypt/decrypt functions. Thats an additional change I have in the air for pgcrypto.sql.in. As for the encrypt/decrypt functions, I am increasingly favouring throwing error in case of NULL arguments. That doesn't seem like a good idea at all. Why shouldn't an encryptable value be NULL? I think you should just make 'em strict. Well, I have mainly issues with decrypt part. I'd like to say, if decrypt succeeds, whoever put the data there, had the key. Existing decrypt() has a smell of it - there is 1/256 chance that data modification won't be detected. With PGP, this is part of functionality - there will be SHA1 attached to data. Now, encrypt() should throw error just for symmetricity and to force user handle the 'no data' case externally. On the other hand, all this is corner-case protection from someone who has already write-access to table. This could be also solved with documenting that user must specifically think how to handle 'success' from null values. As for the crypt() case, lets say you have a new user with hashed password field NULL. In addition, you have client program that compares crypt() result with hashed field itself, in addition it handles NULL's as empty string. Result: it is possible to login with any password. Lots of assumptions but in eg. PHP case they are all filled. Do you object to non-strict crypt() too? -- marko ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
Marko Kreen marko@l-t.ee writes: On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote: That doesn't seem like a good idea at all. Why shouldn't an encryptable value be NULL? I think you should just make 'em strict. Well, I have mainly issues with decrypt part. I'd like to say, if decrypt succeeds, whoever put the data there, had the key. Existing decrypt() has a smell of it - there is 1/256 chance that data modification won't be detected. And that has what to do with throwing an error on NULL input? As for the crypt() case, lets say you have a new user with hashed password field NULL. In addition, you have client program that compares crypt() result with hashed field itself, in addition it handles NULL's as empty string. Result: it is possible to login with any password. Lots of assumptions but in eg. PHP case they are all filled. A NULL password field is intended to have exactly that effect, no? 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/pgcrypto functions not IMMUTABLE?
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote: Marko Kreen marko@l-t.ee writes: On Sun, Jul 03, 2005 at 12:02:38PM -0400, Tom Lane wrote: That doesn't seem like a good idea at all. Why shouldn't an encryptable value be NULL? I think you should just make 'em strict. Well, I have mainly issues with decrypt part. I'd like to say, if decrypt succeeds, whoever put the data there, had the key. Existing decrypt() has a smell of it - there is 1/256 chance that data modification won't be detected. And that has what to do with throwing an error on NULL input? It is not an encrypted value so do not succeed. As for the crypt() case, lets say you have a new user with hashed password field NULL. In addition, you have client program that compares crypt() result with hashed field itself, in addition it handles NULL's as empty string. Result: it is possible to login with any password. Lots of assumptions but in eg. PHP case they are all filled. A NULL password field is intended to have exactly that effect, no? I hope not. But I think I see - throwing error on NULL goes against standard practice and anyway NULL handling should be user responsibility, not pgcrypto's. Maybe I'm getting too paranoid from tracking all the error conditions in pgp code. Michael, the result is, you can make them all STRICT. -- marko ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
On Sun, Jul 03, 2005 at 12:57:54PM -0400, Tom Lane wrote: Marko Kreen marko@l-t.ee writes: As for the crypt() case, lets say you have a new user with hashed password field NULL. In addition, you have client program that compares crypt() result with hashed field itself, in addition it handles NULL's as empty string. Result: it is possible to login with any password. Lots of assumptions but in eg. PHP case they are all filled. A NULL password field is intended to have exactly that effect, no? Not necessarily -- it may mean the user was just created, or it was deactivated by setting the password to NULL. Yes, this last thing is foolish, but people do it anyway ... -- Alvaro Herrera (alvherre[a]surnet.cl) The only difference is that Saddam would kill you on private, where the Americans will kill you in public (Mohammad Saleh, 39, a building contractor) ---(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/pgcrypto functions not IMMUTABLE?
Alvaro Herrera [EMAIL PROTECTED] writes: Marko Kreen marko@l-t.ee writes: As for the crypt() case, lets say you have a new user with hashed password field NULL. In addition, you have client program that compares crypt() result with hashed field itself, in addition it handles NULL's as empty string. Result: it is possible to login with any password. Lots of assumptions but in eg. PHP case they are all filled. A NULL password field is intended to have exactly that effect, no? Not necessarily -- it may mean the user was just created, or it was deactivated by setting the password to NULL. Yes, this last thing is foolish, but people do it anyway ... Nonetheless, I have a problem with allowing this one scenario to drive a bizarre design of the function. For every user that is able to omit an explicit NULL test in this case, there will be ten that have to add one to avoid their apps blowing up because the function errors out on NULLs. Just because it's security-related doesn't mean you shouldn't follow the principle of least surprise and make this SQL function act like 99% of other SQL functions do when handed a NULL. And if crypt() should act this way, why not also md5() for instance? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Checkpoint cost, looks like it is WAL/CRC
Tom Lane [EMAIL PROTECTED] writes: Greg Stark [EMAIL PROTECTED] writes: Can someone explain exactly what the problem being defeated by writing whole pages to the WAL log? Partial writes. Without the full-page image, we do not have enough information in WAL to reconstruct the correct page contents. Sure, but why not? If a 8k page contains 16 low level segments on disk and the old data is and the new data is AAABAAACAAADAAAE then the WAL would contain the B, C, D, and E. Shouldn't that be enough to reconstruct the page? If the actual write only got out AAABAAAC the resulting page is garbage but why isn't what the WAL has enough information to reconstruct the new version? I do worry that a drive could write AAABAAACXYZKWBFH if it loses power in the middle of the write, though. That would be bad. -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Checkpoint cost, looks like it is WAL/CRC
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: Partial writes. Without the full-page image, we do not have enough information in WAL to reconstruct the correct page contents. Sure, but why not? If a 8k page contains 16 low level segments on disk and the old data is and the new data is AAABAAACAAADAAAE then the WAL would contain the B, C, D, and E. Shouldn't that be enough to reconstruct the page? It might contain parts of it ... scattered across a large number of WAL entries ... but I don't think that's enough to reconstruct the page. As an example, a btree insert WAL record will say insert this tuple at position N, shifting the other entries accordingly; that does not give you the ability to reconstruct entries that shifted across sector boundaries, as they may not be present in the on-disk data of either sector. You're also going to have fairly serious problems interpreting the page contents if what's on disk includes the effects of multiple WAL records beyond the record you are currently looking at. We could possibly do it if we added more information to the WAL records, but that strikes me as a net loss: essentially it would pay the penalty all the time instead of only on the first write after a checkpoint. Also, you are assuming that the content of each sector is uniquely --- and determinably --- either old data or new data, not for example unreadable because partially written. 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] Fix for cross compilation
Tom Lane wrote: Hmm ... I suppose the implication of that is that the upstream zic files *are* architecture-independent, else people wouldn't keep them in /share; and looking at the code, it does seem some effort is made in that direction. With that in mind, I have installed the original cross compilation patch (with CC_FOR_BUILD). I realize that the inclusion of pg_config.h is technically wrong, but AFAICT zic doesn't really make use of that (e.g., int64 is not used to create the output files). I think this should be enough to get interested cross compilers started, and we will address specific problems as we see them. I guess a significant share only want libpq anyway. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
Marko Kreen wrote: On Sun, Jul 03, 2005 at 07:54:47AM -0600, Michael Fuhr wrote: In the functions marked STRICT, should I leave the PG_ARGISNULL() checks in place as a precaution? Removing those checks could cause problems if people use the new code but have old (non-STRICT) catalog entries. Good point. Let them be. Assuming the STRICT / IMMUTABLE changes are only going into HEAD, you can safely remove the PG_ARGISNULL() checks -- people upgrading from a prior version of Postgres (and therefore pgcrypto) will need to dump and reload anyway. -Neil ---(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/pgcrypto functions not IMMUTABLE?
On Mon, Jul 04, 2005 at 11:42:14AM +1000, Neil Conway wrote: Assuming the STRICT / IMMUTABLE changes are only going into HEAD, you can safely remove the PG_ARGISNULL() checks -- people upgrading from a prior version of Postgres (and therefore pgcrypto) will need to dump and reload anyway. But if they restore a dump made with pg_dump or pg_dumpall, they'll get the old catalog entries sans STRICT, no? People might rebuild the module when they upgrade, but they might not think to drop and recreate the functions since the definitions are already in the dump. I suppose the Release Notes could mention that recreating the functions is required; it could also show the SQL statements necessary to update pg_proc so a drop/recreate wouldn't be necessary. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
Michael Fuhr wrote: But if they restore a dump made with pg_dump or pg_dumpall, they'll get the old catalog entries sans STRICT, no? People might rebuild the module when they upgrade, but they might not think to drop and recreate the functions since the definitions are already in the dump. I think it is asking for trouble in general to use the DDL from one version of pgcrypto with a different version of the pgcrypto implementation. However, you're right that people are inevitably going to do this, so I suppose we need to keep the checks. Perhaps it would be worth adding something to the installation documentation suggesting that people take care when installing new versions of contrib/ packages and the like without updating the DDL for those packages. -Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] HEAD doesn't cope with libraries in non-default locations
CVS tip fails with ./configure --with-openssl \ --with-includes=/usr/local/ssl/include --with-libs=/usr/local/ssl/lib ... make[3]: Entering directory `/home/postgres/pgsql/src/interfaces/libpq' ... /usr/ccs/bin/ld +h libpq.sl.4 -b +b /home/postgres/testversion/lib fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o getaddrinfo.o -lssl -lcrypto `gcc -L../../../src/port -L/usr/local/ssl/lib -Wl,-z -Wl,+b -Wl,/home/postgres/testversion/lib -print-libgcc-file-name` -L../../../src/port -L/usr/local/ssl/lib -o libpq.sl.4 /usr/ccs/bin/ld: Can't find library for -lssl make[3]: *** [libpq.sl.4] Error 1 It appears that somebody has changed things so that the -L switches appear after the -l switches (ie, too late). I'm too tired to investigate now, but my money is on Autoconf 2.59 being the problem ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Schedule for release 8.1
Here is a rough outline of what is coming for 8.1: o On Monday, we will collect all submitted patches. o Within the next 2-4 weeks, we will apply all patches that can be applied. o We will make sure all changes since 8.1 are working resonably well and are documented. This is the cleanup phase. o Within the next 1-2 months, we will enter beta for 8.1. o Within the next 2-4 months from then, we will have a release of 8.1. This puts the release of 8.1 perhaps in the October/November timeframe. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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] HEAD doesn't cope with libraries in non-default locations
Tom Lane wrote: It appears that somebody has changed things so that the -L switches appear after the -l switches (ie, too late). I'm too tired to investigate now, but my money is on Autoconf 2.59 being the problem ... Perhaps this: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00085.php -O ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
On Sun, Jul 03, 2005 at 08:15:07PM +0300, Marko Kreen wrote: Michael, the result is, you can make them all STRICT. OK. Does anybody else have thoughts on removing the PG_ARGISNULL() checks? Neil suggests removing them because they'd be unnecessary, but I'm concerned about people who'd use the new code with old catalog entries that aren't STRICT (e.g., restored from a dump). Should we leave the PG_ARGISNULL() checks in place as a safety measure, or should the 8.1 Release Notes make it clear that the functions need to be recreated (or pg_proc updated)? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] contrib/pgcrypto functions not IMMUTABLE?
Michael Fuhr [EMAIL PROTECTED] writes: OK. Does anybody else have thoughts on removing the PG_ARGISNULL() checks? Neil suggests removing them because they'd be unnecessary, but I'm concerned about people who'd use the new code with old catalog entries that aren't STRICT (e.g., restored from a dump). I concur with leaving them in for awhile. They aren't all that expensive ... 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] Schedule for release 8.1
On Mon, 4 Jul 2005, Bruce Momjian wrote: Here is a rough outline of what is coming for 8.1: o On Monday, we will collect all submitted patches. o Within the next 2-4 weeks, we will apply all patches that can be applied. o We will make sure all changes since 8.1 are working resonably well and are documented. This is the cleanup phase. All changes since 8.0, don't you mean ... ? o Within the next 1-2 months, we will enter beta for 8.1. o Within the next 2-4 months from then, we will have a release of 8.1. This puts the release of 8.1 perhaps in the October/November timeframe. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
