On tor, 2010-04-29 at 17:34 -0400, Bruce Momjian wrote:
> I talked to a few people personally about this, and it seems there was a
> misunderstanding. I was not asking if pg_migrator should be in 9.0
> beta1. I was asking if we should think about putting it into a later
> 9.0 beta, like 9.0 beta3
Jaime Casanova wrote:
> i was trying recent HS and get this when trying to start the standby,
> actually i was expecting a crash because i use full_page_writes=off
> and i guess it won't work.
> Maybe we could say full_page_writes=off and wal_level=hot_standby are
> conflicting and avoid such setup
On Fri, Apr 30, 2010 at 12:03 AM, Tom Lane wrote:
> Jaime Casanova writes:
>> i was trying recent HS and get this when trying to start the standby,
>
>> TRAP: FailedAssertion("!(( (metabuffer) != 0 && (metabuffer) >=
>> -NLocBuffer && (metabuffer) <= NBuffers ))", File: "ginxlog.c", Line:
>> 590)
On Fri, Apr 30, 2010 at 1:13 AM, Takahiro Itagaki
wrote:
>
> Jaime Casanova wrote:
>
>> ah! this is because COPY doesn't follow inherited tables... should it?
>
> Yes. You can use "COPY (SELECT * FROM a) TO " instead to copy all tuples.
>
> http://developer.postgresql.org/pgdocs/postgres/sql-copy
Jaime Casanova wrote:
> ah! this is because COPY doesn't follow inherited tables... should it?
Yes. You can use "COPY (SELECT * FROM a) TO " instead to copy all tuples.
http://developer.postgresql.org/pgdocs/postgres/sql-copy.html
| COPY can only be used with plain tables, not with views.
| Ho
On Fri, Apr 30, 2010 at 12:56 AM, Takahiro Itagaki
wrote:
>
> Jaime Casanova wrote:
>
>> COPY is not working on latest HEAD?
>> """
>> regression=# select * from a;
>> aa
>>
>> 32
>> 56
>> (2 rows)
>>
>> regression=# COPY a TO '/tmp/copy_test';
>> COPY 0
>> """
>>
>> --
>
> Please send th
2010/4/30 Jaime Casanova :
> Hi,
>
> COPY is not working on latest HEAD?
> """
> regression=# select * from a;
> aa
>
> 32
> 56
> (2 rows)
>
> regression=# COPY a TO '/tmp/copy_test';
> COPY 0
> """
>
ah! this is because COPY doesn't follow inherited tables... should it?
--
Atentamente,
Jaime Casanova wrote:
> COPY is not working on latest HEAD?
> """
> regression=# select * from a;
> aa
>
> 32
> 56
> (2 rows)
>
> regression=# COPY a TO '/tmp/copy_test';
> COPY 0
> """
>
> --
Please send the actual test pattern and your environment information
to reproduce the misbe
Hi,
COPY is not working on latest HEAD?
"""
regression=# select * from a;
aa
32
56
(2 rows)
regression=# COPY a TO '/tmp/copy_test';
COPY 0
"""
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
--
Jaime Casanova writes:
> i was trying recent HS and get this when trying to start the standby,
> TRAP: FailedAssertion("!(( (metabuffer) != 0 && (metabuffer) >=
> -NLocBuffer && (metabuffer) <= NBuffers ))", File: "ginxlog.c", Line:
> 590)
Hm, can you provide a test case?
Hi,
i was trying recent HS and get this when trying to start the standby,
actually i was expecting a crash because i use full_page_writes=off
and i guess it won't work.
Maybe we could say full_page_writes=off and wal_level=hot_standby are
conflicting and avoid such setup?
"""
LOG: database system
Mark Kirkwood wrote:
> Bruce Momjian wrote:
> >
> > and most of the limitations of pg_migrator are gone when migrating to
> > 9.0, even from Postgres 8.3. This could help beta testers move their
> > data to 9.0 as well.
> >
> >
> Wouldn't this help even for beta1?
It would, but there is so muc
Mark Kirkwood writes:
> Bruce Momjian wrote:
>> and most of the limitations of pg_migrator are gone when migrating to
>> 9.0, even from Postgres 8.3. This could help beta testers move their
>> data to 9.0 as well.
> Wouldn't this help even for beta1?
It's too late for beta1. It probably should
Bruce Momjian wrote:
and most of the limitations of pg_migrator are gone when migrating to
9.0, even from Postgres 8.3. This could help beta testers move their
data to 9.0 as well.
Wouldn't this help even for beta1?
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian wrote:
> >> There was talk of including pg_migrator in Postgres 9.0 in /contrib. ?Do
> >> we still want to do that?
>
> > I think you articulated some pretty good reasons previously for
> > keeping it separa
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >> I concur; it's about a month too late to propose this.
> >>
> >
> > I am confused why it is late. We add to /contrib even during beta, and
> > I didn't bring it up earlier because I didn't want to be pushing my own
> > software. Was som
On Thu, 2010-04-29 at 16:18 -0400, Tom Lane wrote:
> * rename recovery_connections to hot_standby (and the underlying
> variable from XLogRequestRecoveryConnections to something like
> EnableHotStandby);
OK
> * change its default value to 'off'.
OK
--
Simon Riggs www.2ndQuadrant.co
On Thu, Apr 29, 2010 at 4:18 PM, Tom Lane wrote:
> This train is leaving the station.
An enthusiastic +1 for train departure.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs writes:
> Objections to commit?
This is not the time to be hacking stuff like this. You haven't even
demonstrated that there's a significant performance issue here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Okay, this thread seems to be running out of steam, and we are running
out of hours before the beta1 wrap. I am going to take it on my own
authority to do the following:
* rename recovery_connections to hot_standby (and the underlying
variable from XLogRequestRecoveryConnections to something like
Simple tuning of btree_xlog_vacuum() using an idea I had a while back,
just never implemented. XXX comments removed.
Allows us to avoid reading in blocks during VACUUM replay that are only
required for correctness of index scans.
Objections to commit?
--
Simon Riggs www.2ndQuadrant.
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Yeah. ISTM the real bottom line here is that we have only a weak grasp
>> on how these features will end up being used; or for that matter what
>> the common error scenarios will be. I think that for the time being
>> we should err on the side of b
Simon Riggs wrote:
> [most significant extra WAL logging for hot standby is:]
> * one extra WAL record every checkpoint, containing a full current
> snapshot's worth of running xids 100-400 bytes typically, could go
> up from there to 4000 bytes in very extreme write workloads that
> also have m
"Kevin Grittner" writes:
> Simon Riggs wrote:
>> 9.0 without HS enabled is fairly untested on the standby, so it's
>> not clear to me turning it off makes you any safer.
> I think you've just made the strongest possible case for not
> defaulting it on during beta testing.
Yes. If we've had it
robertmh...@gmail.com (Robert Haas) writes:
> On Wed, Apr 28, 2010 at 1:40 PM, Dimitri Fontaine
> wrote:
>> Robert Haas writes:
>>> Well, how would you define CREATE OR REPLACE TABLE? I think that
>>> doesn't make much sense, which is why I think CREATE IF NOT EXISTS is
>>> a reasonable approach
On Thu, 2010-04-29 at 21:27 +0300, Heikki Linnakangas wrote:
> I wasn't really following the join removal discussions, but it seems
> much safer and less complex. And it would not have been feasible to have
> both implementations of FSM around and have the user to choose. I have
> been relieved b
Simon Riggs wrote:
> What Heikki hasn't said is that setting max_prepared_transactions
> incorrectly has always caused a fatal error at failover, and still does
> so now when HS is disabled.
Hmm, good point. That should probably be documented somewhere. Now that
we WAL-log the max_prepared_xacts v
Heikki Linnakangas writes:
>>> +1 on changing it to something.
>>
>> Any thoughts on what?
> Well, the obvious possibility is:
> hot_standby = on/off
> allow_recovery_queries? Not sure I like either of those more than
> allow_standby_queries, though, despite what I just wrote.
I don't think we
On Thu, 2010-04-29 at 13:01 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > I've asked for evidence that recovery is any slower as a result of
> > HS.
>
> Can you quantify the impact on the number of bytes written to WAL
> when switching from the archiving level to the hot standby leve
Simon Riggs wrote:
> On Thu, 2010-04-29 at 19:55 +0300, Heikki Linnakangas wrote:
>> It's safer to run
>> with recovery_connections off if you don't need the feature.
>
> Presumably your advice is also that people should not run with Streaming
> Replication if they don't need that feature?
Umm,
Simon Riggs wrote:
> 9.0 without HS enabled is fairly untested on the standby, so it's
> not clear to me turning it off makes you any safer.
I think you've just made the strongest possible case for not
defaulting it on during beta testing.
-Kevin
--
Sent via pgsql-hackers mailing list (pgs
On Thu, 2010-04-29 at 13:20 -0400, Robert Haas wrote:
> This is a pretty good argument, and Heikki's argument just upthread
> that a mismatched max_connections setting could bollix things is an
> even better one. So I'm now changing my mind and thinking this should
> be off by default, also.
Wha
Simon Riggs writes:
> Can we keep the default=on during beta and collect evidence before
> making a final decision at release?
I'd be for doing that if it didn't have adverse effects on the use of
pg_start_backup (which is where we started this thread). But it would
be to get more testing, not b
Tom Lane wrote:
> Huh, that is an interesting point. I think it might eventually be a
> common use case: when you're trying to determine where to stop a PITR
> recovery, it would be really nice to be able to roll forward to some
> point, pause the recovery, and then snoop around in the database in
On Thu, 2010-04-29 at 19:55 +0300, Heikki Linnakangas wrote:
> And Aidan and me are human
> beings, included in "everybody".
Yes, that was too loose. I dislike that kind of argument and I'm sorry
that slipped in here.
> You know that there is cases where it causes problems in the standby,
> even
Simon Riggs wrote:
> I've asked for evidence that recovery is any slower as a result of
> HS.
Can you quantify the impact on the number of bytes written to WAL
when switching from the archiving level to the hot standby level?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Simon Riggs wrote:
> Can we keep the default=on during beta and collect evidence before
> making a final decision at release?
That's tempting to get more (inadvertent) testing of HS, but I don't
think it would be fair to the beta testers. The expectation is that
what's in beta is what's in the rel
On Thu, 2010-04-29 at 13:18 -0400, Tom Lane wrote:
> I've just realized that one of the confusing things about this debate
> is that the recovery_connections parameter is very confusingly named.
> It might have been okay when HS existed in isolation, but with SR in the
> mix, it's not at all clear
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I think a different name would help. The best idea I can come up with
>> on the spur of the moment is "allow_standby_queries", but I'm not sure
>> that can't be improved on. Comments?
> One objection to that name is that it also works during archi
On Thu, 2010-04-29 at 12:16 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > Which is what everybody has requested.
>
> You continue to use the term "everybody" rather loosely.
Sorry, that was imprecise, I didn't mean to exaggerate.
--
Simon Riggs www.2ndQuadrant.com
--
On Thu, Apr 29, 2010 at 1:38 PM, Heikki Linnakangas
wrote:
> Tom Lane wrote:
>> I think a different name would help. The best idea I can come up with
>> on the spur of the moment is "allow_standby_queries", but I'm not sure
>> that can't be improved on. Comments?
>
> One objection to that name i
On Thu, 2010-04-29 at 13:03 -0400, Tom Lane wrote:
> There is not only a performance penalty, but a reliability penalty.
> Enabling these switches turns on a whole lot of code that, with all
> due respect to those who have worked on it, is absolutely positively
> guaranteed to be full of bugs. No
Aidan Van Dyk wrote:
It's all about the path of least *suprise*. My "least suprise" would
have been that a similar config I have now with my PITR slaves would
pretty much still work, and not suddenly start accepting connections,
and even worse, at some later date when I've already verified that
On Thu, 2010-04-29 at 13:03 -0400, Tom Lane wrote:
> There is not only a performance penalty
I've asked for evidence that recovery is any slower as a result of HS.
If we had some, I'm guessing we'd be tuning rather than discussing this.
> Enabling these switches turns on a whole lot of code that
Tom Lane wrote:
> I think a different name would help. The best idea I can come up with
> on the spur of the moment is "allow_standby_queries", but I'm not sure
> that can't be improved on. Comments?
One objection to that name is that it also works during archive
recovery, like during PITR, whic
Tom Lane wrote:
> It is easy to think that this is a parameter that needs to be
> turned on in the master to allow standby slaves to connect to it.
> I think a different name would help.
Yeah, I had to double-check because the current name wasn't, in
itself, unambiguous. We'd be sure to get
On Thu, Apr 29, 2010 at 1:18 PM, Tom Lane wrote:
> I've just realized that one of the confusing things about this debate
> is that the recovery_connections parameter is very confusingly named.
> It might have been okay when HS existed in isolation, but with SR in the
> mix, it's not at all clear t
On Thu, Apr 29, 2010 at 1:03 PM, Tom Lane wrote:
>>> That said, I'ld probalby be happy with PG 9 having a "default" config
>>> of:
>>> wal_mode = hot_standby
>>> recovery_connections = on
>
>> That would be a bad idea - there's a significant performance penalty
>> from setting wal_le
I've just realized that one of the confusing things about this debate
is that the recovery_connections parameter is very confusingly named.
It might have been okay when HS existed in isolation, but with SR in the
mix, it's not at all clear that the parameter refers to client
connections made to a s
Simon Riggs wrote:
> Which is what everybody has requested.
You continue to use the term "everybody" rather loosely.
I don't begrudge people features they want, even when *I* don't need
them; but please don't take my lack of argument against adding this
feature as a silent request for it. S
On Thu, 2010-04-29 at 11:48 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > There is no big use case for "run with HS turned off".
>
> There was mention of running the live database and a warm standby,
> with a connection pooler pointed to both so that it could
> automatically reconnec
Robert Haas writes:
> Nobody is proposing otherwise. What Simon and I are proposing is that
> if the master is configured to support HS, it comes up on the slave by
> default without requiring additional configuration. Now maybe that's
> too much spooky action at a distance, but I suspect it IS
Simon Riggs wrote:
> On Thu, 2010-04-29 at 11:37 -0400, Aidan Van Dyk wrote:
>> It's all about the path of least *suprise*. My "least suprise" would
>> have been that a similar config I have now with my PITR slaves would
>> pretty much still work, and not suddenly start accepting connections,
>> a
Simon Riggs wrote:
> There is no big use case for "run with HS turned off".
There was mention of running the live database and a warm standby,
with a connection pooler pointed to both so that it could
automatically reconnect on failover.
> Everybody wants it on, as long as it works and don't
On Thu, Apr 29, 2010 at 12:17 PM, Aidan Van Dyk wrote:
> * Simon Riggs [100429 12:06]:
>
>> Repeating the same thing when its been refuted doesn't help. What you
>> say has not been proposed.
>>
>> If there is a case for HS-off-by-default, make it. If you want to change
>> code, arguing directly
* Simon Riggs [100429 12:14]:
HS is the most requested feature across multiple polls and *not* being
> able to connect to it is likely to come as a huge surprise to many
> people. HS is just as secure as the main database.
>
> There is no big use case for "run with HS turned off". Everybody want
Simon Riggs wrote:
> On Thu, 2010-04-29 at 18:40 +0300, Heikki Linnakangas wrote:
>
>> It's error-prone to control what happens in the standby from the master.
>> That's the "action at a distance" effect I mentioned earlier. The master
>> should be configured in the master, and each standby should
* Simon Riggs [100429 12:06]:
> Repeating the same thing when its been refuted doesn't help. What you
> say has not been proposed.
>
> If there is a case for HS-off-by-default, make it. If you want to change
> code, arguing directly against your own position, mentioned many times,
> we need a r
On Thu, 2010-04-29 at 11:37 -0400, Aidan Van Dyk wrote:
> * Simon Riggs [100429 11:24]:
> >
> > What is the reason for the *extra* "off" switch? Why two? Why "off"
> > twice?
>
> Because I run a PITR slave off a WAL archive... And I'm going to
> continue to try and use this setup... I expect to
On Thu, 2010-04-29 at 18:40 +0300, Heikki Linnakangas wrote:
> It's error-prone to control what happens in the standby from the master.
> That's the "action at a distance" effect I mentioned earlier. The master
> should be configured in the master, and each standby should configured
> in the stand
Simon Riggs wrote:
> On Thu, 2010-04-29 at 09:48 -0400, Tom Lane wrote:
>> Simon Riggs writes:
>>> recovery_connections was on by default and unanimous agreement until
>>> recently and I don't want to change that now,
>> Uh, it was on by default only because a lot of us hadn't noticed that.
>> I a
* Simon Riggs [100429 11:24]:
>
> What is the reason for the *extra* "off" switch? Why two? Why "off"
> twice?
Because I run a PITR slave off a WAL archive... And I'm going to
continue to try and use this setup... I expect to try and experiment
with wal-streaming too when everything is up to 9,
On Thu, 2010-04-29 at 09:48 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > recovery_connections was on by default and unanimous agreement until
> > recently and I don't want to change that now,
>
> Uh, it was on by default only because a lot of us hadn't noticed that.
> I agree with Heikki's po
Simon Riggs wrote:
> Why do we protect against this?
>
> postgres=# alter table test set (nonexistent = on);
> ERROR: unrecognized parameter "notexistent"
Eh? The parameter doesn't exist. It's not exactly the same as defining
a value for a parameter that exists but is unused.
--
Alvaro Herr
Simon Riggs wrote:
> Also, this seems not to work?
>
> postgres=# alter table test set (my.expectation = on);
> ERROR: unrecognized parameter namespace "my"
>
> I thought we had enabled custom table options in this release?
> Or was that deferred, or even rejected completely?
IIRC you can defi
Oleg Bartunov writes:
> On Thu, 29 Apr 2010, Tom Lane wrote:
>> There's a fuzz factor of (IIRC) 1% in path cost comparisons. It's
>> deciding that the seqscan and bitmapscan total costs are not
>> meaningfully different; then since the startup costs *are* meaningfully
>> different, it's making th
On Thu, 29 Apr 2010, Tom Lane wrote:
Teodor Sigaev writes:
[ planner prefers ]
-> Seq Scan on foo (cost=0.00..5805.00 rows=4907 width=0)
to
-> Bitmap Heap Scan on foo (cost=942.46..5755.08 rows=4907 width=0)
Why does pgsql choose seqscan (5817.28) instead of bitmap one (5767.36)
Simon Riggs writes:
> recovery_connections was on by default and unanimous agreement until
> recently and I don't want to change that now,
Uh, it was on by default only because a lot of us hadn't noticed that.
I agree with Heikki's position here: it should not be on by default.
Teodor Sigaev writes:
> [ planner prefers ]
> -> Seq Scan on foo (cost=0.00..5805.00 rows=4907 width=0)
> to
> -> Bitmap Heap Scan on foo (cost=942.46..5755.08 rows=4907 width=0)
> Why does pgsql choose seqscan (5817.28) instead of bitmap one (5767.36)?
There's a fuzz factor of (IIRC
Robert Haas writes:
> On Thu, Apr 29, 2010 at 7:19 AM, Heikki Linnakangas
> wrote:
>> If you're setting up a reporting server, and hot standby can't start,
>> the server is not functioning properly. I would like to get an error in
>> that case.
>
> Presumably you will actually try connecting to i
On Thu, Apr 29, 2010 at 9:07 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> How about this one? The administrator sets up a master and a slave.
>> She's heard about this new Hot Standby feature and so decides to
>> enable it on the slave just to play around with it. Subsequently, she
>> t
On Thu, Apr 29, 2010 at 9:00 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Thu, Apr 29, 2010 at 7:19 AM, Heikki Linnakangas
>> wrote:
>>> Robert Haas wrote:
I kind of agree with Simon on this one, except I would probably choose
to have just on and off and make on work like hi
Robert Haas wrote:
> How about this one? The administrator sets up a master and a slave.
> She's heard about this new Hot Standby feature and so decides to
> enable it on the slave just to play around with it. Subsequently, she
> takes a better job at another company and they hire a new
> adminis
Robert Haas wrote:
> On Thu, Apr 29, 2010 at 7:19 AM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> I kind of agree with Simon on this one, except I would probably choose
>>> to have just on and off and make on work like his auto.
>>>
>>> In other words, recovery_connections=on means, give
On Thu, Apr 29, 2010 at 7:55 AM, Heikki Linnakangas
wrote:
> What happened,
I don't find that story very compelling because there are an infinite
number of ways to have high-availability not work if you start by
supposing that the person who sets them up doesn't test them properly
and verify that
Simon Riggs wrote:
> recovery_connections was on by default and unanimous agreement until
> recently and I don't want to change that now, just because a change
> somewhere else appears to be forcing that but need not be so.
We never really had that discussion, until now. It has always been 'on'
by
On Thu, 2010-04-29 at 14:55 +0300, Heikki Linnakangas wrote:
> I'd like to scaremonger
Seems so.
recovery_connections was on by default and unanimous agreement until
recently and I don't want to change that now, just because a change
somewhere else appears to be forcing that but need not be so.
Simon Riggs wrote:
> On Thu, 2010-04-29 at 13:46 +0300, Heikki Linnakangas wrote:
>> warm standby for high availability - no
>> offloading taking filesystem-level backups from master - no
>
> These can be explicitly turned off.
> You're presuming there is benefit in turning recovery_connections =
On Thu, Apr 29, 2010 at 7:19 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> I kind of agree with Simon on this one, except I would probably choose
>> to have just on and off and make on work like his auto.
>>
>> In other words, recovery_connections=on means, give me recovery
>> connections
Robert Haas wrote:
> I kind of agree with Simon on this one, except I would probably choose
> to have just on and off and make on work like his auto.
>
> In other words, recovery_connections=on means, give me recovery
> connections if possible, otherwise don't worry about it.
If you're setting up
On Thu, 2010-04-29 at 13:46 +0300, Heikki Linnakangas wrote:
> purpose of the standby - do you want hot standby or not?
> reporting - yes
> offloading queries from master - yes
> offloading pg_dump from master - yes
These would work using the proposed default.
> warm standby for high availabili
On Thu, Apr 29, 2010 at 5:55 AM, Heikki Linnakangas
wrote:
>> The most sensible way is to make the default act intelligently depending
>> upon what it finds in the control file. If WAL contains hot_standby
>> info, then recovery_connections should be on by default, though can be
>> turned off expl
On Thu, Apr 29, 2010 at 5:38 AM, Heikki Linnakangas
wrote:
> NOTICE: WAL archiving is not enabled, you must ensure that all required
> WAL segments are streamed or copied through other means to restore the
> backup
I might think about dropping the words "through other means" from this sentence.
Simon Riggs wrote:
> The whole point of
> wal_level discussion was to avoid needing multiple switches to turn
> something on.
No, the point of wal_level was to make the behavior easier to
understand, by uncoupling the level of WAL-logging from various other
switches, controling it directly and exp
On Thu, 2010-04-29 at 12:55 +0300, Heikki Linnakangas wrote:
> Seems overly complicated.
If you turn wal_level = hot_standby in the master, then the slaves work,
unless you say otherwise. What is complicated about that?
> It would be simpler to just set it 'off' by
> default.
As a parameter, y
2010/4/29 Teodor Sigaev :
> Hi!
>
> There is some strange on current CVS with correct choosing of scans.
Also true with 8.4, default configuration.
> Although bitmap scan is cheaper but postgresql chooses seqscan. Test suite:
>
> CREATE OR REPLACE FUNCTION genvect()
> RETURNS tsvector AS
> $$
>
Simon Riggs wrote:
> On Thu, 2010-04-29 at 10:55 +0300, Heikki Linnakangas wrote:
>
>> Should we change the default to recovery_connections=off ? It is a quite
>> big change in default behavior over previous releases that hot standby
>> is enabled by default, so maybe that would be the right thing
Hi!
There is some strange on current CVS with correct choosing of scans. Although
bitmap scan is cheaper but postgresql chooses seqscan. Test suite:
CREATE OR REPLACE FUNCTION genvect()
RETURNS tsvector AS
$$
SELECT
array_to_string(
ARRAY(
SELECT
Tom Lane wrote:
> Yeah. ISTM the real bottom line here is that we have only a weak grasp
> on how these features will end up being used; or for that matter what
> the common error scenarios will be. I think that for the time being
> we should err on the side of being permissive. We can tighten t
On Wed, 2010-04-28 at 21:11 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > It's possible to set toast reloptions for tables that don't have toast
> > tables at all. e.g.
>
> > create table test (c1 integer);
> > ALTER TABLE test SET (toast.autovacuum_enabled = off);
>
> > Why?
>
> 1. Why no
2010/4/29 Jaime Casanova :
> 2009/10/12 Teodor Sigaev :
>>
>>
>>> Are you planning to submit this as a /contrib module?
>>
>> I haven't objections to do that, we don't planned that because we know
>> sceptical
>> relation of community to hints :)
>
> this could be very useful now that we have HS an
Peter Eisentraut wrote:
On ons, 2010-04-28 at 15:21 +0100, Mike Fowler wrote:
xpath_exists() is needed. It checks, whether or not the path specified
exists in the XML value. (W/o this function we need to use weird
"array_dims(xpath(...)) IS NOT NULL" syntax.)
That sounds like a reason
On Thu, 2010-04-29 at 10:55 +0300, Heikki Linnakangas wrote:
> Should we change the default to recovery_connections=off ? It is a quite
> big change in default behavior over previous releases that hot standby
> is enabled by default, so maybe that would be the right thing to do anyway.
>
> Or may
Fujii Masao wrote:
> On Thu, Apr 29, 2010 at 1:14 AM, Heikki Linnakangas
> wrote:
>> Ok, I've finally committed the patch, using wal_level as the name of the
>> GUC.
>
>> !if (InArchiveRecovery && XLogRequestRecoveryConnections)
>> !{
>> !if (ControlFile->wal_level < WAL_LEVEL
94 matches
Mail list logo
