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
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
[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
[PATCHES] [patch 7/7] remove the API file
There is a choice whether to update it with pgp functions or remove it. I decided to remove it, updating is pointless. I've tried to keep the core of pgcrypto relatively independent from main PostgreSQL, to make it easy to use externally if needed, and that is good. Eg. that made development of PGP functions much nicer. But I have no plans to release it as generic library, so keeping such doc up-to-date is waste of time. If anyone is interested in using it in other products, he can probably bother to read the source too. Commented source is another thing - I'll try to make another pass over code to see if there is anything non-obvious that would need more comments. Index: pgsql/contrib/pgcrypto/API === *** pgsql.orig/contrib/pgcrypto/API --- /dev/null *** *** 1,163 - - C API for pgcrypto - == - - - UN*X crypt() - - - #include - - char * - px_crypt(const char *psw, const char *salt, char *buf, unsigned buflen); - - returns buf or NULL for error. - - unsigned px_gen_salt(const char *salt_type, char *dst, int rounds); - - returns salt size. dst should be PX_MAX_SALT_LEN bytes. - 'rounds' is algorithm specific. 0 means default for - that algorithm. - - Random - == - - int px_get_random_bytes(uint8 *dst, int num) - - - Crypto "objects" - - - PX_MD - Message digest - PX_HMAC- HMAC (Hash MAC) - PX_Cipher - cipher+mode: provided by libs - PX_Combo - higher-level encryption -> padding, [MD] - - Objects are activated with following functions: - - int px_find_digest(const char *name, PX_MD **res); - int px_find_hmac(const char *name, PX_HMAC **res); - int px_find_cipher(const char *name, PX_Cipher **res); - int px_find_combo(const char *name, PX_Combo **res); - - returns 0 on success, < 0 on error. If successful, - *res contains pointer to new object. - - Message Digest - == - - uint px_md_result_size(PX_MD *md) - - returns final result size in bytes - - void px_md_reset(PX_MD *md) - - resets md to clean state - - uint px_md_block_size(PX_MD *md) - - return algorithm block size in bytes - - void px_md_update(PX_MD *md, const uint8 *data, uint dlen) - - updates hash state with new data - - void px_md_finish(PX_MD *md, uint8 *buf) - - puts final hash state into buf. buf should have room - for px_md_result_size() bytes. - - void px_md_free(PX_MD *md) - - frees resources. - - HMAC (Hash Message Authentication Code) - === - - int px_hmac_init(PX_HMAC *hmac, const uint8 *key, uint klen) - - initalized hmac state with key. - - uint px_hmac_result_size(PX_HMAC *md) - - returns final result size in bytes - - void px_hmac_reset(PX_HMAC *md) - - resets md to state after _init() - - uint px_hmac_block_size(PX_HMAC *md) - - return algorithm block size in bytes - - void px_hmac_update(PX_HMAC *md, const uint8 *data, uint dlen) - - updates hash state with new data - - void px_hmac_finish(PX_HMAC *md, uint8 *buf) - - puts final hash state into buf. buf should have room - for px_hmac_result_size() bytes. - - void px_hmac_free(PX_HMAC *md) - - frees resources. - - - Cipher - == - - uint px_cipher_key_size(PX_Cipher *c) - - returns max key size in bytes - - uint px_cipher_block_size(PX_Cipher *c) - - returns cipher+mode block size in bytes. So blowfish - in CFB mode should return 1. - - uint px_cipher_iv_size(PX_Cipher *c) - - returns IV size in bytes. - - int px_cipher_init(PX_Cipher *c, uint8 *key, uint klen, uint8 *iv) - - initializes cipher with supplied key and iv. - - int px_cipher_encrypt(PX_Cipher *c, uint8 *data, uint dlen, uint8 *res) - - encrypts data. res must have room for dlen bytes. - data must be multiple of px_cipher_block_size(). - - int px_cipher_decrypt(PX_Cipher *c, uint8 *data, uint dlen, uint8 *res) - - decrypts data. res must have room for dlen bytes. - - void px_cipher_free(PX_Cipher *c) - - frees resources assiocated. - - PX_Combo - - - uint px_combo_encrypt_len(PX_Combo *c, uint dlen) - - calculates max result length for dlen of data. - - uint px_combo_decrypt_len(PX_Combo *c, uint dlen) - - calculates result length for dlen of data. - - int px_combo_init(PX_Combo *c, uint8 *key, uint klen, uint8 *iv, uint ivlen) - - initializes c with key and iv. If cipher uses fixed length keys, - key will be padded with zeroes to needed length. - - int px_combo_encrypt(PX_Combo *c, uint8 *data, uint dlen, uint8 *res, uint rlen) - - int px_combo_decrypt(PX_Combo *c, uint8 *data, uint dlen, uint8 *res, uint rlen) - - void px_combo_free(PX_Combo *c) - - frees resources assiocated. - --- 0 -- ---(end
[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
***
[PATCHES] [patch 0/7] more patches for pgcrypto
Here are couple of small and one large patch for pgcrypto. The large one adds support for RSA keys and reorganizes the pubkey functions a bit. The actual RSA-specific code there is tiny, most of the patch consists of reorg of the pubkey code, as lots of it was written as elgamal-only. -- marko ---(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 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 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 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_KE
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
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] ALTER OBJECT SET SCHEMA
--On Donnerstag, Juli 28, 2005 23:12:37 -0400 Bruce Momjian 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] per user/database connections limit again
Bruce Momjian 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] [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
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] per user/database connections limit again
Peter Eisentraut wrote: > Am Montag, 25. Juli 2005 18:31 schrieb Tom Lane: > > Bruce Momjian 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] [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] [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
> -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] 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] 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 () "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
[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] per user/database connections limit again
Am Montag, 25. Juli 2005 18:31 schrieb Tom Lane: > Bruce Momjian 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
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] [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
