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 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 problem that e
On Fri, Jan 6, 2012 at 10:24 PM, Robert Haas 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 evidence that the perfo
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 o
On Fri, Jan 6, 2012 at 10:25 PM, Tom Lane 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 avoid having it t
On Sat, Jan 7, 2012 at 10:26 AM, Heikki Linnakangas
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, we write a checksum and it is cor
On Sat, Jan 7, 2012 at 10:55 AM, Simon Riggs 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 see turning it of
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:
http://archives.postgresql.
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 wrote:
>
>
> On 01/
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 arou
- 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 t
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 lo
Heikki Linnakangas 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 think that the measurement overhea
Simon Riggs writes:
> On Fri, Jan 6, 2012 at 10:25 PM, Tom Lane 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
>
Hi!
Patch where most part of issues are fixed is attached.
On Thu, Dec 29, 2011 at 8:35 PM, Noah Misch 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 generality. We might so
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 le
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
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 the
Peter Eisentraut 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 *does* return?
On 07.01.2012 19:18, Tom Lane wrote:
Heikki Linnakangas 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 thin
On 6 January 2012 21:14, Tom Lane 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 same heap page ca
21 matches
Mail list logo
