Re: 9.4 checksum error in recovery with btree index

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.4 checksum error in recovery with btree index
Date: 2014-05-21 06:33:16
Message-ID: CAB7nPqQzrQLHO6kgM5+SLa=nnDHsW1pVRg8_YPUM8pph3jXCxw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 20, 2014 at 5:10 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> What would be a good way of doing that? Mostly I've just been sharing it
> on google drive when I find something. Should I fork the mirror from
> github (https://github.com/postgres/postgres)? Forking the entire
> codebase just to have a 200 line patch and 2 driving scripts seems
> excessive, but I guess that that is the git philosophy. Or is there a
> better way than that?
>
When forking a repository for development purposes, usually the whole
repository is not necessary: push only the master branch that you update
from time to time and create separate branches for each development patch.
If people would like to have a look at your patch, they would simply need
to add a remote link to your fork, fetching only the diffs introduced by
your additional branch(es) and then to checkout the branch on which your
patch is. This has the advantage to let the user merge himself the code
with newer code and not getting failures when applying a patch that will
get chunks of code rejected over time.

My 2c.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2014-05-21 10:11:03 Re: Allowing join removals for more join types
Previous Message Pavel Stehule 2014-05-21 03:16:14 Re: jsonb failed assertions