On Sat, Dec 24, 2011 at 4:54 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Sorry. Last minute changes, didn't retest properly.. Here's another attempt.
When I tested the patch, initdb failed:
$ initdb -D data
initializing dependencies ... PANIC: could not locate a
On Thu, Dec 22, 2011 at 4:20 PM, Robert Haas robertmh...@gmail.com wrote:
You mentioned latency so this morning I ran pgbench with -l and
graphed the output. There are latency spikes every few seconds. I'm
attaching the overall graph as well as the graph of the last 100
seconds, where the
After the various recent discussions on list, I present what I believe
to be a working patch implementing 16-but checksums on all buffer
pages.
page_checksums = on | off (default)
There are no required block changes; checksums are optional and some
blocks may have a checksum, others not. This
On Thu, Dec 22, 2011 at 9:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Dec 22, 2011 at 9:50 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Simon, does it sound like I understand your proposal?
Yes, thanks for restating.
I've implemented that proposal, posting patch on a
On Fri, Dec 23, 2011 at 12:30 PM, Robert Haas robertmh...@gmail.com wrote:
Well, because it doesn't operate on strings.
I argued when we added string_agg that it ought to be called
concat_agg, or something like that, but I got shouted down. So now
here we are.
+1. Using the input type
Simon Riggs si...@2ndquadrant.com writes:
After the various recent discussions on list, I present what I believe
to be a working patch implementing 16-but checksums on all buffer
pages.
I think locking around hint-bit-setting is likely to be unworkable from
a performance standpoint. I also
On Saturday, December 24, 2011 03:46:16 PM Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
After the various recent discussions on list, I present what I believe
to be a working patch implementing 16-but checksums on all buffer
pages.
I think locking around hint-bit-setting is
On Sat, Dec 24, 2011 at 2:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
After the various recent discussions on list, I present what I believe
to be a working patch implementing 16-but checksums on all buffer
pages.
I think locking around
On Sat, Dec 24, 2011 at 3:54 PM, Andres Freund and...@anarazel.de wrote:
On Saturday, December 24, 2011 03:46:16 PM Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
After the various recent discussions on list, I present what I believe
to be a working patch implementing 16-but
On Sat, Dec 24, 2011 at 3:51 PM, Aidan Van Dyk ai...@highrise.ca wrote:
Not an expert here, but after reading through the patch quickly, I
don't see anything that changes the torn-page problem though, right?
Hint bits aren't wal-logged, and FPW isn't forced on the hint-bit-only
dirty, right?
On Saturday, December 24, 2011 05:01:02 PM Simon Riggs wrote:
On Sat, Dec 24, 2011 at 3:54 PM, Andres Freund and...@anarazel.de wrote:
On Saturday, December 24, 2011 03:46:16 PM Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
After the various recent discussions on list, I
On Thu, Dec 22, 2011 at 5:52 PM, Andrew Dunstan and...@dunslane.net wrote:
I've looked at that, and it was discussed a bit previously. It's more
complex because it requires that we keep track of (or calculate) where we
are on the line,
You might try a compromise, just spit out all the columns
On Fri, Dec 16, 2011 at 3:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
On its own that sounds dangerous, but its not. When we need to confirm
the prev link we already know what we expect it to be, so CRC-ing it
is overkill. That isn't true of any other part of the WAL record, so
the prev link is
On Sat, Dec 24, 2011 at 4:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
Checksums merely detect a problem, whereas FPWs correct a problem if
it happens, but only in crash situations.
So this does nothing to remove the need for FPWs, though checksum
detection could be used for double write
14 matches
Mail list logo
