Heikki Linnakangas wrote:
Gregory Stark wrote:
A vacuum being replayed -- even in a different database -- could trigger the
error. Or with the btree split issue, a data load -- again even in a
different
database -- would be quite likely cause your SELECT to be killed.
Hmm, I wonder if we
On Fri, 2008-12-19 at 10:49 +0200, Heikki Linnakangas wrote:
Whenever a B-tree index scan fetches a heap tuple that turns out to be
dead, the B-tree item is marked as killed by calling _bt_killitems. When
the page gets full, all the killed items are removed by calling
_bt_vacuum_one_page.
Simon Riggs wrote:
We have infrastructure in place to make this work correctly, just need
to add latestRemovedXid field to xl_btree_vacuum. So that part is easily
solved.
That's tricky because there's no xmin/xmax on index tuples. You could
conservatively use OldestXmin as latestRemovedXid,
On Fri, 2008-12-19 at 12:24 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
We have infrastructure in place to make this work correctly, just need
to add latestRemovedXid field to xl_btree_vacuum. So that part is easily
solved.
That's tricky because there's no xmin/xmax on index
I'm confused shouldn't read-only transactions on the slave just be
hacked to not set any hint bits including lp_delete?
--
Greg
On 19 Dec 2008, at 03:49, Heikki Linnakangas heikki.linnakan...@enterprisedb.com
wrote:
Whenever a B-tree index scan fetches a heap tuple that turns out to
be
On Fri, 2008-12-19 at 09:22 -0500, Greg Stark wrote:
I'm confused shouldn't read-only transactions on the slave just be
hacked to not set any hint bits including lp_delete?
They could be, though I see no value in doing so.
But that is not Heikki's point. He is discussing what happens on
Simon Riggs si...@2ndquadrant.com wrote:
If I was going to add anything to the btree page header, it would be
latestRemovedLSN, only set during recovery. That way we don't have
to
explicitly kill queries, we can do the a wait on OldestXmin then let
them ERROR out when they find a page that
On Fri, 2008-12-19 at 11:54 -0600, Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
If I was going to add anything to the btree page header, it would be
latestRemovedLSN, only set during recovery. That way we don't have
to
explicitly kill queries, we can do the a wait
On Fri, 2008-12-19 at 10:52 +, Simon Riggs wrote:
You could
conservatively use OldestXmin as latestRemovedXid, but that could stall
the WAL redo a lot more than necessary. Or you could store
latestRemovedXid in the page header, but that would need to be
WAL-logged to ensure
Simon Riggs si...@2ndquadrant.com wrote:
I understand the need, but we won't be using SQLSTATE = 40001.
That corresponds to ERRCODE_T_R_SERIALIZATION_FAILURE, which that
error
would not be.
Isn't it a problem with serialization of database transactions? You
hit it in a different way,
Simon Riggs si...@2ndquadrant.com writes:
The error message ought to be snapshot too old, which could raise a
chuckle, so I called it something else.
The point you raise is a good one and I think we should publish a list
of retryable error messages. I contemplated once proposing a special
On Fri, 2008-12-19 at 18:59 +, Gregory Stark wrote:
Simon Riggs si...@2ndquadrant.com writes:
The error message ought to be snapshot too old, which could raise a
chuckle, so I called it something else.
The point you raise is a good one and I think we should publish a list
of
Simon Riggs si...@2ndquadrant.com wrote:
max_standby_delay is set in recovery.conf, value 0 (forever) -
2,000,000
secs, settable in milliseconds. So think of it like a deadlock
detector
for recovery apply.
Aha! A deadlock is a type of serialization failure. (In fact, on
databases with
On Fri, 2008-12-19 at 13:47 -0600, Kevin Grittner wrote:
Simon Riggs si...@2ndquadrant.com wrote:
max_standby_delay is set in recovery.conf, value 0 (forever) -
2,000,000
secs, settable in milliseconds. So think of it like a deadlock
detector
for recovery apply.
Aha! A deadlock
Simon Riggs si...@2ndquadrant.com writes:
Increasing the waiting time increases the failover time and thus
decreases the value of the standby as an HA system. Others value high
availability higher than you and so we had agreed to provide an option
to allow the max waiting time to be set.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Simon Riggs si...@2ndquadrant.com wrote:
max_standby_delay is set in recovery.conf, value 0 (forever) -
2,000,000
secs, settable in milliseconds. So think of it like a deadlock
detector
for recovery apply.
Aha! A deadlock is a type
Simon Riggs si...@2ndquadrant.com wrote:
The SQL Standard specifically names this error as thrown when it
detects the inability to guarantee the serializability of two or
more
concurrent SQL-transactions. Now that really should only apply when
running with SERIALIZABLE transactions,
I
Kevin Grittner kevin.gritt...@wicourts.gov writes:
PostgreSQL is much less prone to serialization failures, but it is
certainly understandable if hot standby replication introduces new
cases of it.
In this case it will be possible to get this error even if you're just running
a single SELECT
Gregory Stark st...@enterprisedb.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
PostgreSQL is much less prone to serialization failures, but it is
certainly understandable if hot standby replication introduces new
cases of it.
In this case it will be possible to get this
Gregory Stark st...@enterprisedb.com wrote:
I think the fundamental difference is that a deadlock or
serialization
failure
can be predicted as a potential problem when writing the code. This
is
something that can happen for any query any time, even plain old
read-only
select queries.
On Friday 19 December 2008 05:52:42 Simon Riggs wrote:
BTW, I noticed the other day that Oracle 11g only allows you to have a
read only slave *or* allows you to continue replaying. You need to
manually switch back and forth between those modes. They can't do
*both*, as Postgres will be able to
On Fri, 2008-12-19 at 20:54 +, Gregory Stark wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
PostgreSQL is much less prone to serialization failures, but it is
certainly understandable if hot standby replication introduces new
cases of it.
In this case it will be
On Fri, 2008-12-19 at 19:29 -0500, Robert Treat wrote:
On Friday 19 December 2008 05:52:42 Simon Riggs wrote:
BTW, I noticed the other day that Oracle 11g only allows you to have a
read only slave *or* allows you to continue replaying. You need to
manually switch back and forth between
Gregory Stark wrote:
Simon Riggs si...@2ndquadrant.com writes:
Increasing the waiting time increases the failover time and thus
decreases the value of the standby as an HA system. Others value high
availability higher than you and so we had agreed to provide an option
to allow the max waiting
Heikki Linnakangas wrote:
Gregory Stark wrote:
The question I had was whether your solution for btree pointers marked
dead
and later dropped from the index works when the user hasn't configured a
timeout and doesn't want standby queries killed.
Yes, it's not any different from vacuum WAL
Hi,
I found that no one is registered as hot standby reviewer. I'd like
to review the patch, mainly by testing through some benchmark test.
Regards;
2008/11/2 Simon Riggs [EMAIL PROTECTED]:
Hot Standby patch, including all major planned features.
Allows users to connect to server in
On Wed, Dec 3, 2008 at 11:00 AM, Koichi Suzuki [EMAIL PROTECTED] wrote:
Hi,
I found that no one is registered as hot standby reviewer. I'd like
to review the patch, mainly by testing through some benchmark test.
You can yourself edit the Wiki page, though you need to register first. But
Thank you for your advise. I'll edit the Wiki page.
2008/12/3 Pavan Deolasee [EMAIL PROTECTED]:
On Wed, Dec 3, 2008 at 11:00 AM, Koichi Suzuki [EMAIL PROTECTED] wrote:
Hi,
I found that no one is registered as hot standby reviewer. I'd like
to review the patch, mainly by testing
On Thu, Nov 20, 2008 at 8:15 PM, Pavan Deolasee [EMAIL PROTECTED]wrote:
On Thu, Nov 20, 2008 at 7:50 PM, Simon Riggs [EMAIL PROTECTED]wrote:
(I assume you mean bgwriter, not archiver process).
Yeah, its the bgwriter, IIRC hung while taking checkpoint.
Sorry, its the startup process
On Fri, 2008-11-21 at 17:08 +0530, Pavan Deolasee wrote:
Sorry, its the startup process thats stuck in the checkpoint. Here is
the stack trace:
Already fixed in new version I'm preparing for you.
Both the startup process and bgwriter can perform restartpoints, so its
not a problem whether we
On Thu, 2008-11-20 at 11:51 +0530, Pavan Deolasee wrote:
I wonder if we should refactor lazy_scan_heap() so that *all* the real
work of collecting information about dead tuples happens only in
heap_page_prune(). Frankly, there is only a rare chance that a tuple
may become DEAD after the
On Thu, Nov 20, 2008 at 3:38 PM, Simon Riggs [EMAIL PROTECTED] wrote:
I would suggest that we just remove the switch statement:
switch (HeapTupleSatisfiesVacuum(tuple.t_data, OldestXmin, buf))
and alter the following if test since tupgone is also removed.
That will cause
On Thu, 2008-11-20 at 12:03 +0530, Pavan Deolasee wrote:
On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs [EMAIL PROTECTED]
wrote:
Hot Standby patch, including all major planned features.
While experimenting with the patch, I noticed that sometimes the
archiver process
On Thu, Nov 20, 2008 at 7:50 PM, Simon Riggs [EMAIL PROTECTED] wrote:
(I assume you mean bgwriter, not archiver process).
Yeah, its the bgwriter, IIRC hung while taking checkpoint.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Pavan Deolasee [EMAIL PROTECTED] writes:
I wonder if we should refactor lazy_scan_heap() so that *all* the real work
of collecting information about dead tuples happens only in
heap_page_prune(). Frankly, there is only a rare chance that a tuple may
become DEAD after the pruning happened on
On Thu, 2008-11-20 at 10:33 -0500, Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
I wonder if we should refactor lazy_scan_heap() so that *all* the real work
of collecting information about dead tuples happens only in
heap_page_prune(). Frankly, there is only a rare chance that a
On Thu, Nov 20, 2008 at 9:03 PM, Tom Lane [EMAIL PROTECTED] wrote:
I don't think you can do that. Couldn't someone else have run
heap_page_prune between vacuum's first and second visit to the page?
You mean the second visit in the first pass where we again check for
On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Hot Standby patch, including all major planned features.
I wonder if we should refactor lazy_scan_heap() so that *all* the real work
of collecting information about dead tuples happens only in
heap_page_prune(). Frankly,
On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs [EMAIL PROTECTED] wrote:
Hot Standby patch, including all major planned features.
While experimenting with the patch, I noticed that sometimes the archiver
process indefinitely waits for WALInsertLock. I haven't spent much time
debugging that, but
Simon Riggs wrote:
On Mon, 2008-11-03 at 12:16 +1300, Mark Kirkwood wrote:
Trying out a few different scenarios I ran across this:
1/ Setup master and replica with replica using pg_standby
2/ Create a new database (bench in my case)
3/ Initialize pgbench schema size 100
4/ Run with 2
On Mon, 2008-11-03 at 06:41 +, Simon Riggs wrote:
On Mon, 2008-11-03 at 12:16 +1300, Mark Kirkwood wrote:
Trying out a few different scenarios I ran across this:
CONTEXT: xlog redo update: rel 1663/16384/16397; tid 9614/62; new 158828/59
DEBUG: start recovery xid = 7002 lsn =
On Mon, 2008-11-03 at 12:16 +1300, Mark Kirkwood wrote:
Trying out a few different scenarios I ran across this:
CONTEXT: xlog redo update: rel 1663/16384/16397; tid 9614/62; new 158828/59
DEBUG: start recovery xid = 7002 lsn = 0/6F012EE4
CONTEXT: xlog redo update: rel 1663/16384/16397;
On Thu, 2008-10-30 at 10:13 +, Simon Riggs wrote:
On Tue, 2008-10-21 at 15:06 +0100, Simon Riggs wrote:
We can't augment the commit/abort messages because
we must cater for non-transactional invalidations also, plus commit
xlrecs are already complex enough. So we log invalidations
On Tue, 2008-10-21 at 15:06 +0100, Simon Riggs wrote:
We can't augment the commit/abort messages because
we must cater for non-transactional invalidations also, plus commit
xlrecs are already complex enough. So we log invalidations prior to
commit, queue them and then trigger the send at
Simon Riggs [EMAIL PROTECTED] writes:
We can't augment the commit/abort messages because
we must cater for non-transactional invalidations also, plus commit
xlrecs are already complex enough. So we log invalidations prior to
commit, queue them and then trigger the send at commit (if it
On Thu, 2008-10-30 at 08:30 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We can't augment the commit/abort messages because
we must cater for non-transactional invalidations also, plus commit
xlrecs are already complex enough. So we log invalidations prior to
commit,
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-10-30 at 08:30 -0400, Tom Lane wrote:
What about using the existing
syscache logic to re-derive inval information from watching the update
operations?
That does sound possible, but it makes some big assumptions about
transactional machinery
On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
I'm looking to implement the following functions for Hot Standby, to
allow those with administrative tools or management applications to have
more control during recovery. Please let me know if other functions are
required.
What else do
On Mon, 2008-10-27 at 11:42 -0400, Robert Treat wrote:
On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
I'm looking to implement the following functions for Hot Standby, to
allow those with administrative tools or management applications to have
more control during recovery. Please
Simon Riggs wrote:
On Mon, 2008-10-27 at 11:42 -0400, Robert Treat wrote:
On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
I'm looking to implement the following functions for Hot Standby, to
allow those with administrative tools or management applications to have
more control
On Mon, 2008-10-27 at 13:08 -0400, Robert Treat wrote:
Was thinking that admin tools that show hot standby information might
also want to show the corresponding slave information (from the point
of view of the master).
Well, the standby might be persuaded to know something about the master,
On Monday 27 October 2008 12:12:18 Simon Riggs wrote:
On Mon, 2008-10-27 at 11:42 -0400, Robert Treat wrote:
On Monday 20 October 2008 05:25:29 Simon Riggs wrote:
I'm looking to implement the following functions for Hot Standby, to
allow those with administrative tools or management
On Mon, 2008-10-20 at 10:25 +0100, Simon Riggs wrote:
What else do we need?
* pg_freeze_recovery()
* pg_unfreeze_recovery()
Two more functions
pg_freeze_recovery_cleanup()
pg_unfreeze_recovery_cleanup()
These would allow recovery to continue normally, except for row removal
operations
* pg_last_recovered_xact_xid()
Will throw an ERROR if *not* executed in recovery mode.
returns bigint
* pg_last_completed_xact_xid()
Will throw an ERROR *if* executed in recovery mode.
returns bigint
Should these return xid?
And shouldn't these two be folded together ?
It seems
On Tue, 2008-10-21 at 09:44 +0200, Zeugswetter Andreas OSB sIT wrote:
* pg_last_recovered_xact_xid()
Will throw an ERROR if *not* executed in recovery mode.
returns bigint
* pg_last_completed_xact_xid()
Will throw an ERROR *if* executed in recovery mode.
returns bigint
* pg_last_recovered_xact_xid()
Will throw an ERROR if *not* executed in recovery mode.
returns bigint
* pg_last_completed_xact_xid()
Will throw an ERROR *if* executed in recovery mode.
returns bigint
Should these return xid?
...Robert
--
Sent via pgsql-hackers mailing list
On Mon, 2008-10-20 at 16:22 -0400, Robert Haas wrote:
* pg_last_recovered_xact_xid()
Will throw an ERROR if *not* executed in recovery mode.
returns bigint
* pg_last_completed_xact_xid()
Will throw an ERROR *if* executed in recovery mode.
returns bigint
Should these return xid?
On Fri, 2008-10-17 at 16:47 -0400, Merlin Moncure wrote:
On Fri, Oct 17, 2008 at 10:38 AM, Simon Riggs [EMAIL PROTECTED] wrote:
First integrated patch for Hot Standby, allowing queries to be executed
while in recovery mode.
The patch tests successfully with the enclosed files:
*
On Sat, Oct 18, 2008 at 4:11 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Fri, 2008-10-17 at 16:47 -0400, Merlin Moncure wrote:
On Fri, Oct 17, 2008 at 10:38 AM, Simon Riggs [EMAIL PROTECTED] wrote:
First integrated patch for Hot Standby, allowing queries to be executed
while in recovery
On Fri, Oct 17, 2008 at 10:38 AM, Simon Riggs [EMAIL PROTECTED] wrote:
First integrated patch for Hot Standby, allowing queries to be executed
while in recovery mode.
The patch tests successfully with the enclosed files:
* primary_setup_test.sql - run it on primary node
*
On Wed, 2008-09-24 at 00:30 -0400, Robert Treat wrote:
here are some scattered thoughts i had while reading it :
Thanks for your comments.
It is very detailed, so further feedback is going to be very beneficial
in making this all work in the way we hope and expect.
* However, some WAL redo
On Wed, Sep 24, 2008 at 5:30 AM, Robert Treat
[EMAIL PROTECTED] wrote:
I presume this means the backend kill function would work? Also, can you go
into why pgAgent would not work? (I presume it's because you can't update
information that needs to be changed when jobs run, if thats the case it
On Wed, 2008-09-24 at 08:28 +0100, Dave Page wrote:
On Wed, Sep 24, 2008 at 5:30 AM, Robert Treat
[EMAIL PROTECTED] wrote:
I presume this means the backend kill function would work? Also, can you go
into why pgAgent would not work? (I presume it's because you can't update
information
On Wednesday 24 September 2008 03:27:44 Simon Riggs wrote:
On Wed, 2008-09-24 at 00:30 -0400, Robert Treat wrote:
here are some scattered thoughts i had while reading it :
Thanks for your comments.
It is very detailed, so further feedback is going to be very beneficial
in making this all
On Wed, 2008-09-24 at 12:35 -0400, Robert Treat wrote:
On Wednesday 24 September 2008 03:27:44 Simon Riggs wrote:
On Wed, 2008-09-24 at 00:30 -0400, Robert Treat wrote:
* However, some WAL redo actions will be for DDL actions. These DDL
actions are repeating actions that have already
On Tuesday 23 September 2008 14:15:34 Simon Riggs wrote:
Hot Standby design has been growing on the PostgreSQL Wiki for some
weeks now.
I've updated the design to reflect all feedback received so far on
various topics.
http://wiki.postgresql.org/wiki/Hot_Standby
It's not hugely detailed
Ühel kenal päeval, R, 2006-07-21 kell 20:00, kirjutas Chris Campbell:
The documentation [1] says this about On-line backup and point-in-
time recovery:
If we continuously feed the series of WAL files to another machine
that has been loaded with the same base backup file, we have a hot
Is this possible today in a stable and robust way? If so, can we
document the procedure? If not, should we alter the documentation so
it's not misleading? I've had several people ask me where to enable the
hot standby feature, not realizing that PostgreSQL only has some of
the raw materials
901 - 968 of 968 matches
Mail list logo
