hcq/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2026-04-06 03:38:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

Commit Graph

  • c8f345024d New wording, "What is the upgrade process for PostgreSQL?" Bruce Momjian 2006-05-23 15:51:07 +00:00
  • 4fc6aa4bc2 Update heading for upgrades. Bruce Momjian 2006-05-23 15:47:43 +00:00
  • 0f9652848b Add mention that everyone should upgrade to minor releases. Bruce Momjian 2006-05-23 15:22:20 +00:00
  • 798e63ffb0 Remove CXT_printf/CXT1_printf macros. If anyone had found them to be of any use in the past many years, we'd have made some effort to include them in all executor node types; but in fact they were only in nodeAppend.c and nodeIndexscan.c, up until I copied nodeIndexscan.c's occurrence into the new bitmap node types. Remove some other unused macros in execdebug.h, too. Some day the whole header probably ought to go away in favor of better-designed facilities. Tom Lane 2006-05-23 15:21:52 +00:00
  • 74d0cf3974 Make "trigger" section: Bruce Momjian 2006-05-22 20:39:23 +00:00
  • 32bfb1c297 Update Japanese FAQ. Bruce Momjian 2006-05-22 14:12:55 +00:00
  • 9da6508e0a Change \; to ; in RULE, \; unnecessary. Bruce Momjian 2006-05-22 14:08:06 +00:00
  • 79e371037b Add strerror to pg_dump error messages where missing. Peter Eisentraut 2006-05-22 11:21:54 +00:00
  • edec862bb6 Costmetic fix for bug template version stamp. Bruce Momjian 2006-05-22 01:34:20 +00:00
  • e675978ff5 Stamp release 7.3.15. REL7_3_15 Tom Lane 2006-05-21 21:54:31 +00:00
  • 82f56fad31 Stamp release 7.4.13. REL7_4_13 Tom Lane 2006-05-21 21:54:02 +00:00
  • f39fc4769e Stamp release 8.0.8. REL8_0_8 Tom Lane 2006-05-21 21:53:31 +00:00
  • 313a720f95 Stamp release 8.1.4. REL8_1_4 Tom Lane 2006-05-21 21:52:58 +00:00
  • 78e237e1e3 Update release notes for upcoming releases. Tom Lane 2006-05-21 21:50:14 +00:00
  • d6a74fe494 Update release notes for upcoming releases. Tom Lane 2006-05-21 21:50:02 +00:00
  • e35c0aee33 Update release notes for upcoming releases. Tom Lane 2006-05-21 21:49:50 +00:00
  • 3f6b5e21c8 Update release notes for upcoming releases. Tom Lane 2006-05-21 21:49:38 +00:00
  • e9cc53025a Update release notes for upcoming releases. Tom Lane 2006-05-21 21:49:22 +00:00
  • 6450cee473 Fix missed \' to '' conversion. Tom Lane 2006-05-21 21:13:50 +00:00
  • c6aa53e8d6 Remove mention of pg_upgrade in release checklist. Bruce Momjian 2006-05-21 20:29:16 +00:00
  • 29dd673a94 Stamp releases 7.3.15, 7.4.13, and 8.0.8. Bruce Momjian 2006-05-21 20:28:35 +00:00
  • 5421969f72 Stamp releases 7.3.15, 7.4.13, and 8.0.8. Bruce Momjian 2006-05-21 20:28:26 +00:00
  • 502b68876c Stamp releases 7.3.15, 7.4.13, and 8.0.8. Bruce Momjian 2006-05-21 20:28:22 +00:00
  • dd2a4ce6ac Fix errors in fortuna PRNG reseeding logic that could cause a predictable session key to be selected by pgp_sym_encrypt() in some cases. This only affects non-OpenSSL-using builds. Marko Kreen Tom Lane 2006-05-21 20:22:23 +00:00
  • 5cf07901c5 Fix errors in fortuna PRNG reseeding logic that could cause a predictable session key to be selected by pgp_sym_encrypt() in some cases. This only affects non-OpenSSL-using builds. Marko Kreen Tom Lane 2006-05-21 20:22:16 +00:00
  • e6f43f7786 Modify libpq's string-escaping routines to be aware of encoding considerations and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Tom Lane 2006-05-21 20:20:48 +00:00
  • 96871fc236 Modify libpq's string-escaping routines to be aware of encoding considerations and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Tom Lane 2006-05-21 20:20:24 +00:00
  • 94dec9114b Modify libpq's string-escaping routines to be aware of encoding considerations and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Tom Lane 2006-05-21 20:20:05 +00:00
  • 7f615cab57 Modify libpq's string-escaping routines to be aware of encoding considerations and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Tom Lane 2006-05-21 20:19:44 +00:00
  • 515112f9d4 Modify libpq's string-escaping routines to be aware of encoding considerations and standard_conforming_strings. The encoding changes are needed for proper escaping in multibyte encodings, as per the SQL-injection vulnerabilities noted in CVE-2006-2313 and CVE-2006-2314. Concurrent fixes are being applied to the server to ensure that it rejects queries that may have been corrupted by attempted SQL injection, but this merely guarantees that unpatched clients will fail rather than allow injection. An actual fix requires changing the client-side code. While at it we have also fixed these routines to understand about standard_conforming_strings, so that the upcoming changeover to SQL-spec string syntax can be somewhat transparent to client code. Tom Lane 2006-05-21 20:19:23 +00:00
  • 16e77740ea Add a new GUC parameter backslash_quote, which determines whether the SQL parser will allow "\'" to be used to represent a literal quote mark. The "\'" representation has been deprecated for some time in favor of the SQL-standard representation "''" (two single quote marks), but it has been used often enough that just disallowing it immediately won't do. Hence backslash_quote allows the settings "on", "off", and "safe_encoding", the last meaning to allow "\'" only if client_encoding is a valid server encoding. That is now the default, and the reason is that in encodings such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a multibyte character, accepting "\'" allows SQL-injection attacks as per CVE-2006-2314 (further details will be published after release). The "on" setting is available for backward compatibility, but it must not be used with clients that are exposed to untrusted input. Tom Lane 2006-05-21 20:12:20 +00:00
  • 2e319b0e40 Add a new GUC parameter backslash_quote, which determines whether the SQL parser will allow "\'" to be used to represent a literal quote mark. The "\'" representation has been deprecated for some time in favor of the SQL-standard representation "''" (two single quote marks), but it has been used often enough that just disallowing it immediately won't do. Hence backslash_quote allows the settings "on", "off", and "safe_encoding", the last meaning to allow "\'" only if client_encoding is a valid server encoding. That is now the default, and the reason is that in encodings such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a multibyte character, accepting "\'" allows SQL-injection attacks as per CVE-2006-2314 (further details will be published after release). The "on" setting is available for backward compatibility, but it must not be used with clients that are exposed to untrusted input. Tom Lane 2006-05-21 20:11:58 +00:00
  • 9bc62ddd5f Add a new GUC parameter backslash_quote, which determines whether the SQL parser will allow "\'" to be used to represent a literal quote mark. The "\'" representation has been deprecated for some time in favor of the SQL-standard representation "''" (two single quote marks), but it has been used often enough that just disallowing it immediately won't do. Hence backslash_quote allows the settings "on", "off", and "safe_encoding", the last meaning to allow "\'" only if client_encoding is a valid server encoding. That is now the default, and the reason is that in encodings such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a multibyte character, accepting "\'" allows SQL-injection attacks as per CVE-2006-2314 (further details will be published after release). The "on" setting is available for backward compatibility, but it must not be used with clients that are exposed to untrusted input. Tom Lane 2006-05-21 20:11:25 +00:00
  • 3d4dc1acf5 Add a new GUC parameter backslash_quote, which determines whether the SQL parser will allow "\'" to be used to represent a literal quote mark. The "\'" representation has been deprecated for some time in favor of the SQL-standard representation "''" (two single quote marks), but it has been used often enough that just disallowing it immediately won't do. Hence backslash_quote allows the settings "on", "off", and "safe_encoding", the last meaning to allow "\'" only if client_encoding is a valid server encoding. That is now the default, and the reason is that in encodings such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a multibyte character, accepting "\'" allows SQL-injection attacks as per CVE-2006-2314 (further details will be published after release). The "on" setting is available for backward compatibility, but it must not be used with clients that are exposed to untrusted input. Tom Lane 2006-05-21 20:11:02 +00:00
  • b3eb4ea5d8 Add a new GUC parameter backslash_quote, which determines whether the SQL parser will allow "\'" to be used to represent a literal quote mark. The "\'" representation has been deprecated for some time in favor of the SQL-standard representation "''" (two single quote marks), but it has been used often enough that just disallowing it immediately won't do. Hence backslash_quote allows the settings "on", "off", and "safe_encoding", the last meaning to allow "\'" only if client_encoding is a valid server encoding. That is now the default, and the reason is that in encodings such as SJIS that allow 0x5c (ASCII backslash) to be the last byte of a multibyte character, accepting "\'" allows SQL-injection attacks as per CVE-2006-2314 (further details will be published after release). The "on" setting is available for backward compatibility, but it must not be used with clients that are exposed to untrusted input. Tom Lane 2006-05-21 20:10:42 +00:00
  • 5c4de67044 Change the backend to reject strings containing invalidly-encoded multibyte characters in all cases. Formerly we mostly just threw warnings for invalid input, and failed to detect it at all if no encoding conversion was required. The tighter check is needed to defend against SQL-injection attacks as per CVE-2006-2313 (further details will be published after release). Embedded zero (null) bytes will be rejected as well. The checks are applied during input to the backend (receipt from client or COPY IN), so it no longer seems necessary to check in textin() and related routines; any string arriving at those functions will already have been validated. Conversion failure reporting (for characters with no equivalent in the destination encoding) has been cleaned up and made consistent while at it. Tom Lane 2006-05-21 20:07:13 +00:00
  • b252352241 Change the backend to reject strings containing invalidly-encoded multibyte characters in all cases. Formerly we mostly just threw warnings for invalid input, and failed to detect it at all if no encoding conversion was required. The tighter check is needed to defend against SQL-injection attacks as per CVE-2006-2313 (further details will be published after release). Embedded zero (null) bytes will be rejected as well. The checks are applied during input to the backend (receipt from client or COPY IN), so it no longer seems necessary to check in textin() and related routines; any string arriving at those functions will already have been validated. Conversion failure reporting (for characters with no equivalent in the destination encoding) has been cleaned up and made consistent while at it. Tom Lane 2006-05-21 20:06:45 +00:00
  • 70794254a1 Change the backend to reject strings containing invalidly-encoded multibyte characters in all cases. Formerly we mostly just threw warnings for invalid input, and failed to detect it at all if no encoding conversion was required. The tighter check is needed to defend against SQL-injection attacks as per CVE-2006-2313 (further details will be published after release). Embedded zero (null) bytes will be rejected as well. The checks are applied during input to the backend (receipt from client or COPY IN), so it no longer seems necessary to check in textin() and related routines; any string arriving at those functions will already have been validated. Conversion failure reporting (for characters with no equivalent in the destination encoding) has been cleaned up and made consistent while at it. Tom Lane 2006-05-21 20:06:18 +00:00
  • 8fe643b41b Change the backend to reject strings containing invalidly-encoded multibyte characters in all cases. Formerly we mostly just threw warnings for invalid input, and failed to detect it at all if no encoding conversion was required. The tighter check is needed to defend against SQL-injection attacks as per CVE-2006-2313 (further details will be published after release). Embedded zero (null) bytes will be rejected as well. The checks are applied during input to the backend (receipt from client or COPY IN), so it no longer seems necessary to check in textin() and related routines; any string arriving at those functions will already have been validated. Conversion failure reporting (for characters with no equivalent in the destination encoding) has been cleaned up and made consistent while at it. Tom Lane 2006-05-21 20:05:50 +00:00
  • c61a2f5841 Change the backend to reject strings containing invalidly-encoded multibyte characters in all cases. Formerly we mostly just threw warnings for invalid input, and failed to detect it at all if no encoding conversion was required. The tighter check is needed to defend against SQL-injection attacks as per CVE-2006-2313 (further details will be published after release). Embedded zero (null) bytes will be rejected as well. The checks are applied during input to the backend (receipt from client or COPY IN), so it no longer seems necessary to check in textin() and related routines; any string arriving at those functions will already have been validated. Conversion failure reporting (for characters with no equivalent in the destination encoding) has been cleaned up and made consistent while at it. Tom Lane 2006-05-21 20:05:21 +00:00
  • 833e84621c Change \' to '', for SQL standards compliance. Backpatch to 7.3, 7.4, and 8.0. Later releases already patched. Bruce Momjian 2006-05-21 19:57:40 +00:00
  • 48498602a0 Change \' to '', for SQL standards compliance. Backpatch to 7.3, 7.4, and 8.0. Later releases already patched. Bruce Momjian 2006-05-21 19:57:07 +00:00
  • 583a472f7b Change \' to '', for SQL standards compliance. Backpatch to 7.3, 7.4, and 8.0. Later releases already patched. Bruce Momjian 2006-05-21 19:56:41 +00:00
  • 1f219cf433 Add last-vacuum/analyze-time columns to the stats collector, both manual and issued by autovacuum. Add accessor functions to them, and use those in the pg_stat_*_tables system views. Alvaro Herrera 2006-05-19 19:08:27 +00:00
  • 09518fbdf4 Call MarkBufferDirty() before XLogInsert() during completion of insert Teodor Sigaev 2006-05-19 17:15:41 +00:00
  • c8fd45b059 Fix nasty bug in nodeIndexscan.c's detection of duplicate tuples during a multiple (OR'ed) indexscan. It was checking for duplicate tuple->t_data->t_ctid, when what it should be checking is tuple->t_self. The trouble situation occurs when a live tuple has t_ctid not pointing to itself, which can happen if an attempted UPDATE was rolled back. After a VACUUM, an unrelated tuple could be installed where the failed update tuple was, leading to one live tuple's t_ctid pointing to an unrelated tuple. If one of these tuples is fetched by an earlier OR'ed indexscan and the other by a later indexscan, nodeIndexscan.c would incorrectly ignore the second tuple. The bug exists in all 7.4.* and 8.0.* versions, but not in earlier or later branches because this code was only used in those releases. Per trouble report from Rafael Martinez Guerrero. Tom Lane 2006-05-19 16:31:05 +00:00
  • a2e7036909 Fix nasty bug in nodeIndexscan.c's detection of duplicate tuples during a multiple (OR'ed) indexscan. It was checking for duplicate tuple->t_data->t_ctid, when what it should be checking is tuple->t_self. The trouble situation occurs when a live tuple has t_ctid not pointing to itself, which can happen if an attempted UPDATE was rolled back. After a VACUUM, an unrelated tuple could be installed where the failed update tuple was, leading to one live tuple's t_ctid pointing to an unrelated tuple. If one of these tuples is fetched by an earlier OR'ed indexscan and the other by a later indexscan, nodeIndexscan.c would incorrectly ignore the second tuple. The bug exists in all 7.4.* and 8.0.* versions, but not in earlier or later branches because this code was only used in those releases. Per trouble report from Rafael Martinez Guerrero. Tom Lane 2006-05-19 16:30:50 +00:00
  • 420cbff881 Simplify gistSplit() and some refactoring related code. Teodor Sigaev 2006-05-19 16:15:17 +00:00
  • e5ab52b273 Have autovacuum report its activities to the stat collector. Alvaro Herrera 2006-05-19 15:15:38 +00:00
  • 49b3462abb Have autovacuum report its activities to the stat collector. Alvaro Herrera 2006-05-19 15:15:37 +00:00
  • 4adab7eed3 Fix typo in comment. Alvaro Herrera 2006-05-19 14:26:58 +00:00
  • b125d4b0ca Fix Solaris/ASM test for x86. Bruce Momjian 2006-05-19 13:10:11 +00:00
  • 5890790b4a Rework completion of incomplete inserts. Now it writes WAL log during inserts. Teodor Sigaev 2006-05-19 11:10:25 +00:00
  • 3a3622c5f0 Back out \' change for tsearch2, broke regression tests. Bruce Momjian 2006-05-19 04:41:06 +00:00
  • 19892feb3c Back out \' change for tsearch2, broke regression tests. Bruce Momjian 2006-05-19 04:39:47 +00:00
  • e720382441 Stamp 8.1.4, except configure/configure.in. Bruce Momjian 2006-05-19 03:57:17 +00:00
  • 7d866ffad7 Mention packager bumps configure.in/configure. Bruce Momjian 2006-05-19 03:57:09 +00:00
  • 411a64ba73 Stamp 8.1.4, except configure/configure.in. Bruce Momjian 2006-05-19 03:55:40 +00:00
  • ba10a1f3e4 Update for version 8.1.4. Bruce Momjian 2006-05-19 03:52:41 +00:00
  • 289f10c809 Update release notes for 8.1.4. Bruce Momjian 2006-05-19 03:50:07 +00:00
  • 7540476dc6 Update release notes for 8.1.4. Bruce Momjian 2006-05-19 03:49:05 +00:00
  • 95d8b6a7b4 Backpatch FAQs to 8.1.X. Bruce Momjian 2006-05-19 03:34:49 +00:00
  • 9a27f72b37 Use SQL standard '' rather than \' in /contrib. Backpatch to 8.1.X. Bruce Momjian 2006-05-19 02:39:04 +00:00
  • cc84163fa9 Use SQL standard '' rather than \' in /contrib. Backpatch to 8.1.X. Bruce Momjian 2006-05-19 02:38:47 +00:00
  • 40a95aa25b Use unsigned into for slock_t for pre-sparcv8plus. Bruce Momjian 2006-05-18 21:18:40 +00:00
  • 1c01a5108a Fix choose_bitmap_and() so that partial index predicates are considered when deciding whether a potential additional indexscan is redundant or not. As now coded, any use of a partial index that was already used in a previous AND arm will be rejected as redundant. This might be overly restrictive, but not considering the point at all is definitely bad, as per example in bug #2441 from Arjen van der Meijden. In particular, a clauseless scan of a partial index was *never* considered redundant by the previous coding, and that's surely wrong. Being more flexible would also require some consideration of how not to double-count the index predicate's selectivity. Tom Lane 2006-05-18 19:56:56 +00:00
  • eed57b1b92 Fix choose_bitmap_and() so that partial index predicates are considered when deciding whether a potential additional indexscan is redundant or not. As now coded, any use of a partial index that was already used in a previous AND arm will be rejected as redundant. This might be overly restrictive, but not considering the point at all is definitely bad, as per example in bug #2441 from Arjen van der Meijden. In particular, a clauseless scan of a partial index was *never* considered redundant by the previous coding, and that's surely wrong. Being more flexible would also require some consideration of how not to double-count the index predicate's selectivity. Tom Lane 2006-05-18 19:56:46 +00:00
  • 59ca5ebf2c When a bitmap indexscan is using a partial index, it is necessary to include the partial index predicate in the scan's "recheck condition". Otherwise, if the scan becomes lossy for lack of bitmap memory, we would fail to enforce that returned rows satisfy the predicate. Noted while studying bug #2441 from Arjen van der Meijden. Tom Lane 2006-05-18 18:57:37 +00:00
  • f323252642 When a bitmap indexscan is using a partial index, it is necessary to include the partial index predicate in the scan's "recheck condition". Otherwise, if the scan becomes lossy for lack of bitmap memory, we would fail to enforce that returned rows satisfy the predicate. Noted while studying bug #2441 from Arjen van der Meijden. Tom Lane 2006-05-18 18:57:31 +00:00
  • 8d988c7d1c Allow sparcv8plus to use "cas". Bruce Momjian 2006-05-18 18:51:50 +00:00
  • d8f940f281 Code alignment fix. Bruce Momjian 2006-05-18 18:19:47 +00:00
  • d18e334c65 Fix thinko in recent changes to handle ScalarArrayOpExpr as an indexable condition: when there are multiple possible index paths involving ScalarArrayOpExprs, they are logically to be ANDed together not ORed. This thinko was a direct consequence of trying to put the processing inside generate_bitmap_or_paths(), which I now see was a bit too cute. So pull it out and make the callers do it separately (there are only two that need it anyway). Partially responds to bug #2441 from Arjen van der Meijden. There are some additional infelicities exposed by his example, but they are also in 8.1.x, while this mistake is not. Tom Lane 2006-05-18 17:12:10 +00:00
  • d0f9ca34bd Remove canonicalize_path() call for .pgpass socket directory comparison; not worth adding path.c to libpq. Bruce Momjian 2006-05-18 16:26:44 +00:00
  • 0622821853 Mention that gcc/sparc generates sparcv7 binaries. Bruce Momjian 2006-05-18 16:02:30 +00:00
  • 45ec63cb24 Change <type>string</> to <parameter>string</>. Bruce Momjian 2006-05-18 03:18:24 +00:00
  • e6bd9bf7ff Add: Bruce Momjian 2006-05-18 02:32:15 +00:00
  • 3c5665d088 Add more sparcv8plus comments. Bruce Momjian 2006-05-18 01:06:28 +00:00
  • d6a35c8125 Make function param_name/type documentation more consistent. Bruce Momjian 2006-05-18 00:50:08 +00:00
  • 554608d92c Add mention of -xarch=v8plus for "cas" usage on Solaris/sparc. Bruce Momjian 2006-05-18 00:44:29 +00:00
  • 924b9d62b4 Add simplified sparc8 ASM for solaris_sparc.s, from Alan Stange. Bruce Momjian 2006-05-18 00:05:01 +00:00
  • 407885ea3b Add comments that Solaris Sun compiler only supports sparc9 ASM, Bruce Momjian 2006-05-17 23:57:03 +00:00
  • 0d02ef4be4 Change spaces to tabs, for consistency. (Caused by email cut/paste.) Bruce Momjian 2006-05-17 22:06:19 +00:00
  • 18627c5531 Allow the .pgpass hostname to match the default socket directory, as well as a blank pghost. Bruce Momjian 2006-05-17 21:50:54 +00:00
  • 7123349254 Change catalog version due to WAL protocol changes in GiST Teodor Sigaev 2006-05-17 16:37:06 +00:00
  • 8876e37d07 Reduce size of critial section during vacuum full, critical sections now isn't nested. All user-defined functions now is called outside critsections. Small improvements in WAL protocol. Teodor Sigaev 2006-05-17 16:34:59 +00:00
  • 815f58407c Rename macro parameter, for clarity. Bruce Momjian 2006-05-17 01:44:24 +00:00
  • 4aec5303f0 Update pg_dump version wording. Bruce Momjian 2006-05-13 17:11:02 +00:00
  • fb4c180da0 Update pg_dump vesion wording. Bruce Momjian 2006-05-13 17:10:35 +00:00
  • dfc2fc2522 Mention version portability of pg_dump. Bruce Momjian 2006-05-13 16:20:21 +00:00
  • 4b7b1df8a6 Mention version portability of pg_dump. Bruce Momjian 2006-05-13 16:19:54 +00:00
  • 506747337b Fix the sense of the test on DH_check()'s return value. This was preventing custom-generated DH parameters from actually being used by the server. Found by Michael Fuhr. Tom Lane 2006-05-12 22:45:06 +00:00
  • c5c3d8c6db Fix the sense of the test on DH_check()'s return value. This was preventing custom-generated DH parameters from actually being used by the server. Found by Michael Fuhr. Tom Lane 2006-05-12 22:44:58 +00:00
  • f939bdcafe Fix the sense of the test on DH_check()'s return value. This was preventing custom-generated DH parameters from actually being used by the server. Found by Michael Fuhr. Tom Lane 2006-05-12 22:44:50 +00:00
  • 17e048603c Fix the sense of the test on DH_check()'s return value. This was preventing custom-generated DH parameters from actually being used by the server. Found by Michael Fuhr. Tom Lane 2006-05-12 22:44:43 +00:00
  • 91d568e9bb Fix the sense of the test on DH_check()'s return value. This was preventing custom-generated DH parameters from actually being used by the server. Found by Michael Fuhr. Tom Lane 2006-05-12 22:44:36 +00:00
  • 2246e31775 Upon closer inspection, the sparc code in s_lock.c is dead code, and always has been, because it's not got any .globl declaration! We've been relying on the solaris_sparc.s code instead. Rip it out. (Not back-patched, since this is just cosmetic cleanup.) Tom Lane 2006-05-12 16:50:52 +00:00
  • ce84b24c48 Fix typo in comment. Bruce Momjian 2006-05-11 23:27:35 +00:00
  • 76dc24091f Remove unnecessary .seg/.section directives, per Alan Stange. Tom Lane 2006-05-11 22:00:12 +00:00
  • d4ec87c267 Remove unnecessary .seg/.section directives, per Alan Stange. Tom Lane 2006-05-11 21:59:47 +00:00
  • e9c56ce5e9 Remove unnecessary .seg/.section directives, per Alan Stange. Tom Lane 2006-05-11 21:58:37 +00:00