On 07.01.2012 09:58, Heikki Linnakangas wrote:
Here's the patch,
*sigh*, and here's the forgotten attachment.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/storage/lmgr/lwlock.c b/src/backend/storage/lmgr/lwlock.c
index 079eb29..c38a884 100644
On Fri, Jan 6, 2012 at 9:44 PM, Robert Haas robertmh...@gmail.com wrote:
Writing pages during recovery doesn't need WAL. If we crash, we replay
using the already generated WAL.
Which is all fine, except when you start making changes that are not
WAL-logged. Then, you have the same torn page
On Fri, Jan 6, 2012 at 10:24 PM, Robert Haas robertmh...@gmail.com wrote:
Five-minute pgbench run, scale factor 100,
permanent tables, my usual config settings. Somewhat depressingly,
virtually all of the interesting activity still centers around the
same three locks
We've seen clear
On 07.01.2012 12:14, Simon Riggs wrote:
page_checksums is an optional parameter, so you can turn it on or off
on the standby as you wish. People frequently have a standby dedicated
to HA and other standbys for queries. So this is all normal and
natural.
There needs to be a well-documented way
On Fri, Jan 6, 2012 at 10:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Background auto-VACUUMs shouldn't cause this problem because they don't
take snapshots, and ideally it'd be nice if auto-ANALYZE couldn't create
the issue either, but ANALYZE does need a snapshot so it's hard to see
how to
On Sat, Jan 7, 2012 at 10:26 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
There needs to be a well-documented way of turning it on/off. In particular,
from off to on.
There is in the patch.
The checksum field is optional, as is the parameter.
If page_checksums is on,
On Sat, Jan 7, 2012 at 10:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
So there isn't any problem with there being incorrect checksums on
blocks and you can turn the parameter on and off as often and as
easily as you want. I think it can be USERSET but I wouldn't want to
encourage users to
2012/01/07 16:58, Heikki Linnakangas wrote:
On 07.01.2012 00:24, Robert Haas wrote:
It's been a while since I did any testing with LWLOCK_STATS defined,
so I thought it might be about time to do that again and see how
things look. Here's how they looked back in July:
Well I've sent Teodor a personal email asking him if he was interested
and so far no response, so I interpret that as he no longer has
interest in the project.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Jan 6, 2012 at 12:40 PM, Andrew Dunstan and...@dunslane.net
On Saturday, January 07, 2012 04:43:43 PM Dave Cramer wrote:
Well I've sent Teodor a personal email asking him if he was interested
and so far no response, so I interpret that as he no longer has
interest in the project.
I dimly remember him mentioning traveling/hiking planning to travel around
- Original message -
On Saturday, January 07, 2012 04:43:43 PM Dave Cramer wrote:
Well I've sent Teodor a personal email asking him if he was interested
and so far no response, so I interpret that as he no longer has
interest in the project.
I dimly remember him mentioning
On Saturday, January 07, 2012 05:09:41 PM Jan Urbański wrote:
- Original message -
On Saturday, January 07, 2012 04:43:43 PM Dave Cramer wrote:
Well I've sent Teodor a personal email asking him if he was interested
and so far no response, so I interpret that as he no longer has
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
A couple of weeks ago I wrote a little patch that's similar to
LWLOCK_STATS, but it prints out % of wallclock time that is spent
acquiring, releasing, or waiting for a lock. I find that more useful
than the counters.
I would
Simon Riggs si...@2ndquadrant.com writes:
On Fri, Jan 6, 2012 at 10:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Background auto-VACUUMs shouldn't cause this problem because they don't
take snapshots, and ideally it'd be nice if auto-ANALYZE couldn't create
the issue either, but ANALYZE does need
Hi!
Patch where most part of issues are fixed is attached.
On Thu, Dec 29, 2011 at 8:35 PM, Noah Misch n...@leadboat.com wrote:
I find distressing the thought of having two copies of the lossy sampling
code, each implementing the algorithm with different variable names and
levels
of
On an overnight test run, I ran into an unexpected out of space condition.
The writer process was holding on to dozens of file descriptors for
long-ago deleted files from dropped tables and indexes, preventing
their disk space from being freed for reuse.
I think the checkpoint writer process
On tor, 2012-01-05 at 10:04 +, Benedikt Grundmann wrote:
We have recently upgrade two of our biggest postgres databases
to new hardware and minor version number bump (8.4.5 - 8.4.9).
We are experiencing a big performance regression in some queries.
In those cases the planner seems to
There is a bit of confusion around the return values and return
protocols of the sub-main functions in the backend (PostgresMain etc.).
Some functions are declared to return int but never return. It would be
useful to make this consistent by either making them return void or
making some use of
Peter Eisentraut pete...@gmx.net writes:
I suggest that we change PostgresMain(), PostmasterMain(), BackendRun(),
WalSenderMain(), and WalSndLoop() to return void as well.
I agree this code is not very consistent or useful, but one question:
what should the callers do if one of these functions
On 07.01.2012 19:18, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
A couple of weeks ago I wrote a little patch that's similar to
LWLOCK_STATS, but it prints out % of wallclock time that is spent
acquiring, releasing, or waiting for a lock. I find that more
On 6 January 2012 21:14, Tom Lane t...@sss.pgh.pa.us wrote:
When there are lots of duplicates of a particular indexed value, the
existing code will cause an indexscan to search them in physical order,
whereas if we remove the existing logic it'll be random --- in
particular, accesses to the
21 matches
Mail list logo
