On 2015-02-03 14:18:02 +0900, Michael Paquier wrote:
- RecoveryLockList contains entry for lock no longer recorded by
lock manager: xid %u database %u relation %u,
- lock-xid, lock-dbOid, lock-relOid);
+RecoveryLockList contains entry for lock no longer recorded by
lock manager:
On Sat, Jan 31, 2015 at 5:34 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2015-01-29 11:01:51 -0500, Robert Haas wrote:
On Wed, Jan 28, 2015 at 2:41 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Andres Freund wrote:
I think this isn't particularly pretty, but it seems to be
On 2015-01-29 11:01:51 -0500, Robert Haas wrote:
On Wed, Jan 28, 2015 at 2:41 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Andres Freund wrote:
I think this isn't particularly pretty, but it seems to be working well
enough, and changing it would be pretty invasive. So keeping in
On Wed, Jan 28, 2015 at 2:41 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Andres Freund wrote:
I think this isn't particularly pretty, but it seems to be working well
enough, and changing it would be pretty invasive. So keeping in line
with all that code seems to be easier.
OK, I'm
On 2015-01-27 16:23:53 +0900, Michael Paquier wrote:
On Tue, Jan 27, 2015 at 6:24 AM, Andres Freund and...@2ndquadrant.com wrote:
Unfortunately that Assert()s when there's a lock conflict because
e.g. another backend is currently connecting. That's because ProcSleep()
does a
Andres Freund wrote:
I think this isn't particularly pretty, but it seems to be working well
enough, and changing it would be pretty invasive. So keeping in line
with all that code seems to be easier.
OK, I'm convinced with this part to remove the call of
LockSharedObjectForSession that uses
On Tue, Jan 27, 2015 at 6:24 AM, Andres Freund and...@2ndquadrant.com wrote:
Unfortunately that Assert()s when there's a lock conflict because
e.g. another backend is currently connecting. That's because ProcSleep()
does a enable_timeout_after(DEADLOCK_TIMEOUT, DeadlockTimeout) - and
there's
Hello,
After all, I have confirmed that this fixes the problem on crash
recovery of hot-standby botfor 9.3 and HEAD and no problem was
found except unreadability :(
Ok, committed. Thanks!
Thank you.
Any concrete suggestions about the readability? Is there some
particular spot that
Hello,
After all, I have confirmed that this fixes the problem on crash
recovery of hot-standby botfor 9.3 and HEAD and no problem was
found except unreadability :(
By the way, I moderately want to fix an assertion message to a
ordinary one. Details are below.
The server stops with
On 03/05/2014 10:51 AM, Kyotaro HORIGUCHI wrote:
Hello,
After all, I have confirmed that this fixes the problem on crash
recovery of hot-standby botfor 9.3 and HEAD and no problem was
found except unreadability :(
Ok, committed. Thanks!
Any concrete suggestions about the readability? Is
Hello,
At Fri, 28 Feb 2014 14:45:58 +0200, Heikki Linnakangas
hlinnakan...@vmware.com wrote in 53108506.2010...@vmware.com
Yes, but the same stuation could be made by restarting crashed
secondary.
Yeah.
I have no idea about the scenario on whitch this behavior was regarded
as
Ouch! It brought another bug.
I completely understood the behavior thanks to your detailed
explanation. (And how to use log messages effectively :-)
Sorry, I just found that it's wrong, and found another problem
brought by your patch.
I agree that the fix is appropriate.
I believe the
Correcting one point of my last mail.
Ouch! It brought another bug.
My patch also did.
regards,
I completely understood the behavior thanks to your detailed
explanation. (And how to use log messages effectively :-)
Sorry, I just found that it's wrong, and found another problem
Hello,
| * as if we had just replayed the record before the REDO location
| * (or the checkpoint record itself, if it's a shutdown checkpoint).
The test script following raises assertion failure. It's added
with 'non-shutdown' checkpoint' just before shutting down
immediately. Starting
Ouch. this is the same issue to the mail below,
http://www.postgresql.org/message-id/53104595.6060...@lab.ntt.co.jp
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote:
The recovery process stays on 'incosistent' state forever when
the server has crashed before any wal record is inserted after
the last checkpoint.
# killall postgres
# rm -rf $PGDATA/*
initdb
pg_ctl start -w
sleep 1
pg_ctl stop -m i
Hello,
2014/02/28 18:07 Andres Freund :
On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote:
The recovery process stays on 'incosistent' state forever when
the server has crashed before any wal record is inserted after
the last checkpoint.
# killall postgres
# rm -rf $PGDATA/*
On 02/28/2014 11:51 AM, Kyotaro HORIGUCHI wrote:
Hello,
2014/02/28 18:07 Andres Freund :
On 2014-02-28 17:55:21 +0900, Kyotaro HORIGUCHI wrote:
The recovery process stays on 'incosistent' state forever when
the server has crashed before any wal record is inserted after
the last checkpoint.
On 2013-01-17 01:38:31 -0500, Tom Lane wrote:
But having said that ... are we sure this code is not actually broken?
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the client either;
but ereport(FATAL) will try exactly
Pavan Deolasee pavan.deola...@gmail.com writes:
On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the client either;
but ereport(FATAL) will try exactly
On 2013-01-17 10:19:23 -0500, Tom Lane wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the
At 2012-12-29 14:23:45 -0500, sfr...@snowman.net wrote:
Regarding the actual comment, here's the wording that I'd use:
Sorry for nitpicking, but we can't long jumps made me cringe.
Here's a slightly more condensed version:
/*
* We can't use ereport(ERROR) here, because any longjmps
On Thu, Jan 17, 2013 at 9:26 AM, Abhijit Menon-Sen a...@2ndquadrant.comwrote:
At 2012-12-29 14:23:45 -0500, sfr...@snowman.net wrote:
Regarding the actual comment, here's the wording that I'd use:
Sorry for nitpicking, but we can't long jumps made me cringe.
Here's a slightly more
Abhijit Menon-Sen a...@2ndquadrant.com writes:
Sorry for nitpicking, but we can't long jumps made me cringe.
Agreed :-(
Here's a slightly more condensed version:
I find this still not quite right, because where it's placed, it applies
to both the DoingCommandRead and !DoingCommandRead
On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But having said that ... are we sure this code is not actually broken?
I'm not.
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the client either;
Pavan,
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee
pavan.deola...@gmail.comwrote:
Thanks Andres. I also read the original thread and I now understand why we
are using FATAL here, at least until we have a better solution. Obviously
the
Hi,
On 2012-12-04 12:30:43 +0530, Pavan Deolasee wrote:
I was trying some simple queries on a Hot Standby with streaming
replication.
On standby, I do this:
postgres=# begin transaction isolation level repeatable read;
BEGIN
postgres=# explain verbose select count(b) from test WHERE a
On Tue, Dec 4, 2012 at 1:44 PM, Andres Freund and...@2ndquadrant.comwrote:
After max_standby_streaming_delay, the standby starts cancelling the
queries. I get an error like this on the standby:
postgres=# explain verbose select count(b) from test WHERE a 10;
FATAL: terminating
On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
Thanks Andres. I also read the original thread and I now understand why we
are using FATAL here, at least until we have a better solution. Obviously
the connection reset is no good either because as someone
On Fri, Nov 30, 2012 at 6:41 PM, Andres Freund and...@2ndquadrant.com wrote:
While we're talking about changing defaults, how about changing the
default value of the recovery.conf parameter 'standby_mode' to on?
Not sure about anybody else, but I never want it any other way.
Hm. But only if
Magnus Hagander wrote:
On 30.11.2012 21:02, Andres Freund wrote:
There are workloads where its detrimental, but in general having it
default to on improver experience tremendously because getting conflicts
because of vacuum is rather confusing.
In the workloads where it might not be a good
On 30 November 2012 19:02, Andres Freund and...@2ndquadrant.com wrote:
The subject says it all.
There are workloads where its detrimental, but in general having it
default to on improver experience tremendously because getting conflicts
because of vacuum is rather confusing.
In the
On Fri, Nov 30, 2012 at 2:02 PM, Andres Freund and...@2ndquadrant.com wrote:
Does anybody have an argument against changing the default value?
Well, the disadvantage of it is that the standby can bloat the master,
which might be surprising to some people, too. But I don't really
have a lot of
In the workloads where it might not be a good idea (very long queries on
the standby, many dead tuples on the primary) you need to think very
carefuly about the strategy of avoiding conflicts anyway, and explicit
configuration is required as well.
Does anybody have an argument against
On 30.11.2012 21:02, Andres Freund wrote:
Hi,
The subject says it all.
There are workloads where its detrimental, but in general having it
default to on improver experience tremendously because getting conflicts
because of vacuum is rather confusing.
In the workloads where it might not be a
On Fri, Nov 30, 2012 at 5:46 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Think of someone setting up a test server, by setting it up as a standby
from the master. Now, when someone holds a transaction open in the test
server, you get bloat in the master. Or if you set up a standby
Robert Haas robertmh...@gmail.com writes:
While we're talking about changing defaults, how about changing the
default value of the recovery.conf parameter 'standby_mode' to on?
Not sure about anybody else, but I never want it any other way.
Dunno, it's been only a couple of days since there
On 30.11.2012 22:49, Claudio Freire wrote:
On Fri, Nov 30, 2012 at 5:46 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Think of someone setting up a test server, by setting it up as a standby
from the master. Now, when someone holds a transaction open in the test
server, you get bloat
Claudio Freire wrote:
Without hot standby feedback, reporting queries are impossible.
I've experienced it. Cancellations make it impossible to finish
any decently complex reporting query.
With what setting of max_standby_streaming_delay? I would rather
default that to -1 than default
On Fri, Nov 30, 2012 at 6:06 PM, Kevin Grittner kgri...@mail.com wrote:
Without hot standby feedback, reporting queries are impossible.
I've experienced it. Cancellations make it impossible to finish
any decently complex reporting query.
With what setting of max_standby_streaming_delay? I
Claudio Freire klaussfre...@gmail.com writes:
Without hot standby feedback, reporting queries are impossible. I've
experienced it. Cancellations make it impossible to finish any
decently complex reporting query.
The original expectation was that slave-side cancels would be
infrequent. Maybe
Claudio Freire wrote:
With what setting of max_standby_streaming_delay? I would rather
default that to -1 than default hot_standby_feedback on. That
way what you do on the standby only affects the standby.
1d
Was there actually a transaction hanging open for an entire day on
the standby?
On Fri, Nov 30, 2012 at 6:20 PM, Kevin Grittner kgri...@mail.com wrote:
Claudio Freire wrote:
With what setting of max_standby_streaming_delay? I would rather
default that to -1 than default hot_standby_feedback on. That
way what you do on the standby only affects the standby.
1d
Was
On 30.11.2012 23:40, Claudio Freire wrote:
On Fri, Nov 30, 2012 at 6:20 PM, Kevin Grittnerkgri...@mail.com wrote:
Claudio Freire wrote:
With what setting of max_standby_streaming_delay? I would rather
default that to -1 than default hot_standby_feedback on. That
way what you do on the
On Fri, Nov 30, 2012 at 6:49 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I have most certainly managed databases where holding up vacuuming
on the source would cripple performance to the point that users
would have demanded that any other process causing it must be
immediately
On 2012-11-30 14:35:37 -0500, Robert Haas wrote:
On Fri, Nov 30, 2012 at 2:02 PM, Andres Freund and...@2ndquadrant.com wrote:
Does anybody have an argument against changing the default value?
Well, the disadvantage of it is that the standby can bloat the master,
which might be surprising to
On Fri, Nov 30, 2012 at 11:35 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Nov 30, 2012 at 2:02 PM, Andres Freund and...@2ndquadrant.com wrote:
Does anybody have an argument against changing the default value?
Well, the disadvantage of it is that the standby can bloat the master,
On Fri, Nov 30, 2012 at 9:46 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 30.11.2012 21:02, Andres Freund wrote:
Hi,
The subject says it all.
There are workloads where its detrimental, but in general having it
default to on improver experience tremendously because getting
On Fri, Nov 30, 2012 at 10:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Claudio Freire klaussfre...@gmail.com writes:
Without hot standby feedback, reporting queries are impossible. I've
experienced it. Cancellations make it impossible to finish any
decently complex reporting query.
The
On 2012-11-30 22:46:06 +0200, Heikki Linnakangas wrote:
On 30.11.2012 21:02, Andres Freund wrote:
Hi,
The subject says it all.
There are workloads where its detrimental, but in general having it
default to on improver experience tremendously because getting conflicts
because of vacuum is
All:
Well, the problem is that we have three configurations which only work
for one very common scenario:
- reporting slave: feedback off, very long replication_delay
- load-balancing slave: feedback on, short replication_delay
- backup/failover slave: feedback off, short replication_delay
I
On 2012-11-30 16:09:15 -0500, Tom Lane wrote:
Claudio Freire klaussfre...@gmail.com writes:
Without hot standby feedback, reporting queries are impossible. I've
experienced it. Cancellations make it impossible to finish any
decently complex reporting query.
The original expectation was
On Tue, May 22, 2012 at 12:15 PM, chinnaobi chinna...@gmail.com wrote:
You mean when the primary which is going to switch its role to standby might
not have sent all the WAL records to the standby and If it is switched to
standby it has more WAL records than the standby which is now serves as
chinnaobi wrote:
You mean when the primary which is going to switch its role to
standby might not have sent all the WAL records to the standby and
If it is switched to standby it has more WAL records than the
standby which is now serves as primary. Is it ??
What happens when there is a
Dear Kevin,
Thank you for your reply. Yeah I am writing an application using powershell,
it's true it is not trivial and especially a guy like me who has no idea on
database.
You raised all the cases which I am muddling with, But currently I am
testing this setup:
Always standby server is
Sorry to mention, In my setup the primary and standby servers receive same
traffic, so no issue with the
network fault between the primary and the standby, but not between the
primary and some of the clients updating it
--
View this message in context:
On Mon, May 14, 2012 at 8:18 AM, chinnaobi chinna...@gmail.com wrote:
I do base backup only first time on standby when it is going to be
replicated. when ever primary goes down, standby becomes primary and
primary becomes standby when primary comes up. When primary becomes standby
I am
Dear Robert,
Thank you very much for the reply.
You mean when the primary which is going to switch its role to standby might
not have sent all the WAL records to the standby and If it is switched to
standby it has more WAL records than the standby which is now serves as
primary. Is it ??
It
On 02/27/2012 10:05 PM, Lucky Haryadi wrote:
3. When Master A fails to service, the database will failovered to Slave
B by triggering with trigger file.
As soon as you trigger a standby, it changes it to a new timeline. At
that point, the series of WAL files diverges. It's no longer
On Fri, Feb 3, 2012 at 4:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think saner behavior might only require this change:
/*
* Any unexpected exit (including FATAL exit) of the startup
* process is treated as a crash, except that we don't want to
On Thu, Feb 2, 2012 at 8:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's a bit disturbing that nobody has reported this from the field yet.
Seems to imply that hot standby isn't being used much.
I have seen this, but didn't get to dig in, as I thought it could be a
problem from other things done
I wrote:
I'm currently working with Duncan Rance's test case for bug #6425, and
I am observing a very nasty behavior in HEAD: once one of the
hot-standby query backends crashes, the standby postmaster SIGQUIT's
all its children and then just quits itself, with no log message and
apparently no
On Fri, Feb 3, 2012 at 1:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I'm currently working with Duncan Rance's test case for bug #6425, and
I am observing a very nasty behavior in HEAD: once one of the
hot-standby query backends crashes, the standby postmaster SIGQUIT's
all its
On Mon, Jan 30, 2012 at 4:36 AM, Igor Schtein ischt...@gmail.com wrote:
Is it possible to use a standby instance as a master/primary for another
standby in Postgres 9.0? In other words, does PG 9.0 supports cascading
standby configuration?
No, but 9.2 will support that feature, known as
On 1/29/12 8:36 PM, Igor Schtein wrote:
Hi,
Is it possible to use a standby instance as a master/primary for another
standby in Postgres 9.0? In other words, does PG 9.0 supports cascading
standby configuration?
No, that's a 9.2 feature in development.
If you can build PostgreSQL from
On Fri, Oct 28, 2011 at 3:42 AM, Chris Redekop ch...@replicon.com wrote:
On a side note I am sporadically seeing another error on hotstandby startup.
I'm not terribly concerned about it as it is pretty rare and it will work
on a retry so it's not a big deal. The error is FATAL: out-of-order
oopsreply-to-all
-- Forwarded message --
From: Chris Redekop ch...@replicon.com
Date: Wed, Nov 2, 2011 at 8:41 AM
Subject: Re: [HACKERS] Hot Standby startup with overflowed snapshots
To: Simon Riggs si...@2ndquadrant.com
Sure, I've got quite a few logs lying around - I've
Thanks for the patch Simon, but unfortunately it does not resolve the issue
I am seeing. The standby still refuses to finish starting up until long
after all clients have disconnected from the primary (10 minutes). I do
see your new log statement on startup, but only once - it does not repeat.
On Thu, Oct 27, 2011 at 5:26 PM, Chris Redekop ch...@replicon.com wrote:
Thanks for the patch Simon, but unfortunately it does not resolve the issue
I am seeing. The standby still refuses to finish starting up until long
after all clients have disconnected from the primary (10 minutes). I do
hrmz, still basically the same behaviour. I think it might be a *little*
better with this patch. Before when under load it would start up quickly
maybe 2 or 3 times out of 10 attemptswith this patch it might be up to 4
or 5 times out of 10...ish...or maybe it was just fluke *shrug*. I'm
On Thu, Oct 27, 2011 at 10:09 PM, Chris Redekop ch...@replicon.com wrote:
hrmz, still basically the same behaviour. I think it might be a *little*
better with this patch. Before when under load it would start up quickly
maybe 2 or 3 times out of 10 attemptswith this patch it might be up
Sorry...designed was poor choice of words, I meant not unexpected.
Doing the checkpoint right after pg_stop_backup() looks like it will work
perfectly for me, so thanks for all your help!
On a side note I am sporadically seeing another error on hotstandby startup.
I'm not terribly concerned
On Thu, Oct 27, 2011 at 6:55 PM, Simon Riggs si...@2ndquadrant.com wrote:
It seems cheap to add in a call to LogStandbySnapshot() after each
call to pg_stop_backup().
Does anyone think this case is worth adding code for? Seems like one
more thing to break.
Why at that particular time?
It
On Thu, Jun 9, 2011 at 5:14 AM, Daniel Farina dan...@heroku.com wrote:
The first fact is that turning off hot standby will let the cluster
start up, but only after seeing a spate of messages like these (dozen
or dozens, not thousands):
2011-06-09 08:02:32 UTC LOG: restored log file
On Fri, Mar 11, 2011 at 4:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Is this an open item for 9.1?
Simon fixed it, commit b9075a6d2f9b07a00262a670dd60272904c79dce.
Oh, thanks!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source
On Thu, Dec 9, 2010 at 4:55 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-12-09 at 00:16 +0100, Heikki Linnakangas wrote:
On 09.12.2010 00:10, Heikki Linnakangas wrote:
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
On 11.03.2011 06:21, Fujii Masao wrote:
On Thu, Dec 9, 2010 at 4:55 PM, Simon Riggssi...@2ndquadrant.com wrote:
On Thu, 2010-12-09 at 00:16 +0100, Heikki Linnakangas wrote:
On 09.12.2010 00:10, Heikki Linnakangas wrote:
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that
On Tue, Dec 7, 2010 at 3:42 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Just wanted to say thanks for the review, since I haven't yet managed to
fix and commit this. I expect to later this month.
On Mon, 2010-09-27 at 23:06 -0400, Robert Haas wrote:
On Thu, Apr 29, 2010 at 4:12 PM, Simon Riggs si...@2ndquadrant.com wrote:
Simple tuning of btree_xlog_vacuum() using
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to implement that.
Looking to commit in next few hours barring objections/suggestions, to
both HEAD and 9_0_STABLE, in
On 09.12.2010 00:10, Heikki Linnakangas wrote:
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to implement that.
Looking to commit in next few hours barring
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to implement that.
This doesn't look right to me. btree_xlog_delete_get_latestRemovedXid()
function calculates the
On Thu, 2010-12-09 at 00:39 +0100, Heikki Linnakangas wrote:
vacuum_defer_cleanup_age should take effect in
the master, not during recovery.
Hmmm, more to the point, it does take effect on the master and so there
is no need for this at all. What were you thinking? What was I? Doh.
--
On Thu, 2010-12-09 at 00:16 +0100, Heikki Linnakangas wrote:
On 09.12.2010 00:10, Heikki Linnakangas wrote:
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to
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
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 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 steps
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
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
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 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
On 24.11.2010 06:56, Joachim Wieland wrote:
On Tue, Nov 23, 2010 at 8:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 19.11.2010 23:46, Joachim Wieland wrote:
FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids: 9978,
pArray-maxKnownAssignedXids: 6890
Hmm,
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
heikki.linnakan...@enterprisedb.com wrote:
On 19.11.2010 23:46, Joachim Wieland wrote:
FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids:
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
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
On Tue, Nov 23, 2010 at 8:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
On Sun, Nov 21, 2010 at 11:48 PM, Fujii Masao masao.fu...@gmail.com 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
*
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 Sat, Nov 20, 2010 at 6:46 AM, Joachim Wieland j...@mcknight.de 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.
On Tue, 2010-11-09 at 13:34 +0200, Heikki Linnakangas wrote:
(cleaning up my inbox, and bumped into this..)
On 22.04.2010 12:31, Simon Riggs wrote:
On Thu, 2010-04-22 at 12:18 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2010-04-22 at 11:56 +0300, Heikki Linnakangas wrote:
1 - 100 of 968 matches
Mail list logo
