On 17 April 2013 22:36, Bruce Momjian wrote:
>> > I would like to know the answer of how an upgrade from checksum to
>> > no-checksum would behave so I can modify pg_upgrade to allow it.
>>
>> Why? 9.3 pg_upgrade certainly doesn't need it. When we get to 9.4, if
>> someone has checksums enabled a
Peter Eisentraut writes:
> Offhand, that seems about enough, but I'm just beginning to explore.
I'm interested into hearing about any such use case…
> Chances are, event triggers will end up somewhere near the top of the
> release announcements, so we should have a consistent message about what
On Wed, Apr 17, 2013 at 11:08 PM, Andres Freund wrote:
> On 2013-04-17 18:16:36 -0700, Daniel Farina wrote:
>> The original paper is often shorthanded "Castagnoli 93", but it exists
>> in the IEEE's sphere of influence and is hard to find a copy of.
>> Luckily, a pretty interesting survey paper di
On Thu, Apr 18, 2013 at 5:08 AM, Greg Smith wrote:
> On 4/17/13 8:56 PM, Ants Aasma wrote:
>>
>> Nothing from the two points, but the CRC calculation algorithm can be
>> switched out for slice-by-4 or slice-by-8 variant. Speed up was around
>> factor of 4 if I remember correctly...I can provide yo
On Thu, Apr 18, 2013 at 09:17:39AM +0100, Simon Riggs wrote:
> On 17 April 2013 22:36, Bruce Momjian wrote:
>
> >> > I would like to know the answer of how an upgrade from checksum to
> >> > no-checksum would behave so I can modify pg_upgrade to allow it.
> >>
> >> Why? 9.3 pg_upgrade certainly d
Dimitri Fontaine escribió:
> Peter Eisentraut writes:
> > Offhand, that seems about enough, but I'm just beginning to explore.
>
> I'm interested into hearing about any such use case…
>
> > Chances are, event triggers will end up somewhere near the top of the
> > release announcements, so we sho
On 4/18/13 5:05 AM, Dimitri Fontaine wrote:
> Peter Eisentraut writes:
>> > Offhand, that seems about enough, but I'm just beginning to explore.
> I'm interested into hearing about any such use case…
Without going into too many details (because I don't have them yet), I
was thinking about trigger
Alvaro Herrera writes:
> You can be as much silent as you want in marketing materials (though
> maybe Berkus will disagree with you about being silent there), but it is
> not admissible to be silent in the documentation or pretend the feature
> is not there. Whatever got committed, however small,
Peter Eisentraut writes:
> Without going into too many details (because I don't have them yet), I
> was thinking about triggering an external test suite whenever there is a
> schema change in the database.
So if all you want to know about is that something did change in the
schema to trigger your
Dimitri Fontaine escribió:
> Alvaro Herrera writes:
> > You can be as much silent as you want in marketing materials (though
> > maybe Berkus will disagree with you about being silent there), but it is
> > not admissible to be silent in the documentation or pretend the feature
> > is not there. W
On 4/12/2013 1:57 PM, Tom Lane wrote:
Kevin Grittner writes:
Tom Lane wrote:
I think that the minimum appropriate fix here is to revert the hunk
I quoted, ie take out the suppression of stats reporting and analysis.
I'm not sure I understand -- are you proposing that is all we do
for both
On 4/12/2013 2:08 PM, Alvaro Herrera wrote:
Tom Lane escribió:
Are you saying you intend to revert that whole concept? That'd be
okay with me, I think. Otherwise we need some thought about how to
inform the stats collector what's really happening.
Maybe what we need is to consider table tru
On 4/18/2013 11:44 AM, Jan Wieck wrote:
Yes, that was the rationale behind it combined with "don't change
function call sequences and more" all over the place.
function call signatures
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
S
On Thu, Apr 18, 2013 at 5:57 PM, Ants Aasma wrote:
> I'll generate an avalanche diagram for CRC32C too, but it will take a
> while even if I use a smaller dataset.
Well that was useless... In CRC flipping each bit in the input flips
preset pattern of bits in the output regardless of the actual da
On Wed, 2013-04-17 at 20:21 -0400, Greg Smith wrote:
> -Original checksum feature used Fletcher checksums. Its main problems,
> to quote wikipedia, include that it "cannot distinguish between blocks
> of all 0 bits and blocks of all 1 bits".
That is fairly easy to fix by using a different modul
* Greg Smith:
> The TCP/IP checksum spec is at https://tools.ietf.org/html/rfc793 ;
> its error detection limitations are described at
> http://www.noahdavids.org/self_published/CRC_and_checksum.html ; and a
> good article about optimizing its code is at
> http://www.locklessinc.com/articles/tcp_c
On Apr18, 2013, at 19:04 , Jeff Davis wrote:
> On Wed, 2013-04-17 at 20:21 -0400, Greg Smith wrote:
>> -Original checksum feature used Fletcher checksums. Its main problems,
>> to quote wikipedia, include that it "cannot distinguish between blocks
>> of all 0 bits and blocks of all 1 bits".
>
On Thu, Apr 18, 2013 at 8:05 PM, Florian Pflug wrote:
> On Apr18, 2013, at 19:04 , Jeff Davis wrote:
>> On Wed, 2013-04-17 at 20:21 -0400, Greg Smith wrote:
>>> -Original checksum feature used Fletcher checksums. Its main problems,
>>> to quote wikipedia, include that it "cannot distinguish betw
On Apr18, 2013, at 18:48 , Ants Aasma wrote:
> On Thu, Apr 18, 2013 at 5:57 PM, Ants Aasma wrote:
>> I'll generate an avalanche diagram for CRC32C too, but it will take a
>> while even if I use a smaller dataset.
>
> Well that was useless... In CRC flipping each bit in the input flips
> preset p
On Thu, Apr 18, 2013 at 8:15 PM, Florian Pflug wrote:
> So either the CRC32-C polynomial isn't irreducible, or there something
> fishy going on. Could there be a bug in your CRC implementation? Maybe
> a mixup between big and little endian, or something like that?
I'm suspecting an implementation
On Thu, 2013-04-18 at 19:05 +0200, Florian Pflug wrote:
> On Apr18, 2013, at 19:04 , Jeff Davis wrote:
> > On Wed, 2013-04-17 at 20:21 -0400, Greg Smith wrote:
> >> -Original checksum feature used Fletcher checksums. Its main problems,
> >> to quote wikipedia, include that it "cannot distinguish
On Thu, Apr 18, 2013 at 8:24 PM, Ants Aasma wrote:
> On Thu, Apr 18, 2013 at 8:15 PM, Florian Pflug wrote:
>> So either the CRC32-C polynomial isn't irreducible, or there something
>> fishy going on. Could there be a bug in your CRC implementation? Maybe
>> a mixup between big and little endian,
I just found out that if you use continuous archiving and online
backups, it's surprisingly difficult to restore a backup, without
replaying any more WAL than necessary.
If you don't set a recovery target, PostgreSQL will recover all the WAL
it finds. You can set recovery target time to a poin
On 18.04.2013, at 20:02, Ants Aasma wrote:
> On Thu, Apr 18, 2013 at 8:24 PM, Ants Aasma wrote:
>> On Thu, Apr 18, 2013 at 8:15 PM, Florian Pflug wrote:
>>> So either the CRC32-C polynomial isn't irreducible, or there something
>>> fishy going on. Could there be a bug in your CRC implementation?
On Thu, Apr 18, 2013 at 6:04 PM, Florian Weimer wrote:
> The TCP checksum is too weak to be practical. Every now an then, I
> see data transfers where the checksum is valid, but the content
> contains bit flips.
Well of course, it's only a 16-bit checksum. 64k packets isn't very
many so if you'r
25 matches
Mail list logo
