On Tue, 2010-04-13 at 17:18 +0300, Heikki Linnakangas wrote:
I've reviewed your changes and they look correct to me; the main chunk
of code is mine and that was tested by me.
Ok, committed after fixing an obsoleted comment other small
editorialization.
Looks good, thanks.
--
Simon
Simon Riggs wrote:
On Thu, 2010-04-08 at 19:02 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
OK, that seems better. I'm happy with that instead.
Have you tested this? Is it ready to commit?
Only very briefly. I think the code is ready, but please review and test
to see I didn't miss
On Tue, 2010-04-06 at 10:22 +0100, Simon Riggs wrote:
Initial patch. I will be testing over next day. No commit before at
least midday on Wed 7 Apr.
Various previous discussions sidelined a very important point: what
exactly does it mean to start recovery from a shutdown checkpoint?
If
Simon Riggs wrote:
On Tue, 2010-04-06 at 10:22 +0100, Simon Riggs wrote:
Initial patch. I will be testing over next day. No commit before at
least midday on Wed 7 Apr.
Various previous discussions sidelined a very important point: what
exactly does it mean to start recovery from a
On Thu, 2010-04-08 at 13:33 +0300, Heikki Linnakangas wrote:
If standby_mode is enabled and there is no source of WAL, then we get a
stream of messages saying
LOG: record with zero length at 0/C88
...
but most importantly we never get to the main recovery loop, so Hot
On Thu, Apr 8, 2010 at 6:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
If standby_mode is enabled and there is no source of WAL, then we get a
stream of messages saying
LOG: record with zero length at 0/C88
...
but most importantly we never get to the main recovery loop, so Hot
Simon Riggs wrote:
In StartupXlog() when we get to the point where we Find the first
record that logically follows the checkpoint, in the current code
ReadRecord() loops forever, spitting out
LOG: record with zero length at 0/C88
...
That prevents us from going further down
On Thu, 2010-04-08 at 18:35 +0300, Heikki Linnakangas wrote:
So I have introduced the new mode (snapshot mode) to enter hot
standby
anyway. That avoids us having to screw around with the loop logic
for
redo. I don't see any need to support the case of where we have no
WAL
source
Simon Riggs wrote:
OK, that seems better. I'm happy with that instead.
Have you tested this? Is it ready to commit?
Only very briefly. I think the code is ready, but please review and test
to see I didn't miss anything.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Thu, 2010-04-08 at 19:02 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
OK, that seems better. I'm happy with that instead.
Have you tested this? Is it ready to commit?
Only very briefly. I think the code is ready, but please review and test
to see I didn't miss anything.
I'm
Initial patch. I will be testing over next day. No commit before at
least midday on Wed 7 Apr.
The existing call to PrescanPreparedTransactions() looks correct to me
but the comment is wrong. I will change that also, if we agree.
--
Simon Riggs www.2ndQuadrant.com
diff --git
11 matches
Mail list logo
