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 wond
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 should/could track the "latestRe
Simon Riggs wrote:
On Sat, 2008-12-20 at 09:21 +0200, Heikki Linnakangas wrote:
Gregory Stark wrote:
Simon Riggs 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
On Sat, 2008-12-20 at 09:21 +0200, Heikki Linnakangas wrote:
> Gregory Stark wrote:
> > Simon Riggs 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 s
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 reco
Gregory Stark wrote:
Simon Riggs 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.
Sure
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 betwe
On Fri, 2008-12-19 at 20:54 +, Gregory Stark wrote:
> "Kevin Grittner" 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 er
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
>>> Gregory Stark 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.
I've heard that
>>> Gregory Stark wrote:
> "Kevin Grittner" 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
> runnin
"Kevin Grittner" 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 query -- and that's the
>>> Simon Riggs 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 disagree. Data
"Kevin Grittner" writes:
Simon Riggs 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
Simon Riggs 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.
Sure, it's a nice opt
On Fri, 2008-12-19 at 13:47 -0600, Kevin Grittner wrote:
> >>> Simon Riggs 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 t
>>> Simon Riggs 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 lock-based concur
On Fri, 2008-12-19 at 18:59 +, Gregory Stark wrote:
> Simon Riggs 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 er
Simon Riggs 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 log
> level for a
>>> Simon Riggs 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, but if it is a t
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
On Fri, 2008-12-19 at 11:54 -0600, Kevin Grittner wrote:
> >>> Simon Riggs 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 OldestXm
>>> Simon Riggs 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 has been modif
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
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 > wrote:
Whenever a B-tree index scan fetches a heap tuple that turns out to
be dead, the B-tree item is marked as k
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 i
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, bu
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_pa
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 b
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
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 ar
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 w
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
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
HeapTupleSatisf
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 cha
"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 happene
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
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 proce
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 HEAPTUP
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 p
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, b
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(). Frankl
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 clien
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
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/163
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 invalidat
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
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
> >
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 i
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
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 maste
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 manageme
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 dur
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. Pl
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
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
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.
> > > r
> > * 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 togeth
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 thes
> * 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 (pgsql-
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
>> > whi
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 fil
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
> * standby_al
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 al
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 thi
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
> > inf
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 cas
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 red
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 de
Ü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
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 - 971 of 971 matches
Mail list logo
