Following bugs were fixed for postgresql server, including critical ones , which repairs possible data corruption durning replication:
*Fix VACUUM's tests to see whether it can update relfrozenxid:
In some cases VACUUM (either manual or autovacuum) could incorrectly advance a table's relfrozenxid value, allowing tuples to escape freezing, causing those rows to become invisible once 2^31 transactions have elapsed. The probability of data loss is fairly low since multiple incorrect advancements would need to happen before actual loss occurs, but it's not zero. Users upgrading from releases 9.0.4 or 8.4.8 or earlier are not affected, but all later versions contain the bug.

The issue can be ameliorated by, after upgrading, vacuuming all tables in all databases while having vacuum_freeze_table_age set to zero. This will fix any latent corruption but will not be able to fix all pre-existing data errors. However, an installation can be presumed safe after performing this vacuuming if it has executed fewer than 2^31 update transactions in its lifetime (check this with SELECT txid_current() < 2^31).

*Fix initialization of pg_clog and pg_subtrans during hot standby startup

This bug can cause data loss on standby servers at the moment they start to accept hot-standby queries, by marking committed transactions as uncommitted. The likelihood of such corruption is small unless, at the time of standby startup, the primary server has executed many updating transactions since its last checkpoint. Symptoms include missing rows, rows that should have been deleted being still visible, and obsolete versions of updated rows being still visible alongside their newer versions.

This bug was introduced in versions 9.3.0, 9.2.5, 9.1.10, and 9.0.14. Standby servers that have only been running earlier releases are not at risk. It's recommended that standby servers that have ever run any of the buggy releases be re-cloned from the primary (e.g., with a new base backup) after upgrading.

*Truncate pg_multixact contents during WAL replay

This avoids ever-increasing disk space consumption in standby servers.

*Fix race condition in GIN index posting tree page deletion

This could lead to transient wrong answers or query failures.

*Avoid flattening a subquery whose SELECT list contains a volatile function wrapped inside a sub-SELECT

This avoids unexpected results due to extra evaluations of the volatile function.

*Fix planner's processing of non-simple-variable subquery outputs nested within outer joins

This error could lead to incorrect plans for queries involving multiple levels of subqueries within JOIN syntax.

*Fix premature deletion of temporary files

*Fix possible read past end of memory in rule printing

*Fix array slicing of int2vector and oidvector values

Expressions of this kind are now implicitly promoted to regular int2 or oid arrays.

*Fix incorrect behaviors when using a SQL-standard, simple GMT offset timezone

In some cases, the system would use the simple GMT offset value when it should have used the regular timezone setting that had prevailed before the simple offset was selected. This change also causes the timeofday function to honor the simple GMT offset zone.

*Fix pg_dumpall to work when a source database sets default_transaction_read_only via ALTER DATABASE SET

Previously, the generated script would fail during restore.

*Fix ecpg's processing of lists of variables declared varchar

*Make contrib/lo defend against incorrect trigger definitions

*Update time zone data files to tzdata release 2013h for DST law changes in Argentina, Brazil, Jordan, Libya, Liechtenstein, Morocco, and Palestine. Also, new timezone abbreviations WIB, WIT, WITA for Indonesia.