On 8th of February, Simon Riggs committed patch:
Extend ALTER TABLE TO allow FOREIGN KEYS TO be added WITHOUT initial validation. FK constraints that are marked NOT VALID may later be VALIDATED, which uses an ShareUpdateExclusiveLock ON CONSTRAINT TABLE AND RowShareLock ON referenced TABLE. Significantly reduces LOCK strength AND duration WHEN adding FKs. NEW state visible FROM psql. Simon Riggs, WITH reviews FROM Marko Tiikkaja AND Robert Haas
On 1st of February, Tom Lane committed patch:
Support LIKE and ILIKE index searches via contrib/pg_trgm indexes. Unlike Btree-based LIKE optimization, this works for non-left-anchored search patterns. The effectiveness of the search depends on how many trigrams can be extracted from the pattern. (The worst case, with no trigrams, degrades to a full-table scan, so this isn't a panacea. But it can be very useful.) Alexander Korotkov, reviewed by Jan Urbanski
On 25th of January, Tom Lane committed patch:
Implement ALTER TABLE ADD UNIQUE/PRIMARY KEY USING INDEX. This feature allows a UNIQUE OR pkey CONSTRAINT TO be created USING an already-existing UNIQUE INDEX. While the CONSTRAINT isn't very functionally different from the bare index, it's nice TO be able TO do that FOR documentation purposes. The main advantage OVER just issuing a plain ALTER TABLE ADD UNIQUE/PRIMARY KEY IS that the INDEX can be created WITH CREATE INDEX CONCURRENTLY, so that there IS NOT a long INTERVAL WHERE the TABLE IS locked against updates. ON the way, refactor SOME OF the code IN DefineIndex() AND index_create() so that we don't have to pass through those functions in order to create the index constraint's catalog entries. Also, IN parse_utilcmd.c, pass around the ParseState pointer IN struct CreateStmtContext TO save ON notation, AND ADD error location pointers TO SOME error reports that didn't have one before. Gurjeet Singh, reviewed by Steve Singer and Tom Lane
Continue reading Waiting for 9.1 – Add UNIQUE/PRIMARY KEY with index
As of yesterday OmniPITR got following changes/fixes:
I'm very ashamed of the first thing (smart/immediate finish request), as it was simply my lack of test.
Second thing – the problem was that with streaming replication slave behaves a bit differently than normally, and so the backup procedure had to be modified.
As for third – restore command in streaming replication environment has to behave differently than normal restore command – i.e. it should finish, with error, as soon as it will be called for wal file that does not exist in wal archive. Which is direct opposite of what should be done normally.
Now, omnipitr-restore got switch (-sr) to make it work correctly in SR situation.
Links for svn/docs are listed on project page.