== PostgreSQL Weekly News - December 23 2012 ==
От | David Fetter |
---|---|
Тема | == PostgreSQL Weekly News - December 23 2012 == |
Дата | |
Msg-id | 20121224062547.GA22544@fetter.org обсуждение исходный текст |
Список | pgsql-announce |
== PostgreSQL Weekly News - December 23 2012 == FOSDEM PGDay is a one day conference that will be held before FOSDEM in Brussels, Belgium, on Feb 1st, 2013. Details below. http://fosdem2013.pgconf.eu/ The New York City PostgreSQL User Group is pleased to announce that registrations for PGDay NYC 2013 on Friday, March 22, 2013 at the ACE Hotel are now open. Super Early Bird tickets are available until they sell out or December 29, 2012, whichever comes first. You can purchase them at http://pgday.nycpug.org/registration/ PyPgDay will be held on March 13th at the Santa Clara Convention Center, the first day of PyCon. Info here: http://wiki.postgresql.org/wiki/PyPgDay2013 Submit your proposal here by January 20, 2013: http://tinyurl.com/PyPgDayCfP == PostgreSQL Product News == Ora2PG 10 released. http://ora2pg.darold.net/ pg_activity 0.2.0 released. https://github.com/julmon/pg_activity/ Skytools 3.1.3, a package of tools developed by Skype for replication and failover including PgQ, a generic queuing framework and Londiste, a row-based master-slave replication replication system, released: https://github.com/markokr/skytools == PostgreSQL Jobs for December == http://archives.postgresql.org/pgsql-jobs/2012-12/threads.php == PostgreSQL Local == The FOSDEM PGDay conference that will be held before FOSDEM in Brussels, Belgium, on Feb 1st, 2013. The CfP for both this event and for the PG track of FOSDEM are open. http://fosdem2013.pgconf.eu/callforpapers/ There will be a PgDay at PyCon on March 13th, in the Santa Clara convention center. More details once we have things organized. Please put it on your calendar. PGDay NYC 2013 will be held on March 22, 2013 in New York City. The CfP submission deadline is January 7th, 2013 at noon eastern time. papers AT nycpug DOT org. http://pgday.nycpug.org/speakers PostgreSQL Session will be held on March 28th, 2013 in Paris, France. The Call for Papers is open. http://www.postgresql-sessions.org/en/5/ PGCon 2013 will be held May 23-24 2013, in Ottawa at the University of Ottawa. The Call for Papers is open. http://www.pgcon.org/2013/ == PostgreSQL in the News == Planet PostgreSQL: http://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm Pacific time. Please send English language ones to david@fetter.org, German language to pwn@pgug.de, Italian language to pwn@itpug.org. Spanish language to pwn@arpug.com.ar. == Applied Patches == Tom Lane pushed: - Fix failure to ignore leftover temp tables after a server crash. During crash recovery, we remove disk files belonging to temporary tables, but the system catalog entries for such tables are intentionally not cleaned up right away. Instead, the first backend that uses a temp schema is expected to clean out any leftover objects therein. This approach requires that we be careful to ignore leftover temp tables (since any actual access attempt would fail), *even if their BackendId matches our session*, if we have not yet established use of the session's corresponding temp schema. That worked fine in the past, but was broken by commit debcec7dc31a992703911a9953e299c8d730c778 which incorrectly removed the rd_islocaltemp relcache flag. Put it back, and undo various changes that substituted tests like "rel->rd_backend == MyBackendId" for use of a state-aware flag. Per trouble report from Heikki Linnakangas. Back-patch to 9.1 where the erroneous change was made. In the back branches, be careful to add rd_islocaltemp in a spot in the struct that was alignment padding before, so as not to break existing add-on code. http://git.postgresql.org/pg/commitdiff/6919b7e3294702adc39effd16634b2715d04f012 - Ignore libedit/libreadline while probing for standard functions. Some versions of libedit expose bogus definitions of setproctitle(), optreset, and perhaps other symbols that we don't want configure to pick up on. There was a previous report of similar problems with strlcpy(), which we addressed in commit 59cf88da91bc88978b05275ebd94ac2d980c4047, but the problem has evidently grown in scope since then. In hopes of not having to deal with it again in future, rearrange configure's tests for supplied functions so that we ignore libedit/libreadline except when probing specifically for functions we expect them to provide. Per report from Christoph Berg, though this is slightly more aggressive than his proposed patch. http://git.postgresql.org/pg/commitdiff/2666a6d0b934b19d4a691b93a64c7d3208acad43 - Fix pg_extension_config_dump() to handle update cases more sanely. If pg_extension_config_dump() is executed again for a table already listed in the extension's extconfig, the code was blindly making a new array entry. This does not seem useful. Fix it to replace the existing array entry instead, so that it's possible for extension update scripts to alter the filter conditions for configuration tables. In addition, teach ALTER EXTENSION DROP TABLE to check for an extconfig entry for the target table, and remove it if present. This is not a 100% solution because it's allowed for an extension update script to just summarily DROP a member table, and that code path doesn't go through ExecAlterExtensionContentsStmt. We could probably make that case clean things up if we had to, but it would involve sticking a very ugly wart somewhere in the guts of dependency.c. Since on the whole it seems quite unlikely that extension updates would want to remove pre-existing configuration tables, making the case possible with an explicit command seems sufficient. Per bug #7756 from Regina Obe. Back-patch to 9.1 where extensions were introduced. http://git.postgresql.org/pg/commitdiff/343c2a865bc6c0a03358709df854ce1eac52ca45 - Fix documentation typo. "GetForeignTableColumnOptions" should be "GetForeignColumnOptions". Noted by Metin Döşlü. http://git.postgresql.org/pg/commitdiff/eb035068121532ed7db47081e71655746d31cd16 - Prevent failure when RowExpr or XmlExpr is parse-analyzed twice. transformExpr() is required to cope with already-transformed expression trees, for various ugly-but-not-quite-worth-cleaning-up reasons. However, some of its newer subroutines hadn't gotten the memo. This accounts for bug #7763 from Norbert Buchmuller: transformRowExpr() was overwriting the previously determined type of a RowExpr during CREATE TABLE LIKE INCLUDING INDEXES. Additional investigation showed that transformXmlExpr had the same kind of problem, but all the other cases seem to be safe. Andres Freund and Tom Lane http://git.postgresql.org/pg/commitdiff/31bc839724439440b2e94ea616b28ce5be94e19c Peter Eisentraut pushed: - doc: Put PL/pgSQL RAISE USING keywords into a list. Karl O. Pinc http://git.postgresql.org/pg/commitdiff/8d2e9a9dbd56aabb9273fbc30ca6c03d6f24b996 - Remove allow_nonpic_in_shlib This was used in a time when a shared libperl or libpython was difficult to come by. That is obsolete, and the idea behind the flag was never fully portable anyway and will likely fail on more modern CPU architectures. http://git.postgresql.org/pg/commitdiff/1a5f04dd7eed0ac27cc5da9520ef55e16531bca6 - pg_basebackup: Small message punctuation improvements http://git.postgresql.org/pg/commitdiff/6925e38dadca0e64e8528316ccee7591fe88331f - Rename SQL feature S403 to ARRAY_MAX_CARDINALITY. In an earlier version of the standard, this was called just "MAX_CARDINALITY". http://git.postgresql.org/pg/commitdiff/f2b88080db43fbadaef990a1b240bd634d1d4275 - Fix grammatical mistake in error message http://git.postgresql.org/pg/commitdiff/a0bfb7b36e0795a1c69c86b4184ee952dbb650d1 - Make some messages more consistent in style http://git.postgresql.org/pg/commitdiff/740ee42da5fc07e5b1be5c358673224d99cb2aae Andrew Dunstan pushed: - Don't include postgres.h in postgres_fe.h for cpluspluscheck. Error exposed by recent Assert changes. Complaint from Peter Eisentraut. http://git.postgresql.org/pg/commitdiff/9ac749ceb5ad040dc2aa834d9f698a3da2425a96 Heikki Linnakangas pushed: - Check if we've reached end-of-backup point also if no redo is required. If you restored from a backup taken from a standby, and the last record in the backup is the checkpoint record, ie. there is no redo required except for the checkpoint record, we would fail to notice that we've reached the end-of-backup point, and the database is consistent. The result was an error "WAL ends before end of online backup". To fix, move the have-we-reached-end-of-backup check into CheckRecoveryConsistency(), which is already responsible for similar checks with minRecoveryPoint, and is called in the right places. Backpatch to 9.2, this check and bug did not exist before that. http://git.postgresql.org/pg/commitdiff/e43f947bf32f3ea4caa5b895ca7c7659b17192ae - Don't set ThisTimeLineID in checkpointer & bgwriter during recovery. We used to set it to the current recovery target timeline, but the recovery target timeline can change during recovery, leaving ThisTimeLineID at an old value. That seems worse than always leaving it at zero to begin with. AFAICS there was no good reason to set it in the first place. ThisTimeLineID is not needed in checkpointer or bgwriter process, until it's time to write the end-of-recovery checkpoint, and at that point ThisTimeLineID is updated anyway. http://git.postgresql.org/pg/commitdiff/1a11d4609efaae39d9b7472fb965bca1c0aeda01 - Fix recycling of WAL segments after switching timeline during recovery. This was broken before, we would recycle old WAL segments on wrong timeline after the recovery target timeline had changed, but my recent commit to not initialize ThisTimeLineID at all in a standby's checkpointer process broke this completely. The problem is that when installing a recycled WAL segment as a future one, ThisTimeLineID is used to construct the filename. To fix, always update ThisTimeLineID to the current timeline being recovered, before recycling WAL segments at a restartpoint. This still leaves a small window where we might install WAL segments under wrong timeline ID, if the timeline is changed just as we're about to start recycling. Also, even if we're replaying timeline X at the momnent, there's no guarantee that we'll need as many WAL segments on that timeline as we recycle. We might be just about to reach the point where we switch to next timeline, so might only need one more WAL segment on the current timeline. We'll live with the waste in that situation. Bug pointed out by Fujii Masao. 9.1 and 9.2 had the same issue, when recovery target timeline was changed, but I committed a slightly different version of this patch on those branches. http://git.postgresql.org/pg/commitdiff/343ee00b730e9c422082160718b9785f0cb7f8f6 - Follow TLI of last replayed record, not recovery target TLI, in walsenders. Most of the time, the last replayed record comes from the recovery target timeline, but there is a corner case where it makes a difference. When the startup process scans for a new timeline, and decides to change recovery target timeline, there is a window where the recovery target TLI has already been bumped, but there are no WAL segments from the new timeline in pg_xlog yet. For example, if we have just replayed up to point 0/30002D8, on timeline 1, there is a WAL file called 000000010000000000000003 in pg_xlog that contains the WAL up to that point. When recovery switches recovery target timeline to 2, a walsender can immediately try to read WAL from 0/30002D8, from timeline 2, so it will try to open WAL file 000000020000000000000003. However, that doesn't exist yet - the startup process hasn't copied that file from the archive yet nor has the walreceiver streamed it yet, so walsender fails with error "requested WAL segment 000000020000000000000003 has already been removed". That's harmless, in that the standby will try to reconnect later and by that time the segment is already created, but error messages that should be ignored are not good. To fix that, have walsender track the TLI of the last replayed record, instead of the recovery target timeline. That way walsender will not try to read anything from timeline 2, until the WAL segment has been created and at least one record has been replayed from it. The recovery target timeline is now xlog.c's internal affair, it doesn't need to be exposed in shared memory anymore. This fixes the error reported by Thom Brown. depesz the same error message, but I'm not sure if this fixes his scenario. http://git.postgresql.org/pg/commitdiff/af275a12dfeecd621ed9899a9382f26a68310263 - Forgot to remove extern declaration of GetRecoveryTargetTLI(). Fujii Masao http://git.postgresql.org/pg/commitdiff/d57a97343ecec89ecb7d932c21c886058ad64e6b - Fix race condition if a file is removed while pg_basebackup is running. If a relation file was removed when the server-side counterpart of pg_basebackup was just about to open it to send it to the client, you'd get a "could not open file" error. Fix that. Backpatch to 9.1, this goes back to when pg_basebackup was introduced. http://git.postgresql.org/pg/commitdiff/36e4456d78b6a27cdaf82280b98998fc3bf3e9c7 - Fix sloppiness in the timeline switch over streaming replication patch. Here's another attempt at fixing the logic that decides how far the WAL can be streamed, which was still broken if the timeline changed while streaming. You would get an assertion failure. The way the logic is now written is more readable, too. Thom Brown reported the assertion failure. http://git.postgresql.org/pg/commitdiff/1ff92eea140ccf0503b7399549031976e5c6642e Bruce Momjian pushed: - Add pg_upgrade comment about mismatch error. Add comment stating that constraint and index names must match. http://git.postgresql.org/pg/commitdiff/345fb82f1616b4d44d8a67a6c10e964400d29c09 - Avoid using NAMEDATALEN in pg_upgrade. Because the client encoding might not match the server encoding, pg_upgrade can't allocate NAMEDATALEN bytes for storage of database, relation, and namespace identifiers. Instead pg_strdup() the memory and free it. Also add C comment in initdb.c about safe NAMEDATALEN usage. http://git.postgresql.org/pg/commitdiff/dc9896a2457f0d72458f1ff45935362521f0f99c Robert Haas pushed: - Adjust many backend functions to return OID rather than void. Extracted from a larger patch by Dimitri Fontaine. It is hoped that this will provide infrastructure for enriching the new event trigger functionality, but it seems possibly useful for other purposes as well. http://git.postgresql.org/pg/commitdiff/c504513f83a9ee8dce4a719746ca73102cae9f13 == Rejected Patches (for now) == No one was disappointed this week :-) == Pending Patches == Jeff Davis sent in another revision of a patch to implement SP-GiST for ranges based on 2d-mapping and quad-tree. Alexander Korotkov sent in another revision of a patch to implement index support for DFA regexes. Andres Freund sent in a patch to rearrange how XLByte* is used. Shigeru HANADA and Pavel Stehule traded patches to add \pset to psql. Amit Kapila sent in another revision of a patch to add hooks for pre- and post-processor executables for COPY and \copy. KaiGai Kohei sent in another revision of a patch to add row-level access control. Laurenz Albe sent in a patch to fix a bug in the LDAP documentation. Tomas Vondra sent in another revision of a patch to enable reducing the amount of pgbench output. Andres Freund sent in a patch to removes some of the cruft from gram.y. Gurjeet Singh sent in another revision of a patch to use 64-bit ints in pgbench for performance. Peter Eisentraut sent in a patch to improve PL/Python on OS X. Peter Geoghegan sent in another revision of a patch to improve memory usage in tuplesort. Marko (johto) Tiikkaja sent in a patch to add a STRICT option to PERFORM in PL/pgsql. Phil Sorber sent in two more revisions of a patch to create a pg_ping utility. Marko Kreen sent in a patch to fix an infelicity in pgcrypto when SSL is on. Bruce Momjian sent in a patch to speed up pg_upgrade. KaiGai Kohei sent in another revision of a patch to add write support to the FDW interface. Tomas Vondra sent in another revision of a patch to optimize droppign multiple tables in a transaction.
В списке pgsql-announce по дате отправления: