Simon Riggs wrote:
> On Tue, 2010-05-04 at 13:23 -0400, Tom Lane wrote:
>
>> * LogStandbySnapshot is merest fantasy: no guarantee that either the
>> XIDs list or the locks list will be consistent with the point in WAL
>> where it will get inserted. What's worse, locking things down enough
>> to g
On Mon, May 3, 2010 at 14:04, Andrew Dunstan wrote:
>
> [ Awesome work getting buildfarm support for git ]
> Note, this is running from my test git repo, not the community's repo.
BTW +1 for gitting (heh, git puns are fun) a good git repo published.
Ive given up trying to trust it for back branc
On Wed, May 5, 2010 at 5:01 AM, Andrew Dunstan wrote:
> Our process is shot to pieces. But then, we knew that, didn't we ;-)
>
Franky I think these kinds of usability questions are things that
we'll never have great success getting feedback on without users
banging on the system. There are soluti
Robert Haas wrote:
On Tue, May 4, 2010 at 11:06 PM, Bruce Momjian wrote:
Should I be concerned that we are redesigning HS features at this stage
in the release?
Yep. You can decide whether you want to be concerned by the redesign
itself, or by the concerns about the underlying code
On Tue, Apr 27, 2010 at 9:59 PM, Robert Haas wrote:
> [storage.c,xact.c,twophase.c] smgrGetPendingDeletes returns via an out
> parameter (its second argument) a list of RelFileNodes pending delete,
> which we then write to WAL or to the two-phase state file.
It appears that we are playing a littl
On Tue, May 4, 2010 at 11:06 PM, Bruce Momjian wrote:
> Should I be concerned that we are redesigning HS features at this stage
> in the release?
Yep. You can decide whether you want to be concerned by the redesign
itself, or by the concerns about the underlying code that are
motivating the rede
Tom Lane wrote:
> Greg Smith writes:
> > Anyway, I have no idea where the idea that recommending time
> > synchronization is a somehow a "high end" requirement,
>
> Considering that clock skew was only one of several scenarios in which
> the max_standby_delay code misbehaves, it's not that impor
On Tue, May 04, 2010 at 10:00:52PM -0400, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
> >On Tue, May 04, 2010 at 04:40:22PM -0700, Josh Berkus wrote:
> >>Hackers, Driver maintainers,
> >>
> >>The 9.0 "don't rename index cols" behavior has already broken JDBC. We
> >>need to get in touch with
David Fetter wrote:
On Tue, May 04, 2010 at 04:40:22PM -0700, Josh Berkus wrote:
Hackers, Driver maintainers,
The 9.0 "don't rename index cols" behavior has already broken JDBC. We
need to get in touch with other driver authors to see if they are
affected by this, and to let them know tha
On Tue, May 04, 2010 at 04:40:22PM -0700, Josh Berkus wrote:
> Hackers, Driver maintainers,
>
> The 9.0 "don't rename index cols" behavior has already broken JDBC. We
> need to get in touch with other driver authors to see if they are
> affected by this, and to let them know that they'll need a n
On 05/05/10 13:15, Mark Kirkwood wrote:
Please log into postgres do:
SELECT version();
(and Robert suggested)
Should read *as* Robert suggested - sorry.
Also you could do this from the os:
$ aptitude show postgresql-8.3*
*which will display more detail for the version.
Cheers
Mark
*
*
On 05/05/10 06:24, Srinivas Naik wrote:
I am sorry for that, but I made two different installations and I was
messing up with various inputs.
Actually, the installed versions are below
*postgresql-8.3*
*Ubuntu 8.10 with 2.6.27 Kernel*
*and its an 32Bit O/S*
pgsql$ SELECT substring(B'00
> Releasing a hot standby which *only* works for users with an operational
> ntp implementation is highly unrealistic. Having built-in replication
> in PostgreSQL was supposed to give the *majority* of users a *simple*
> option for 2-server failover, not cater only to the high end. Every
> admi
Greg Smith writes:
> Anyway, I have no idea where the idea that recommending time
> synchronization is a somehow a "high end" requirement,
Considering that clock skew was only one of several scenarios in which
the max_standby_delay code misbehaves, it's not that important whether
you consider it
Josh Berkus wrote:
Having built-in replication in PostgreSQL was supposed to give the *majority*
of users a *simple*
option for 2-server failover, not cater only to the high end.
If that's your criteria, 9.0 has already failed that goal. Just the
fact that you have to make your own base back
On Tue, 2010-05-04 at 16:34 -0700, Josh Berkus wrote:
> On 5/4/10 4:26 PM, Greg Smith wrote:
> >
> > Not the database's problem to worry about. Document that time should be
> > carefully sync'd and move on. I'll add that.
>
> Releasing a hot standby which *only* works for users with an operatio
On Tue, 2010-05-04 at 13:23 -0400, Tom Lane wrote:
> * LogStandbySnapshot is merest fantasy: no guarantee that either the
> XIDs list or the locks list will be consistent with the point in WAL
> where it will get inserted. What's worse, locking things down enough
> to guarantee consistency would
Hackers, Driver maintainers,
The 9.0 "don't rename index cols" behavior has already broken JDBC. We
need to get in touch with other driver authors to see if they are
affected by this, and to let them know that they'll need a new driver
release for 9.0, if so.
--
On 5/4/10 4:26 PM, Greg Smith wrote:
>
> Not the database's problem to worry about. Document that time should be
> carefully sync'd and move on. I'll add that.
Releasing a hot standby which *only* works for users with an operational
ntp implementation is highly unrealistic. Having built-in re
Greg Smith writes:
> If the standby is not current, you may not want people to execute
> queries against it. In some situations, returning results against
> obsolete data is worse than not letting the query execute at all. As I
> see it, the current max_standby_delay implementation includes t
Tom Lane wrote:
1. The timestamps we are reading from the log might be historical,
if we are replaying from archive rather than reading a live SR stream.
In the current implementation that means zero grace period for standby
queries. Now if your only interest is catching up as fast as possible,
On Tue, 2010-05-04 at 18:53 -0400, Tom Lane wrote:
> I think you missed the point: "do nothing" is not a viable option.
> I was proposing something that seemed simple enough to be safe to
> drop into 9.0 at this point.
I've posted a patch that meets your stated objections. If you could
review th
Josh Berkus writes:
> Given your clarification on the whole set of behaviors, I'm highly
> dubious about the idea of implementing Tom's proposal when we're already
> Beta 1. It seems like a 9.1 thing.
I think you missed the point: "do nothing" is not a viable option.
I was proposing something th
On Tue, May 4, 2010 at 5:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> One possible thing we might do (bearing in mind that we might need to
>> wall off access at multiple levels) would be to forbid creating a
>> relcache entry for a non-local temprel. That would, in turn, forbid
>> doing pret
Alvaro Herrera writes:
> I don't very much like the wildcard idea; but I don't think it's
> unreasonable to refuse to provide a file size. If the owning backend
> has still got part of the table in local buffers, you'll get a
> misleading answer, so perhaps it's best to not give an answer at all.
Robert Haas writes:
> One possible thing we might do (bearing in mind that we might need to
> wall off access at multiple levels) would be to forbid creating a
> relcache entry for a non-local temprel. That would, in turn, forbid
> doing pretty much anything to such a relation, although I'm not s
Gurjeet Singh wrote:
> There are quite a few GUC parameters that need restart. Is there a
> way we can avoid some of them needing restart? I am specifically
> looking at archive_mode and the new wal_level.
I'll second this on a "don't know if it's practicable, but it would
be nice if..." basis
>> AFAIK, Tom was proposing that the
>> pending recovery data would wait for max_standby_delay, total, then
>> cancel *all* queries which conflicted with it. Now that we've talked
>> this out, though, I can see that this can still result in "mass cancel"
>> issues, just like the current max_sta
There are quite a few GUC parameters that need restart. Is there a way we
can avoid some of them needing restart? I am specifically looking at
archive_mode and the new wal_level.
>From my limited understanding, these parameters need restart because in a
running cluster we cannot safely change thes
On Tue, 2010-05-04 at 21:34 +0200, Stefan Kaltenbrunner wrote:
> FWIW - I'm seeing a behaviour here under pgbench -S workloads that looks
> kinda related.
>
> using -j 16 -c 16 -T 120 I get either 10tps and around 66
> contextswitches per second or on some runs I end up with 15tps a
On Tue, 2010-05-04 at 13:23 -0400, Tom Lane wrote:
> * max_standby_delay logic is broken, as per other thread.
Proposed fix submitted,
> * handle_standby_sig_alarm is broken to the point of needing to be
> thrown away; you can NOT do that kind of thing in an interrupt handler.
This was modelled
On Tue, 2010-05-04 at 11:27 -0700, Josh Berkus wrote:
> I still don't see how that works.
...
The good news is we agree by the time we get to the bottom... ;-)
> I'm more interested in your assertion that there's a lot in the
> replication stream which doesn't take a lock; if that's the case, th
On Tue, May 4, 2010 at 3:03 PM, Alvaro Herrera
wrote:
>> > Hmm, wasn't there a proposal to have the owning backend delete the files
>> > instead of asking the bgwriter to?
>>
>> I did propose that upthread; it may have been proposed previously
>> also. This might be worth doing independently of th
On Tue, May 4, 2010 20:26, Greg Smith wrote:
> Erik Rijkers wrote:
>> OS: Centos 5.4
>> 2 quadcores: Intel(R) Xeon(R) CPU X5482 @ 3.20GHz
>> Areca 1280ML
>> primary and standby db both on a 12 disk array (sata 7200rpm, Seagat
>> Barracuda ES.2)
>>
>
> To fill in from data you already menti
Erik Rijkers wrote:
Hi Simon,
In another thread you mentioned you were lacking information from me:
On Tue, May 4, 2010 17:10, Simon Riggs wrote:
There is no evidence that Erik's strange performance has anything to do
with HS; it hasn't been seen elsewhere and he didn't respond to
questions ab
Robert Haas escribió:
> On Tue, May 4, 2010 at 2:06 PM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
>
> Hey, thanks for writing back! I just spent the last few hours
> thinking about this and beating my head against the wall.
:-)
> >> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr
Srinivas Naik wrote:
> Actually, the installed versions are below
> *postgresql-8.3*
> I just wanted to know how severe it is and how it can effect the
> database to result Memory Corruption/DoS.
Well, you're clearly *not* on 8.3.10, or you would not get the
error. Perhaps you should apply
On Mon, May 3, 2010 at 4:37 PM, Tom Lane wrote:
> 1. The timestamps we are reading from the log might be historical,
> 2. There could be clock skew between the master and slave servers.
> 3. There could be significant propagation delay from master to slave,
So it sounds like what you're expecti
Simon,
> Yes, the max wait on any *one* blocker will be max_standby_delay. But if
> you wait for two blockers, then the total time by which the standby lags
> will now be 2*max_standby_delay. Add a third, fourth etc and the standby
> lag keeps rising.
I still don't see how that works. If we're l
Erik Rijkers wrote:
OS: Centos 5.4
2 quadcores: Intel(R) Xeon(R) CPU X5482 @ 3.20GHz
Areca 1280ML
primary and standby db both on a 12 disk array (sata 7200rpm, Seagat
Barracuda ES.2)
To fill in from data you already mentioned upthread:
32 GB RAM
CentOS release 5.4 (Final), x86_64 Li
I am sorry for that, but I made two different installations and I was
messing up with various inputs.
Actually, the installed versions are below
*postgresql-8.3*
*Ubuntu 8.10 with 2.6.27 Kernel*
*and its an 32Bit O/S*
pgsql$ SELECT substring(B'0001' from 5 for -2);
ERROR:invalid memo
On Tue, May 4, 2010 at 2:06 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
Hey, thanks for writing back! I just spent the last few hours
thinking about this and beating my head against the wall.
>> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr for temporary
>> relations? I think the
Robert Haas escribió:
> [smgr.c,inval.c] Do we need to call CacheInvalidSmgr for temporary
> relations? I think the only backend that can have an smgr reference
> to a temprel other than the owning backend is bgwriter, and AFAICS
> bgwriter will only have such a reference if it's responding to a
On Tue, 2010-05-04 at 13:23 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > There hasn't been anything more than a minor bug in weeks, so not really
> > sure how you arrive at that the idea the code needs "stabilising".
>
> Simon, if you don't think the code needs stabilizing, you need to think
On Tue, 2010-05-04 at 13:00 -0400, Bruce Momjian wrote:
> Well, this is kind of my point --- that if few people are going to need
> a parameter and it is going to take us to tell them to use it, it isn't
> a good parameter because the other 99.9% are going to stare at the
> parameters and not konw
Simon Riggs writes:
> There hasn't been anything more than a minor bug in weeks, so not really
> sure how you arrive at that the idea the code needs "stabilising".
Simon, if you don't think the code needs stabilizing, you need to think
again.
* max_standby_delay logic is broken, as per other th
Simon Riggs wrote:
> On Mon, 2010-05-03 at 22:45 -0400, Bruce Momjian wrote:
>
> > As I remember, 9.0 has two behaviors:
> >
> > o master delays vacuum cleanup
> > o slave delays WAL application
> >
> > and in 9.1 we will be adding:
> >
> > o slave communicates snapshots to maste
On Tue, May 4, 2010 18:19, Simon Riggs wrote:
> On Tue, 2010-05-04 at 18:10 +0200, Erik Rijkers wrote:
>> It would be interesting if anyone repeated these simple tests and
>> produced evidence that these non-HS.
>>
>> (Unfortunately, I have at the moment not much time for more testing)
>
> Would yo
On Tue, 2010-05-04 at 18:10 +0200, Erik Rijkers wrote:
> It would be interesting if anyone repeated these simple tests and
> produced
> evidence that these non-HS.
>
> (Unfortunately, I have at the moment not much time for more testing)
Would you be able to make those systems available for furthe
Hi Simon,
In another thread you mentioned you were lacking information from me:
On Tue, May 4, 2010 17:10, Simon Riggs wrote:
>
> There is no evidence that Erik's strange performance has anything to do
> with HS; it hasn't been seen elsewhere and he didn't respond to
> questions about the test se
On Tue, May 4, 2010 at 11:10 AM, Simon Riggs wrote:
> This is clearly a response to issues raised about HS and not a new
> feature.
I don't find that clear at all. In fact, I find the exact opposition
position to be clear.
> It's also proposed in the most minimal way possible with
> respect for
Robert Haas wrote:
On Mon, May 3, 2010 at 4:04 PM, Andrew Dunstan wrote:
For those who have been following along, today I reached a bit of a
milestone. The buildfarm member quoll, which is running a git-ized buildfarm
client due to be released in a week or so, today successfully built all
On Tue, 2010-05-04 at 11:12 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > In the original patch I had Pause/Resume feature for controlling
> > recovery during Hot Standby. It was removed for lack of time.
>
> > With all the discussion around the HS UI, it would be something that
> > could be b
Robert Haas wrote:
> But I don't have strong feelings about it.
Nor do I. Perhaps this question should be floated on -general?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacker
Simon Riggs writes:
> In the original patch I had Pause/Resume feature for controlling
> recovery during Hot Standby. It was removed for lack of time.
> With all the discussion around the HS UI, it would be something that
> could be back very easily.
Sure. In 9.1. You have enough bugs to fix t
On Tue, 2010-05-04 at 09:36 -0400, Robert Haas wrote:
> On Tue, May 4, 2010 at 4:02 AM, Simon Riggs wrote:
> > In the original patch I had Pause/Resume feature for controlling
> > recovery during Hot Standby. It was removed for lack of time.
>
> Well, it's not like we have more time now than we
Robert Haas writes:
> On Tue, May 4, 2010 at 10:29 AM, Kevin Grittner
> wrote:
>> We have maintained nonstandard behavior in the past for
>> compatibility reasons, so it's a fair question; however, I'm
>> inclined toward the standard on this one.
> In a case like this, it seems unlikely that som
On Tue, May 4, 2010 at 10:29 AM, Kevin Grittner
wrote:
> We have maintained nonstandard behavior in the past for
> compatibility reasons, so it's a fair question; however, I'm
> inclined toward the standard on this one.
In a case like this, it seems unlikely that someone would be counting
on a ne
On Tue, 2010-05-04 at 14:49 +0100, Simon Riggs wrote:
> The only difference is that max_standby_delay is measured from log
> timestamp. Perhaps it should work from WAL receipt timestamp rather than
> from log timestamp? That would make some of the problems go away without
> significantly changing
2010/5/4 Merlin Moncure :
> On Tue, May 4, 2010 at 10:05 AM, Pavel Stehule
> wrote:
>> and then string_to_array and array_to_string are orthogonal with NULL.
>
> I like the behavior, but should it share the name with the 2 argument
> version given the incompatibility? Maybe make a new function
>
Robert Haas wrote:
> I think the OP is probably running a version that doesn't include
> the Jan 7 commit, which was effectively undone by the Jan 25
> commit for CVS HEAD.
It sure looks like it.
> It looks like this was intentional based on spec behavior
> of overlay(), but should we consid
Downthread, I said..
On Tue, 2010-05-04 at 14:49 +0100, Simon Riggs wrote:
> The only difference is that max_standby_delay is measured from log
> timestamp. Perhaps it should work from WAL receipt timestamp rather than
> from log timestamp? That would make some of the problems go away without
> s
On Tue, May 4, 2010 at 10:05 AM, Pavel Stehule wrote:
> and then string_to_array and array_to_string are orthogonal with NULL.
I like the behavior, but should it share the name with the 2 argument
version given the incompatibility? Maybe make a new function
to_string(anyarray, sep, nullsym='') an
On Tue, May 4, 2010 at 10:08 AM, Erik Rijkers wrote:
> fwiw, results for all current postgres versions:
> [ only 9.0beta1 is different ]
It looks like the relevant commits are:
commit 822f2ac5a2ec7c6f10634f62a0b2dc6cc9929759
Author: Tom Lane
Date: Mon Jan 25 20:55:32 2010 +
Add get_b
2010/5/4 Pavel Stehule :
> 2010/5/4 Tom Lane :
>> Josh Berkus writes:
quietly removing NULL is maybe good for compatibility but is wrong for
functionality.
>>
>>> I agree. I wasn't aware of this little misfeature.
>>
>>> Default display for NULL should be a zero-length string.
>>
>> Tha
On Tue, May 4, 2010 15:40, Robert Haas wrote:
> On Tue, May 4, 2010 at 7:46 AM, Srinivas Naik wrote:
>> Hi Mark,
>>
>> Please find the below details:
>>
>> postgresql-8.3
>>
>> and UBUNTU-8.10 with linux-image-2.6.27.18-standard_810_i386.deb
>>
>> and its an 32bit Ubuntu.
>
> Err, before you s
On Tue, 2010-05-04 at 09:12 -0400, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > If recovery waits for max_standby_delay every time something gets in its
> > way, it should be clear that if many things get in its way it will
> > progressively fall behind. There is no limit
On Tue, May 4, 2010 at 7:46 AM, Srinivas Naik wrote:
> Hi Mark,
>
> Please find the below details:
>
> postgresql-8.3
>
> and UBUNTU-8.10 with linux-image-2.6.27.18-standard_810_i386.deb
>
> and its an 32bit Ubuntu.
Err, before you said 8.4.3. Now you're saying 8.3. Those are totally
differ
On Tue, May 4, 2010 at 4:02 AM, Simon Riggs wrote:
> In the original patch I had Pause/Resume feature for controlling
> recovery during Hot Standby. It was removed for lack of time.
Well, it's not like we have more time now than we did then. I think
we need to postpone this discussion to 9.1. I
* Simon Riggs (si...@2ndquadrant.com) wrote:
> If recovery waits for max_standby_delay every time something gets in its
> way, it should be clear that if many things get in its way it will
> progressively fall behind. There is no limit to this and it can always
> fall further behind. It does result
2010/5/4 Josh Berkus :
>
>> quietly removing NULL is maybe good for compatibility but is wrong for
>> functionality.
>
> I agree. I wasn't aware of this little misfeature.
>
> Default display for NULL should be a zero-length string.
>
I disagree - NULL is NULL, not empty string (Oracle is differe
Hi Mark,
Please find the below details:
postgresql-8.3
and UBUNTU-8.10 with linux-image-2.6.27.18-standard_810_i386.deb
and its an 32bit Ubuntu.
On Tue, May 4, 2010 at 9:02 AM, Mark Kirkwood wrote:
> On 04/05/10 18:47, Srinivas Naik wrote:
>
> Hi,
>
> Can any one tell me whats the ef
On Tue, 2010-05-04 at 07:13 -0400, Robert Haas wrote:
> On Tue, May 4, 2010 at 4:37 AM, Simon Riggs wrote:
> > option for them, especially for the stated reason. (My point about
> > ndistinct: 99% of users have no idea that exists or when to use it, but
> > it still exists as an option because it
On Tue, May 4, 2010 at 4:37 AM, Simon Riggs wrote:
> option for them, especially for the stated reason. (My point about
> ndistinct: 99% of users have no idea that exists or when to use it, but
> it still exists as an option because it solves a known issue, just like
> this.)
Slightly OT, but fun
On 04/05/10 18:47, Srinivas Naik wrote:
Hi,
Can any one tell me whats the effect of the below Query
SELECT substring(B'0001' from 5 for -2);
SELECT substring(B'0001' from 4 for -3);
its observed that there's an Error "invalid memory alloc request size
4244635647"
What w
Simon Riggs writes:
> In the original patch I had Pause/Resume feature for controlling
> recovery during Hot Standby. It was removed for lack of time.
>
> With all the discussion around the HS UI, it would be something that
> could be back very easily.
Please!
Manual control over recovery is th
On Mon, 2010-05-03 at 22:45 -0400, Bruce Momjian wrote:
> As I remember, 9.0 has two behaviors:
>
> o master delays vacuum cleanup
> o slave delays WAL application
>
> and in 9.1 we will be adding:
>
> o slave communicates snapshots to master
> How would this figure into w
On Mon, 2010-05-03 at 15:04 -0700, Josh Berkus wrote:
> I don't see the issue with Tom's approach from a wait perspective. The
> max wait becomes 1.001X max_standby_delay; there's no way I can think of
> that replay would wait longer than that. I've yet to see an explanation
> why it would be lo
On Mon, 2010-05-03 at 23:36 -0400, Jan Wieck wrote:
> Suppose we had something similar to the NULL value bitmap, specifying
> plain or compressed values (not TOAST references), that are moved to a
> shadow tuple inside the toast table. Suppose further we had some
> statistics about how often att
In the original patch I had Pause/Resume feature for controlling
recovery during Hot Standby. It was removed for lack of time.
With all the discussion around the HS UI, it would be something that
could be back very easily.
I would like to do it as a recovery control plugin. The plugin would be
p
80 matches
Mail list logo
