Hannu Krosing wrote:
Actually we came up with a solution to this - use filesystem level
snapshots (like LVM2+XFS or ZFS), and redirect backends with
long-running queries to use fs snapshot mounted to a different
mountpoint.
I don't think Simon has yet put full support for it in code, but it
Hannu Krosing ha...@krosing.net writes:
Actually we came up with a solution to this - use filesystem level
snapshots (like LVM2+XFS or ZFS), and redirect backends with
long-running queries to use fs snapshot mounted to a different
mountpoint.
Uhm, how do you determine which snapshot to
I don't see any way around the fact that when a tuple is removed, it's
gone and can't be accessed by queries. Either you don't remove it, or
you kill the query.
Actually we came up with a solution to this - use filesystem level
snapshots (like LVM2+XFS or ZFS), and redirect backends with
On Tue, 2009-02-03 at 08:40 -0500, Andrew Dunstan wrote:
Hannu Krosing wrote:
Actually we came up with a solution to this - use filesystem level
snapshots (like LVM2+XFS or ZFS), and redirect backends with
long-running queries to use fs snapshot mounted to a different
mountpoint.
I
On Tue, 2009-02-03 at 09:14 -0500, Robert Haas wrote:
I don't see any way around the fact that when a tuple is removed, it's
gone and can't be accessed by queries. Either you don't remove it, or
you kill the query.
Actually we came up with a solution to this - use filesystem level
On Tue, 2009-02-03 at 09:14 -0500, Robert Haas wrote:
I think _the_ solution is to notice when you're about to vacuum a page
that is still visible to a running backend on the standby, and save
that page off to a separate cache of old page versions (perhaps using
the relation fork mechanism).
On Tue, 2009-02-03 at 13:50 +, Gregory Stark wrote:
Hannu Krosing ha...@krosing.net writes:
Actually we came up with a solution to this - use filesystem level
snapshots (like LVM2+XFS or ZFS), and redirect backends with
long-running queries to use fs snapshot mounted to a different
On Tue, 2009-02-03 at 08:40 -0500, Andrew Dunstan wrote:
Hannu Krosing wrote:
Actually we came up with a solution to this - use filesystem level
snapshots (like LVM2+XFS or ZFS), and redirect backends with
long-running queries to use fs snapshot mounted to a different
mountpoint.
I
On Tue, Feb 3, 2009 at 9:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2009-02-03 at 09:14 -0500, Robert Haas wrote:
I think _the_ solution is to notice when you're about to vacuum a page
that is still visible to a running backend on the standby, and save
that page off to a separate
On Tue, 2009-02-03 at 15:55 +0100, Andres Freund wrote:
Hi,
On 02/03/2009 02:26 PM, Hannu Krosing wrote:
I don't see any way around the fact that when a tuple is removed, it's
gone and can't be accessed by queries. Either you don't remove it, or
you kill the query.
Actually we came up
On Tue, 2009-02-03 at 10:19 -0500, Robert Haas wrote:
On Tue, Feb 3, 2009 at 9:40 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2009-02-03 at 09:14 -0500, Robert Haas wrote:
I think _the_ solution is to notice when you're about to vacuum a page
that is still visible to a running
On Tue, 2009-02-03 at 14:28 +, Simon Riggs wrote:
On Tue, 2009-02-03 at 08:40 -0500, Andrew Dunstan wrote:
Hannu Krosing wrote:
Actually we came up with a solution to this - use filesystem level
snapshots (like LVM2+XFS or ZFS), and redirect backends with
long-running queries to
Hi,
On 02/03/2009 02:26 PM, Hannu Krosing wrote:
I don't see any way around the fact that when a tuple is removed, it's
gone and can't be accessed by queries. Either you don't remove it, or
you kill the query.
Actually we came up with a solution to this - use filesystem level
snapshots (like
On Tue, 2009-02-03 at 18:09 +0200, Hannu Krosing wrote:
On Tue, 2009-02-03 at 14:28 +, Simon Riggs wrote:
On Tue, 2009-02-03 at 08:40 -0500, Andrew Dunstan wrote:
Hannu Krosing wrote:
Actually we came up with a solution to this - use filesystem level
snapshots (like LVM2+XFS
On Wed, 2009-01-28 at 22:19 +0200, Heikki Linnakangas wrote:
Tom Lane wrote:
...
Well, those unexpectedly cancelled queries could have represented
critical functionality too. I think this argument calls the entire
approach into question. If there is no safe setting for the parameter
I skimmed through the Hot Standby patch for a preliminary review. I noted the
following things, some minor tweaks, some just questions. None of the things I
noted are big issues unless some of the questions uncover issues.
1) This code is obviously a cut-pasto:
+ else if (strcmp(tok1,
On Wed, 2009-01-28 at 18:55 +, Gregory Stark wrote:
I skimmed through the Hot Standby patch for a preliminary review. I noted the
following things, some minor tweaks, some just questions. None of the things I
noted are big issues unless some of the questions uncover issues.
Thanks for
On Wed, 2009-01-28 at 19:27 +, Simon Riggs wrote:
On Wed, 2009-01-28 at 18:55 +, Gregory Stark wrote:
Agreed. As explained when I published that patch it is deliberately
severe to allow testing of conflict resolution and feedback on it.
I still *strongly* feel the default has to be
Gregory Stark wrote:
6) I still don't understand why you need unobserved_xids. We don't need this
in normal running, an xid we don't know for certain is committed is exactly
the same as a transaction we know is currently running or aborted. So why do
you need it during HS?
In normal operation,
On Wed, 2009-01-28 at 18:55 +, Gregory Stark wrote:
I still don't understand why you need unobserved_xids. We don't need
this in normal running, an xid we don't know for certain is committed
is exactly the same as a transaction we know is currently running or
aborted. So why do you need
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-01-28 at 19:27 +, Simon Riggs wrote:
On Wed, 2009-01-28 at 18:55 +, Gregory Stark wrote:
I still *strongly* feel the default has to be the
non-destructive conservative -1.
I don't. Primarily, we must support high
* Tom Lane t...@sss.pgh.pa.us [090128 15:02]:
Well, those unexpectedly cancelled queries could have represented
critical functionality too. I think this argument calls the entire
approach into question. If there is no safe setting for the parameter
then we need to find a way to not have
(sorry for top posting -- blame apple)
I don't see anything dangerous with either setting. For use cases
where the backup is the primary purpose then killing queries is fine.
For use cases where the maching is a reporting machine then saving
large amounts of archived logs is fine.
Put another way: your characterization is no more true than claiming
there's no safe setting for statement_timeout since a large value
means clog could overflow your disk and your tables could bloat.
(I note we default statement_timeout to off though)
--
Greg
On 28 Jan 2009, at 19:56, Tom
On Wed, 2009-01-28 at 21:41 +0200, Heikki Linnakangas wrote:
So, you can think of the unobserved xids array as an extension of
ProcArray. The entries are like light-weight PGPROC entries. In fact I
proposed earlier to simply create dummy PGPROC entries instead.
Which we don't do because we
On Wed, 2009-01-28 at 19:27 +, Simon Riggs wrote:
my failover was 12 hours behind when I needed it to be 10 seconds
behind and I lost a $1 million because of downtime of Postgres
The same could be said for warm standby right now. Or Slony-I, for that
matter. I think that we can reasonably
Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-01-28 at 19:27 +, Simon Riggs wrote:
On Wed, 2009-01-28 at 18:55 +, Gregory Stark wrote:
I still *strongly* feel the default has to be the
non-destructive conservative -1.
I don't. Primarily, we must support
On Wed, 2009-01-28 at 11:33 -0800, Joshua D. Drake wrote:
On Wed, 2009-01-28 at 19:27 +, Simon Riggs wrote:
On Wed, 2009-01-28 at 18:55 +, Gregory Stark wrote:
Agreed. As explained when I published that patch it is deliberately
severe to allow testing of conflict resolution and
On Wed, 2009-01-28 at 14:56 -0500, Tom Lane wrote:
Well, those unexpectedly cancelled queries could have represented
critical functionality too. I think this argument calls the entire
approach into question. If there is no safe setting for the parameter
then we need to find a way to not
Simon Riggs wrote:
The essential choice is What would you like the max failover time to
be?. Some users want one server with max 5 mins behind, some want two
servers, one with 0 seconds behind, one with 12 hours behind
It's not quite that simple. Setting max_standby_delay=5mins means that
On Wed, 2009-01-28 at 22:47 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
The essential choice is What would you like the max failover time to
be?. Some users want one server with max 5 mins behind, some want two
servers, one with 0 seconds behind, one with 12 hours behind
It's
On Wed, 2009-01-28 at 22:47 +0200, Heikki Linnakangas wrote:
It's not quite that simple. Setting max_standby_delay=5mins means that
you're willing to wait 5 minutes for each query to die. Which means that
in worst case you have to stop for 5 minutes at every single vacuum
record, and fall
I don't. Primarily, we must support high availability. It is much better
if we get people saying I get my queries cancelled and we say RTFM and
change parameter X, than if people say my failover was 12 hours behind
when I needed it to be 10 seconds behind and I lost a $1 million because
of
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2009-01-28 at 14:56 -0500, Tom Lane wrote:
Well, those unexpectedly cancelled queries could have represented
critical functionality too. I think this argument calls the entire
approach into question. If there is no safe setting for the
Robert Haas robertmh...@gmail.com writes:
I vote with Simon. The thing is that if you get some queries
cancelled, you'll realize you have a problem.
... or if you don't, they couldn't have been all that critical.
Having your failover be 12 hours
behind (or 12 months behind) is something
On Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
Bug fix patch against git repo.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
***
On Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
I'm seeing an off-by-one error on xmax, in some cases. That then causes
the flat file update
On Sat, 2009-01-24 at 11:20 +, Simon Riggs wrote:
On Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
I'm seeing an off-by-one error
Simon Riggs wrote:
On Sat, 2009-01-24 at 11:20 +, Simon Riggs wrote:
On Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
Simon Riggs wrote:
* Put corrected version into GIT
* Produce outstanding items as patch-on-patch via GIT
I've applied the hot standby patch and recovery infra v9 patch to
branches in my git repository, and pushed those to:
git://git.postgresql.org/git/~hlinnaka/pgsql.git
You can clone
On Fri, 2009-01-23 at 16:14 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
* Put corrected version into GIT
* Produce outstanding items as patch-on-patch via GIT
I've applied the hot standby patch and recovery infra v9 patch to
branches in my git repository, and pushed those to:
Simon Riggs wrote:
On Fri, 2009-01-23 at 16:14 +0200, Heikki Linnakangas wrote:
I made a couple of minor changes after importing your
patches.
I've applied them both to v9g, attached here.
If you wouldn't mind redoing the initial step, I will promise not to do
anything else to the code,
@@ -1601,6 +1602,24 @@ BufferProcessRecoveryConflictsIfAny(volatile BufferDesc
*bufHdr)
{
XLogRecPtr bufLSN = BufferGetLSN(bufHdr);
+ /*
+* If the buffer is recent we may need to cancel ourselves
+* rather than risk
On Fri, 2009-01-23 at 18:22 +0200, Heikki Linnakangas wrote:
@@ -1601,6 +1602,24 @@ BufferProcessRecoveryConflictsIfAny(volatile
BufferDesc *bufHdr)
{
XLogRecPtr bufLSN = BufferGetLSN(bufHdr);
+ /*
+* If the buffer is
Simon Riggs wrote:
If you have a serializable transaction with subtransactions that suffers
a serializability error it only cancels the current subtransaction. That
means it's snapshot is still valid and can be used again. By analogy, as
long as a transaction does not see any data that is
Heikki Linnakangas wrote:
Simon Riggs wrote:
If you have a serializable transaction with subtransactions that suffers
a serializability error it only cancels the current subtransaction. That
means it's snapshot is still valid and can be used again. By analogy, as
long as a transaction does
If you have a serializable transaction with subtransactions that
suffers
a serializability error it only cancels the current subtransaction.
This is a complete tangent to your work, but I wonder if this is
really right. I mean it's not as if we could have srrialized the
transaction
On Fri, 2009-01-23 at 20:13 +, Greg Stark wrote:
If you have a serializable transaction with subtransactions that
suffers
a serializability error it only cancels the current subtransaction.
This is a complete tangent to your work, but I wonder if this is
really right. I mean it's
Simon Riggs wrote:
On Thu, 2009-01-22 at 22:35 +, Simon Riggs wrote:
* Bug fix v9 over next few days
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
master:
=# create database
49 matches
Mail list logo
