Fix the logic in libpqrcv_receive() to determine if there's any incoming data
that can be read without blocking. It used to conclude that there isn't, even
though there was data in the socket receive buffer. That lead walreceiver to
flush the WAL after every received chunk, potentially causing big
Fix the logic in libpqrcv_receive() to determine if there's any incoming data
that can be read without blocking. It used to conclude that there isn't, even
though there was data in the socket receive buffer. That lead walreceiver to
flush the WAL after every received chunk, potentially causing big
More libpq documentation adjustments from Leslie S Satenstein, reviewed
by Robert Haas.
Branch
--
master
Details
---
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=712dd95370fc6c3a8d20f71b8e195a7af3c50f42
Modified Files
--
doc/src/sgml/libpq.sgml | 22
Make sure walsender state is only read while holding the spinlock
Noted by Robert Haas.
Branch
--
master
Details
---
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=9eacd427e811a97337de1fdd61a3cb90604981ad
Modified Files
--
src/backend/replication/walsender.
Revert incorrect memory-conservation hack in inheritance_planner().
This reverts commit d1001a78ce612a16ea622b558f5fc2b68c45ab4c of 2010-12-05,
which was broken as reported by Jeff Davis. The problem is that the
individual planning steps may have side-effects on substructures of
PlannerGlobal, no
Code review for postmaster.pid contents changes.
Fix broken test for pre-existing postmaster, caused by wrong code for
appending lines to the lockfile; don't write a failed listen_address
setting into the lockfile; don't arbitrarily change the location of the
data directory in the lockfile compare
