On Sun, 2012-02-19 at 21:49 +, Simon Riggs wrote:
> On Thu, Feb 16, 2012 at 11:16 AM, Simon Riggs 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 ready for the
On Sun, 2012-02-19 at 21:49 +, Simon Riggs wrote:
> On Thu, Feb 16, 2012 at 11:16 AM, Simon Riggs 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, so last call
On Sun, Feb 19, 2012 at 1:49 PM, Simon Riggs wrote:
> On Thu, Feb 16, 2012 at 11:16 AM, Simon Riggs wrote:
>
>> v8 attached
>
> v10 attached.
>
> This patch covers all the valid concerns discussed and has been
> extensively tested.
If I turn wal_level to anything other than minimal, this fails t
On Fri, Mar 2, 2012 at 2:11 AM, Tom Lane wrote:
> Robert Haas 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).
>> Ideall
On 23 February 2012 01:39, Robert Haas 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:
http://pagechecksum.staticlou
On Thu, Mar 1, 2012 at 9:11 PM, Tom Lane wrote:
> Robert Haas 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).
>> Ideall
Robert Haas 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 bytes on pages that a
On Thu, Mar 1, 2012 at 8:32 PM, Tom Lane wrote:
> Alvaro Herrera 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 ver
Alvaro Herrera 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.
That's exactly the poin
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 wrote:
> > Robert Haas 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 w
On Thu, Mar 1, 2012 at 4:08 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 was most certainl
>> 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
On Thu, Mar 1, 2012 at 12:42 PM, Josh Berkus 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 work fo
>> 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.
http:
On Wed, Feb 29, 2012 at 5:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane 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
Jim Nasby 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 checksums
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 Haas writes:
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
wrote:
The utility would run in the old cluster before upgrading, so the the flag
would have to be present
Robert Haas writes:
> On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane 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 never be able to decide that
>>
On Wed, Feb 29, 2012 at 4:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
>> 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
Excerpts from Tom Lane's message of mié feb 29 18:34:27 -0300 2012:
>
> Robert Haas writes:
> > On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
> > 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_upg
Robert Haas writes:
> On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
> 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 is set, refusing to upgrade if it isn't, with an
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
wrote:
> On 29.02.2012 21:30, Robert Haas wrote:
>>
>> On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
>> wrote:
>>>
>>> Note that if we want such an utility to walk and transform pages, we
>>> probably need a marker in the catalogs somewhere s
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 ca
On 29.02.2012 21:30, Robert Haas wrote:
On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
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 -- whic
On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera
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
> that we should get in
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 upg
On Wed, Feb 29, 2012 at 2:09 PM, Heikki Linnakangas
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 debate about how to add features
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 abou
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 ag
On Wed, Feb 29, 2012 at 4:41 PM, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs wrote:
>> On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
>> wrote:
>>
Are you saying you would accept the patch if we had this?
>>
>>> I think I would still be uncomfortable with the hac
On Wed, Feb 29, 2012 at 5:44 PM, Robert Haas 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 the very
On Wed, Feb 29, 2012 at 12:26 PM, Simon Riggs wrote:
> On Wed, Feb 29, 2012 at 4:41 PM, Robert Haas wrote:
>> On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs wrote:
>>> On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
>>> wrote:
>>>
> Are you saying you would accept the patch if we had thi
On Wed, Feb 29, 2012 at 11:24 AM, Simon Riggs wrote:
> On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
> 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 so
On Wed, Feb 29, 2012 at 3:46 PM, Heikki Linnakangas
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
input from multiple people, in
On 29.02.2012 17:42, Simon Riggs wrote:
On Wed, Feb 29, 2012 at 3:30 PM, Heikki Linnakangas
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
On Wed, Feb 29, 2012 at 3:30 PM, Heikki Linnakangas
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 if we had this?
--
Simon Rigg
On 29.02.2012 17:01, Simon Riggs wrote:
On Wed, Feb 29, 2012 at 2:40 PM, Heikki Linnakangas
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.
This can happen:
1. checksums are i
On Wed, Feb 29, 2012 at 2:40 PM, Heikki Linnakangas
wrote:
> On 22.02.2012 14:30, Simon Riggs wrote:
>>
>> On Wed, Feb 22, 2012 at 7:06 AM, Noah Misch wrote:
>>>
>>> On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
Another disadvantage of the current scheme is that there's n
On 22.02.2012 14:30, Simon Riggs wrote:
On Wed, Feb 22, 2012 at 7:06 AM, Noah Misch 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 h
On Wed, Feb 22, 2012 at 6:17 PM, 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'
>
> checksum16_with_wallogged_hint_bits.v10.pa
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'
>
> checksum16_with_wallogged_hint_
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 pgbench-too
On Tue, Feb 21, 2012 at 5:07 AM, Noah Misch 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 the same
> funct
On Wed, Feb 22, 2012 at 7:06 AM, Noah Misch 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 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
On Sun, Feb 19, 2012 at 05:04:06PM -0500, Robert Haas wrote:
> On Sun, Feb 19, 2012 at 11:35 AM, Simon Riggs 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 explained
On Tue, Feb 21, 2012 at 10:07 AM, Noah Misch 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 BUFFER_LOCK_SHARE caller
On Mon, Feb 20, 2012 at 08:57:08AM -0500, Robert Haas wrote:
> On Mon, Feb 20, 2012 at 4:18 AM, Simon Riggs 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, th
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 Mon, Feb 20, 2012 at 11:09 PM, Bruce Momjian 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 checksums, yo
On Mon, Feb 20, 2012 at 6:22 PM, Robert Haas wrote:
> On Mon, Feb 20, 2012 at 12:53 PM, Josh Berkus 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,
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
>> 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 th
On Mon, Feb 20, 2012 at 12:53 PM, Josh Berkus 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 ...
Yes, we are.
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 p
On Mon, Feb 20, 2012 at 4:18 AM, Simon Riggs 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 tends
> to assume tha
On Mon, Feb 20, 2012 at 12:42 AM, Robert Haas 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 the standby, on
On Sun, Feb 19, 2012 at 6:57 PM, Simon Riggs 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 or 0s will throw an
On Sun, Feb 19, 2012 at 6:33 PM, Simon Riggs wrote:
> On Sun, Feb 19, 2012 at 10:04 PM, Robert Haas 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
On Sun, Feb 19, 2012 at 10:04 PM, Robert Haas 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 there's anything s
On Sun, Feb 19, 2012 at 10:04 PM, Robert Haas 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 mode, despite the exi
On Sun, Feb 19, 2012 at 11:35 AM, Simon Riggs 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 the master b
On Sun, Feb 19, 2012 at 4:35 PM, Simon Riggs 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 aspects
of hint bi
On Thu, Feb 16, 2012 at 1:53 PM, Robert Haas 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 Thu, Feb 16, 2012 at 1:53 PM, Robert Haas wrote:
> On Thu, Feb 16, 2012 at 6:16 AM, Simon Riggs 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 few days off grid.
It's possible it do
On Thu, Feb 16, 2012 at 6:16 AM, Simon Riggs 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.
+*/
+ recptr = Buffer
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 Wed, Feb 8, 2012 at 2:05 PM, Noah Misch wrote:
> On Wed, Feb 08, 2012 at 11:40:34AM +, Simon Riggs wrote:
>> On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch wrote:
>> > On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
>> >> On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch wrote:
>> >> >
On Wed, Feb 08, 2012 at 11:40:34AM +, Simon Riggs wrote:
> On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch wrote:
> > On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
> >> On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch wrote:
> >> > This patch uses FPIs to guard against torn hint writes,
On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch wrote:
> On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
>> On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch wrote:
>> > On Wed, Jan 11, 2012 at 10:12:31PM +, Simon Riggs wrote:
>
>> > This patch uses FPIs to guard against torn hint writes, e
On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
> On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch 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 could not s
On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch 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 disabled. O
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
>
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 loc
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 06.02.2012 11:25, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas
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, by allowing clog to grow indefinite
On Mon, Feb 6, 2012 at 10:02 AM, Heikki Linnakangas
wrote:
> On 06.02.2012 10:05, Simon Riggs wrote:
>>
>> On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
>> wrote:
>>>
>>> On 06.02.2012 05:48, Bruce Momjian wrote:
Thanks. Clearly we don't need 16 bits to represent our page ve
On 06.02.2012 10:05, Simon Riggs wrote:
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
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 good thing is I don't
remember anyone
On Mon, Feb 6, 2012 at 7:51 AM, Heikki Linnakangas
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 used as a checksum ra
On Mon, Feb 6, 2012 at 4:48 AM, Bruce Momjian wrote:
> On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
>> On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian wrote:
>> > On Sat, Dec 24, 2011 at 03:56:58PM +, Simon Riggs wrote:
>> >> > Also, as far as I can see this patch usurps the pag
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 v
On Sun, Feb 05, 2012 at 08:40:09PM +, Simon Riggs wrote:
> On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian 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-sig
On Sun, Feb 5, 2012 at 3:59 AM, Bruce Momjian 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 change w
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 nex
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 wrote:
> > > Why don't you use the same tricks as the former patch and copy the buffer,
> > > compute the checks
On Fri, Jan 27, 2012 at 4:07 PM, Dan Scales 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)
Maybe we should
On 28.01.2012 15:49, Simon Riggs wrote:
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scales 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 checksumming a bunch o
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scales 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)
I'll have anot
Linnakangas"
, "Andres Freund" ,
"Kevin Grittner" , da...@fetter.org,
ai...@highrise.ca, st...@mit.edu, pgsql-hackers@postgresql.org, "Simon Riggs"
Sent: Friday, January 27, 2012 5:19:32 AM
Subject: Re: [HACKERS] 16-bit page checksums for 9.2
On Thu,
On Thu, Jan 26, 2012 at 7:01 PM, Dan Scales 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 there a
> disadvan
o: "Simon Riggs"
Cc: "Heikki Linnakangas" , "Robert Haas"
, "Andres Freund" , "Kevin Grittner"
, da...@fetter.org, ai...@highrise.ca,
st...@mit.edu, pgsql-hackers@postgresql.org
Sent: Thursday, January 26, 2012 12:20:39 PM
Subject: Re: [HACKERS] 16-bit p
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 previousl
On Sun, Jan 8, 2012 at 2:03 PM, Simon Riggs wrote:
> On Sat, Jan 7, 2012 at 11:09 AM, Simon Riggs wrote:
>> 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
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 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 calculate
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 wrote:
>>> * Simon Riggs (si...@2ndquadrant.com) wrote:
I discover that non-all-zeroes holes are fairly common, just not very
fre
On Sat, Jan 7, 2012 at 11:09 AM, Simon Riggs wrote:
> 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 bu
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
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 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
1 - 100 of 171 matches
Mail list logo
