Add comment about memory reordering to PredicateLockTupleRowVersionLink.
Dan Ports, per head-scratching from Simon Riggs and myself.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/71932ecc2b6ca0d748176a7e8b11d3575bf4caf3
Modified Files
--
src/backend/st
Adjust pg_upgrade FATAL error messages to have consistent newlines.
Also adjust some error message capitalization for consistency.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/5c5f83507cb697e436f8f9d20d62787c1a66d19c
Modified Files
--
contrib/pg_upgra
Fix typos in SECURITY LABEL documentation.
KaiGai Kohei
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/3ef5b2df9738fd0795c1ffcaada93c3c5df7cd49
Modified Files
--
doc/src/sgml/ref/security_label.sgml | 10 +-
1 files changed, 5 insertions(+), 5
Improve compiler string shown in version()
With some compilers such as Clang and ICC emulating GCC, using a
version string of the form "GCC $version" can be quite misleading.
Also, a great while ago, the version output from gcc --version started
including the string "gcc", so it is redundant to re
Move RegisterPredicateLockingXid() call to a safer place.
The SSI patch inserted a call of RegisterPredicateLockingXid into
GetNewTransactionId, which was a bad idea on a couple of grounds. First,
it's not necessary to hold XidGenLock while manipulating that shared
memory, and doing so is bad bec