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 will actually happen to the Postgresql
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
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
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
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 what we
Simon Riggs si...@2ndquadrant.com 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
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
On Tue, May 4, 2010 at 4:37 AM, Simon Riggs si...@2ndquadrant.com 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.)
On Tue, 2010-05-04 at 07:13 -0400, Robert Haas wrote:
On Tue, May 4, 2010 at 4:37 AM, Simon Riggs si...@2ndquadrant.com 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
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 mark.kirkw...@catalyst.net.nz
wrote:
On 04/05/10 18:47, Srinivas Naik wrote:
Hi,
Can
2010/5/4 Josh Berkus j...@agliodbs.com:
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
* 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 in
On Tue, May 4, 2010 at 4:02 AM, Simon Riggs si...@2ndquadrant.com 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
On Tue, May 4, 2010 at 7:46 AM, Srinivas Naik naik.sr...@gmail.com 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
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 to
On Tue, May 4, 2010 15:40, Robert Haas wrote:
On Tue, May 4, 2010 at 7:46 AM, Srinivas Naik naik.sr...@gmail.com 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
2010/5/4 Pavel Stehule pavel.steh...@gmail.com:
2010/5/4 Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com 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
On Tue, May 4, 2010 at 10:08 AM, Erik Rijkers e...@xs4all.nl 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 t...@sss.pgh.pa.us
Date: Mon Jan 25
On Tue, May 4, 2010 at 10:05 AM, Pavel Stehule pavel.steh...@gmail.com 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
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
Robert Haas robertmh...@gmail.com 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
2010/5/4 Merlin Moncure mmonc...@gmail.com:
On Tue, May 4, 2010 at 10:05 AM, Pavel Stehule pavel.steh...@gmail.com
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
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 the
On Tue, May 4, 2010 at 10:29 AM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Robert Haas robertmh...@gmail.com writes:
On Tue, May 4, 2010 at 10:29 AM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On Tue, 2010-05-04 at 09:36 -0400, Robert Haas wrote:
On Tue, May 4, 2010 at 4:02 AM, Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com 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:
On Tue, 2010-05-04 at 11:12 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
Robert Haas wrote:
On Mon, May 3, 2010 at 4:04 PM, Andrew Dunstan and...@dunslane.net 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
On Tue, May 4, 2010 at 11:10 AM, Simon Riggs si...@2ndquadrant.com 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
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 setup
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 further
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 you be able
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 master
How would
Simon Riggs si...@2ndquadrant.com 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
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
On Tue, 2010-05-04 at 13:23 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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, May 4, 2010 at 2:06 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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
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
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
On Mon, May 3, 2010 at 4:37 PM, Tom Lane t...@sss.pgh.pa.us 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
Srinivas Naik naik.sr...@gmail.com 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
Robert Haas escribió:
On Tue, May 4, 2010 at 2:06 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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
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 mentioned upthread:
On Tue, May 4, 2010 at 3:03 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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, then
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 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 and
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
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_standby_delay.
Gurjeet Singh singh.gurj...@gmail.com 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
Robert Haas robertmh...@gmail.com 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,
Alvaro Herrera alvhe...@commandprompt.com 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
On Tue, May 4, 2010 at 5:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Josh Berkus j...@agliodbs.com 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
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 that,
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,
Greg Smith g...@2ndquadrant.com 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
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
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 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 be
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 operational
ntp
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
Greg Smith g...@2ndquadrant.com 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
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
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
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 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 new
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 that
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 other driver
Tom Lane wrote:
Greg Smith g...@2ndquadrant.com 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
On Tue, May 4, 2010 at 11:06 PM, Bruce Momjian br...@momjian.us 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
On Tue, Apr 27, 2010 at 9:59 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas wrote:
On Tue, May 4, 2010 at 11:06 PM, Bruce Momjian br...@momjian.us 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
On Wed, May 5, 2010 at 5:01 AM, Andrew Dunstan and...@dunslane.net 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
On Mon, May 3, 2010 at 14:04, Andrew Dunstan and...@dunslane.net 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
80 matches
Mail list logo
