84Beta2Changes

From PostgreSQL wiki

Revision as of 01:01, 7 November 2009 by Itagaki (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

List of significant fixes and changes between 8.4 Beta 1 and 8.4 Beta 2

2009-05-14 16:31 heikki

* contrib/pg_standby/pg_standby.c, doc/src/sgml/backup.sgml, doc/src/sgml/pgstandby.sgml, src/backend/access/transam/xlog.c: Add recovery_end_command option to recovery.conf. recovery_end_command is run at the end of archive recovery, providing a chance to do external cleanup. Modify pg_standby so that it no longer removes the trigger file, that is to be done using the recovery_end_command now.

Provide a "smart" failover mode in pg_standby, where we don't fail over immediately, but only after recovering all unapplied WAL from the archive. That gives you zero data loss assuming all WAL was archived before failover, which is what most users of pg_standby actually want.

recovery_end_command by Simon Riggs, pg_standby changes by Fujii Masao and myself.

2009-05-13 16:27 tgl

* src/: backend/access/transam/xact.c, backend/utils/adt/xml.c, include/utils/xml.h: Rewrite xml.c's memory management (yet again). Give up on the idea of redirecting libxml's allocations into a Postgres context. Instead, just let it use malloc directly, and add PG_TRY blocks as needed to be sure we release libxml data structures in error recovery code paths. This is ugly but seems much more likely to play nicely with third-party uses of libxml, as seen in recent trouble reports about using Perl XML facilities in pl/perl and bug #4774 about contrib/xml2.

I left the code for allocation redirection in place, but it's only built/used if you #define USE_LIBXMLCONTEXT. This is because I found it useful to corral libxml's allocations in a palloc context when hunting for libxml memory leaks, and we're surely going to have more of those in the future with this type of approach. But we don't want it turned on in a normal build because it breaks exactly what we need to fix.

I have not re-indented most of the code sections that are now wrapped by PG_TRY(); that's for ease of review. pg_indent will fix it.

This is a pre-existing bug in 8.3, but I don't dare back-patch this change until it's gotten a reasonable amount of field testing.

2009-05-12 12:43 tgl

* src/: backend/access/heap/heapam.c, backend/commands/lockcmds.c, include/access/heapam.h: Fix LOCK TABLE to eliminate the race condition that could make it give weird errors when tables are concurrently dropped. To do this we must take lock on each relation before we check its privileges. The old code was trying to do that the other way around, which is a bit pointless when there are lots of other commands that lock relations before checking privileges. I did keep it checking each relation's privilege before locking the next relation, which is a detail that ALTER TABLE isn't too picky about.

2009-05-11 23:11 tgl

* src/: backend/catalog/pg_inherits.c, backend/commands/lockcmds.c, backend/commands/tablecmds.c, backend/optimizer/prep/prepunion.c, backend/parser/parse_coerce.c, include/catalog/pg_inherits.h, include/catalog/pg_inherits_fn.h: Modify find_inheritance_children() and find_all_inheritors() to add the ability to lock relations as they scan pg_inherits, and to ignore any relations that have disappeared by the time we get lock on them. This makes uses of these functions safe against concurrent DROP operations on child tables: we will effectively ignore any just-dropped child, rather than possibly throwing an error as in recent bug report from Thomas Johansson (and similar past complaints). The behavior should not change otherwise, since the code was acquiring those same locks anyway, just a little bit later.

An exception is LockTableCommand(), which is still behaving unsafely; but that seems to require some more discussion before we change it.

2009-05-11 04:06 mha

* src/backend/libpq/be-secure.c: Support SSL certificate chains in the server certificate file.

Andrew Gierth

2009-05-09 22:51 tgl

* src/bin/pg_dump/pg_dumpall.c: Adjust pg_dumpall so that it emits ENCODING, LC_COLLATE, and LC_CTYPE options in its CREATE DATABASE commands only for databases that have settings different from the installation defaults. This is a low-tech method of avoiding unnecessary platform dependencies in dump files. Eventually we ought to have a platform-independent way of specifying LC_COLLATE and LC_CTYPE, but that's not going to happen for 8.4, and this patch at least avoids the issue for people who aren't setting up per-database locales. ENCODING doesn't have the platform dependency problem, but it seems consistent to make it act the same as the locale settings.

2009-05-09 18:51 tgl

* src/: backend/optimizer/path/costsize.c, backend/optimizer/plan/createplan.c, backend/optimizer/util/restrictinfo.c, include/optimizer/restrictinfo.h: Fix cost_nestloop and cost_hashjoin to model the behavior of semi and anti joins a bit better, ie, understand the differing cost functions for matched and unmatched outer tuples. There is more that could be done in cost_hashjoin but this already helps a great deal. Per discussions with Robert Haas.

2009-05-07 18:01 tgl

* contrib/pgbench/pgbench.c, doc/src/sgml/pgbench.sgml: Change pgbench to use the table names pgbench_accounts, pgbench_branches, pgbench_history, and pgbench_tellers, rather than just accounts, branches, history, and tellers. This is to prevent accidental conflicts with real application tables, as has been reported to happen at least once. Also remove the automatic "SET search_path = public" that it did at startup, as this seems to restrict testing flexibility without actually buying much. Per proposal by Joshua Drake and ensuing discussion.

Joshua Drake and Tom Lane

2009-05-06 12:15 tgl

* doc/src/sgml/charset.sgml, doc/src/sgml/manage-ag.sgml, doc/src/sgml/ref/create_database.sgml, src/backend/commands/dbcommands.c, src/test/mb/README, src/test/mb/mbregress.sh: Modify CREATE DATABASE to enforce that the source database's encoding setting must be used for the new database, except when copying from template0. This is the same rule that we now enforce for locale settings, and it has the same motivation: databases other than template0 might contain data that would be invalid according to a different setting. This represents another step in a continuing process of locking down ways in which encoding violations could occur inside the backend. Per discussion of a few days ago.

In passing, fix pre-existing breakage of mbregress.sh, and fix up a couple of ereport() calls in dbcommands.c that failed to specify sqlstate codes.

2009-05-05 16:06 tgl

* src/backend/storage/ipc/ipc.c: Install an atexit(2) callback that ensures that proc_exit's cleanup processing will still be performed if something in a backend process calls exit() directly, instead of going through proc_exit() as we prefer. This is a second response to the issue that we might load third-party code that doesn't know it should not call exit(). Such a call will now cause a reasonably graceful backend shutdown, if possible. (Of course, if the reason for the exit() call is out-of-memory or some such, we might not be able to recover, but at least we will try.)

2009-05-05 15:59 tgl

* src/: backend/postmaster/postmaster.c, backend/storage/ipc/ipci.c, backend/storage/ipc/pmsignal.c, backend/storage/lmgr/proc.c, backend/utils/init/globals.c, include/miscadmin.h, include/postmaster/postmaster.h, include/storage/pmsignal.h: Install a "dead man switch" to allow the postmaster to detect cases where a backend has done exit(0) or exit(1) without having disengaged itself from shared memory. We are at risk for this whenever third-party code is loaded into a backend, since such code might not know it's supposed to go through proc_exit() instead. Also, it is reported that under Windows there are ways to externally kill a process that cause the status code returned to the postmaster to be indistinguishable from a voluntary exit (thank you, Microsoft). If this does happen then the system is probably hosed --- for instance, the dead session might still be holding locks. So the best recovery method is to treat this like a backend crash.

The dead man switch is armed for a particular child process when it acquires a regular PGPROC, and disarmed when the PGPROC is released; these should be the first and last touches of shared memory resources in a backend, or close enough anyway. This choice means there is no coverage for auxiliary processes, but I doubt we need that, since they shouldn't be executing any user-provided code anyway.

This patch also improves the management of the EXEC_BACKEND ShmemBackendArray array a bit, by reducing search costs.

Although this problem is of long standing, the lack of field complaints seems to mean it's not critical enough to risk back-patching; at least not till we get some more testing of this mechanism.

2009-05-05 14:32 petere

* doc/src/sgml/syntax.sgml, src/backend/parser/scan.l, src/test/regress/expected/strings.out, src/test/regress/sql/strings.sql: Disable the use of Unicode escapes in string constants (U&) when standard_conforming_strings is not on, for security reasons.

2009-05-02 21:17 ishii

* src/backend/utils/mb/Unicode/: euc_kr_to_utf8.map, johab_to_utf8.map, uhc_to_utf8.map, utf8_to_euc_kr.map, utf8_to_johab.map, utf8_to_uhc.map: Update UTF-8 <--> EUC_KR, JOHAB, UHC mappings. Patch contributed by Chuck McDevitt

2009-05-02 13:27 tgl

* doc/src/sgml/plpgsql.sgml, src/pl/plpgsql/src/pl_exec.c: Fix plpgsql's EXIT so that an EXIT without a label only matches a loop, never a BEGIN block. This is required for Oracle compatibility and is also plainly stated to be the behavior by our original documentation (up until 8.1, in which the docs were adjusted to match the code's behavior; but actually the old docs said the correct thing and the code was wrong).

Not back-patched because this introduces an incompatibility that could break working applications. Requires release note.

2009-04-24 05:43 mha

* doc/src/sgml/libpq.sgml, doc/src/sgml/runtime.sgml, src/interfaces/libpq/fe-connect.c, src/interfaces/libpq/fe-secure.c, src/interfaces/libpq/libpq-int.h: Remove sslverify parameter again, replacing it with two new sslmode values: "verify-ca" and "verify-full".

Since "prefer" remains the default, this will make certificate validation off by default, which should lead to less upgrade issues.

2009-04-22 20:23 tgl

* doc/src/sgml/config.sgml, doc/src/sgml/ref/prepare_transaction.sgml, src/backend/access/transam/twophase.c, src/backend/access/transam/varsup.c, src/backend/utils/misc/guc.c, src/backend/utils/misc/postgresql.conf.sample, src/test/regress/expected/prepared_xacts.out, src/test/regress/expected/prepared_xacts_1.out, src/test/regress/pg_regress.c, src/test/regress/sql/prepared_xacts.sql: Change the default value of max_prepared_transactions to zero, and add documentation warnings against setting it nonzero unless active use of prepared transactions is intended and a suitable transaction manager has been installed. This should help to prevent the type of scenario we've seen several times now where a prepared transaction is forgotten and eventually causes severe maintenance problems (or even anti-wraparound shutdown).

The only real reason we had the default be nonzero in the first place was to support regression testing of the feature. To still be able to do that, tweak pg_regress to force a nonzero value during "make check". Since we cannot force a nonzero value in "make installcheck", add a variant regression test "expected" file that shows the results that will be obtained when max_prepared_transactions is zero.

Also, extend the HINT messages for transaction wraparound warnings to mention the possibility that old prepared transactions are causing the problem.

All per today's discussion.

2009-04-21 11:49 momjian

* doc/src/sgml/ref/psql-ref.sgml, src/bin/psql/command.c, src/bin/psql/describe.c, src/bin/psql/describe.h, src/bin/psql/help.c, src/test/regress/expected/polymorphism.out: Add agg/normal/trigger/window flags for psql \df and in \df output.

David Fetter

2009-04-19 17:08 tgl

* src/backend/: commands/copy.c, parser/scan.l: Fix de-escaping checks so that we will reject \000 as well as other invalidly encoded sequences. Per discussion of a couple of days ago.

2009-04-19 14:52 tgl

* doc/src/sgml/plpgsql.sgml, src/pl/plpgsql/src/gram.y, src/pl/plpgsql/src/pl_comp.c, src/pl/plpgsql/src/pl_funcs.c, src/pl/plpgsql/src/plpgsql.h, src/pl/plpgsql/src/scan.l, src/test/regress/expected/plpgsql.out, src/test/regress/sql/plpgsql.sql: Revise plpgsql's scanner to process comments and string literals in a way more nearly matching the core SQL scanner. The user-visible effects are:

* Block comments (slash-star comments) now nest, as per SQL spec.

* In standard_conforming_strings mode, backslash as the last character of a non-E string literal is now correctly taken as an ordinary character; formerly it was misinterpreted as escaping the ending quote. (Since the string also had to pass through the core scanner, this invariably led to syntax errors.)

* Formerly, backslashes in the format string of RAISE were always treated as quoting the next character, regardless of mode. Now, they are ordinary characters with standard_conforming_strings on, while with it off, they introduce the same set of escapes as in the core SQL scanner. Also, escape_string_warning is now effective for RAISE format strings. These changes make RAISE format strings work just like any other string literal.

This is implemented by copying and pasting a lot of logic from the core scanner. It would be a good idea to look into getting rid of plpgsql's scanner entirely in favor of using the core scanner. However, that involves more change than I can justify making during beta --- in particular, the core scanner would have to become re-entrant.

In passing, remove the kluge that made the plpgsql scanner emit T_FUNCTION or T_TRIGGER as a made-up first token. That presumably had some value once upon a time, but now it's just useless complication for both the scanner and the grammar.

2009-04-12 17:02 adunstan

* src/bin/pg_dump/pg_backup_archiver.c: Fix logic to detect conflicts or blocks involving exclusive locks in parallel restore items. If a currently running item needs an exclusive lock on any item that the candidate items needs any sort of lock on, or vice versa, then the candidate item is not allowed to run now, and must wait till later.

2009-04-11 16:23 tgl

* src/bin/pg_dump/pg_dumpall.c: Fix pg_dumpall so that when --clean is specified, it drops roles and tablespaces in an order that has some chance of working. Per a complaint from Kevin Bailey.

This is a pre-existing bug, but given the lack of prior complaints I'm not sure it's worth back-patching. In most cases failure of the DROP commands wouldn't be that important anyway.

In passing, fix syntax errors in dumpCreateDB()'s queries for old servers; these were apparently introduced in recent binary_upgrade patch.

Personal tools