On Wed, Feb 24, 2010 at 2:31 AM, Simon Riggs 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 to a
>
>
> 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 show
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
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 re
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
decisi
On Wed, Feb 24, 2010 at 5:11 PM, Robert Haas 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 settings in one central
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 fo
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
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 pg_advisory_lo
"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)
On Wed, Feb 24, 2010 at 12:57 PM, William 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 steps exactly but I
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; --
>
>
> 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 t
Magnus Hagander writes:
> 2010/2/24 Tom Lane :
>> 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 and restoring the
>> regres
On Wed, Feb 24, 2010 at 9:41 AM, 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 d
Karl Schnaitter 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 two ag
Tom Lane wrote:
> Magnus Hagander writes:
> > 2010/2/24 Tom Lane :
> >> 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 dum
Tom Lane wrote:
Magnus Hagander writes:
2010/2/24 Tom Lane :
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 and restoring the
Bruce Momjian writes:
> Robert Haas wrote:
>> On Wed, Feb 24, 2010 at 5:03 AM, Stefan Kaltenbrunner
>> 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
>>> 8.0). I'm also not reall
Tom Lane wrote:
> Bruce Momjian writes:
> > Robert Haas wrote:
> >> On Wed, Feb 24, 2010 at 5:03 AM, Stefan Kaltenbrunner
> >> 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 togethe
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 m
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian writes:
Robert Haas wrote:
On Wed, Feb 24, 2010 at 5:03 AM, Stefan Kaltenbrunner
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
8
Tom Lane 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 the possible
On Wed, Feb 24, 2010 at 3:12 PM, Tom Lane 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 sequentially, ign
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
>
>
> 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
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
>
> 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
r
On Wed, Feb 24, 2010 at 11:05 AM, Gokulakannan Somasundaram
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 event, you
Magnus Hagander writes:
> 2010/2/22 Tom Lane :
>> 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 * 1024)
You need "1024L" there t
Gokulakannan Somasundaram 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 leaf pages
Andrew Dunstan 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, restore the dump
On Wed, Feb 24, 2010 at 11:07 AM, Bruce Momjian 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 based on the cl
"Kevin Grittner" 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 lot like index pages, y
2010/2/24 Tom Lane :
> Magnus Hagander writes:
>> 2010/2/22 Tom Lane :
>>> 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_limi
Magnus Hagander writes:
> 2010/2/24 Tom Lane :
>> 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 support isn't compiled, but I fo
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,
>
On Tue, Feb 23, 2010 at 6:54 PM, Jaime Casanova
wrote:
> On Tue, Feb 23, 2010 at 4:40 AM, Magnus Hagander wrote:
>> 2010/2/23 Jaime Casanova :
>>> Hi,
>>>
>>> it's safe to set synchrounous_commit to off in a pg_dump generated
>>> script? if yes, would this help to the performance of restore a
>>>
On Tue, Dec 22, 2009 at 11:25 AM, Fujii Masao 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
string in the doc.
Le 24 févr. 2010 à 01:04, Marko Kreen a écrit :
> On 2/24/10, Rémi Zara 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 --without-
Tom Lane 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 Grouped
Index Tuple
On 2/24/10, Rémi Zara wrote:
> Le 24 févr. 2010 à 01:04, Marko Kreen a écrit :
> > On 2/24/10, Rémi Zara 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) :
> >>
> >
> >> Anythin
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
On Wed, Feb 24, 2010 at 4:12 PM, Gokulakannan Somasundaram
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
some tuples dependi
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:
htt
Greg Stark wrote:
> Gokulakannan Somasundaram 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 new page is
> allocated. Vac
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" writes:
> Greg Stark 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 clever trick for solving this b
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 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'
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 upgr
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 stat
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 a
On Wed, Feb 24, 2010 at 5:46 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Greg Stark 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
>>
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 co
On Wed, Feb 24, 2010 at 1:07 PM, 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.
TFM in fact says:
http://www.postgresql.org/docs/8.4/static/app-pg-ctl.html#APP-PG-CTL-DESCRIPTION
In stop mode, t
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 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 a
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.
> 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 (pgsql-ha
On Wed, Feb 24, 2010 at 10:09 PM, Tom Lane wrote:
> "Kevin Grittner" 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
> > IO
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.
On Wed, Feb 24, 2010 at 1:20 PM, 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
> 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
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 op
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 feedb
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 p
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 tes
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 (pg_stop_
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
> 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 ti
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 unf
> 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 wh
What happened to this patch?
---
Itagaki Takahiro wrote:
>
> Merlin Moncure wrote:
>
> > Takahiro wrote:
> > > contrib/dblink seems to have no treatments for query cancels.
> > > (1) Users need to wait for completion of r
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()
pg_xlogfile_name_offset(pg_l
On Wed, Feb 24, 2010 at 2:33 PM, Bruce Momjian 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 changes to your subscr
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
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 n
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
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 woul
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 dev
>
>> 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
>>
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 f
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 co
On Wed, Feb 24, 2010 at 8:04 PM, 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, no
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 y
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
> issu
> 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
fa
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
> pg_s
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*
1 - 100 of 152 matches
Mail list logo
