On Tue, Dec 7, 2010 at 3:42 AM, Heikki Linnakangas
wrote:
> Ok, I've committed this patch now.
I can confirm that I could continue replaying the logfiles on the
standby host with this patch.
Thanks a lot,
Joachim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On 02.12.2010 12:31, Heikki Linnakangas wrote:
On 02.12.2010 13:25, Simon Riggs wrote:
On Thu, 2010-12-02 at 12:41 +0200, Heikki Linnakangas wrote:
On 02.12.2010 11:02, Simon Riggs wrote:
The cause of the issue is that replay starts at one LSN and there is a
delay until the RunningXacts WAL re
On 02.12.2010 13:25, Simon Riggs wrote:
On Thu, 2010-12-02 at 12:41 +0200, Heikki Linnakangas wrote:
On 02.12.2010 11:02, Simon Riggs wrote:
The cause of the issue is that replay starts at one LSN and there is a
delay until the RunningXacts WAL record occurs. If there was no delay,
there would
On Thu, 2010-12-02 at 12:41 +0200, Heikki Linnakangas wrote:
> On 02.12.2010 11:02, Simon Riggs wrote:
> > The cause of the issue is that replay starts at one LSN and there is a
> > delay until the RunningXacts WAL record occurs. If there was no delay,
> > there would be no issue at all. In CreateC
On 02.12.2010 11:02, Simon Riggs wrote:
The cause of the issue is that replay starts at one LSN and there is a
delay until the RunningXacts WAL record occurs. If there was no delay,
there would be no issue at all. In CreateCheckpoint() we start by
grabbing the WAInsertLock and later recording tha
On Thu, 2010-12-02 at 10:39 +0200, Heikki Linnakangas wrote:
> On 01.12.2010 20:51, Heikki Linnakangas wrote:
> > Another approach would be to revisit the way the running-xacts snapshot
> > is taken. Currently, we first take a snapshot, and then WAL-log it.
> > There is a small window between the s
On 01.12.2010 20:51, Heikki Linnakangas wrote:
Another approach would be to revisit the way the running-xacts snapshot
is taken. Currently, we first take a snapshot, and then WAL-log it.
There is a small window between the steps where backends can begin/end
transactions, and recovery has to deal
On 24.11.2010 12:48, Heikki Linnakangas wrote:
When recovery starts, we fetch the oldestActiveXid from the checkpoint
record. Let's say that it's 100. We then start replaying WAL records
from the Redo pointer, and the first record (heap insert in your case)
contains an Xid that's much larger than
On Wed, 2010-11-24 at 12:48 +0200, Heikki Linnakangas wrote:
> When recovery starts, we fetch the oldestActiveXid from the checkpoint
> record. Let's say that it's 100. We then start replaying WAL records
> from the Redo pointer, and the first record (heap insert in your case)
> contains an Xid th
On 24.11.2010 13:38, Heikki Linnakangas wrote:
It's dangerous to initialize latestObservedXid to anything to an older
value.
older value than the nextXid-1 from the checkpoint record, I meant to say.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hacker
On 24.11.2010 12:48, Heikki Linnakangas wrote:
On 24.11.2010 06:56, Joachim Wieland wrote:
On Tue, Nov 23, 2010 at 8:45 AM, Heikki Linnakangas
wrote:
On 19.11.2010 23:46, Joachim Wieland wrote:
FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids: 9978,
pArray->maxKnownAssignedXids: 68
On 24.11.2010 06:56, Joachim Wieland wrote:
On Tue, Nov 23, 2010 at 8:45 AM, Heikki Linnakangas
wrote:
On 19.11.2010 23:46, Joachim Wieland wrote:
FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids: 9978,
pArray->maxKnownAssignedXids: 6890
Hmm, that's a lot of entries in KnownAssi
On Tue, Nov 23, 2010 at 8:45 AM, Heikki Linnakangas
wrote:
> On 19.11.2010 23:46, Joachim Wieland wrote:
>>
>> FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids: 9978,
>> pArray->maxKnownAssignedXids: 6890
>
> Hmm, that's a lot of entries in KnownAssignedXids.
>
> Can you recompile with
On 19.11.2010 23:46, Joachim Wieland wrote:
FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids: 9978,
pArray->maxKnownAssignedXids: 6890
Hmm, that's a lot of entries in KnownAssignedXids.
Can you recompile with WAL_DEBUG, and run the recovery again with
wal_debug=on ? That will print
On Sun, Nov 21, 2010 at 11:48 PM, Fujii Masao wrote:
> --
> If you suspect a bug in Hot Standby, please set
> trace_recovery_messages = DEBUG2
> in postgresql.conf and repeat the action
>
> Always useful to know
> * max_connections
> * current number of sessions
> * whether we h
On Sat, Nov 20, 2010 at 6:46 AM, Joachim Wieland wrote:
> I still have the server, if you want me to debug anything or send a
> patch against 9.0.1 that gives more output, just let me know.
Per previous Simon's comment, the following information would be useful.
http://archives.postgresql.org/pgs
Hi,
I am seeing the following here on 9.0.1 on Linux x86-64:
LOG: redo starts at 1F8/FC00E978
FATAL: too many KnownAssignedXids
CONTEXT: xlog redo insert: rel 1663/16384/18373; tid 3829898/23
and this is the complete history:
postgres was running as HS in foreground, Ctrl-C'ed it for a rest
17 matches
Mail list logo
