On 03/26/2015 09:45 PM, Arthur Silva wrote:
On Mar 26, 2015 4:20 AM, "Vladimir Borodin" wrote:
26 марта 2015 г., в 7:32, Michael Paquier
написал(а):
On Thu, Mar 26, 2015 at 12:23 PM, Venkata Balaji N
wrote:
If the master is crashed or killed abruptly, it may not be possible to
do a
On Mar 26, 2015 4:20 AM, "Vladimir Borodin" wrote:
>
>
>> 26 марта 2015 г., в 7:32, Michael Paquier
написал(а):
>>
>> On Thu, Mar 26, 2015 at 12:23 PM, Venkata Balaji N
wrote:
>>>
>>> Test 1 :
>>>
>>> [...]
>>>
>>> If the master is crashed or killed abruptly, it may not be possible to
do a
>>> r
> 26 марта 2015 г., в 7:32, Michael Paquier
> написал(а):
>
> On Thu, Mar 26, 2015 at 12:23 PM, Venkata Balaji N wrote:
>> Test 1 :
>>
>> [...]
>>
>> If the master is crashed or killed abruptly, it may not be possible to do a
>> rewind. Is my understanding correct ?
>
> Yep. This is mention
On Thu, Mar 26, 2015 at 12:23 PM, Venkata Balaji N wrote:
> Test 1 :
>
> [...]
>
> If the master is crashed or killed abruptly, it may not be possible to do a
> rewind. Is my understanding correct ?
Yep. This is mentioned in the documentation:
http://www.postgresql.org/docs/devel/static/app-pgrew
> I have committed this, with some more kibitzing. hope I have not missed
> any comments given so far. Many thanks for the review, and please continue
> reviewing and testing it :-).
I have been testing the pg_rewind and have an analysis to share along with
few questions -
I had a streaming rep
On 03/14/2015 02:31 PM, Amit Kapila wrote:
Getting below linking error with Asserts enabled in Windows build.
1>xlogreader.obj : error LNK2019: unresolved external symbol
ExceptionalCondition referenced in function
XLogReadRecord
1>.\Debug\pg_rewind\pg_rewind.exe : fatal error LNK1120: 1 unresol
On Wed, Mar 11, 2015 at 2:23 PM, Heikki Linnakangas wrote:
>
> On 03/11/2015 05:01 AM, Amit Kapila wrote:
>>
>>
>>
>> Can't that happen if the source database (new-master) haven't
>> received all of the data from target database (old-master) at the
>> time of promotion?
>> If yes, then source data
Amit Kapila wrote:
> Getting below linking error with Asserts enabled in Windows build.
>
> 1>xlogreader.obj : error LNK2019: unresolved external symbol
> ExceptionalCondition referenced in function
> XLogReadRecord
> 1>.\Debug\pg_rewind\pg_rewind.exe : fatal error LNK1120: 1 unresolved
> externa
On Fri, Mar 13, 2015 at 1:13 AM, Heikki Linnakangas wrote:
>
> The cause was a silly typo in truncate_target_file:
>
>> @@ -397,7 +397,7 @@ truncate_target_file(const char *path, off_t newsize)
>>
>> snprintf(dstpath, sizeof(dstpath), "%s/%s", datadir_target,
path);
>>
>> - fd = open
On 03/12/2015 08:49 AM, Amit Kapila wrote:
With attached modified script, I am able to reproduce the
error (I have used the latest pg_rewind patch (pg_rewind-bin-8))
Thanks! That reproduced the error for me too. Not sure why I couldn't
reproduce it earlier.
The cause was a silly typo in trun
On Wed, Mar 11, 2015 at 2:23 PM, Heikki Linnakangas wrote:
> On 03/11/2015 05:01 AM, Amit Kapila wrote:
>>
>> I have tried without backslash as well, but still it returns
>> same error.
>>
>> pg_rewind.exe -D ..\..\Data --source-pgdata=..\..\Database1
>> The servers diverged at WAL position 0/176
On 03/11/2015 05:01 AM, Amit Kapila wrote:
On Wed, Mar 11, 2015 at 3:44 AM, Heikki Linnakangas wrote:
On 03/10/2015 07:46 AM, Amit Kapila wrote:
Isn't it possible incase of async replication that old cluster has
some blocks which new cluster doesn't have, what will it do
in such a case?
Su
On Wed, Mar 11, 2015 at 3:44 AM, Heikki Linnakangas wrote:
> On 03/10/2015 07:46 AM, Amit Kapila wrote:
>
>>
>> Isn't it possible incase of async replication that old cluster has
>> some blocks which new cluster doesn't have, what will it do
>> in such a case?
>>
>
> Sure, that's certainly possib
On 03/10/2015 07:46 AM, Amit Kapila wrote:
On Mon, Mar 9, 2015 at 7:32 PM, Heikki Linnakangas wrote:
Attached is a new patch version, fixing all the little things you listed.
I believe this is pretty much ready for commit. I'm going to read it
through myself one more time before committing, b
Michael Paquier wrote:
> On top of that, I had an extra look at this patch, testing pg_rewind
> with OSX, Linux, MinGW-32 and MSVC. Particularly on Windows, I have
> been able to rewind a node and to reconnect it to a promoted standby
> using this utility compiled on both MinGW-32 and MSVC (nothin
On Mon, Mar 9, 2015 at 7:32 PM, Heikki Linnakangas wrote:
>
> Attached is a new patch version, fixing all the little things you listed.
I believe this is pretty much ready for commit. I'm going to read it
through myself one more time before committing, but I don't have anything
mind now that needs
On Mon, Mar 9, 2015 at 11:59 PM, Alvaro Herrera
wrote:
> Heikki Linnakangas wrote:
>
>> Attached is a new patch version, fixing all the little things you listed. I
>> believe this is pretty much ready for commit. I'm going to read it through
>> myself one more time before committing, but I don't h
Heikki Linnakangas wrote:
> Attached is a new patch version, fixing all the little things you listed. I
> believe this is pretty much ready for commit. I'm going to read it through
> myself one more time before committing, but I don't have anything mind now
> that needs fixing anymore.
I do -- it
On 01/19/2015 07:38 AM, Michael Paquier wrote:
Looking at the set of TAP tests, I think that those lines open again
the door of CVE-2014-0067 (vulnerability with make check) on Windows:
# Initialize master, data checksums are mandatory
remove_tree($test_master_datadir);
On Mon, Jan 19, 2015 at 2:50 PM, Michael Paquier
wrote:
> On Mon, Jan 19, 2015 at 2:38 PM, Michael Paquier
> wrote:
> > Heikki Linnakangas wrote:
> >> Addressed most of your comments, and Michael's. Another version
> attached.
>
> Extra thing: src/bin/pg_rewind/Makefile surely forgets to clean u
On Mon, Jan 19, 2015 at 2:38 PM, Michael Paquier
wrote:
> Heikki Linnakangas wrote:
>> Addressed most of your comments, and Michael's. Another version attached.
Extra thing: src/bin/pg_rewind/Makefile surely forgets to clean up the
stuff from the regression tests:
+clean distclean maintainer-clea
Heikki Linnakangas wrote:
> Addressed most of your comments, and Michael's. Another version attached.
Looking at the set of TAP tests, I think that those lines open again
the door of CVE-2014-0067 (vulnerability with make check) on Windows:
# Initialize master, data checksums are mandatory
On 01/16/2015 03:30 AM, Peter Eisentraut wrote:
Here is a random bag of comments for the v5 patch:
Addressed most of your comments, and Michael's. Another version
attached. More on a few of the comments below.
The option --source-server had be confused at first, because the entry
above unde
Here is a random bag of comments for the v5 patch:
pg_xlogdump fails to build:
CC xlogreader.o
CC rmgrdesc.o
../../src/include/access/rmgrlist.h:32:46: error: 'dbase_desc' undeclared here
(not in a function)
PG_RMGR(RM_DBASE_ID, "Database", dbase_redo, dbase_desc, dbase_identify, NULL,
On 01/15/2015 03:21 PM, Greg Stark wrote:
I must have missed this, how did you some the hint bit problem with
pg_rewind? Last I understood you ran the risk that the server has unlogged
hint bit updates that you wouldn't know to rewind.
There's a new GUC in 9.4, wal_log_hints, for that. It has t
On 2015-01-15 13:21:56 +, Greg Stark wrote:
> I must have missed this, how did you some the hint bit problem with
> pg_rewind? Last I understood you ran the risk that the server has unlogged
> hint bit updates that you wouldn't know to rewind.
wal_log_hints = on
Greetings,
Andres Freund
--
I must have missed this, how did you some the hint bit problem with
pg_rewind? Last I understood you ran the risk that the server has unlogged
hint bit updates that you wouldn't know to rewind.
On Wed, Jan 14, 2015 at 6:43 PM, Heikki Linnakangas
wrote:
> Here is a new version. There are now a fair amount of code changes compared
> to the version on github, like the logging and progress information, and a
> lot of comment changes. I also improved the documentation.
Perhaps this could a d
On Wed, Jan 7, 2015 at 8:44 AM, Andrew Dunstan wrote:
> I understand, but I think "pg_rewind" is likely to be misleading to many
> users who will say "but I don't want just to rewind".
>
> I'm not wedded to the name I suggested, but I think we should look at
> possible alternative names. We do hav
On 2015-01-14 10:53:40 +0100, Andres Freund wrote:
> On 2015-01-14 11:43:00 +0200, Heikki Linnakangas wrote:
> > I'm not thrilled about sprinkling fsync() calls everywhere that we touch
> > files. But I guess that would be the right thing to do. I'm planning to do
> > that as an add-on patch later,
On 2015-01-09 10:48:39 +0200, Heikki Linnakangas wrote:
> It would nevertheless be handy to be able to do more stuff in a replication
> connection. For example, you might want to run functions like
> pg_create_restore_point(), pg_xlog_replay_pause/resume etc. in a replication
> connection. We shoul
On 2015-01-14 11:43:00 +0200, Heikki Linnakangas wrote:
> No. The question is, should pg_rewind fsync() every file that it
> modifies?
Not immediately, but before the end, yes.
> It would be a reasonable thing to do, to make sure that if you crash
> immediately after running pg_rewind, the cluste
On 01/07/2015 06:19 PM, Alvaro Herrera wrote:
Fixed most of the issues you listed. More on a few remaining ones below.
Please don't name files with generic names such as util.c/h. It's
annoying later; for instance when I want to open analyze.c I have to
choose the one in parser or commands. (
There are two ways in which access control for replication connections
is separate:
- replication pseudo-database in pg_hba.conf
- replication role attribute
If someone has a restrictive setup for replication and pg_basebackup,
and then pg_rewind enters, they will have to
- add a line to pg_hba
On 01/08/2015 10:44 PM, Peter Eisentraut wrote:
On 1/6/15 7:17 PM, Andres Freund wrote:
One problem is that it doesn't use the replication protocol,
so the setup is going to be inconsistent with pg_basebackup. Maybe the
replication protocol could be extended to provide the required data.
I'm
On Fri, Jan 9, 2015 at 1:02 AM, Heikki Linnakangas
wrote:
> Fixed all the errors I got on MSVC. The biggest change was rewriting the
> code that determines if a file is a relation file, based on its filename. It
> used a regular expression, which I replaced with a bunch of sscanf calls,
> and a cr
On 1/6/15 7:17 PM, Andres Freund wrote:
>> One problem is that it doesn't use the replication protocol,
>> > so the setup is going to be inconsistent with pg_basebackup. Maybe the
>> > replication protocol could be extended to provide the required data.
> I'm not particularly bothered by the requi
On 01/06/2015 09:13 AM, Michael Paquier wrote:
Some more comments:
- Nitpicking: the header formats of filemap.c, datapagemap.c,
datapagemap.h and util.h are incorrect (I pushed a fix about that in
pg_rewind itself, feel free to pick it up).
Ah, fixed.
- parsexlog.c has a copyright mention to
What is this define good for? I couldn't understand where it fits; is
it just a leftover?
+#define pageinfo_set_truncation(forkno, rnode, blkno)
datapagemap_set_truncation(pagemap, forkno, rnode, blkno)
Please don't name files with generic names such as util.c/h. It's
annoying later; for inst
On 01/06/2015 10:39 PM, Peter Eisentraut wrote:
The test suite should probably be reimplemented in Perl. (I might be
able to help.) Again, ingenious, but it's very hard to follow the
sequence of what is being tested. And some Windows person is going to
complain. ;-)
I took a shot at rewritin
On 01/07/2015 03:22 AM, Heikki Linnakangas wrote:
On 01/07/2015 01:54 AM, Andrew Dunstan wrote:
I also think it's a great idea. But I think we should consider the name
carefully. pg_resync might be a better name. Strictly, you might not be
quite rewinding, AIUI.
pg_resync sounds too generic.
On 01/06/2015 10:39 PM, Peter Eisentraut wrote:
If this ends up shipping, it's going to be a massively popular tool. I
see it as a companion to pg_basebackup. So it should sort of work the
same way. One problem is that it doesn't use the replication protocol,
so the setup is going to be incons
On 01/07/2015 01:54 AM, Andrew Dunstan wrote:
I also think it's a great idea. But I think we should consider the name
carefully. pg_resync might be a better name. Strictly, you might not be
quite rewinding, AIUI.
pg_resync sounds too generic. It's true that if the source server has
changes of
On 01/07/2015 02:17 AM, Andres Freund wrote:
On 2015-01-06 15:39:29 -0500, Peter Eisentraut wrote:
It wouldn't hurt if we could share SimpleXLogPageRead() between
pg_xlogdump and pg_rewind as the differences are more or less
superficial, but that seems simple enough to achieve by putting a
fronte
On 2015-01-06 15:39:29 -0500, Peter Eisentraut wrote:
> I applaud the ingenuity on all levels in this patch. But it seems to me
> that there is way too much backend knowledge encoded and/or duplicated
> in a front-end program.
Hm. There's really not that much in the current version anymore? Sure,
On 01/06/2015 03:39 PM, Peter Eisentraut wrote:
I applaud the ingenuity on all levels in this patch. But it seems to me
that there is way too much backend knowledge encoded and/or duplicated
in a front-end program.
If this ends up shipping, it's going to be a massively popular tool. I
see it
On Wed, Jan 7, 2015 at 5:39 AM, Peter Eisentraut wrote:
> Also, since you have been maintaining this tool for a while, what is the
> effort for maintaining it from version to version?
>From my own experience, the main source of maintenance across major
versions is the modification of the WAL recor
I applaud the ingenuity on all levels in this patch. But it seems to me
that there is way too much backend knowledge encoded and/or duplicated
in a front-end program.
If this ends up shipping, it's going to be a massively popular tool. I
see it as a companion to pg_basebackup. So it should sort
On Tue, Jan 6, 2015 at 2:38 AM, Heikki Linnakangas
wrote:
> Here's an updated version of pg_rewind. The code itself is the same as
> before, and corresponds to the sources in the current pg_rewind github
> repository, as of commit a65e3754faf9ca9718e6b350abc736de586433b7. Based
> mostly on Michael
Here's an updated version of pg_rewind. The code itself is the same as
before, and corresponds to the sources in the current pg_rewind github
repository, as of commit a65e3754faf9ca9718e6b350abc736de586433b7. Based
mostly on Michael's comments, I have:
* replaced VMware copyright notices with
On 2014/12/16 18:37, Heikki Linnakangas wrote:
On 12/16/2014 11:23 AM, Satoshi Nagayasu wrote:
pg_rewind assumes that the source PostgreSQL has, at least, one
checkpoint after getting promoted. I think the target timeline id
in the pg_control file to be read is only available after the first
che
On 12/16/2014 11:23 AM, Satoshi Nagayasu wrote:
Hi,
On 2014/12/12 23:13, Heikki Linnakangas wrote:
> Hi,
>
> I'd like to include pg_rewind in contrib. I originally wrote it as an
> external project so that I could quickly get it working with the
> existing versions, and because I didn'
Hi,
On 2014/12/12 23:13, Heikki Linnakangas wrote:
> Hi,
>
> I'd like to include pg_rewind in contrib. I originally wrote it as an
> external project so that I could quickly get it working with the
> existing versions, and because I didn't feel it was quite ready for
> production use yet. Now, wi
On Tue, Dec 16, 2014 at 10:26 AM, Michael Paquier
wrote:
> In any case, I have a couple of comments about this patch as-is:
> - If the move to src/bin is done, let's update the MSVC scripts accordingly
> - contrib/pg_rewind/.gitignore should be cleaned up from its unnecessary
> entries
> - README
On Tue, Dec 16, 2014 at 9:32 AM, Michael Paquier
wrote:
> On Sat, Dec 13, 2014 at 12:01 AM, Heikki Linnakangas
> wrote:
>> On 12/12/2014 04:20 PM, Andres Freund wrote:
>>>
>>> Not sure if the copyright notices in the current form are actually ok?
>>
>>
>> Hmm. We do have such copyright notices in
On Sat, Dec 13, 2014 at 12:01 AM, Heikki Linnakangas
wrote:
> On 12/12/2014 04:20 PM, Andres Freund wrote:
>>
>> Not sure if the copyright notices in the current form are actually ok?
>
>
> Hmm. We do have such copyright notices in the source tree, but I know that
> we're trying to avoid it in new
On Sat, Dec 13, 2014 at 10:49 PM, David Fetter wrote:
>
> On Fri, Dec 12, 2014 at 10:06:32AM -0500, Tom Lane wrote:
> > Heikki Linnakangas writes:
> > > I'd like to include pg_rewind in contrib.
> >
> > I don't object to adding the tool as such, but let's wait to see
> > what happens with Peter's
On Fri, Dec 12, 2014 at 10:06:32AM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > I'd like to include pg_rewind in contrib.
>
> I don't object to adding the tool as such, but let's wait to see
> what happens with Peter's proposal to move contrib command-line
> tools into src/bin/. If it
Heikki Linnakangas writes:
> I'd like to include pg_rewind in contrib.
I don't object to adding the tool as such, but let's wait to see what
happens with Peter's proposal to move contrib command-line tools into
src/bin/. If it should be there it'd be less code churn if it went
into there in the
On 12/12/2014 04:20 PM, Andres Freund wrote:
Not sure if the copyright notices in the current form are actually ok?
Hmm. We do have such copyright notices in the source tree, but I know
that we're trying to avoid it in new code. They had to be there when the
code lived as a separate project,
On Fri, Dec 12, 2014 at 11:13 PM, Heikki Linnakangas
wrote:
> I'd like to include pg_rewind in contrib. I originally wrote it as an
> external project so that I could quickly get it working with the existing
> versions, and because I didn't feel it was quite ready for production use
> yet. Now, wi
On Fri, Dec 12, 2014 at 03:20:47PM +0100, Andres Freund wrote:
> Hi,
>
> On 2014-12-12 16:13:13 +0200, Heikki Linnakangas wrote:
> > I'd like to include pg_rewind in contrib. I originally wrote it as an
> > external project so that I could quickly get it working with the existing
> > versions, and
Hi,
On 2014-12-12 16:13:13 +0200, Heikki Linnakangas wrote:
> I'd like to include pg_rewind in contrib. I originally wrote it as an
> external project so that I could quickly get it working with the existing
> versions, and because I didn't feel it was quite ready for production use
> yet. Now, wi
63 matches
Mail list logo
