Andrew Dunstan wrote:
>
>
> On 06/09/2011 11:28 PM, Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >>
> >>
> >>
> >> On 06/09/2011 08:51 PM, Bruce Momjian wrote:
> >>> Mention "pg_ctl stop" in pgindent README instructions.
> >>>
> >> This change make no sense at all. Why would you be running 'p
Bruce Momjian wrote:
> > Then the answer is "don't do that." Surely it's far saner to run
> > configure --prefix=/path/to/temploc and then go from there. Disturbing a
> > running postmaster for this purpose is crazy. BTW, for years I've used a
> > gadget to set up every piece of development work
Small comment fixes and enhancements.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c79c570bd8fbd6f074b8c186dfb08a9f4e3907e0
Modified Files
--
src/backend/storage/lmgr/README-SSI |2 +-
src/backend/storage/lmgr/predicate.c | 48 +
Use a constant sprintf format to silence compiler warning
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/3d114b63b253605eb60055c910aa2e55c98d5ed2
Modified Files
--
src/backend/storage/file/fd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Use "transient" files for blind writes, take 2
"Blind writes" are a mechanism to push buffers down to disk when
evicting them; since they may belong to different databases than the one
a backend is connected to, the backend does not necessarily have a
relation to link them to, and thus no way to b
Add comment about pg_ctl stop
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/d69149ed71cc4f073f222f11f702a20a6d279e0c
Modified Files
--
src/tools/pgindent/README |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--
Sent via pgsql-committers m
Fix locking while setting flags in MySerializableXact.
Even if a flag is modified only by the backend owning the transaction, it's
not safe to modify it without a lock. Another backend might be setting or
clearing a different flag in the flags field concurrently, and that
operation might be lost b
Work around gcc 4.6.0 bug that breaks WAL replay.
ReadRecord's habit of using both direct references to tmpRecPtr and
references to *RecPtr (which is pointing at tmpRecPtr) triggers an
optimization bug in gcc 4.6.0, which apparently has forgotten about
aliasing rules. Avoid the compiler bug, and
Work around gcc 4.6.0 bug that breaks WAL replay.
ReadRecord's habit of using both direct references to tmpRecPtr and
references to *RecPtr (which is pointing at tmpRecPtr) triggers an
optimization bug in gcc 4.6.0, which apparently has forgotten about
aliasing rules. Avoid the compiler bug, and
Work around gcc 4.6.0 bug that breaks WAL replay.
ReadRecord's habit of using both direct references to tmpRecPtr and
references to *RecPtr (which is pointing at tmpRecPtr) triggers an
optimization bug in gcc 4.6.0, which apparently has forgotten about
aliasing rules. Avoid the compiler bug, and
Work around gcc 4.6.0 bug that breaks WAL replay.
ReadRecord's habit of using both direct references to tmpRecPtr and
references to *RecPtr (which is pointing at tmpRecPtr) triggers an
optimization bug in gcc 4.6.0, which apparently has forgotten about
aliasing rules. Avoid the compiler bug, and
Work around gcc 4.6.0 bug that breaks WAL replay.
ReadRecord's habit of using both direct references to tmpRecPtr and
references to *RecPtr (which is pointing at tmpRecPtr) triggers an
optimization bug in gcc 4.6.0, which apparently has forgotten about
aliasing rules. Avoid the compiler bug, and
Log Message:
---
Don't clear the parsed plan in SC_recycle_statement().
Modified Files:
--
psqlodbc:
statement.c (r1.155 -> r1.156)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/statement.c?r1=1.155&r2=1.156)
version.h (r1.192 -> r1
13 matches
Mail list logo