Simon Riggs [EMAIL PROTECTED] writes:
I still do, for multi-user systems. Releasing unused memory from a large
CREATE INDEX will allow that memory to be swapped out, even if the brk
point can't be changed.
Say what? It can get swapped out anyway, whether we free() it or not.
More to the
On Sat, 22 Apr 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Fri, 21 Apr 2006, Tom Lane wrote:
Yeah. NaN == 0 is just silly ...
From what I can tell from the instruction set docs and test programs, the
actual bug/misoptimization is that NaN == anything. Which is even
On Sat, Apr 22, 2006 at 01:49:25PM -0700, David Fetter wrote:
On Sat, Apr 22, 2006 at 01:14:42PM -0700, David Gould wrote:
To avoid running out of swap and triggering the oom killer we have
had to reduce work_mem below what we prefer.
Dunno about your work_mem, but you can make sure the
Kevin Grittner wrote:
On Mon, Mar 20, 2006 at 7:58 pm, in message
[EMAIL PROTECTED], Bruce Momjian
pgman@candle.pha.pa.us wrote:
Tom Lane wrote:
But not once per statement --- in reality, you get a fairly
arbitrary
behavior that will advance in some cases and not others when
dealing
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
The patch as given strikes me as pretty broken --- it does not advance
statement_timestamp when I would expect (AFAICS it only sets it during
transaction start).
Uh, it does advance:
But not once per
The attached patch removes or minimizes some documentation mentions of
backward compatibility for release 7.2 and earlier. I have not altered
any mentions of release 7.3 or later. The release notes were not
modified, so the changes are still documented, just not in the main
docs.
Patch
