| HEAD | 6ed83d5 | Use bump memory context for tuplesorts 29f6a959c added a bump allocator type for efficient compact allocations. Here we make use of this for non-bounded tuplesorts to store tuples. This is very space efficient when storing narrow tuples due to bump.c not having chunk headers. This means we can fit more tuples in work_mem before spilling to disk, or perform an in-memory sort touching fewer cacheline. Author: David Rowley Reviewed-by: Nathan Bossart Reviewed-by: Matthias van de Meent Reviewed-by: Tomas Vondra Reviewed-by: John Naylor Discussion: https://postgr.es/m/CAApHDvqGSpCU95TmM=Bp=6xjL_nLys4zdZOpfNyWBk97Xrdj2w@mail.gmail.com | 07 April 2024, 12:32:26 UTC |
| refs/heads/REL2_0B | 676e3c7 | Here's a little patch to keep the compiler quiet when compiling PostgreSQL V6.0 on the SPARC Solaris2 platform. Submitted by: Keith Parks <emkxp01@mtcc.demon.co.uk> | 22 December 1996, 03:28:25 UTC |
| refs/heads/REL6_4 | 2ecbf94 | Retrofit hashtable and shared-mem-size-estimation bug fixes into REL6_4. | 07 March 1999, 02:01:09 UTC |
| refs/heads/REL6_5_PATCHES | 21f0db9 | Back-patch critical fixes for NUMERIC values in plpgsql functions. | 16 January 2000, 00:45:33 UTC |
| refs/heads/REL7_0_PATCHES | 1a604c3 | Back-patch password leak fix for Vaschenko. | 07 February 2001, 23:42:27 UTC |
| refs/heads/REL7_1_STABLE | 1af623c | Remove stray semicolons in old ecpg preproc grammar ... modern bison versions won't compile it at all with those there. Probably of only academic interest now, but ... | 13 October 2004, 22:09:20 UTC |
| refs/heads/REL7_2_STABLE | f47f4be | Remove registration message in all the supported back branches; we had decided to drop it for 7.4, and no one misses it. | 16 August 2005, 03:33:39 UTC |
| refs/heads/REL7_3_STABLE | c3f8e03 | Check to ensure the number of primary key fields supplied does not exceed the total number of non-dropped source table fields for dblink_build_sql_*(). Addresses bug report from Rushabh Lathia. Backpatch all the way to the 7.3 branch. | 03 February 2010, 23:02:39 UTC |
| refs/heads/REL7_4_STABLE | fd7fdbc | Tag 7.4.30 | 01 October 2010, 13:40:30 UTC |
| refs/heads/REL8_0_STABLE | c689dac | Tag 8.0.26 | 01 October 2010, 13:39:44 UTC |
| refs/heads/REL8_1_STABLE | b196a71 | Tag 8.1.23. | 14 December 2010, 03:52:30 UTC |
| refs/heads/REL8_2_STABLE | 105f3ef | Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches. With this optimization flag enabled, recent versions of gcc can generate incorrect code that assumes variable-length arrays (such as oidvector) are actually fixed-length because they're embedded in some larger struct. The known instance of this problem was fixed in 9.2 and up by commit 8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides actually-variable-length catalog fields from the compiler altogether. And we plan to gradually convert variable-length fields to official "flexible array member" notation over time, which should prevent this type of bug from reappearing as gcc gets smarter. We're not going to try to back-port those changes into older branches, though, so apply this band-aid instead. Andres Freund This is a backpatch of commit 649839dd9 to unsupported branches REL8_2_STABLE and REL8_3_STABLE, so that they work with newer toolsets. | 20 January 2015, 15:26:20 UTC |
| refs/heads/REL8_3_STABLE | d13f41d | Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches. With this optimization flag enabled, recent versions of gcc can generate incorrect code that assumes variable-length arrays (such as oidvector) are actually fixed-length because they're embedded in some larger struct. The known instance of this problem was fixed in 9.2 and up by commit 8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides actually-variable-length catalog fields from the compiler altogether. And we plan to gradually convert variable-length fields to official "flexible array member" notation over time, which should prevent this type of bug from reappearing as gcc gets smarter. We're not going to try to back-port those changes into older branches, though, so apply this band-aid instead. Andres Freund This is a backpatch of commit 649839dd9 to unsupported branches REL8_2_STABLE and REL8_3_STABLE, so that they work with newer toolsets. | 20 January 2015, 15:26:20 UTC |
| refs/heads/REL8_4_STABLE | 8dd3875 | Stamp 8.4.22. | 21 July 2014, 19:18:03 UTC |
| refs/heads/REL8_5_ALPHA1_BRANCH | 5dfe321 | Version stamp 8.5alpha1 | 19 August 2009, 08:28:51 UTC |
| refs/heads/REL8_5_ALPHA2_BRANCH | b4f1a6c | Version stamp 8.5alpha2 | 21 October 2009, 19:56:21 UTC |
| refs/heads/REL8_5_ALPHA3_BRANCH | af7bab7 | Version stamp 8.5alpha3 | 20 December 2009, 07:31:43 UTC |
| refs/heads/REL9_0_ALPHA4_BRANCH | 3ba6a3c | Version stamp 9.0alpha4 (in the right branch) | 19 February 2010, 18:43:31 UTC |
| refs/heads/REL9_0_ALPHA5_BRANCH | 3403150 | Version stamp 9.0alpha5. | 01 April 2010, 01:46:31 UTC |
| refs/heads/REL9_0_STABLE | 9a42e85 | Stamp 9.0.23. | 05 October 2015, 19:19:44 UTC |
| refs/heads/REL9_1_STABLE | e854935 | Stamp 9.1.24. | 24 October 2016, 20:19:49 UTC |
| refs/heads/REL9_2_STABLE | 4c1f42f | Keep perl style checker happy It doesn't like code before "use strict;". (cherry picked from commit ed2c2d063bd110f299211611b72a5dbe07a4d7be) | 05 February 2019, 20:16:55 UTC |
| refs/heads/REL9_3_STABLE | 5244405 | Keep perl style checker happy It doesn't like code before "use strict;". (cherry picked from commit ed2c2d063bd110f299211611b72a5dbe07a4d7be) | 05 February 2019, 20:16:55 UTC |
| refs/heads/REL9_4_STABLE | 4bcf352 | Create common infrastructure for cross-version upgrade testing. To test pg_upgrade across major PG versions, we have to be able to modify or drop any old objects with no-longer-supported properties, and we have to be able to deal with cosmetic changes in pg_dump output. Up to now, the buildfarm and pg_upgrade's own test infrastructure had separate implementations of the former, and we had nothing but very ad-hoc rules for the latter (including an arbitrary threshold on how many lines of unchecked diff were okay!). This patch creates a Perl module that can be shared by both those use-cases, and adds logic that deals with pg_dump output diffs in a much more tightly defined fashion. This largely supersedes previous efforts in commits 0df9641d3, 9814ff550, and 62be9e4cd, which developed a SQL-script-based solution for the task of dropping old objects. There was nothing fundamentally wrong with that work in itself, but it had no basis for solving the output-formatting problem. The most plausible way to deal with formatting is to build a Perl module that can perform editing on the dump files; and once we commit to that, it makes more sense for the same module to also embed the knowledge of what has to be done for dropping old objects. Back-patch versions of the helper module as far as 9.2, to support buildfarm animals that still test that far back. It's also necessary to back-patch PostgreSQL/Version.pm, because the new code depends on that. I fixed up pg_upgrade's 002_pg_upgrade.pl in v15, but did not look into back-patching it further than that. Tom Lane and Andrew Dunstan Discussion: https://postgr.es/m/891521.1673657296@sss.pgh.pa.us | 17 January 2023, 01:35:53 UTC |
| refs/heads/REL9_5_STABLE | bfa3d27 | Create common infrastructure for cross-version upgrade testing. To test pg_upgrade across major PG versions, we have to be able to modify or drop any old objects with no-longer-supported properties, and we have to be able to deal with cosmetic changes in pg_dump output. Up to now, the buildfarm and pg_upgrade's own test infrastructure had separate implementations of the former, and we had nothing but very ad-hoc rules for the latter (including an arbitrary threshold on how many lines of unchecked diff were okay!). This patch creates a Perl module that can be shared by both those use-cases, and adds logic that deals with pg_dump output diffs in a much more tightly defined fashion. This largely supersedes previous efforts in commits 0df9641d3, 9814ff550, and 62be9e4cd, which developed a SQL-script-based solution for the task of dropping old objects. There was nothing fundamentally wrong with that work in itself, but it had no basis for solving the output-formatting problem. The most plausible way to deal with formatting is to build a Perl module that can perform editing on the dump files; and once we commit to that, it makes more sense for the same module to also embed the knowledge of what has to be done for dropping old objects. Back-patch versions of the helper module as far as 9.2, to support buildfarm animals that still test that far back. It's also necessary to back-patch PostgreSQL/Version.pm, because the new code depends on that. I fixed up pg_upgrade's 002_pg_upgrade.pl in v15, but did not look into back-patching it further than that. Tom Lane and Andrew Dunstan Discussion: https://postgr.es/m/891521.1673657296@sss.pgh.pa.us | 17 January 2023, 01:35:53 UTC |
| refs/heads/REL9_6_STABLE | 3911fd5 | Create common infrastructure for cross-version upgrade testing. To test pg_upgrade across major PG versions, we have to be able to modify or drop any old objects with no-longer-supported properties, and we have to be able to deal with cosmetic changes in pg_dump output. Up to now, the buildfarm and pg_upgrade's own test infrastructure had separate implementations of the former, and we had nothing but very ad-hoc rules for the latter (including an arbitrary threshold on how many lines of unchecked diff were okay!). This patch creates a Perl module that can be shared by both those use-cases, and adds logic that deals with pg_dump output diffs in a much more tightly defined fashion. This largely supersedes previous efforts in commits 0df9641d3, 9814ff550, and 62be9e4cd, which developed a SQL-script-based solution for the task of dropping old objects. There was nothing fundamentally wrong with that work in itself, but it had no basis for solving the output-formatting problem. The most plausible way to deal with formatting is to build a Perl module that can perform editing on the dump files; and once we commit to that, it makes more sense for the same module to also embed the knowledge of what has to be done for dropping old objects. Back-patch versions of the helper module as far as 9.2, to support buildfarm animals that still test that far back. It's also necessary to back-patch PostgreSQL/Version.pm, because the new code depends on that. I fixed up pg_upgrade's 002_pg_upgrade.pl in v15, but did not look into back-patching it further than that. Tom Lane and Andrew Dunstan Discussion: https://postgr.es/m/891521.1673657296@sss.pgh.pa.us | 17 January 2023, 01:35:53 UTC |
| refs/heads/REL_10_STABLE | c18c12c | AdjustUpgrade.pm should zap test_ext_cine, too. test_extensions' test_ext_cine extension has the same upgrade hazard as test_ext7: the regression test leaves it in an updated state from which no downgrade path to default is provided. This causes the update_extensions.sql script helpfully provided by pg_upgrade to fail. So drop it in cross-version-upgrade testing. Not entirely sure how come I didn't hit this in testing yesterday; possibly I'd built the upgrade reference databases with testmodules-install-check disabled. Backpatch to v10 where this module was introduced. | 17 January 2023, 21:00:39 UTC |
| refs/heads/REL_11_STABLE | fd851f9 | Stamp 11.22. | 06 November 2023, 22:13:58 UTC |
| refs/heads/REL_12_STABLE | 360d007 | Fix ecpg's mechanism for detecting unsupported cases in the grammar. ecpg wants to emit a warning if it parses a SQL construct that the backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED error for. The way it was testing for this was to see if the string ERRCODE_FEATURE_NOT_SUPPORTED appeared anywhere in the gram.y code. This is, of course, not nearly good enough, as there are plenty of rules in gram.y that throw that error only conditionally. There was a hack dating to 2008 to suppress the warning in one rule that doesn't even exist anymore, but nothing for other cases we've created since then. End result was that you could get "unsupported feature will be passed to server" warnings while compiling perfectly good SQL code in ecpg. Somehow we'd not heard complaints about this, but it was exposed by the recent addition of an ecpg test for a SQL/JSON construct. To fix, suppress the warning if the rule contains any "if" statement. Manual comparison of gram.y with the generated preproc.y file shows that the warning is now emitted only in rules where it's sensible. This problem has existed for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/603615.1712245382@sss.pgh.pa.us | 04 April 2024, 19:31:53 UTC |
| refs/heads/REL_13_STABLE | 5ba29e9 | Fix ecpg's mechanism for detecting unsupported cases in the grammar. ecpg wants to emit a warning if it parses a SQL construct that the backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED error for. The way it was testing for this was to see if the string ERRCODE_FEATURE_NOT_SUPPORTED appeared anywhere in the gram.y code. This is, of course, not nearly good enough, as there are plenty of rules in gram.y that throw that error only conditionally. There was a hack dating to 2008 to suppress the warning in one rule that doesn't even exist anymore, but nothing for other cases we've created since then. End result was that you could get "unsupported feature will be passed to server" warnings while compiling perfectly good SQL code in ecpg. Somehow we'd not heard complaints about this, but it was exposed by the recent addition of an ecpg test for a SQL/JSON construct. To fix, suppress the warning if the rule contains any "if" statement. Manual comparison of gram.y with the generated preproc.y file shows that the warning is now emitted only in rules where it's sensible. This problem has existed for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/603615.1712245382@sss.pgh.pa.us | 04 April 2024, 19:31:53 UTC |
| refs/heads/REL_14_STABLE | d3167ed | Fix ecpg's mechanism for detecting unsupported cases in the grammar. ecpg wants to emit a warning if it parses a SQL construct that the backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED error for. The way it was testing for this was to see if the string ERRCODE_FEATURE_NOT_SUPPORTED appeared anywhere in the gram.y code. This is, of course, not nearly good enough, as there are plenty of rules in gram.y that throw that error only conditionally. There was a hack dating to 2008 to suppress the warning in one rule that doesn't even exist anymore, but nothing for other cases we've created since then. End result was that you could get "unsupported feature will be passed to server" warnings while compiling perfectly good SQL code in ecpg. Somehow we'd not heard complaints about this, but it was exposed by the recent addition of an ecpg test for a SQL/JSON construct. To fix, suppress the warning if the rule contains any "if" statement. Manual comparison of gram.y with the generated preproc.y file shows that the warning is now emitted only in rules where it's sensible. This problem has existed for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/603615.1712245382@sss.pgh.pa.us | 04 April 2024, 19:31:53 UTC |
| refs/heads/REL_15_STABLE | f159f18 | Fix ecpg's mechanism for detecting unsupported cases in the grammar. ecpg wants to emit a warning if it parses a SQL construct that the backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED error for. The way it was testing for this was to see if the string ERRCODE_FEATURE_NOT_SUPPORTED appeared anywhere in the gram.y code. This is, of course, not nearly good enough, as there are plenty of rules in gram.y that throw that error only conditionally. There was a hack dating to 2008 to suppress the warning in one rule that doesn't even exist anymore, but nothing for other cases we've created since then. End result was that you could get "unsupported feature will be passed to server" warnings while compiling perfectly good SQL code in ecpg. Somehow we'd not heard complaints about this, but it was exposed by the recent addition of an ecpg test for a SQL/JSON construct. To fix, suppress the warning if the rule contains any "if" statement. Manual comparison of gram.y with the generated preproc.y file shows that the warning is now emitted only in rules where it's sensible. This problem has existed for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/603615.1712245382@sss.pgh.pa.us | 04 April 2024, 19:31:53 UTC |
| refs/heads/REL_16_STABLE | 118558e | Fix ecpg's mechanism for detecting unsupported cases in the grammar. ecpg wants to emit a warning if it parses a SQL construct that the backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED error for. The way it was testing for this was to see if the string ERRCODE_FEATURE_NOT_SUPPORTED appeared anywhere in the gram.y code. This is, of course, not nearly good enough, as there are plenty of rules in gram.y that throw that error only conditionally. There was a hack dating to 2008 to suppress the warning in one rule that doesn't even exist anymore, but nothing for other cases we've created since then. End result was that you could get "unsupported feature will be passed to server" warnings while compiling perfectly good SQL code in ecpg. Somehow we'd not heard complaints about this, but it was exposed by the recent addition of an ecpg test for a SQL/JSON construct. To fix, suppress the warning if the rule contains any "if" statement. Manual comparison of gram.y with the generated preproc.y file shows that the warning is now emitted only in rules where it's sensible. This problem has existed for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/603615.1712245382@sss.pgh.pa.us | 04 April 2024, 19:31:53 UTC |
| refs/heads/Release_1_0_3 | 0748c1f | A small patch from Andrew for the linux port in v1.09 | 09 November 1996, 10:55:35 UTC |
| refs/heads/WIN32_DEV | 9cdea75 | Change Win32 rename/unlink timeout to 3 seconds. | 10 October 2003, 03:28:24 UTC |
| refs/heads/ecpg_big_bison | 0e25360 | Synced yet again. Deactivated backend prepare/execute/deallocate for the time being. | 20 September 2002, 06:19:07 UTC |
| refs/heads/master | 6ed83d5 | Use bump memory context for tuplesorts 29f6a959c added a bump allocator type for efficient compact allocations. Here we make use of this for non-bounded tuplesorts to store tuples. This is very space efficient when storing narrow tuples due to bump.c not having chunk headers. This means we can fit more tuples in work_mem before spilling to disk, or perform an in-memory sort touching fewer cacheline. Author: David Rowley Reviewed-by: Nathan Bossart Reviewed-by: Matthias van de Meent Reviewed-by: Tomas Vondra Reviewed-by: John Naylor Discussion: https://postgr.es/m/CAApHDvqGSpCU95TmM=Bp=6xjL_nLys4zdZOpfNyWBk97Xrdj2w@mail.gmail.com | 07 April 2024, 12:32:26 UTC |
| refs/tags/PG95-1_01 | d31084e | Postgres95 1.01 Distribution - Virgin Sources | 09 July 1996, 06:22:35 UTC |
| refs/tags/PG95-1_08 | bf3473c | Oops, wrong message with the other patch...this was the patch for the other comment, so here is the comment for the other patch *grin* > > You are right. I checked the gramar and saw the ability to use the > > parameter. I looked at the manual pages, and saw no reference to it. I > > tried running it, and found vacuum does nothing when you give it a table > > name. > > > > I checked a debug version of postgres, and the table name is passed to > > vacuum() in the variable (char *vacrel). The problem is that the vacuum > > spans transactions, and the vacrel name gets changed to '<vacuum>', > > which is the name of the portal that gets created in > > vacuum.c::_vc_vacuum(). vacuum.c::_vc_init() does a > > CommitTransactionCommand() which frees the memory allocated to vacrel. > > > > Should I change vacuum.c to copy the relation name to a local string > > variable of vacuum(), or do you recommend we allocate the table name in > > a different fashion? You are the man who knows the most about this. > > static NameData VacRel; Done. Attached is the patch. I have already applied it to the 2.0 tree. (Marc!) I tested it and it works. I also applied documentation patches to go with it. So now vacuum can be run for only one table if you wish. Submitted by: Bruce Momjian <maillist@candle.pha.pa.us> | 04 October 1996, 20:38:49 UTC |
| refs/tags/PG95-1_09 | 1b5e30e | remove KERBEROS config cruft from Makefile.global - don't advertise something that jus tdoes'nt work | 31 October 1996, 20:25:56 UTC |
| refs/tags/REL2_0 | 14a3ecf | This commit was manufactured by cvs2git to create branch 'REL2_0B'. Sprout from master 1996-12-09 01:24:53 UTC Bryan Henderson <bryanh@giraffe.netgate.net> 'Remove include of libpq-fe.h. This file has nothing to do with libpq.' Delete: src/bin/monitor/Makefile src/bin/monitor/monitor.c | 09 December 1996, 01:24:54 UTC |
| refs/tags/REL6_1 | 0acf9c9 | Update LInux and Irix FAQs. | 13 June 1997, 14:08:48 UTC |
| refs/tags/REL6_1_1 | b6d9835 | Update files and dates for 6.1.1 release. | 21 July 1997, 22:29:41 UTC |
| refs/tags/REL6_2 | d663f1c | Sparc lock fix for Linux/netbsd. | 02 October 1997, 18:32:58 UTC |
| refs/tags/REL6_2_1 | 8a1a39c | Update for 6.2.1 | 18 October 1997, 16:59:06 UTC |
| refs/tags/REL6_3 | b1c7c31 | One last change to configure for 'non-gcc' compiler | 02 March 1998, 14:54:59 UTC |
| refs/tags/REL6_3_2 | b542fa1 | From: Peter T Mount <patches@maidast.demon.co.uk> This fixes a problem in ResultSet.getDate() when the column is NULL (reported by Vincent Partington <Vincent.Partington@nmg.nl>) And fixes a problem with Field's (ResultSet.getObject() was proving to be slow as it repetedly send queries for oid -> name mapping - fixed by creating a cache. (reported by Mario Ellebrecht <ellebrec@nads.de>) | 18 April 1998, 18:32:44 UTC |
| refs/tags/REL6_4_2 | 3be6c6e | HISTORY update. | 03 January 1999, 06:50:17 UTC |
| refs/tags/REL6_5 | 275a1d0 | Undo Jan's typo that broke regress.sh's detection of system type name. | 14 June 1999, 17:49:06 UTC |
| refs/tags/REL6_5_1 | c7092a8 | Update README.NT. | 19 July 1999, 05:08:23 UTC |
| refs/tags/REL6_5_2 | d5d33e2 | Another little 'must fix' for 6.5.2: someone removed HAVE_KILL from the configuration symbols, but neglected to remove #ifdef HAVE_KILL from async.c in the REL6_5 branch. Result: cross-backend NOTIFY dead in the water. | 14 September 1999, 22:33:35 UTC |
| refs/tags/REL6_5_3 | ef26b94 | Update bsdi for bsd/os 4.1 | 04 November 1999, 16:22:41 UTC |
| refs/tags/REL7_0 | f44328b | Change HISTORY to show outer joins in 7.1 or 7.2. | 08 May 2000, 23:56:50 UTC |
| refs/tags/REL7_0_2 | e261306 | Update install for upgraders. | 05 June 2000, 17:02:27 UTC |
| refs/tags/REL7_0_3 | 6835ca6 | put a quick, short note in about Tom's last bug fix for the 'double portal on abort' crash ... hopefully I'm sum'd up his explanation close enough? :) | 12 November 2000, 07:31:36 UTC |
| refs/tags/REL7_1 | 741604d | tag the source tree as REL7_1, renaming the old tag REL7_1_BETA like it should have been done generate a new Changelog from rc4, which is nice and short ... one python interface change tag configure as 7.1, for generating the packages ... This is it folks ... Release 7.1 is officially here ... | 13 April 2001, 21:21:33 UTC |
| refs/tags/REL7_1_1 | ed65860 | add in the changelog file I forgot about | 05 May 2001, 20:23:57 UTC |
| refs/tags/REL7_1_2 | 0b471cc | Patch from Barry Lind to correctly decode time zones in timestamp results. Without patch, the time zone field is ignored and the returned time is not correct. Already applied to the development tree... | 22 May 2001, 14:46:46 UTC |
| refs/tags/REL7_1_3 | 8c78169 | Add a changelog file for 7.1.3 from 7.1.2 | 17 August 2001, 17:10:16 UTC |
| refs/tags/REL7_1_BETA | d946604 | Fix bogus makefiles ... these didn't build on platforms that are sticky about being given accurate references to referenced libraries ... | 04 December 2000, 01:32:19 UTC |
| refs/tags/REL7_1_BETA2 | 6781aa4 | tag configure as beta2 .. | 07 January 2001, 02:23:25 UTC |
| refs/tags/REL7_1_BETA3 | 460a9f8 | jump version to beta3 ... beta2 was created and pulled due to a couple of large-ish bugs that Tom and Vadim were able to fix, but to avoid any confusion, beta2 was removed ... and for tag'ng purposes, beta3 is being created ... | 09 January 2001, 13:11:32 UTC |
| refs/tags/REL7_2 | 42e28d2 | Stamp configure/configure.in for 7.2, already did register.txt and bug.template. | 03 February 2002, 21:04:12 UTC |
| refs/tags/REL7_2_1 | 9de8b7b | Update release list. | 26 March 2002, 05:34:37 UTC |
| refs/tags/REL7_2_2 | 30ab8da | Update HISTORY with Neil's changes. | 23 August 2002, 02:33:06 UTC |
| refs/tags/REL7_2_3 | 4526d21 | Brand 7.2.3. | 01 October 2002, 03:34:29 UTC |
| refs/tags/REL7_2_4 | 895491b | Brand 7.2.4. | 29 January 2003, 22:13:19 UTC |
| refs/tags/REL7_2_5 | a59084f | Update 7.2 regression tests to match what you get when using a modern version of Bison. | 19 August 2004, 20:03:49 UTC |
| refs/tags/REL7_2_6 | 6452043 | Stamp release 7.2.6. | 22 October 2004, 00:27:34 UTC |
| refs/tags/REL7_2_7 | ebe0341 | Recommend security@postgresql.org as the contact point for security-related bugs. | 30 January 2005, 21:32:38 UTC |
| refs/tags/REL7_2_8 | 6a36111 | Update release notes for upcoming re-releases. | 09 May 2005, 00:10:53 UTC |
| refs/tags/REL7_2_BETA1 | 05584c9 | Code cleanup. | 25 October 2001, 06:27:56 UTC |
| refs/tags/REL7_2_BETA2 | 27e7ac1 | Update for latest version of horology test. | 06 November 2001, 18:03:48 UTC |
| refs/tags/REL7_2_BETA3 | 604f54c | Some minor tweaks of REINDEX processing: grab exclusive lock a little earlier, make error checks more uniform. | 20 November 2001, 02:46:13 UTC |
| refs/tags/REL7_2_BETA4 | 219b4b2 | tag it as b4, with all the changes that have gone on ... | 12 December 2001, 13:30:12 UTC |
| refs/tags/REL7_2_BETA5 | da83ecb | tag as beta 5 for *hopefully* a very very short beta cycle on this one? | 14 January 2002, 13:15:28 UTC |
| refs/tags/REL7_2_RC1 | c64f083 | okay, sorry for delay all ... here is the tag for RC1 ... | 22 January 2002, 17:55:30 UTC |
| refs/tags/REL7_2_RC2 | 0e8ab3a | let's roll up rc2 .. | 25 January 2002, 02:09:26 UTC |
| refs/tags/REL7_3 | 920c586 | rm should be rm -f, per comment from Peter Harris. (Checked with Peter Eisentraut.) | 27 November 2002, 23:21:20 UTC |
| refs/tags/REL7_3_1 | a3feaba | Fix possible buffer overrun in \d command: substr(..., 128) produces a result of at most 128 chars, but that could be more than 128 bytes. Also ensure we don't try to pfree uninitialized pointers during error cleanup. | 21 December 2002, 01:07:21 UTC |
| refs/tags/REL7_3_10 | e5921b3 | Update release notes for upcoming re-releases. | 09 May 2005, 00:10:35 UTC |
| refs/tags/REL7_3_11 | ae049f1 | Stamp release 7.3.11. | 03 October 2005, 17:24:27 UTC |
| refs/tags/REL7_3_12 | fbb687f | Stamp 7.3.12. | 09 December 2005, 20:56:45 UTC |
| refs/tags/REL7_3_13 | 751c481 | Release-note updates and copy editing. | 06 January 2006, 03:00:46 UTC |
| refs/tags/REL7_3_14 | eb46ad5 | Stamp 7.3.14. | 12 February 2006, 22:38:54 UTC |
| refs/tags/REL7_3_15 | e675978 | Stamp release 7.3.15. | 21 May 2006, 21:54:31 UTC |
| refs/tags/REL7_3_16 | 53d7eec | Stamp 7.3.16. | 12 October 2006, 19:42:21 UTC |
| refs/tags/REL7_3_17 | 4c884c3 | Fix markup because older releases couldn't like to refernce pages. | 06 January 2007, 04:15:43 UTC |
| refs/tags/REL7_3_18 | af8a424 | Stamp release 7.3.18. Security: CVE-2007-0555, CVE-2007-0556 | 02 February 2007, 00:16:01 UTC |
| refs/tags/REL7_3_19 | 6b5ecb4 | Update configure.in for release Security: hold for release | 20 April 2007, 16:19:11 UTC |
| refs/tags/REL7_3_2 | caa72ad | Add mention of CURRENT_SCHEMA for object creation. | 03 February 2003, 15:57:03 UTC |
| refs/tags/REL7_3_20 | 1aea75f | Update release notes for last-minute fix. | 16 September 2007, 03:04:09 UTC |
| refs/tags/REL7_3_21 | 9d4269f | Stamp release 7.3.21. Security: CVE-2007-4769, CVE-2007-4772, CVE-2007-6067, CVE-2007-6600, CVE-2007-6601 | 03 January 2008, 21:42:44 UTC |
| refs/tags/REL7_3_3 | abb2963 | Update for 7.3.3. | 22 May 2003, 20:38:56 UTC |
| refs/tags/REL7_3_4 | 091b9c2 | Fix timestamp_date for HAVE_INT64_TIMESTAMP case. | 24 July 2003, 04:38:27 UTC |
| refs/tags/REL7_3_5 | 7af352f | Brand 7.3.5. | 02 December 2003, 16:26:00 UTC |
| refs/tags/REL7_3_6 | 2d558b2 | Brand 7.3.6. | 02 March 2004, 00:44:55 UTC |
| refs/tags/REL7_3_7 | 1cfe0a4 | Wups, seem to have used an ungood version of lynx to generate this. | 15 August 2004, 01:27:47 UTC |
| refs/tags/REL7_3_8 | 42a8068 | Stamp release 7.3.8. | 22 October 2004, 00:27:05 UTC |
| refs/tags/REL7_3_9 | d40cda0 | Recommend security@postgresql.org as the contact point for security-related bugs. | 30 January 2005, 21:32:20 UTC |
