On Tue, Apr 3, 2018 at 4:32 PM, Tom Lane wrote:
> I wrote:
> > Magnus Hagander writes:
> >> Unless.. %ld is the wrong thing to print:
> >> static int64 total_checksum_failures;
> >> We should perhaps be using something other than %ld to print that?
>
> > INT64_FORMAT.
>
> BTW, don't just stick I
I wrote:
> Magnus Hagander writes:
>> Unless.. %ld is the wrong thing to print:
>> static int64 total_checksum_failures;
>> We should perhaps be using something other than %ld to print that?
> INT64_FORMAT.
BTW, don't just stick INT64_FORMAT into the message-to-be-translated,
or you'll break thi
Magnus Hagander writes:
> Unless.. %ld is the wrong thing to print:
> static int64 total_checksum_failures;
> We should perhaps be using something other than %ld to print that?
INT64_FORMAT.
regards, tom lane
On Tue, Apr 3, 2018 at 4:25 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > Seems the tests are failing on prairiedog:
> > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?
> nm=prairiedog&dt=2018-04-03%2012%3A15%3A27&stg=pg_basebackup-check
> > I don't have time to dive in right now
Magnus Hagander writes:
> Seems the tests are failing on prairiedog:
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=prairiedog&dt=2018-04-03%2012%3A15%3A27&stg=pg_basebackup-check
> I don't have time to dive in right now, but that seems interesting -- it's
> reporting the failures
On Tue, Apr 3, 2018 at 4:00 PM, Michael Banck
wrote:
> Hi Magnus,
>
> Am 03.04.2018 13:59 schrieb Magnus Hagander :
>
> And of course I forgot that particular part in the first push, so I've
> pushed it as a separate commit.
>
>
> Many thanks for cleaning up the patch and committing it!
>
>
Seems
Hi Magnus,Am 03.04.2018 13:59 schrieb Magnus Hagander :And of course I forgot that particular part in the first push, so I've pushed it as a separate commit. Many thanks for cleaning up the patch and committing it!Michael-- Michael BanckProjektleiter / Senior BeraterTel.: +49 2166 9901-171Fax: +49
On Tue, Apr 3, 2018 at 1:52 PM, Magnus Hagander wrote:
>
>
> On Mon, Apr 2, 2018 at 2:48 PM, Michael Banck
> wrote:
>
>> Hi!
>>
>> On Sun, Apr 01, 2018 at 05:27:21PM +0200, Magnus Hagander wrote:
>> > It might be a micro-optimisation, but ISTM that we shouldn't do the
>> > basename(palloc(fn)) i
On Mon, Apr 2, 2018 at 2:48 PM, Michael Banck
wrote:
> Hi!
>
> On Sun, Apr 01, 2018 at 05:27:21PM +0200, Magnus Hagander wrote:
> > It might be a micro-optimisation, but ISTM that we shouldn't do the
> > basename(palloc(fn)) in is_heap_file() unless we actually need it -- so
> not
> > at the top
Hi!
On Sun, Apr 01, 2018 at 05:27:21PM +0200, Magnus Hagander wrote:
> It might be a micro-optimisation, but ISTM that we shouldn't do the
> basename(palloc(fn)) in is_heap_file() unless we actually need it -- so not
> at the top of the function. (And surely "." and ".." should not occur here?
> I
On Sat, Mar 31, 2018 at 2:54 PM, Michael Banck
wrote:
> Hi,
>
> On Fri, Mar 30, 2018 at 07:46:02AM -0400, Stephen Frost wrote:
> > * Magnus Hagander (mag...@hagander.net) wrote:
> > > On Fri, Mar 30, 2018 at 5:35 AM, David Steele
> wrote:
> > >
> > > > On 3/24/18 10:32 AM, Michael Banck wrote:
>
Hi,
On Fri, Mar 30, 2018 at 07:46:02AM -0400, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Fri, Mar 30, 2018 at 5:35 AM, David Steele wrote:
> >
> > > On 3/24/18 10:32 AM, Michael Banck wrote:
> > > > Am Freitag, den 23.03.2018, 17:43 +0100 schrieb Michael Banck:
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Mar 30, 2018 at 5:35 AM, David Steele wrote:
>
> > On 3/24/18 10:32 AM, Michael Banck wrote:
> > > Am Freitag, den 23.03.2018, 17:43 +0100 schrieb Michael Banck:
> > >> Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steel
On Fri, Mar 30, 2018 at 5:35 AM, David Steele wrote:
> On 3/24/18 10:32 AM, Michael Banck wrote:
> > Am Freitag, den 23.03.2018, 17:43 +0100 schrieb Michael Banck:
> >> Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steele:
> >>> In my experience actual block errors are relatively rare, so
On 3/24/18 10:32 AM, Michael Banck wrote:
> Am Freitag, den 23.03.2018, 17:43 +0100 schrieb Michael Banck:
>> Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steele:
>>> In my experience actual block errors are relatively rare, so there
>>> aren't likely to be more than a few in a file. More
Hi,
Am Freitag, den 23.03.2018, 17:43 +0100 schrieb Michael Banck:
> Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steele:
> > In my experience actual block errors are relatively rare, so there
> > aren't likely to be more than a few in a file. More common are
> > overwritten or transpose
Hi David,
Am Freitag, den 23.03.2018, 10:54 -0400 schrieb David Steele:
> On 3/23/18 5:36 AM, Michael Banck wrote:
> > Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele:
> > >
> > > +if (phdr->pd_checksum != checksum)
> > >
> > > I've attached a patch that adds basic retry func
Hi Michael,
On 3/23/18 5:36 AM, Michael Banck wrote:
> Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele:
>>
>> +if (phdr->pd_checksum != checksum)
>>
>> I've attached a patch that adds basic retry functionality. It's not
>> terrible efficient since it rereads the entire buffer
Hi David,
thanks for the review!
Am Donnerstag, den 22.03.2018, 12:22 -0400 schrieb David Steele:
> On 3/17/18 5:34 PM, Michael Banck wrote:
> > On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
> > I think most people (including those I had off-list discussions about
> > this with)
Hi Magnus,
thanks a lot for looking at my patch!
Am Donnerstag, den 22.03.2018, 15:07 +0100 schrieb Magnus Hagander:
> On Sat, Mar 17, 2018 at 10:34 PM, Michael Banck
> wrote:
> > On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
> > > Possibly open questions:
> > >
> > > 1. I have
Hi Michael,
On 3/17/18 5:34 PM, Michael Banck wrote:
>
> On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
>
> I think most people (including those I had off-list discussions about
> this with) were of the opinion that such an option should be there, so I
> added an additional optio
On Sat, Mar 17, 2018 at 10:34 PM, Michael Banck
wrote:
> Hi,
>
> On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
> > Possibly open questions:
> >
> > 1. I have not so far changed the replication protocol to make verifying
> > checksums optional. I can go about that next if the cons
Hi,
On Fri, Mar 09, 2018 at 10:35:33PM +0100, Michael Banck wrote:
> Possibly open questions:
>
> 1. I have not so far changed the replication protocol to make verifying
> checksums optional. I can go about that next if the consensus is that we
> need such an option (and cannot just check it ever
Hi,
Am Mittwoch, den 28.02.2018, 19:08 +0100 schrieb Michael Banck:
> some installations have data which is only rarerly read, and if they are
> so large that dumps are not routinely taken, data corruption would only
> be detected with some large delay even with checksums enabled.
>
> The attache
Hi Michael,
On 3/5/18 6:36 AM, Stephen Frost wrote:
> * Michael Banck (michael.ba...@credativ.de) wrote:
>
>> So I guess this would have to be sent back via the replication protocol,
>> but I don't see an off-hand way to do this easily?
>
> The final ordinary result set could be extended to inclu
Michael,
* Michael Banck (michael.ba...@credativ.de) wrote:
> Am Montag, den 05.03.2018, 06:36 -0500 schrieb Stephen Frost:
> > * Michael Banck (michael.ba...@credativ.de) wrote:
> > > On Sun, Mar 04, 2018 at 06:19:00PM +0100, Magnus Hagander wrote:
> > > > So sure, if we go with WARNING + exit wi
Hi,
Am Montag, den 05.03.2018, 06:36 -0500 schrieb Stephen Frost:
> Michael,
>
> * Michael Banck (michael.ba...@credativ.de) wrote:
> > On Sun, Mar 04, 2018 at 06:19:00PM +0100, Magnus Hagander wrote:
> > > So sure, if we go with WARNING + exit with an errorcode, that is perhaps
> > > the best co
Michael,
* Michael Banck (michael.ba...@credativ.de) wrote:
> On Sun, Mar 04, 2018 at 06:19:00PM +0100, Magnus Hagander wrote:
> > So sure, if we go with WARNING + exit with an errorcode, that is perhaps
> > the best combination of the two.
>
> I had a look at how to go about this, but it appears
Hi,
On Sun, Mar 04, 2018 at 06:19:00PM +0100, Magnus Hagander wrote:
> So sure, if we go with WARNING + exit with an errorcode, that is perhaps
> the best combination of the two.
I had a look at how to go about this, but it appears to be a bit
complicated; the first problem is that sendFile() and
On Sun, Mar 4, 2018 at 3:49 PM, Stephen Frost wrote:
> Greetings Magnus, all,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > I think it would also be a good idea to have this a three-mode setting,
> > with "no check", "check and warning", "check and error". Where "check and
> > error" sho
Greetings Magnus, all,
* Magnus Hagander (mag...@hagander.net) wrote:
> I think it would also be a good idea to have this a three-mode setting,
> with "no check", "check and warning", "check and error". Where "check and
> error" should be the default, but you could turn off that in "save whatever
On Fri, Mar 2, 2018 at 7:04 PM, Robert Haas wrote:
> On Fri, Mar 2, 2018 at 6:23 AM, Magnus Hagander
> wrote:
> > Another quick note -- we need to assert that the size of the buffer is
> > actually divisible by BLCKSZ. I don't think it's a common scenario, but
> it
> > could break badly if someb
On Fri, Mar 2, 2018 at 6:23 AM, Magnus Hagander wrote:
> Another quick note -- we need to assert that the size of the buffer is
> actually divisible by BLCKSZ. I don't think it's a common scenario, but it
> could break badly if somebody changes BLCKSZ. Either that or perhaps just
> change the TARS
On Wed, Feb 28, 2018 at 7:08 PM, Michael Banck
wrote:
> Hi,
>
> some installations have data which is only rarerly read, and if they are
> so large that dumps are not routinely taken, data corruption would only
> be detected with some large delay even with checksums enabled.
>
I think this is a
On 2/28/18 1:08 PM, Michael Banck wrote:
>
> The attached small patch verifies checksums (in case they are enabled)
> during a basebackup. The rationale is that we are reading every block in
> this case anyway, so this is a good opportunity to check them as well.
> Other and complementary ways of
35 matches
Mail list logo
