On Wed, Feb 24, 2010 at 2:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-02-24 at 08:30 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Mon, 2010-02-22 at 11:47 +, Heikki Linnakangas wrote:
Log Message:
---
Move documentation of all recovery.conf option
I think Gokul was asking because he wanted to work on it, but wanted to
check community approval first.
Yes the problem is that we need to come to a consensus on broken data types.
As Heikki pointed out, those data types, which is based on a unstable
function like time, date, random etc.
On Wed, 2010-02-24 at 03:11 -0500, Robert Haas wrote:
But I do think it's good to list all the
recovery.conf settings in one central place.
That part is fine, as long as we have links to it from necessary places.
The reason why these docs must be within a related chapter is that it
then shows
On Wed, 2010-02-24 at 13:50 +0530, Gokulakannan Somasundaram wrote:
Please consider my following statements from a database tuner
perspective. I don't want to discourage the visibility map feature,
but it has the disadvantages, which we already discussed. While i do a
explain analyze and i
Simon Riggs wrote:
I would add that both Heikki and Greg Stark have argued at length that
the visibility map cannot be relied upon in production systems.
It cannot be relied on *in its current form*. There's a hole in crash
recovery where it can be left in an inconsistent state. That obviously
On Wed, 2010-02-24 at 10:40 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
I would add that both Heikki and Greg Stark have argued at length that
the visibility map cannot be relied upon in production systems.
It cannot be relied on *in its current form*. There's a hole in crash
The fragility there is not an issue in a mostly read-only application,
but it definitely would be a concern in other cases.
While we accept that visibility map is good for read only application, why
can't we make it optional? Atleast if there is a way for a person to drop
the visibility map
On Wed, 2010-02-24 at 07:31 +, Simon Riggs wrote:
Please revert the change to create a new chapter.
I will downgrade my request from a revert to the next rung down. Such
requests should be saved for the most serious matters.
Major change is necessary here; this change in particular is
On Wed, Feb 24, 2010 at 12:53 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
Again not to deviate from my initial question, can we make a decision
regarding unstable/mutable functions / broken data types ?
I second this question. A year or two ago, Gokul and I both proposed a
On Wed, 2010-02-24 at 14:23 +0530, Gokulakannan Somasundaram wrote:
can we make a decision regarding unstable/mutable functions / broken
data types ?
You need to take about 5 steps back. Diving straight into a particular
technical detail is not the right approach. Nobody will confirm a
On Wed, Feb 24, 2010 at 5:11 PM, Robert Haas robertmh...@gmail.com wrote:
Looking at it, I think I do agree that this shouldn't be a whole
chapter by itself. It's not nearly as high-level a concept as the
chapters that surround it. But I do think it's good to list all the
recovery.conf
Gokulakannan Somasundaram wrote:
While we accept that visibility map is good for read only application, why
can't we make it optional? Atleast if there is a way for a person to drop
the visibility map for a table(if it gets created by default), the
application need not incur the overhead for
Forgot to include the group..
On Wed, Feb 24, 2010 at 5:38 PM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
I am not familiar with this term broken data types, and I just looked for
it in the source code and couldn't find it.
What exactly are you referring to?
cheers
andrew
On this page:
http://www.postgresql.org/docs/8.4/interactive/explicit-locking.html
This chapter:
13.3.4. Advisory Locks
This example:
SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok
SELECT pg_advisory_lock(id) FROM foo WHERE id 12345 LIMIT 100; -- danger!
SELECT
Kevin Grittner wrote:
Robert Haas wrote:
Perhaps we should add it to the next CommitFest?
Sounds like the right course of action to me. If nobody objects
or beats me to it, I'll do that.
Done.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Wed, Feb 24, 2010 at 12:57 PM, William whair...@hotmail.com wrote:
Hello Pqsql-hacker,
This isn't a question for -hackers. Please use the general list in future.
I have tried everything and ask many but cannot get my Installation of your
PostgreSQL 8.4.1.1 to install. I following all the
strk wrote:
On this page:
http://www.postgresql.org/docs/8.4/interactive/explicit-locking.html
This chapter:
13.3.4. Advisory Locks
This example:
SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok
SELECT pg_advisory_lock(id) FROM foo WHERE id 12345 LIMIT 100; -- danger!
If you have a scenario where the visibility map incurs a measurable
overhead, let's hear it. I didn't see any in the tests I performed, but
it's certainly possible that if the circumstances are just right it
makes a difference.
Heikki,
The obvious one, i could observe is that it
Magnus Hagander mag...@hagander.net writes:
2010/2/24 Tom Lane t...@postgresql.org:
Log Message:
---
Un-break pg_dump for the case of zero-column tables.
This was evidently broken by the CREATE TABLE OF TYPE patch. It would have
been noticed if anyone had bothered to try dumping
On Wed, Feb 24, 2010 at 9:41 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
If you have a scenario where the visibility map incurs a measurable
overhead, let's hear it. I didn't see any in the tests I performed, but
it's certainly possible that if the circumstances are just right it
Karl Schnaitter karl...@gmail.com writes:
On Wed, Feb 24, 2010 at 12:53 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
Again not to deviate from my initial question, can we make a decision
regarding unstable/mutable functions / broken data types ?
I second this question. A year or
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
2010/2/24 Tom Lane t...@postgresql.org:
Log Message:
---
Un-break pg_dump for the case of zero-column tables.
This was evidently broken by the CREATE TABLE OF TYPE patch. ?It would have
been noticed if anyone had
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
2010/2/24 Tom Lane t...@postgresql.org:
Log Message:
---
Un-break pg_dump for the case of zero-column tables.
This was evidently broken by the CREATE TABLE OF TYPE patch. It would have
been noticed if anyone had
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
On Wed, Feb 24, 2010 at 5:03 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
per http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy 7.4 is
still supported for a few months to come (and will be EOL'd together with
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
On Wed, Feb 24, 2010 at 5:03 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
per http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy 7.4
is
still supported for a few months to come (and
On Wed, 24 Feb 2010, Bruce Momjian wrote:
Well, I stand by my statement that it is a judgement call on how much we
keep, and there is a cost to readers to keep it, but there isn't very
much of it. Are the people who wanted more aggressive removal OK with
putting back the pre-7.4 documentation
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
On Wed, Feb 24, 2010 at 5:03 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
per http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy 7.4 is
still supported for a few months to
Tom Lane t...@sss.pgh.pa.us wrote:
The fundamental point IMHO is that indexes are more complex and
much more fragile than heaps. This is obviously true
theoretically and we have years of experience that proves it to be
true in the field as well. Broken comparison functions are just
one of
On Wed, Feb 24, 2010 at 3:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
With an IOT I don't understand how you get out of index corruption
without data loss. That's a showstopper for practical use, I think.
That doesn't seem insurmountable to me. You could always allow a
REINDEX to scan the index
Stefan Kaltenbrunner wrote:
Yea, let me try again and rephrase some of it to highlight the behavior
and not the version change.
Well the behaviour changed with a given version which is crucial
information for somebody doing a migration... It is also useful
historical information for
I think you're a barking up the wrong tree. AFAIUI, the need for the
visibility map has not very much to do with whether the table has
indices, and everything to do with avoiding unnecessary VACUUMs. In
any event, you've not shown that the visibility map HAS any overhead,
so talking about
Did this patch go anywhere? Is it a TODO?
---
Heikki Linnakangas wrote:
Here's my first attempt at setting client_encoding automatically from
locale.
It adds a new conninfo parameter to libpq, client_encoding. If set
But adding 24 bytes to every index entry seems
pretty unlikely to be a win anyways.
We actually wanted to make it optional. Not every index will be like that.
More than that we can make it into 16 bytes. Only commands within the same
transaction will not be able to do a index only scan.
With an IOT I don't understand how you get out of index corruption
without data loss. That's a showstopper for practical use, I think.
For simplicity, say we are storing all the non-leaf pages of the index in a
seperate file, then the leaf pages are nothing but the table. So if we can
On Wed, Feb 24, 2010 at 11:05 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
I think you're a barking up the wrong tree. AFAIUI, the need for the
visibility map has not very much to do with whether the table has
indices, and everything to do with avoiding unnecessary VACUUMs. In
any
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
If you want to do it, I'd be fine with it.
Seems easy enough, see attached. Comments?
Looks mostly okay to me, a few notes:
+ if (ssl_renegotiation_limit port-count
ssl_renegotiation_limit *
Gokulakannan Somasundaram gokul...@gmail.com wrote:
With an IOT I don't understand how you get out of index
corruption without data loss. That's a showstopper for practical
use, I think.
For simplicity, say we are storing all the non-leaf pages of the
index in a seperate file, then the
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I think it would make sense to add it as a buildfarm phase, probably
after installcheck not check so you still have a working postmaster.
I'm not sure how easy it'd be to automate though. What I usually do
is make a text dump,
On Wed, Feb 24, 2010 at 11:07 AM, Bruce Momjian br...@momjian.us wrote:
Did this patch go anywhere? Is it a TODO?
There were problems with that patch, maybe Heikki will review it again
for 9.1 but for now it's already a TODO, it's in the Multi-Language
Support section
Set client encoding
Kevin Grittner kevin.gritt...@wicourts.gov writes:
So you are essentially proposing that rather than moving the heap
data into the leaf tuples of the index in the index file, you will
move the leaf index data into the heap tuples? The pages in such a
IOT heap file would still need to look a
2010/2/24 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
If you want to do it, I'd be fine with it.
Seems easy enough, see attached. Comments?
Looks mostly okay to me, a few notes:
+ if (ssl_renegotiation_limit
Magnus Hagander mag...@hagander.net writes:
2010/2/24 Tom Lane t...@sss.pgh.pa.us:
Also, the coding seems a bit confused about whether the
ssl_renegotiation_limit GUC exists when USE_SSL isn't set. I think we
have a project policy about whether GUCs should still exist when the
underlying
Gokulakannan Somasundaram wrote:
If you have a scenario where the visibility map incurs a measurable
overhead, let's hear it. I didn't see any in the tests I performed, but
it's certainly possible that if the circumstances are just right it
makes a difference.
Heikki,
The obvious
On Tue, Feb 23, 2010 at 6:54 PM, Jaime Casanova
jcasa...@systemguards.com.ec wrote:
On Tue, Feb 23, 2010 at 4:40 AM, Magnus Hagander mag...@hagander.net wrote:
2010/2/23 Jaime Casanova jcasa...@systemguards.com.ec:
Hi,
it's safe to set synchrounous_commit to off in a pg_dump generated
On Tue, Dec 22, 2009 at 11:25 AM, Fujii Masao masao.fu...@gmail.com wrote:
I found there is no primary tag for the HS parameters
in config.sgml. Attached patch adds that tag.
I found another small problem in HS doc; though the type of
trace_recovery_messages is actually enum, it's described as
Le 24 févr. 2010 à 01:04, Marko Kreen a écrit :
On 2/24/10, Rémi Zara remi_z...@mac.com wrote:
Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row
pgcrypto/test sha2 because of the following warning (identical each time) :
Anything I should try ?
Please try
Tom Lane t...@sss.pgh.pa.us wrote:
Isn't that just a variant on Heikki's grouped index tuples idea?
With apologies to Heikki for having forgotten that effort, yes.
With the simplifying technique of keeping the leaf level in a
separate file, it becomes hard to distinguish from Heikki's
On 2/24/10, Rémi Zara remi_z...@mac.com wrote:
Le 24 févr. 2010 à 01:04, Marko Kreen a écrit :
On 2/24/10, Rémi Zara remi_z...@mac.com wrote:
Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row
pgcrypto/test sha2 because of the following warning (identical each
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit :
Is this buildfarm member for detecting bugs in the already
obsolete NetBSD 5.0 BETA, or what? The final 5.0 and
two bugfix releases are already out for a while. The owner
of that particular machine should upgrade.
I upgraded pika to
Kevin Grittner wrote:
With the simplifying technique of keeping the leaf level in a
separate file, it becomes hard to distinguish from Heikki's Grouped
Index Tuples approach when you include the maintain cluster order
patch. That really looks like where anyone should work from for any
IOT
On Wed, Feb 24, 2010 at 4:12 PM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
Sequential scans can be done on IOTs, just scan through the leaf pages.
That doesn't work because when you split an index page any sequential
scan in progress will either see the same tuples twice or will miss
Simon Riggs wrote:
Major change is necessary here; this change in particular is regrettably
a very bad one. Please reconsider and make substantial improvements.
Any suggestions?
Berkus suggested adding a new page to collect together reference
documentation of all the configuration files:
Greg Stark gsst...@mit.edu wrote:
Gokulakannan Somasundaram gokul...@gmail.com wrote:
scan through the leaf pages.
That doesn't work because when you split an index page any
sequential scan in progress will either see the same tuples twice
or will miss some tuples depending on where the
On Wed, 2010-02-24 at 15:52 +, Greg Stark wrote:
We can do
better with stuff like Heikki's grouped index tuple and the
visibility map which don't interfere with other features as much.
Yes, much better plan. More practical, nearly there.
--
Simon Riggs www.2ndQuadrant.com
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Greg Stark gsst...@mit.edu wrote:
That doesn't work because when you split an index page any
sequential scan in progress will either see the same tuples twice
or will miss some tuples depending on where the new page is
allocated. Vacuum has a
On Wed, 2010-02-24 at 19:30 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Major change is necessary here; this change in particular is regrettably
a very bad one. Please reconsider and make substantial improvements.
Any suggestions?
A new section inside the HA chapter would be
On Wed, 2010-02-24 at 18:59 +0900, Fujii Masao wrote:
On Wed, Feb 24, 2010 at 5:11 PM, Robert Haas robertmh...@gmail.com wrote:
Looking at it, I think I do agree that this shouldn't be a whole
chapter by itself. It's not nearly as high-level a concept as the
chapters that surround it. But
Rémi Zara írta:
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit :
Is this buildfarm member for detecting bugs in the already
obsolete NetBSD 5.0 BETA, or what? The final 5.0 and
two bugfix releases are already out for a while. The owner
of that particular machine should upgrade.
Simon,
It's not a common setup mistake. Nothing changed in this release and
this has never been reported before.
The behaviour to wait for pg_stop_backup() was added by user request.
The behaviour for shutdown to wait for pg_stop_backup() was also added
by user request.
Your two
Oleg, Teodor, would you look at this? I see the same behavior in 9.0.
---
Alexey Bashtanov wrote:
The following bug has been logged online:
Bug reference: 4887
Logged by: Alexey Bashtanov
Email
On Wed, Feb 24, 2010 at 5:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Greg Stark gsst...@mit.edu wrote:
That doesn't work because when you split an index page any
sequential scan in progress will either see the same tuples twice
or will miss
On Wed, 2010-02-24 at 10:07 -0800, Josh Berkus wrote:
Simon,
Your mistake was not typoing an archive_command, it was not correctly
testing that what you had done was actually working. The fix is to read
the manual and correct the typo. Shutting down the server after failing
to configure
On Wed, Feb 24, 2010 at 1:07 PM, Josh Berkus j...@agliodbs.com wrote:
And, while it makes sense for smart shutdown to wait for
pg_stop_backup(), it does not make sense for fast shutdown to wait.
TFM in fact says:
http://www.postgresql.org/docs/8.4/static/app-pg-ctl.html#APP-PG-CTL-DESCRIPTION
Did anyone see this? This seems like a pretty grave problem in
streaming replication.
On Tue, Feb 23, 2010 at 2:46 PM, Greg Stark st...@mit.edu wrote:
I tried to set up a simple master/slave setup and immediately ran into
this assertion failure. The slave is just a cold copy of the database
Simon Riggs wrote:
A new section inside the HA chapter would be useful, so this is on the
same level as Streaming Replication. So just drop everything down one
level.
The problem with that is that the recovery.conf options are also
relevant to plain-old recovery from an archive. And PITR. So
Your OP was not too clear about whether you tried a smart shutdown or
a fast shutdown, but if you meant a fast shutdown, this is apparently
(he says without testing) a regression.
Ah, sorry. Yes, I attempted a fast shutdown.
--Josh Berkus
--
Sent via pgsql-hackers mailing list
On Wed, Feb 24, 2010 at 10:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
So you are essentially proposing that rather than moving the heap
data into the leaf tuples of the index in the index file, you will
move the leaf index data into the
Josh Berkus wrote:
And, while it makes sense for smart shutdown to wait for
pg_stop_backup(), it does not make sense for fast shutdown to wait.
Hang on, fast shutdown does *not* wait for backup to finish.
Aside from that, the main issue is not having shutdown wait for
pg_stop_backup; it's
On Wed, 2010-02-24 at 10:07 -0800, Josh Berkus wrote:
The behaviour to wait for pg_stop_backup() was added by user request.
The behaviour for shutdown to wait for pg_stop_backup() was also added
by user request.
Your two statements above contradict each other.
No they don't.
And,
On Wed, Feb 24, 2010 at 1:20 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
A new section inside the HA chapter would be useful, so this is on the
same level as Streaming Replication. So just drop everything down one
level.
The problem with that is that
Yes. The visibility map doesn't need any new WAL records to be written.
We probably will need to add some WAL logging to close the holes with
crash recovery, required for relying on it for index-only-scans, but
AFAICS only for VACUUM and probably only one WAL record for a whole
bunch of heap
On Wed, 2010-02-24 at 20:20 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
A new section inside the HA chapter would be useful, so this is on the
same level as Streaming Replication. So just drop everything down one
level.
The problem with that is that the recovery.conf options are
On Wed, 2010-02-24 at 10:17 -0800, Joshua D. Drake wrote:
Basically the reports boil down to people who are actually going to be
dealing with this in the field. Simon with respect you have been 6 feet
deep in code for too long on this. You need to step back and take some
constructive feedback
Simon Riggs wrote:
Which is why, in the next paragraph, I proposed a way forwards...
Oh, sorry.
There are 3 use cases: PITR, file-based replication and streaming
replication. Having 3 separate sections would be less confusing since it
would allow focused examples. A final section could be
Missed the group...
On Thu, Feb 25, 2010 at 12:34 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
On Thu, Feb 25, 2010 at 12:28 AM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
That doesn't work because when you split an index page any sequential
scan in progress will
On 2/24/10 10:40 AM, Heikki Linnakangas wrote:
Josh Berkus wrote:
And, while it makes sense for smart shutdown to wait for
pg_stop_backup(), it does not make sense for fast shutdown to wait.
Hang on, fast shutdown does *not* wait for backup to finish.
It did when I tried it. I'll test to
Missed the group
So basically you want to have index-only scans, but you want them to
be really slow?
No Robert, i just asked him to make it optional, so that the crash safe
visibility map is used only when its need is realized by the DB designer.
When there is a table with no indexes/
I haven't ignored the issue. The behaviour you are complaining about was
put there following complaints that it didn't wait. You're ignoring the
point that there hasn't been any change in this release and so your
comments are unfounded in reality.
I've posted a reproduceable bug
Gokulakannan Somasundaram wrote:
Hmmm So whenever the update transaction changes a page, it will update
the visibility map, but won't enter the WAL record.
So after the crash we have a visibility map, which has false positives.
The WAL record of the heap insert/update/delete contains a
It might be slightly easier given the assumption that you only want to
scan leaf tuples.
But there's an additional problem I didn't think of before. Currently
we optimize index scans by copying all relevant tuples to local memory
so we don't need to hold an index lock for an extended time or
On Wed, 2010-02-24 at 11:07 -0800, Josh Berkus wrote:
I haven't ignored the issue. The behaviour you are complaining about was
put there following complaints that it didn't wait. You're ignoring the
point that there hasn't been any change in this release and so your
comments are unfounded
You haven't posted a reproduceable bug, nor is this new to 9.0.
Yes, I have.
1) set up a failing archive_command on an idle database
2) do pg_start_backup
3) do pg_stop_backup
4) pg_stop_backup waits forever (or at least 5 minutes, which as long as
I've given it so far).
This is about
What happened to this patch?
---
Itagaki Takahiro wrote:
Merlin Moncure mmonc...@gmail.com wrote:
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
contrib/dblink seems to have no treatments for query cancels.
(1)
What happened to this patch?
---
Itagaki Takahiro wrote:
contrib/dblink in 8.4 supports a server name by CREATE SERVER for connection
string, but it always requires an user-mapping (by CREATE USER MAPPING).
However, I
I have two 9.0devel machines (*not* alpha but cvs as of 2010.02.19 22.48).
One primary, one slave.
In an attempt to keep track of standby progression (versus primary), I ran
slave-side:
replicas=# select
pg_last_xlog_replay_location()
On Wed, Feb 24, 2010 at 2:33 PM, Bruce Momjian br...@momjian.us wrote:
What happened to this patch?
I'm pretty sure it's the same as this:
https://commitfest.postgresql.org/action/patch_view?id=263
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit :
Here's the attached test code. Compile it with
gcc -Wall -o nantest nantest.c -lm
and run it. It tests NAN anf INFINITY values with isinf() and isnan().
The expected output is:
==
$ ./nantest
computed NAN
1 0
On Wed, 2010-02-24 at 19:02 +, Simon Riggs wrote:
On Wed, 2010-02-24 at 10:17 -0800, Joshua D. Drake wrote:
You make the mistake of assuming that someone that can develop has no
solution experience. That is exactly how I fund further development, so
you are off base by a long way.
I
On Wed, 2010-02-24 at 11:31 -0800, Josh Berkus wrote:
This is about what happens in production, not your laptop. The required
behaviour in-production is to assume that the sysadmin has configured it
correctly and we wait for them to fix the problem.
90% of our user base does not have a
Simon,
If you have a concrete proposal, get off your soapbox and make one,
based upon the technical information you've received. There are clear
reasons why things are the way they are and those reasons will not be
ignored, by me.
OK, can you go through the reasons why pg_stop_backup would
On 2/24/10 11:55 AM, Joshua D. Drake wrote:
On Wed, 2010-02-24 at 19:02 +, Simon Riggs wrote:
On Wed, 2010-02-24 at 10:17 -0800, Joshua D. Drake wrote:
You make the mistake of assuming that someone that can develop has no
solution experience. That is exactly how I fund further
That doesn't work because when you split an index page any sequential
scan in progress will either see the same tuples twice or will miss
some tuples depending on where the new page is allocated. Vacuum has a
clever trick for solving this but it doesn't work for arbitrarily many
concurrent
On 24/02/10 13:09, William wrote:
Hello Pqsql-hacker,
I have tried everything and ask many but cannot get my Installation of your
PostgreSQL 8.4.1.1 to install.
While you are having problems, take the opportunity to download 8.4.2
and work with that. That's the latest set of bugfixes.
I
Josh Berkus wrote:
OK, can you go through the reasons why pg_stop_backup would not
complete?
pg_stop_backup() doesn't complete until all the WAL segments needed to
restore from the backup are archived. If archive_command is failing,
that never happens.
And why it's a problem to have it
On Wed, Feb 24, 2010 at 8:04 PM, Gokulakannan Somasundaram
gokul...@gmail.com wrote:
OK I think, i can think of a solution to achieve fast full index scan like
oracle.
a) Issue ids to every block that gets created inside the index. we are
already doing that
b) Now before the fast full index
Greg Stark wrote:
I tried to set up a simple master/slave setup and immediately ran into
this assertion failure. The slave is just a cold copy of the database
immediately after initdb. The first WAL segment hasn't been archived
yet. It sees that the first archive fail hasn't been archived yet,
Gokulakannan Somasundaram wrote:
OK I think, i can think of a solution to achieve fast full index scan like
oracle.
a) Issue ids to every block that gets created inside the index. we are
already doing that
b) Now before the fast full index scan starts, note down the max id that got
issued.
pg_stop_backup() doesn't complete until all the WAL segments needed to
restore from the backup are archived. If archive_command is failing,
that never happens.
OK, so we need a way out of that cycle if the user is issuing
pg_stop_backup because they *already know* that archive_command is
On Wed, 2010-02-24 at 12:32 -0800, Josh Berkus wrote:
pg_stop_backup() doesn't complete until all the WAL segments needed to
restore from the backup are archived. If archive_command is failing,
that never happens.
OK, so we need a way out of that cycle if the user is issuing
Josh Berkus wrote:
pg_stop_backup() doesn't complete until all the WAL segments needed to
restore from the backup are archived. If archive_command is failing,
that never happens.
OK, so we need a way out of that cycle if the user is issuing
pg_stop_backup because they *already know* that
1 - 100 of 152 matches
Mail list logo
