Re: [PATCHES] [HACKERS] Autovacuum loose ends
Alvaro Herrera wrote: Here is another patch for autovacuum: ... - Xid-wraparound VACUUM is now FULL without ANALYZE Am I right in my assumption that this VACUUM FULL can happen for any database, not just a template database? I think this is a bad idea. Vacuum full is not an option for our and many other production databases. I suggest that should be a plain VACUUM. Otherwise I think you have done great job finally integrating auto vacuum into the backend. Best Regards, Michael Paesold ---(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] [HACKERS] For review: Server instrumentation patch
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 01 August 2005 03:26 To: Dave Page Cc: PostgreSQL-patches Subject: Re: [HACKERS] For review: Server instrumentation patch Dave Page wrote: [Resent as the list seems to have rejected yesterdays attempt] As per Bruce's request, here's a copy of Andreas' server instrumentation patch for review. I've separated out the dbsize stuff and pg_terminate_backend is also not included. This version was generated against CVS today. As far as I can tell from review of comments made back to pre-8.0, all security and other concerns raised have been addressed. Here is a modified version of your patch that adds functions to do configuration file reload, and log file rotation. OK, thanks. Are there any objections to adding pg_dir_ls() and pg_file_read() which will allow us to look at the log directory, and the logfiles themselves? Regards, Dave ---(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: [PATCHES] per user/database connections limit again
Am Montag, 25. Juli 2005 18:31 schrieb Tom Lane: Bruce Momjian pgman@candle.pha.pa.us writes: The new syntax for this command is CREATE/ALTER DATABASE/USER: | MAX CONNECTIONS Iconst This adds 'max' as a keyword, though at a fairly unreserved level, I think. Should we use the syntax LIMIT CONNECTIONS so we don't have to add MAX as a keyword at all? I didn't like that either. I was thinking of just CONNECTIONS. LIMIT CONNECTIONS sort of works grammatically, I guess. Would this not work in the context of the general user-specific ALTER USER ... SET something = something? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Win32 Thread Safety
The attached patch updates the thread test program to run stand-alone on Windows. The test itself is bypassed in configure as discussed, and libpq has been updated appropriately to allow it to build in thread-safe mode. To apply, apply the patch as normal, then rename src/interface/libpq/pthread.h.win32 to src/interface/libpq/pthread-win32.h. Finally, run autoconf to regenerate configure. Regards, Dave. win32_thread_safety.diff.gz Description: win32_thread_safety.diff.gz ---(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: [PATCHES] [HACKERS] Autovacuum loose ends
On Mon, Aug 01, 2005 at 09:55:11AM +0200, Michael Paesold wrote: Alvaro Herrera wrote: Here is another patch for autovacuum: ... - Xid-wraparound VACUUM is now FULL without ANALYZE Am I right in my assumption that this VACUUM FULL can happen for any database, not just a template database? Ah, right. I think it would be OK if we made it FULL only for datallowcon=false databases. OTOH maybe it's not worth at all making the distinction and we should continue using the previous policy of issuing only non-FULL VACUUM. -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) Having your biases confirmed independently is how scientific progress is made, and hence made our great society what it is today (Mary Gardiner) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 01 August 2005 03:26 To: Dave Page Cc: PostgreSQL-patches Subject: Re: [HACKERS] For review: Server instrumentation patch Dave Page wrote: [Resent as the list seems to have rejected yesterdays attempt] As per Bruce's request, here's a copy of Andreas' server instrumentation patch for review. I've separated out the dbsize stuff and pg_terminate_backend is also not included. This version was generated against CVS today. As far as I can tell from review of comments made back to pre-8.0, all security and other concerns raised have been addressed. Here is a modified version of your patch that adds functions to do configuration file reload, and log file rotation. OK, thanks. Are there any objections to adding pg_dir_ls() and pg_file_read() which will allow us to look at the log directory, and the logfiles themselves? pg_dir_ls isn't necessary for reading the logfiles; pg_logdir_ls will do this. Regards, Andreas ---(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] [HACKERS] For review: Server instrumentation patch
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 01 August 2005 14:47 To: Dave Page Cc: Bruce Momjian; PostgreSQL-patches Subject: Re: [PATCHES] [HACKERS] For review: Server instrumentation patch Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 01 August 2005 03:26 To: Dave Page Cc: PostgreSQL-patches Subject: Re: [HACKERS] For review: Server instrumentation patch Dave Page wrote: [Resent as the list seems to have rejected yesterdays attempt] As per Bruce's request, here's a copy of Andreas' server instrumentation patch for review. I've separated out the dbsize stuff and pg_terminate_backend is also not included. This version was generated against CVS today. As far as I can tell from review of comments made back to pre-8.0, all security and other concerns raised have been addressed. Here is a modified version of your patch that adds functions to do configuration file reload, and log file rotation. OK, thanks. Are there any objections to adding pg_dir_ls() and pg_file_read() which will allow us to look at the log directory, and the logfiles themselves? pg_dir_ls isn't necessary for reading the logfiles; pg_logdir_ls will do this. Err, yes, sorry - that was a thinko. /D ---(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: [PATCHES] [HACKERS] Autovacuum loose ends
Alvaro Herrera [EMAIL PROTECTED] writes: - Xid-wraparound VACUUM is now FULL without ANALYZE Am I right in my assumption that this VACUUM FULL can happen for any database, not just a template database? Ah, right. I think it would be OK if we made it FULL only for datallowcon=false databases. OTOH maybe it's not worth at all making the distinction and we should continue using the previous policy of issuing only non-FULL VACUUM. Strikes me as a waste of cycles: the one database *least* likely to be in need of a VACUUM FULL is template0. What we perhaps should consider is VACUUM FREEZE, not FULL, when hitting a template database --- this would maximize the interval before needing to do it again. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
Dave Page wrote: pg_dir_ls isn't necessary for reading the logfiles; pg_logdir_ls will do this. Err, yes, sorry - that was a thinko. The list isn't complete. pgadmin uses these three functions for logfile tracking: - pg_logdir_ls to list logfiles - pg_file_length to check for changes of the current logfile - pg_file_read to retrieve a logfile Regards, Andreas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] per user/database connections limit again
Peter Eisentraut wrote: Am Montag, 25. Juli 2005 18:31 schrieb Tom Lane: Bruce Momjian pgman@candle.pha.pa.us writes: The new syntax for this command is CREATE/ALTER DATABASE/USER: | MAX CONNECTIONS Iconst This adds 'max' as a keyword, though at a fairly unreserved level, I think. Should we use the syntax LIMIT CONNECTIONS so we don't have to add MAX as a keyword at all? I didn't like that either. I was thinking of just CONNECTIONS. LIMIT CONNECTIONS sort of works grammatically, I guess. Would this not work in the context of the general user-specific ALTER USER ... SET something = something? No because it isn't a GUC variable, it is per-user/db value. We could have used that syntax, but it might confuse people. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] per user/database connections limit again
An updated version of your patch has been applied and will be in 8.1. Thanks. --- pgman wrote: I have worked over your patch and I think it is ready for application. I changed the syntax to CONNECTION LIMIT, which seems most natural. We could skip CONNECTION and just use a LIMIT keyword, but that seems too terse. I removed your use of the pg_auth flat file. By the time you have the PROC entry to do your lookups, you might as well just use the system cache. There is a race condition in the code because we set our PROC entry before we check for other entries. If there is one connection left and two backends do this at the same time, they would both fail, while one should fail and the other succeed. Without a lock, I see no way to avoid it so I just commented it in the code. Also, I felt that zero should mean allow no/zero connections, rather than representing unlimited connections. I used -1 for unlimited. We can either document the use of -1, or add syntax to allow NO CONNECTION LIMIT, or something like that. The patch requires a catalog version update when applied. -- 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: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] For review: Server instrumentation patch
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 01 August 2005 15:05 To: Dave Page Cc: Bruce Momjian; PostgreSQL-patches Subject: Re: [PATCHES] [HACKERS] For review: Server instrumentation patch Dave Page wrote: pg_dir_ls isn't necessary for reading the logfiles; pg_logdir_ls will do this. Err, yes, sorry - that was a thinko. The list isn't complete. pgadmin uses these three functions for logfile tracking: - pg_logdir_ls to list logfiles - pg_file_length to check for changes of the current logfile - pg_file_read to retrieve a logfile Yes you're right, I didn't check thoroughly (in my defence, the coffee machine broke this morning). Anyhoo, pg_file_stat is used by pg_file_length, so that would be required as well. None of those allow any modification of the filesystem, so do not suffer the potential security issues that Tom was concerned about, so hopefully there is no problem with them going in? Regards, Dave. ---(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] per user/database connections limit again
Bruce Momjian pgman@candle.pha.pa.us writes: Peter Eisentraut wrote: Would this not work in the context of the general user-specific ALTER USER ... SET something = something? No because it isn't a GUC variable, it is per-user/db value. We could have used that syntax, but it might confuse people. Yeah --- casting it as a GUC would create issues like what is the global default?. I think treating it as a hard-wired feature is fine. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] ALTER OBJECT SET SCHEMA
--On Donnerstag, Juli 28, 2005 23:12:37 -0400 Bruce Momjian pgman@candle.pha.pa.us wrote: Here is an updated version of your patch. Would you supply SGML documentation updates to match the code changes? Thanks. Here's my first shot on this. Let me know if there's somenthing missing or broken (note: English is not my native language, i hope there aren't too much faults). -- Bernd alter_set_schema_doc.patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ALTER OBJECT SET SCHEMA
Bernd Helmle [EMAIL PROTECTED] writes: Here is an updated version of your patch. Would you supply SGML documentation updates to match the code changes? Thanks. Here's my first shot on this. Applied with additional minor editing. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Implementing SELECT FOR UPDATE [NOWAIT]
Karel Zak [EMAIL PROTECTED] writes: This is new version of SELECT FOR UPDATE NOWAIT patch. Applied with revisions. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] [patch 4/7] small fixes
o pgp_mpi_free: Accept NULLs
o pgp_mpi_cksum: result should be 16bit
o Remove function name from error messages - to be similar to other
SQL functions, and it does not match anyway the called function
o remove couple junk lines
Index: pgsql/contrib/pgcrypto/pgp-mpi.c
===
*** pgsql.orig/contrib/pgcrypto/pgp-mpi.c
--- pgsql/contrib/pgcrypto/pgp-mpi.c
*** int pgp_mpi_create(uint8 *data, int bits
*** 66,71
--- 66,73
int pgp_mpi_free(PGP_MPI *mpi)
{
+ if (mpi == NULL)
+ return 0;
memset(mpi, 0, sizeof(*mpi) + mpi-bytes);
px_free(mpi);
return 0;
*** unsigned pgp_mpi_cksum(unsigned cksum, P
*** 129,134
for (i = 0; i n-bytes; i++)
cksum += n-data[i];
! return cksum;
}
--- 131,136
for (i = 0; i n-bytes; i++)
cksum += n-data[i];
! return cksum 0x;
}
Index: pgsql/contrib/pgcrypto/pgp-pubkey.c
===
*** pgsql.orig/contrib/pgcrypto/pgp-pubkey.c
--- pgsql/contrib/pgcrypto/pgp-pubkey.c
***
*** 34,41
#include mbuf.h
#include pgp.h
- #define PXE_PGP_BAD_KEY -90
-
int pgp_key_alloc(PGP_PubKey **pk_p)
{
PGP_PubKey *pk;
--- 34,39
Index: pgsql/contrib/pgcrypto/pgp-pgsql.c
===
*** pgsql.orig/contrib/pgcrypto/pgp-pgsql.c
--- pgsql/contrib/pgcrypto/pgp-pgsql.c
*** encrypt_internal(int is_pubenc, int is_t
*** 496,502
mbuf_free(dst);
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION),
!errmsg(pgp_encrypt error: %s,
px_strerror(err;
}
/* res_len includes VARHDRSZ */
--- 496,502
mbuf_free(dst);
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION),
!errmsg(%s, px_strerror(err;
}
/* res_len includes VARHDRSZ */
*** out:
*** 591,597
mbuf_free(dst);
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION),
!errmsg(pgp_decrypt error: %s,
px_strerror(err;
}
res_len = mbuf_steal_data(dst, restmp);
--- 591,597
mbuf_free(dst);
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION),
!errmsg(%s, px_strerror(err;
}
res_len = mbuf_steal_data(dst, restmp);
*** pg_dearmor(PG_FUNCTION_ARGS)
*** 879,885
if (res_len 0)
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION),
!errmsg(dearmor: %s, px_strerror(res_len;
if (res_len guess_len)
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION),
--- 879,885
if (res_len 0)
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION),
!errmsg(%s, px_strerror(res_len;
if (res_len guess_len)
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION),
*** pgp_key_id_w(PG_FUNCTION_ARGS)
*** 909,917
buf = create_mbuf_from_vardata(data);
res = palloc(VARHDRSZ + 17);
- px_set_debug_handler(show_debug);
res_len = pgp_get_keyid(buf, VARDATA(res));
- px_set_debug_handler(NULL);
mbuf_free(buf);
if (res_len 0)
ereport(ERROR,
--- 909,915
Index: pgsql/contrib/pgcrypto/px.c
===
*** pgsql.orig/contrib/pgcrypto/px.c
--- pgsql/contrib/pgcrypto/px.c
*** static const struct error_desc px_err_li
*** 72,85
{PXE_PGP_SHORT_ELGAMAL_KEY, Elgamal keys must be at least 1024 bits
long},
{PXE_PGP_RSA_UNSUPPORTED, pgcrypto does not support RSA keys},
{PXE_PGP_UNKNOWN_PUBALGO, Unknown public-key encryption algorithm},
! {PXE_PGP_WRONG_KEYID, Data is not encrypted with this key},
{PXE_PGP_MULTIPLE_KEYS,
Several keys given - pgcrypto does not handle keyring},
{PXE_PGP_EXPECT_PUBLIC_KEY, Refusing to encrypt with secret key},
{PXE_PGP_EXPECT_SECRET_KEY, Cannot decrypt with public key},
{PXE_PGP_NOT_V4_KEYPKT, Only V4 key packets are supported},
{PXE_PGP_KEYPKT_CORRUPT, Corrupt key packet},
!
[PATCHES] [patch 3/7] Elgamal speedup
I was bit hasty making the random exponent 'k' a prime. Further researh shows that Elgamal encryption has no specific needs in respect to k, any random number is fine. It is bit different for signing, there it needs to be 'relatively prime' to p - 1, that means GCD(k, p-1) == 1, which is also a lot lighter than full primality. As we don't do signing, this can be ignored. This brings major speedup to Elgamal encryption. Index: pgsql/contrib/pgcrypto/pgp-mpi-openssl.c === *** pgsql.orig/contrib/pgcrypto/pgp-mpi-openssl.c --- pgsql/contrib/pgcrypto/pgp-mpi-openssl.c *** pgp_elgamal_encrypt(PGP_PubKey *pk, PGP_ *** 120,126 * generate k */ k_bits = decide_k_bits(BN_num_bits(p)); ! if (!BN_generate_prime(k, k_bits, 0, NULL, NULL, NULL, NULL)) goto err; /* --- 120,126 * generate k */ k_bits = decide_k_bits(BN_num_bits(p)); ! if (!BN_rand(k, k_bits, 0, 0)) goto err; /* -- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] [patch 6/7] small updates for README
o Tom stuck a CVS id into file. I doubt the usefulness of it, but if it needs to be in the file then rather at the end. Also tag it as comment for asciidoc. o Mention bytea vs. text difference o Couple clarifications Index: pgsql/contrib/pgcrypto/README.pgcrypto === *** pgsql.orig/contrib/pgcrypto/README.pgcrypto --- pgsql/contrib/pgcrypto/README.pgcrypto *** *** 1,4 - $PostgreSQL: pgsql/contrib/pgcrypto/README.pgcrypto,v 1.12 2005/07/18 17:17:12 tgl Exp $ pgcrypto - cryptographic functions for PostgreSQL = --- 1,3 *** cracking. Or may not. *** 278,284 --- The functions here implement the encryption part of OpenPGP (RFC2440) ! standard. 5.1. Overview --- 277,283 --- The functions here implement the encryption part of OpenPGP (RFC2440) ! standard. Supported are both symmetric-key and public-key encryption. 5.1. Overview *** Options are described in section 5.7. *** 334,339 --- 333,342 Decrypt a symmetric-key encrypted PGP message. + Decrypting bytea data with `pgp_sym_decrypt` is disallowed. + This is to avoid outputting invalid character data. Decrypting + originally textual data with `pgp_sym_decrypt_bytea` is fine. + Options are described in section 5.7. *** key is password-protected, you must give *** 362,367 --- 365,374 there is no password, but you want to specify option for function, you need to give empty password. + Decrypting bytea data with `pgp_pub_decrypt` is disallowed. + This is to avoid outputting invalid character data. Decrypting + originally textual data with `pgp_pub_decrypt_bytea` is fine. + Options are described in section 5.7. *** cipher-algo:: *** 422,428 Default: aes128 Applies: pgp_sym_encrypt, pgp_pub_encrypt - compress-algo:: Which compression algorithm to use. Needs building with zlib. --- 429,434 *** s2k-cipher-algo:: *** 492,498 Which cipher to use for encrypting separate session key. Values: bf, aes, aes128, aes192, aes256 ! Default: same as cipher-algo. Applies: pgp_sym_encrypt unicode-mode:: --- 498,504 Which cipher to use for encrypting separate session key. Values: bf, aes, aes128, aes192, aes256 ! Default: use cipher-algo. Applies: pgp_sym_encrypt unicode-mode:: *** Generate a new key: *** 513,519 gpg --gen-key ! You need to pick DSA and Elgamal key type, others are sign-only. List keys: --- 519,528 gpg --gen-key ! The preferred key type is DSA and Elgamal. ! ! For RSA encryption you must create either DSA or RSA sign-only key ! as master and then add RSA encryption subkey with `gpg --edit-key`. List keys: *** You need to use `dearmor()` on them befo *** 531,536 --- 540,548 pgp_pub_* functions. Or if you can handle binary data, you can drop -a from gpg. + For more details see `man gpg`, http://www.gnupg.org/gph/en/manual.html[ + The GNU Privacy Handbook] and other docs on http://www.gnupg.org[] site. + 5.10. Limitations of PGP code ~~~ *** pgp_pub_* functions. Or if you can hand *** 538,546 - No support for signing. That also means that it is not checked whether the encryption subkey belongs to master key. ! - No support for RSA keys. Only Elgamal encryption keys are supported ! - No support for several encryption subkeys. 6. Raw encryption --- 550,562 - No support for signing. That also means that it is not checked whether the encryption subkey belongs to master key. ! - No support for encryption key as master key. As such practice ! is generally discouraged, it should not be a problem. ! - No support for several subkeys. This may seem like a problem, as this ! is common practice. On the other hand, you should not use your regular ! GPG/PGP keys with pgcrypto, but create new ones, as the usage scenario ! is rather different. 6. Raw encryption *** I have used code from following sources: *** 631,636 --- 647,655 9.1. Useful reading ~ + http://www.gnupg.org/gph/en/manual.html[]:: + The GNU Privacy Handbook + http://www.openwall.com/crypt/[]:: Describes the crypt-blowfish algorithm. *** http://jlcooke.ca/random/[]:: *** 673,675 --- 692,698 http://www.cs.ut.ee/~helger/crypto/[]:: Collection of cryptology pointers. + + + // $PostgreSQL: pgsql/contrib/pgcrypto/README.pgcrypto,v 1.12 2005/07/18 17:17:12 tgl Exp $ + -- ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] [patch 1/7] remove unnecessary libs
The SHLIB section was copy-pasted from somewhere and contains several unnecessary libs. This cleans it up a bit. -lcrypt we don't use system crypt() -lssl, -lssleay32 no SSL here -lz in win32 section already added on previous line -ldes The chance anybody has it is pretty low. And the chance pgcrypto works with it is even lower. Also trim the win32 section. Index: pgsql/contrib/pgcrypto/Makefile === *** pgsql.orig/contrib/pgcrypto/Makefile --- pgsql/contrib/pgcrypto/Makefile *** endif *** 56,72 # Add libraries that pgcrypto depends (or might depend) on into the # shared library link. (The order in which you list them here doesn't # matter.) ! SHLIB_LINK += $(filter -lcrypt -ldes -lcrypto -lssl -lz, $(LIBS)) ifeq ($(PORTNAME), win32) ! SHLIB_LINK += $(filter -leay32 -lssleay32 -lz, $(LIBS)) ! endif ! ! # to make ws2_32.lib the last library (must occur after definition of PORTNAME) ! ifeq ($(PORTNAME),win32) SHLIB_LINK += -lwsock32 -lws2_32 endif - rijndael.o: rijndael.tbl rijndael.tbl: --- 56,68 # Add libraries that pgcrypto depends (or might depend) on into the # shared library link. (The order in which you list them here doesn't # matter.) ! SHLIB_LINK += $(filter -lcrypto -lz, $(LIBS)) ifeq ($(PORTNAME), win32) ! SHLIB_LINK += $(filter -leay32, $(LIBS)) ! # those must be at the end SHLIB_LINK += -lwsock32 -lws2_32 endif rijndael.o: rijndael.tbl rijndael.tbl: -- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] [patch 5/7] support for RSA, pubkey reorg
o Support for RSA encryption
o Big reorg to better separate generic and algorithm-specific code.
o Regression tests for RSA.
Index: pgsql/contrib/pgcrypto/pgp-mpi-openssl.c
===
*** pgsql.orig/contrib/pgcrypto/pgp-mpi-openssl.c
--- pgsql/contrib/pgcrypto/pgp-mpi-openssl.c
*** pgp_elgamal_encrypt(PGP_PubKey *pk, PGP_
*** 104,112
int res = PXE_PGP_MATH_FAILED;
int k_bits;
BIGNUM *m = mpi_to_bn(_m);
! BIGNUM *p = mpi_to_bn(pk-elg_p);
! BIGNUM *g = mpi_to_bn(pk-elg_g);
! BIGNUM *y = mpi_to_bn(pk-elg_y);
BIGNUM *k = BN_new();
BIGNUM *yk = BN_new();
BIGNUM *c1 = BN_new();
--- 104,112
int res = PXE_PGP_MATH_FAILED;
int k_bits;
BIGNUM *m = mpi_to_bn(_m);
! BIGNUM *p = mpi_to_bn(pk-pub.elg.p);
! BIGNUM *g = mpi_to_bn(pk-pub.elg.g);
! BIGNUM *y = mpi_to_bn(pk-pub.elg.y);
BIGNUM *k = BN_new();
BIGNUM *yk = BN_new();
BIGNUM *c1 = BN_new();
*** pgp_elgamal_decrypt(PGP_PubKey *pk, PGP_
*** 159,166
int res = PXE_PGP_MATH_FAILED;
BIGNUM *c1 = mpi_to_bn(_c1);
BIGNUM *c2 = mpi_to_bn(_c2);
! BIGNUM *p = mpi_to_bn(pk-elg_p);
! BIGNUM *x = mpi_to_bn(pk-elg_x);
BIGNUM *c1x = BN_new();
BIGNUM *div = BN_new();
BIGNUM *m = BN_new();
--- 159,166
int res = PXE_PGP_MATH_FAILED;
BIGNUM *c1 = mpi_to_bn(_c1);
BIGNUM *c2 = mpi_to_bn(_c2);
! BIGNUM *p = mpi_to_bn(pk-pub.elg.p);
! BIGNUM *x = mpi_to_bn(pk-sec.elg.x);
BIGNUM *c1x = BN_new();
BIGNUM *div = BN_new();
BIGNUM *m = BN_new();
*** err:
*** 195,197
--- 195,259
return res;
}
+ int
+ pgp_rsa_encrypt(PGP_PubKey *pk, PGP_MPI *_m, PGP_MPI **c_p)
+ {
+ int res = PXE_PGP_MATH_FAILED;
+ BIGNUM *m = mpi_to_bn(_m);
+ BIGNUM *e = mpi_to_bn(pk-pub.rsa.e);
+ BIGNUM *n = mpi_to_bn(pk-pub.rsa.n);
+ BIGNUM *c = BN_new();
+ BN_CTX *tmp = BN_CTX_new();
+
+ if (!m || !e || !n || !c || !tmp)
+ goto err;
+
+ /*
+* c = m ^ e
+*/
+ if (!BN_mod_exp(c, m, e, n, tmp))
+ goto err;
+
+ *c_p = bn_to_mpi(c);
+ if (*c_p)
+ res = 0;
+ err:
+ if (tmp) BN_CTX_free(tmp);
+ if (c) BN_clear_free(c);
+ if (n) BN_clear_free(n);
+ if (e) BN_clear_free(e);
+ if (m) BN_clear_free(m);
+ return res;
+ }
+
+ int
+ pgp_rsa_decrypt(PGP_PubKey *pk, PGP_MPI *_c, PGP_MPI **m_p)
+ {
+ int res = PXE_PGP_MATH_FAILED;
+ BIGNUM *c = mpi_to_bn(_c);
+ BIGNUM *d = mpi_to_bn(pk-sec.rsa.d);
+ BIGNUM *n = mpi_to_bn(pk-pub.rsa.n);
+ BIGNUM *m = BN_new();
+ BN_CTX *tmp = BN_CTX_new();
+
+ if (!m || !d || !n || !c || !tmp)
+ goto err;
+
+ /*
+* m = c ^ d
+*/
+ if (!BN_mod_exp(m, c, d, n, tmp))
+ goto err;
+
+ *m_p = bn_to_mpi(m);
+ if (*m_p)
+ res = 0;
+ err:
+ if (tmp) BN_CTX_free(tmp);
+ if (m) BN_clear_free(m);
+ if (n) BN_clear_free(n);
+ if (d) BN_clear_free(d);
+ if (c) BN_clear_free(c);
+ return res;
+ }
+
Index: pgsql/contrib/pgcrypto/pgp-pubdec.c
===
*** pgsql.orig/contrib/pgcrypto/pgp-pubdec.c
--- pgsql/contrib/pgcrypto/pgp-pubdec.c
*** control_cksum(uint8 *msg, int msglen)
*** 91,96
--- 91,145
return 0;
}
+ static int
+ decrypt_elgamal(PGP_PubKey *pk, PullFilter *pkt, PGP_MPI **m_p)
+ {
+ int res;
+ PGP_MPI *c1 = NULL;
+ PGP_MPI *c2 = NULL;
+
+ if (pk-algo != PGP_PUB_ELG_ENCRYPT)
+ return PXE_PGP_WRONG_KEY;
+
+ /* read elgamal encrypted data */
+ res = pgp_mpi_read(pkt, c1);
+ if (res 0)
+ goto out;
+ res = pgp_mpi_read(pkt, c2);
+ if (res 0)
+ goto out;
+
+ /* decrypt */
+ res = pgp_elgamal_decrypt(pk, c1, c2, m_p);
+
+ out:
+ pgp_mpi_free(c1);
+ pgp_mpi_free(c2);
+ return res;
+ }
+
+ static int
+ decrypt_rsa(PGP_PubKey *pk, PullFilter *pkt, PGP_MPI **m_p)
+ {
+ int res;
+ PGP_MPI *c;
+
+ if (pk-algo != PGP_PUB_RSA_ENCRYPT
+pk-algo != PGP_PUB_RSA_ENCRYPT_SIGN)
+ return PXE_PGP_WRONG_KEY;
+
+ /* read rsa encrypted data */
+ res = pgp_mpi_read(pkt, c);
+ if (res 0)
+ return res;
+
+ /* decrypt */
+ res = pgp_rsa_decrypt(pk, c, m_p);
+
+ pgp_mpi_free(c);
+ return res;
+ }
+
/* key id is missing - user is expected to try all keys */
static const uint8
any_key[] = {0, 0, 0, 0, 0, 0, 0, 0};
*** pgp_parse_pubenc_sesskey(PGP_Context *ct
*** 102,108
int
[PATCHES] [patch 2/7] remove last pieces of system crypt()
It is already disabled in Makefile, remove code too.
Index: pgsql/contrib/pgcrypto/px-crypt.c
===
*** pgsql.orig/contrib/pgcrypto/px-crypt.c
--- pgsql/contrib/pgcrypto/px-crypt.c
***
*** 35,42
#include px-crypt.h
- #ifndef PX_SYSTEM_CRYPT
-
static char *
run_crypt_des(const char *psw, const char *salt,
char *buf, unsigned len)
--- 35,40
*** px_crypt(const char *psw, const char *sa
*** 107,130
return c-crypt(psw, salt, buf, len);
}
- #else /* PX_SYSTEM_CRYPT */
-
- extern char *crypt(const char *psw, const char *salt);
-
- char *
- px_crypt(const char *psw, const char *salt,
-char *buf, unsigned len)
- {
- char *res;
-
- res = crypt(psw, salt);
- if (!res || strlen(res) = len)
- return NULL;
- strcpy(buf, res);
- return buf;
- }
- #endif
-
/*
* salt generators
*/
--- 105,110
Index: pgsql/contrib/pgcrypto/px-crypt.h
===
*** pgsql.orig/contrib/pgcrypto/px-crypt.h
--- pgsql/contrib/pgcrypto/px-crypt.h
*** char *_crypt_gensalt_md5_rn(unsigned lon
*** 73,80
char *_crypt_gensalt_blowfish_rn(unsigned long count,
const char *input, int size, char *output, int
output_size);
- #ifndef PX_SYSTEM_CRYPT
-
/* disable 'extended DES crypt' */
/* #define DISABLE_XDES */
--- 73,78
*** char *px_crypt_des(const char *key, c
*** 88,93
/* crypt-md5.c */
char *px_crypt_md5(const char *pw, const char *salt,
char *dst, unsigned dstlen);
- #endif /* !PX_SYSTEM_CRYPT */
#endif /* _PX_CRYPT_H */
--- 86,90
--
---(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: [PERFORM] [PATCHES] COPY FROM performance improvements
Alon Goldshuv [EMAIL PROTECTED] writes: This patch appears to reverse out the most recent committed changes in copy.c. Which changes do you refer to? I thought I accommodated all the recent changes (I recall some changes to the tupletable/tupleslot interface, HEADER in cvs, and hex escapes and maybe one or 2 more). What did I miss? The latest touch of copy.c, namely this patch: 2005-07-10 17:13 tgl * doc/src/sgml/ref/create_type.sgml, src/backend/commands/copy.c, src/backend/commands/typecmds.c, src/backend/tcop/fastpath.c, src/backend/tcop/postgres.c, src/backend/utils/adt/arrayfuncs.c, src/backend/utils/adt/date.c, src/backend/utils/adt/numeric.c, src/backend/utils/adt/rowtypes.c, src/backend/utils/adt/timestamp.c, src/backend/utils/adt/varbit.c, src/backend/utils/adt/varchar.c, src/backend/utils/adt/varlena.c, src/backend/utils/mb/mbutils.c, src/include/catalog/catversion.h, src/include/catalog/pg_proc.h, src/test/regress/expected/type_sanity.out, src/test/regress/sql/type_sanity.sql: Change typreceive function API so that receive functions get the same optional arguments as text input functions, ie, typioparam OID and atttypmod. Make all the datatypes that use typmod enforce it the same way in typreceive as they do in typinput. This fixes a problem with failure to enforce length restrictions during COPY FROM BINARY. It was rather obvious, given that the first chunk of the patch backed up the file's CVS version stamp from 1.247 to 1.246 :-( regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] AIX - pgport/contrib resolution
Rocco Altier [EMAIL PROTECTED] writes: Here is a backport of patches to get AIX to work on 8.0. Basically, it's the changes to : backend/Makefile - redo the linking of the SUBSYS objects contrib/cube - pick up -lm port/getopt_long.c - fix include files (might want to think about other files changed here too?) contrib/tsearch2 - similar include file fixes Applied; many thanks for doing the legwork! regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
