On Sun, 2012-02-19 at 21:49 +, Simon Riggs wrote:
On Thu, Feb 16, 2012 at 11:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
v8 attached
v10 attached.
This patch covers all the valid concerns discussed and has been
extensively tested.
Is there something I can do to help get this
On Sun, 2012-02-19 at 21:49 +, Simon Riggs wrote:
On Thu, Feb 16, 2012 at 11:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
v8 attached
v10 attached.
This patch covers all the valid concerns discussed and has been
extensively tested.
I expect to commit this in about 24 hours,
On 23 February 2012 01:39, Robert Haas robertmh...@gmail.com wrote:
Thanks for testing this. The graph obscures a bit how much percentage
change we're talking about here - could you post the raw tps numbers?
Sorry for not following up on this until now. The report is available from:
On Fri, Mar 2, 2012 at 2:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
One thing I'm not too sure about is how to extend the page format to
handle optional features. For example, suppose we want to add 2 bytes
to the page header for a checksum (or 4
On Sun, Feb 19, 2012 at 1:49 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, Feb 16, 2012 at 11:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
v8 attached
v10 attached.
This patch covers all the valid concerns discussed and has been
extensively tested.
If I turn wal_level to
On Wed, Feb 29, 2012 at 5:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Easier for who? I don't care for the idea of code that has to cope with
two page formats, or before long N page
And how would a DBA know that?
We'd add a column to pg_class that tracks which page version is in use
for each relation.
So a relation can't have some pages in Version 9.2, and other pages in
version 9.3? How will this work for 2TB tables?
--
Josh Berkus
PostgreSQL Experts Inc.
On Thu, Mar 1, 2012 at 12:42 PM, Josh Berkus j...@agliodbs.com wrote:
And how would a DBA know that?
We'd add a column to pg_class that tracks which page version is in use
for each relation.
So a relation can't have some pages in Version 9.2, and other pages in
version 9.3? How will this
So a relation can't have some pages in Version 9.2, and other pages in
version 9.3? How will this work for 2TB tables?
Not very well, but better than Tom's proposal to require upgrading the
entire cluster in a single off-line operation.
Yes, but the result will be that anyone with a 2TB
Robert Haas robertmh...@gmail.com writes:
So a relation can't have some pages in Version 9.2, and other pages in
version 9.3? How will this work for 2TB tables?
Not very well, but better than Tom's proposal to require upgrading the
entire cluster in a single off-line operation.
WTF? That
On Thu, Mar 1, 2012 at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So a relation can't have some pages in Version 9.2, and other pages in
version 9.3? How will this work for 2TB tables?
Not very well, but better than Tom's proposal to require
Excerpts from Robert Haas's message of jue mar 01 21:23:06 -0300 2012:
On Thu, Mar 1, 2012 at 4:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So a relation can't have some pages in Version 9.2, and other pages in
version 9.3? How will this work for
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of jue mar 01 21:23:06 -0300 2012:
and that, further, you were arguing that we should not support
multiple page versions.
I don't think we need to support multiple page versions, if multiple
means 2.
On Thu, Mar 1, 2012 at 8:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of jue mar 01 21:23:06 -0300 2012:
and that, further, you were arguing that we should not support
multiple page versions.
I don't think we
Robert Haas robertmh...@gmail.com writes:
One thing I'm not too sure about is how to extend the page format to
handle optional features. For example, suppose we want to add 2 bytes
to the page header for a checksum (or 4 bytes, or any other number).
Ideally, I'd like to not use up those 2
On Thu, Mar 1, 2012 at 9:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
One thing I'm not too sure about is how to extend the page format to
handle optional features. For example, suppose we want to add 2 bytes
to the page header for a checksum (or 4
On 22.02.2012 14:30, Simon Riggs wrote:
On Wed, Feb 22, 2012 at 7:06 AM, Noah Mischn...@leadboat.com wrote:
On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
Another disadvantage of the current scheme is that there's no
particularly easy way to know that your whole cluster has
On Wed, Feb 29, 2012 at 2:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.02.2012 14:30, Simon Riggs wrote:
On Wed, Feb 22, 2012 at 7:06 AM, Noah Mischn...@leadboat.com wrote:
On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
Another disadvantage of
On 29.02.2012 17:01, Simon Riggs wrote:
On Wed, Feb 29, 2012 at 2:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.02.2012 14:30, Simon Riggs wrote:
Agreed. No reason to change a checksum unless we rewrite the block, no
matter whether page_checksums is on or off.
On Wed, Feb 29, 2012 at 3:30 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Surely it can be done online. You'll just need a third state between off and
on, where checksums are written but not verified, while the cluster is
scanned.
Are you saying you would accept the patch
On 29.02.2012 17:42, Simon Riggs wrote:
On Wed, Feb 29, 2012 at 3:30 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Surely it can be done online. You'll just need a third state between off and
on, where checksums are written but not verified, while the cluster is
scanned.
On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Are you saying you would accept the patch if we had this?
I think I would still be uncomfortable with the hacks in the page header.
There are no hacks. There are some carefully designed changes with
On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Are you saying you would accept the patch if we had this?
I think I would still be uncomfortable with the hacks in the
On Wed, Feb 29, 2012 at 12:26 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Feb 29, 2012 at 4:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
On Wed, Feb 29, 2012 at 5:44 PM, Robert Haas robertmh...@gmail.com wrote:
You have comments from three different people, all experienced
hackers, disagreeing with this position;
Who is the third person you speak of? Perhaps they will speak again if
they wish to be heard.
Tom Lane. It was
On Wed, Feb 29, 2012 at 4:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Are you saying you would accept the patch if we
On 29.02.2012 19:54, Simon Riggs wrote:
I'm beginning to lose faith that objections are being raised at a
rational level. It's not a panel game with points for clever answers,
its an engineering debate about how to add features real users want.
And they do want, so let me solve the problems by
Excerpts from Heikki Linnakangas's message of mié feb 29 16:09:02 -0300 2012:
On 29.02.2012 19:54, Simon Riggs wrote:
I'm beginning to lose faith that objections are being raised at a
rational level. It's not a panel game with points for clever answers,
its an engineering debate about how
On Wed, Feb 29, 2012 at 2:09 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 29.02.2012 19:54, Simon Riggs wrote:
I'm beginning to lose faith that objections are being raised at a
rational level. It's not a panel game with points for clever answers,
its an engineering
On 29.02.2012 21:18, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mié feb 29 16:09:02 -0300 2012:
I thought my view on how this should be done was already clear, but just
in case it isn't, let me restate: Enlarge the page header to make room
for the checksum. To handle
On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Note that if we want such an utility to walk and transform pages, we
probably need a marker in the catalogs somewhere so that pg_upgrade can
make sure that it was done in all candidate tables -- which is something
On 29.02.2012 21:30, Robert Haas wrote:
On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Note that if we want such an utility to walk and transform pages, we
probably need a marker in the catalogs somewhere so that pg_upgrade can
make sure that it was done in
Excerpts from Heikki Linnakangas's message of mié feb 29 16:29:26 -0300 2012:
On 29.02.2012 21:18, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of mié feb 29 16:09:02 -0300
2012:
I thought my view on how this should be done was already clear, but just
in case it
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 29.02.2012 21:30, Robert Haas wrote:
On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Note that if we want such an utility to walk and transform pages, we
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The utility would run in the old cluster before upgrading, so the the flag
would have to be present in the old version. pg_upgrade would check that the
flag
Excerpts from Tom Lane's message of mié feb 29 18:34:27 -0300 2012:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The utility would run in the old cluster before upgrading, so the the flag
would
On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The utility would run in the old cluster before upgrading, so the the flag
would have to
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Easier for who? I don't care for the idea of code that has to cope with
two page formats, or before long N page formats, because if we don't
have some mechanism like this then we will
On 2/29/12 3:53 PM, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mié feb 29 18:34:27 -0300 2012:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The utility would run in the old cluster
Jim Nasby j...@nasby.net writes:
On 2/29/12 3:53 PM, Alvaro Herrera wrote:
.. in fact this is precisely what killed Zdenek Kotala's idea of
upgrading.
This is also why Simon has avoided the whole upgrade thing with his 16 bit
checksum idea (otherwise presumably we'd be looking at bigger
On Wed, Feb 22, 2012 at 7:06 AM, Noah Misch n...@leadboat.com wrote:
On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
On Sun, Feb 19, 2012 at 11:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
So, when the page has a checksum, PD_CHECKSUM2 is not set, and when it
doesn't have a
On Tue, Feb 21, 2012 at 5:07 AM, Noah Misch n...@leadboat.com wrote:
We do, in numerous places, drop a shared buffer content lock and reacquire it
in exclusive mode. However, the existing users of that pattern tend to trade
the lock, complete subsequent work, and unlock the buffer all within
I decided that it would be worth benchmarking this patch.
Specifically, I tested:
master, as a basis of comparison
checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'on'
checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'off'
This test was performed using
On Wed, Feb 22, 2012 at 11:17:53PM +, Peter Geoghegan wrote:
I decided that it would be worth benchmarking this patch.
Specifically, I tested:
master, as a basis of comparison
checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'on'
On Wed, Feb 22, 2012 at 6:17 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
I decided that it would be worth benchmarking this patch.
Specifically, I tested:
master, as a basis of comparison
checksum16_with_wallogged_hint_bits.v10.patch, page_checksums = 'on'
On Mon, Feb 20, 2012 at 08:57:08AM -0500, Robert Haas wrote:
On Mon, Feb 20, 2012 at 4:18 AM, Simon Riggs si...@2ndquadrant.com wrote:
What straightforward implementation is that?? This *is* the straightforward
one.
God knows what else we'd break if we drop the lock, reacquire as an
On Tue, Feb 21, 2012 at 10:07 AM, Noah Misch n...@leadboat.com wrote:
Consequently, I find the idea of requiring
a spinlock acquisition to read or write pd_lsn/pd_tli under BUFFER_LOCK_SHARE
to be a sensible one.
OK
Within that umbrella, some details need attention:
- Not all
On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
On Sun, Feb 19, 2012 at 11:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
So, when the page has a checksum, PD_CHECKSUM2 is not set, and when it
doesn't have a checksum, PD_CHECKSUM2 is not set? ?What good does that
do?
As
On Mon, Feb 20, 2012 at 12:42 AM, Robert Haas robertmh...@gmail.com wrote:
I think we could do worse than this patch, but I don't really believe
it's ready for commit. We don't have a single performance number
showing how much of a performance regression this causes, either on
the master or
On Mon, Feb 20, 2012 at 4:18 AM, Simon Riggs si...@2ndquadrant.com wrote:
What straightforward implementation is that?? This *is* the straightforward
one.
God knows what else we'd break if we drop the lock, reacquire as an
exclusive, then drop it again and reacquire in shared mode. Code
On 2/20/12 5:57 AM, Robert Haas wrote:
3. You're rearranging the page header in a way that I find ugly and baroque.
Guys, are we talking about an on-disk format change? If so, this may
need to be kicked out of 9.2 ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
On Mon, Feb 20, 2012 at 12:53 PM, Josh Berkus j...@agliodbs.com wrote:
On 2/20/12 5:57 AM, Robert Haas wrote:
3. You're rearranging the page header in a way that I find ugly and baroque.
Guys, are we talking about an on-disk format change? If so, this may
need to be kicked out of 9.2 ...
Guys, are we talking about an on-disk format change? If so, this may
need to be kicked out of 9.2 ...
Yes, we are. Simon's gone to some pains to make it backward
compatible, but IMHO it's a lot messier and less future-proof than it
could be with some more work, and if we commit this
On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
Another disadvantage of the current scheme is that there's no
particularly easy way to know that your whole cluster has checksums.
No matter how we implement checksums, you'll have to rewrite every
table in the cluster in order to
On Mon, Feb 20, 2012 at 6:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Feb 20, 2012 at 12:53 PM, Josh Berkus j...@agliodbs.com wrote:
On 2/20/12 5:57 AM, Robert Haas wrote:
3. You're rearranging the page header in a way that I find ugly and baroque.
Guys, are we talking about an
On Mon, Feb 20, 2012 at 11:09 PM, Bruce Momjian br...@momjian.us wrote:
On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
Another disadvantage of the current scheme is that there's no
particularly easy way to know that your whole cluster has checksums.
No matter how we implement
On Mon, Feb 20, 2012 at 11:23:42PM +, Simon Riggs wrote:
If you use pg_upgrade, and enable the checksum GUC, your database will
become progressively checksummed, and as Simon pointed out, the only
clean way is VACUUM FULL. It is quite hard to estimate the checksum
coverage of a
On Thu, Feb 16, 2012 at 1:53 PM, Robert Haas robertmh...@gmail.com wrote:
+ /*
+ * If we're in recovery we cannot dirty a page
because of a hint.
+ * We can set the hint, just not dirty the page as a
result so
+
On Sun, Feb 19, 2012 at 4:35 PM, Simon Riggs si...@2ndquadrant.com wrote:
We don't need to wait until nobody has it set, we just need to wait
for the people that had it set when we first checked to be out of that
state momentarily.
I've just finished doing some performance analysis on various
On Sun, Feb 19, 2012 at 11:35 AM, Simon Riggs si...@2ndquadrant.com wrote:
Doesn't this seem awfully bad for performance on Hot Standby servers?
I agree that it fixes the problem with un-WAL-logged pages there, but
I seem to recall some recent complaining about performance features
that work
On Sun, Feb 19, 2012 at 10:04 PM, Robert Haas robertmh...@gmail.com wrote:
To me, it seems that you are applying a double standard. You have
twice attempted to insist that I do extra work to make major features
that I worked on - unlogged tables and index-only scans - work in Hot
Standby
On Sun, Feb 19, 2012 at 10:04 PM, Robert Haas robertmh...@gmail.com wrote:
As explained in detailed comments, the purpose of this is to implement
Heikki's suggestion that we have a bit set to zero so we can detect
failures that cause a run of 1s.
I think it's nonsensical to pretend that
On Sun, Feb 19, 2012 at 6:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, Feb 19, 2012 at 10:04 PM, Robert Haas robertmh...@gmail.com wrote:
To me, it seems that you are applying a double standard. You have
twice attempted to insist that I do extra work to make major features
that I
On Sun, Feb 19, 2012 at 6:57 PM, Simon Riggs si...@2ndquadrant.com wrote:
I thought it was a reasonable and practical idea from Heikki. The bit
is not selected arbitrarily, it is by design adjacent to one of the
other bits. So overall, 3 bits need to be set to a precise value and a
run of 1s
On Thu, Feb 16, 2012 at 1:53 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 16, 2012 at 6:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
v8 attached
It's hard to believe that this version has been tested terribly
thoroughly, because it doesn't compile.
I'm just back home from a
A Dijous, 16 de febrer de 2012 12:16:31, Simon Riggs va escriure:
v8 attached
Maybe the docs should include what will happen if the checksum is not correct?
--
Albert Cervera i Areny
http://www.NaN-tic.com
Tel: +34 93 553 18 03
http://twitter.com/albertnan
http://www.nan-tic.com/blog
On Thu, Feb 16, 2012 at 6:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
v8 attached
It's hard to believe that this version has been tested terribly
thoroughly, because it doesn't compile.
+ LockBufHdr(buf);
+
+ /*
+* Run PageGetLSN while holding header lock.
+*/
+
On Wed, Feb 8, 2012 at 2:05 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Feb 08, 2012 at 11:40:34AM +, Simon Riggs wrote:
On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
On Thu, Jan 26, 2012 at 8:20 PM,
On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
This patch uses FPIs to guard
On Wed, Feb 08, 2012 at 11:40:34AM +, Simon Riggs wrote:
On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch n...@leadboat.com wrote:
This patch uses FPIs to guard
On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
v7
Thanks very much for the review. Just realised I hadn't actually replied...
This patch uses FPIs to guard against torn hint writes, even when the
checksums are
On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
This patch uses FPIs to guard against torn hint writes, even when the
checksums are disabled. ?One
On Mon, Feb 6, 2012 at 4:48 AM, Bruce Momjian br...@momjian.us wrote:
On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
Also, as far as I can see
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2012 05:48, Bruce Momjian wrote:
On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
In the proposed scheme there are two flag bits set on the page to
indicate whether the field is
On 06.02.2012 10:05, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2012 05:48, Bruce Momjian wrote:
Thanks. Clearly we don't need 16 bits to represent our page version
number because we rarely change it. The other
On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2012 10:05, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.02.2012 05:48, Bruce Momjian wrote:
Thanks. Clearly
On 06.02.2012 11:25, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Good idea. However, the followup idea to that discussion was to not only
avoid the I/O needed to mark tuples as frozen, but to avoid xid wraparound
altogether,
On Mon, Feb 06, 2012 at 09:05:19AM +, Simon Riggs wrote:
In any case, I think it's a very bad idea to remove the page version field.
How are we supposed to ever be able to change the page format again if we
don't even have a version number on the page? I strongly oppose removing it.
On Mon, Feb 06, 2012 at 08:51:34AM +0100, Heikki Linnakangas wrote:
I wonder if we should just dedicate 3 page header bits, call that the
page version number, and set this new version number to 1, and assume
all previous versions were zero, and have them look in the old page
version location
On Mon, Feb 06, 2012 at 12:59:59PM -0500, Bruce Momjian wrote:
I'm also not very comfortable with the idea of having flags on the page
indicating whether it has a checksum or not. It's not hard to imagine a
software of firmware bug or hardware failure that would cause pd_flags
field
On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
Also, as far as I can see this patch usurps the page version field,
which I find unacceptably short-sighted. Do you really think this is
the last page layout
On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian br...@momjian.us wrote:
On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
Also, as far as I can see this patch usurps the page version field,
which I find unacceptably
On 06.02.2012 05:48, Bruce Momjian wrote:
On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
In the proposed scheme there are two flag bits set on the page to
indicate whether the field is used as a checksum rather than a version
number. So its possible the checksum could look like a
On Sun, Dec 25, 2011 at 04:25:19PM +0100, Martijn van Oosterhout wrote:
On Sat, Dec 24, 2011 at 04:01:02PM +, Simon Riggs wrote:
On Sat, Dec 24, 2011 at 3:54 PM, Andres Freund and...@anarazel.de wrote:
Why don't you use the same tricks as the former patch and copy the buffer,
compute
On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
Also, as far as I can see this patch usurps the page version field,
which I find unacceptably short-sighted. Do you really think this is
the last page layout change we'll ever make?
No, I don't. I hope and expect the next page
On Fri, Jan 27, 2012 at 4:07 PM, Dan Scales sca...@vmware.com wrote:
The advantage of putting the checksum calculation in smgrwrite() (or
mdwrite()) is that it catches a bunch of page writes that don't go through
the buffer pool (see calls to smgrwrite() in nbtree.c, nbtsort.c, spginsert.c)
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scales sca...@vmware.com wrote:
The advantage of putting the checksum calculation in smgrwrite() (or
mdwrite()) is that it catches a bunch of page writes that don't go through
the buffer pool (see calls to smgrwrite() in nbtree.c, nbtsort.c, spginsert.c)
On 28.01.2012 15:49, Simon Riggs wrote:
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scalessca...@vmware.com wrote:
Also, I missed this before: don't you want to add the checksum calculation
(PageSetVerificationInfo) to mdextend() (or preferably smgrextend()) as well?
Otherwise, you won't be
On Thu, Jan 26, 2012 at 7:01 PM, Dan Scales sca...@vmware.com wrote:
I'm not sure why you moved the checksum calculation (PageSetVerificationInfo)
to mdwrite() rather than smgrwrite(). If there were every another storage
backend, it would have to duplicate the checksum check, right? Is
: [HACKERS] 16-bit page checksums for 9.2
On Thu, Jan 26, 2012 at 7:01 PM, Dan Scales sca...@vmware.com wrote:
I'm not sure why you moved the checksum calculation (PageSetVerificationInfo)
to mdwrite() rather than smgrwrite(). If there were every another storage
backend, it would have
On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
v7
This patch uses FPIs to guard against torn hint writes, even when the
checksums are disabled. One could not simply condition them on the
page_checksums setting, though. Suppose page_checksums=off and we're hinting
a page
, January 26, 2012 12:20:39 PM
Subject: Re: [HACKERS] 16-bit page checksums for 9.2
On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
v7
This patch uses FPIs to guard against torn hint writes, even when the
checksums are disabled. One could not simply condition them on the
page_checksums
On Sun, Jan 8, 2012 at 2:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, Jan 7, 2012 at 11:09 AM, Simon Riggs si...@2ndquadrant.com wrote:
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
On Jan 6, 2012, at 4:36 AM, Andres Freund wrote:
On Friday, January 06, 2012 11:30:53 AM Simon Riggs wrote:
On Fri, Jan 6, 2012 at 1:10 AM, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@2ndquadrant.com) wrote:
I discover that non-all-zeroes holes are fairly common, just not very
On 1/7/12 5:26 AM, Heikki Linnakangas wrote:
Perhaps there
needs to be a third setting, calculate-but-dont-verify, where CRCs are
updated but existing CRCs are not expected to be correct. And a utility
to scan through your database and fix any incorrect CRCs, so that after
that's run in
On 12/30/11 9:44 AM, Aidan Van Dyk wrote:
So moving to this new double-write-area bandwagon, we move from a WAL
FPW synced at the commit, collect as many other writes, then final
sync type system to a system where *EVERY* write requires syncs of 2
separate 8K writes at buffer write-out time.
On Sat, Jan 7, 2012 at 11:09 AM, Simon Riggs si...@2ndquadrant.com wrote:
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
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 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 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,
1 - 100 of 170 matches
Mail list logo
