On Friday 03 July 2009 02:28:22 Bruce Momjian wrote:
> I looked at that and the problem is that pg_migrator must be built
> against the _new_ source tree, and will issue an error and exit if it
> isn't. The problem with PGXS is it silently chooses the source tree to
> use based on which pg_config
Hi,
Thanks for the brilliant comments!
On Wed, Jul 8, 2009 at 4:00 AM, Heikki
Linnakangas wrote:
>> There are still some interesting questions in this about exactly how you
>> switch over from "catchup mode" to following the live WAL broadcast.
>> With the above design it would be the master's re
On Wed, Jul 8, 2009 at 6:43 AM, Itagaki
Takahiro wrote:
>
> to...@tuxteam.de wrote:
>
>> As other posters have put it, I'd be very sceptical of server-side
>> decryption. If the server "has" all the necessary bits to decrypt the
>> data, all bets are off.
>
> Server can access both encrypted data a
2009/7/8 Peter Eisentraut :
> I have the following concern: Likely, this tool and the overall process will
> evolve over time. To pick an example that may or may not be actually useful,
> in the future we might want to change from a fixed list of patch sections to a
> free list of tags, say. Then
to...@tuxteam.de wrote:
> As other posters have put it, I'd be very sceptical of server-side
> decryption. If the server "has" all the necessary bits to decrypt the
> data, all bets are off.
Server can access both encrypted data and its password, but we can put
them in different disk drives. We
2009/7/8 Alvaro Herrera :
>
> By the way, if the migration of the current commitfest was an automatic
> procedure, is there a chance that the old commitfests can be migrated as
> well?
>
It wasn't really automatic as such. I used a few scripts that I saved
in case we needed to use them again, but
Pgbench is a famous tool to measure postgres performance, but nowadays
it does not work well because it cannot use multiple CPUs. On the other
hand, postgres server can use CPUs very well, so the bottle-neck of
workload is *in pgbench*.
Multi-threading would be a solution. The attached patch adds
On Thu, Jul 02, 2009 at 03:42:56PM +0100, Dave Page wrote:
> On Thu, Jul 2, 2009 at 3:22 PM, Joshua Tolley wrote:
> > On Thu, Jul 02, 2009 at 08:41:27AM +0100, Dave Page wrote:
> >> As far as I'm aware, there's been no code
> >> review yet either, which would probably be a good idea.
> >
> > I don'
Hi,
On Wed, Jul 8, 2009 at 4:00 AM, Heikki
Linnakangas wrote:
>> I would envision the slaves
>> connecting to the master's replication port and asking "feed me WAL
>> beginning at LSN position thus-and-so", with no notion of WAL file
>> boundaries exposed anyplace.
>
> Yep, that's the way I envis
Hi,
On Wed, Jul 8, 2009 at 12:49 AM, Tom Lane wrote:
> This design seems totally wrong to me. It's confusing the master's
> pg_xlog directory with the archive. We should *not* use pg_xlog as
> a long-term archive area; that's terrible from both a performance
> and a reliability perspective. Per
On Tue, Jul 7, 2009 at 6:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Jul 7, 2009, at 4:56 PM, Tom Lane wrote:
>>> My own thought is that from_collapse_limit has more justification,
>
>> That's pretty much where I am with it, too. The feature I was
>> referring to was not the collapse limi
Andrew Dunstan wrote:
Andrew Chernow wrote:
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using
CBC or CFB mode. Although, an IV is never suppose
Andrew Chernow wrote:
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using
CBC or CFB mode. Although, an IV is never supposed to be used more
than
Encrypting lots of small chunks of data with the same key is a very
dangerous thing to do and it's very tricky to get right.
Using an initialization vector (IV) is the way to go, recommend using CBC or CFB
mode. Although, an IV is never supposed to be used more than once with the same
key;
On Wed, Jul 8, 2009 at 1:49 AM, Itagaki
Takahiro wrote:
> Heikki Linnakangas wrote:
>
>> Greg Stark wrote:
>> > It would still protect against offline attacks such as against backup
>> > files.
>>
>> True, but filesystem-level encryption handles that scenario with less pain.
>
> Yes, I intended o
Heikki Linnakangas wrote:
> Greg Stark wrote:
> > It would still protect against offline attacks such as against backup files.
>
> True, but filesystem-level encryption handles that scenario with less pain.
Yes, I intended offline attacks, and also agree that ilesystem-level
encryption will be
On Tue, Jul 7, 2009 at 8:12 PM, Tom Lane wrote:
> (If nothing else, there is no point in keeping so much WAL that catching
> up by scanning it would take longer than taking a fresh base backup.
> My impression from recent complaints about our WAL-reading speed is that
> that might be a pretty tight
Tom Lane writes:
> Sergey Burladyan writes:
> > Oh, now problem with simple query:
>
> > 8.4.0 from Debian
> > explain analyze select i from t where i >= 10 and i = 1;
> > QUERY PLAN
> > ---
Hi,
It seems our makefiles fail to install fmgroids.h by "make install" in a
VPATH build.
The reason is that they do this (src/include/Makefile)
for dir in $(SUBDIRS); do \
cp $(srcdir)/$$dir/*.h '$(DESTDIR)$(includedir_server)'/$$dir/ || exit; \
chmod $(INSTALL_DATA_MODE) '$(DES
On Tue, 2009-07-07 at 19:38 +0100, Dean Rasheed wrote:
> This approach works well if the number of potential conflicts is
> small.
[...]
> Curing the scalability problem by spooling the queue to disk shouldn't
> be too hard to do, but that doesn't address the problem that if a
> significant propo
Andrew Dunstan wrote:
<...>
> > branch | released | curr_version | curr_date | final_date
> > ++--++
> > 8.4| 2009-07-01 | 8.4.0| 2009-07-01 |
> > 8.3| 2008-02-04 | 8.3.7| 2009-03-16 |
> > 8.2| 2006-12-0
Sergey Burladyan writes:
> Oh, now problem with simple query:
> 8.4.0 from Debian
> explain analyze select i from t where i >= 10 and i = 1;
> QUERY PLAN
>
> Result (cost=0.
Robert Haas writes:
> On Jul 7, 2009, at 4:56 PM, Tom Lane wrote:
>> My own thought is that from_collapse_limit has more justification,
> That's pretty much where I am with it, too. The feature I was
> referring to was not the collapse limits, but the ability to
> explicitly specify the joi
Oh, now problem with simple query:
8.4.0 from Debian
explain analyze select i from t where i >= 10 and i = 1;
QUERY PLAN
Result (cost=0.00..0.01 rows=1 width=0) (actual time
On Jul 7, 2009, at 4:56 PM, Tom Lane wrote:
Robert Haas writes:
I guess my point is that there's not a lot of obvious benefit in
allowing the functionality to exist but handicapping it so that it's
useful in as few cases as possible. If the consensus is that we want
half a feature (but not m
First, I'm happy that you're working on this; I think it's important. I
am working on another index constraints feature that may have some
interaction:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00302.php
Let me know if you see any potential conflicts between our work.
On Tue, 2009-
Mark Mielke writes:
> Which of the following two great things occurred?
> 1) Tom popped a quick fix on CVS HEAD? (Pretty fast!)
> 2) Tom or somebody else had already done it?
http://archives.postgresql.org/pgsql-committers/2009-07/msg00067.php
regards, tom lane
Alvaro Herrera writes:
> Tom Lane escribió:
>> My own thought is that from_collapse_limit has more justification,
>> since it basically acts to stop a subquery from being flattened when
>> that would make the parent query too complex, and that seems like a
>> more understandable and justifiable be
I found Tom's response ambiguous - but positive in either way, so it
gave me a smile. :-)
Which of the following two great things occurred?
1) Tom popped a quick fix on CVS HEAD? (Pretty fast!)
2) Tom or somebody else had already done it?
Cheers,
mark
On 07/07/2009 05:14 PM, Sergey Bur
Tom Lane escribió:
> My own thought is that from_collapse_limit has more justification,
> since it basically acts to stop a subquery from being flattened when
> that would make the parent query too complex, and that seems like a
> more understandable and justifiable behavior than treating JOIN
> s
Peter Eisentraut writes:
> Here is a first cut at a new hex bytea input and output format. Example:
> ...
> SET bytea_output_hex = true;
> Should the configuration parameter be a boolean or an enum, opening
> possibilities for other formats?
Enum. If we do this then it seems entirely fair tha
On Wednesday 06 May 2009 18:47:57 Tom Lane wrote:
> So the ambiguous-input problem is solved if we define the new format(s)
> to be started by backslash and something that the old code would reject.
> I'd keep it short, like "\x", but there's still room for multiple
> formats if anyone really wants
Robert Haas wrote:
> "Kevin Grittner" > Robert Haas wrote:
>>
>>> if we think it's reasonable for people to want to explicitly
>>> specify the join order
>>
>> Regardless of the syntax (GUC or otherwise), that is an optimizer
>> hint. I thought we were trying to avoid those.
>
> I guess my poin
Robert Haas writes:
> I guess my point is that there's not a lot of obvious benefit in
> allowing the functionality to exist but handicapping it so that it's
> useful in as few cases as possible. If the consensus is that we want
> half a feature (but not more or less than half), that's OK w
On Jul 7, 2009, at 3:03 PM, "Kevin Grittner" > wrote:
Robert Haas wrote:
if we think it's reasonable for people to want to explicitly specify
the join order
Regardless of the syntax (GUC or otherwise), that is an optimizer
hint. I thought we were trying to avoid those.
I guess my point i
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
> Also, if hash indexes were a realistic alternative to btree for this,
> we'd already have come up against the problem that the CONSTRAINT syntax
> doesn't provide any way to specify what kind of index you want to use
> underneath the constraint.
"Kevin Grittner" writes:
> Although -- we do have all those enable_* GUC values which are also
> optimizer hints; perhaps this should be another of those?
> enable_join_reorder?
Not a bad suggestion, especially since turning it off would usually be
considered just about as bad an idea as turning
Dimitri Fontaine writes:
> Could we add yet another postmaster specialized child to handle the
> archive, which would be like a default archive_command implemented in
> core.
I think this fails the basic sanity check: do you need it to still work
when the master is dead. It's reasonable to a
Tom Lane writes:
> As of CVS HEAD you get
>
> QUERY PLAN
>
>
> Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.011..0.011 rows=0
>
Hello.
Here's a patch(WIP) that implements INSERT .. RETURNING inside a CTE.
Should apply cleanly against CVS head.
The INSERT query isn't rewritten so rules and default values don't work.
Recursive CTEs don't work either.
Regards,
Marko Tiikkaja
*** a/src/backend/commands/explain.c
--- b/s
On Jul 7, 2009, at 12:59 PM, Alvaro Herrera wrote:
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have
formal
control over scheduled maintenance expirations…
The web team already has a table, and it is published
Le 7 juil. 09 à 21:45, Tom Lane a écrit :
Dimitri Fontaine writes:
Another idea would be to have more complex metrics for deciding when
to run geqo
Pointless, since GEQO is only concerned with examining alternative
join
orderings. I see no reason whatever to think that number-of-relations
Robert Haas escribió:
> I suspect both are true, but in the unlikely event that we decide on
> some massive change to the system, we can either run the DBs in parallel
> as Tom suggests, or dump out the older data in Wiki markup and post it on
> there. But I can't imagine what we'd want to do
On Jul 7, 2009, at 2:14 PM, Peter Eisentraut wrote:
On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote:
We're now about a week away from the start of the July 2009
commitfest, and we need to make a decision about whether to start
using http://commitfest.postgresql.org to manage it, or punt to
Robert Haas wrote:
> if we think it's reasonable for people to want to explicitly specify
> the join order
Regardless of the syntax (GUC or otherwise), that is an optimizer
hint. I thought we were trying to avoid those.
Although -- we do have all those enable_* GUC values which are also
op
Le 7 juil. 09 à 21:12, Tom Lane a écrit :
Heikki Linnakangas writes:
And I'm sure people will want the option to retain WAL longer in the
master, to avoid an expensive resync if the slave falls behind. It
would
be simple to provide a GUC option for "always retain X GB of old
WAL in
pg_xlog
David E. Wheeler wrote:
> On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote:
>
>>> And it only goes back to 8.0
>>
>> Huh, true :-( This should be fixed.
>
> Yeah. Or we should have a table. I could create one in the wiki, I
> guess, but I would assume that the core team would want to have forma
Dimitri Fontaine writes:
> Another idea would be to have more complex metrics for deciding when
> to run geqo, that is guesstimate the query planning difficulty very
> quickly, based on more than just the number of relations in the from:
> presence of subqueries, UNION, EXISTS, IN, or branch
Peter Eisentraut writes:
> With the wiki, the data of the old fests will pretty much stay what is
> was, unless we change the wiki templates in drastic ways, as I
> understand it. But if we did changes like the above, or more
> complicated things, perhaps, what will happen? Perhaps we simply
> d
Peter Eisentraut writes:
> On Tuesday 07 July 2009 19:35:54 Tom Lane wrote:
>> I looked at this patch. I'm a bit disturbed by the
>> ORDER BY c.oid::pg_catalog.regclass
>> business. I doubt that does what the author thinks, and I'm not sure
>> what we really want anyway. If we want the child ta
Le 7 juil. 09 à 21:16, Robert Haas a écrit :
Now, here's another thought: if we think it's reasonable for people
to want to explicitly specify the join order, a GUC isn't really the
best fit, because it's all or nothing. Maybe we'd be better off
dropping the GUCs entirely and adding some ot
Le 7 juil. 09 à 19:37, Greg Stark a écrit :
I propose that there's a maximum reasonable planning time
It sounds so much like the planner_effort GUC that has been talked
about in the past...
http://archives.postgresql.org/pgsql-performance/2009-05/msg00137.php
...except this time you want
On Tue, 2009-07-07 at 14:57 -0400, Tom Lane wrote:
> I don't think this even approximates the need --- in particular it's not
> clear what the semantics of combination across different index columns
> are. I assume you've hot-wired it so that several BTEqualStrategyNumber
> columns will work like
Peter Eisentraut wrote:
> in the future we might want to change from a fixed list of patch
> sections to a free list of tags, say. Then someone might alter the
> application backend, and we'd use that new version for the next
> commit fest at the time. What will that do to the data of old
> c
On Jul 7, 2009, at 12:32 PM, Tom Lane wrote:
Robert Haas writes:
One possibility would be to remove join_collapse_limit entirely, but
that would eliminate one possibily-useful piece of functionality that
it current enables: namely, the ability to exactly specify the join
order by setting join
David E. Wheeler wrote:
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public notice
of any EOL for a branch. At least a couple of months, preferably. If
the lifetime were absolutely fixed it might not matter so much, but
as it isn'
On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote:
> We're now about a week away from the start of the July 2009
> commitfest, and we need to make a decision about whether to start
> using http://commitfest.postgresql.org to manage it, or punt to the
> next commitfest and continue to use the wiki
Heikki Linnakangas writes:
> And I'm sure people will want the option to retain WAL longer in the
> master, to avoid an expensive resync if the slave falls behind. It would
> be simple to provide a GUC option for "always retain X GB of old WAL in
> pg_xlog".
Right, we would want to provide some m
On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote:
And it only goes back to 8.0
Huh, true :-( This should be fixed.
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have formal
control over scheduled maintenanc
On Tuesday 07 July 2009 19:35:54 Tom Lane wrote:
> Peter Eisentraut writes:
> > On Sunday 10 May 2009 03:05:48 dam...@dalibo.info wrote:
> >> Here's a second version. Main changes are :
> >>
> >> * Child tables are sorted by name
> >> * \d only shows the number of child tables
> >> * \d+ shows the
David E. Wheeler wrote:
> On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote:
>
>> We have an RSS:
>> http://www.postgresql.org/versions.rss
>
> Does anyone use it?
No idea.
> And it only goes back to 8.0
Huh, true :-( This should be fixed.
> and it served with the text/html content-type.
Not
Tom Lane wrote:
> Greg Stark writes:
>> On Tue, Jul 7, 2009 at 4:49 PM, Tom Lane wrote:
>>> This design seems totally wrong to me.
>>> ...
>
>> But this conflicts with earlier discussions where we were concerned
>> about the length of the path wal has to travel between the master and
>> the slave
Jeff Davis writes:
> On Tue, 2009-07-07 at 18:36 +0100, Simon Riggs wrote:
>> On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
>> It is likely to be useful in the future to allow an index with N
>> columns, yet which can provide uniqueness with < N of those columns.
>> This capability is known a
On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote:
We have an RSS:
http://www.postgresql.org/versions.rss
Does anyone use it? And it only goes back to 8.0 and it served with
the text/html content-type.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Tue, 2009-07-07 at 18:36 +0100, Simon Riggs wrote:
> On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
> It is likely to be useful in the future to allow an index with N
> columns, yet which can provide uniqueness with < N of those columns.
> This capability is known as covered indexes and will
On Monday 06 July 2009 22:16:12 Tom Lane wrote:
> Peter Eisentraut writes:
> > I have the attached patch that would make character_octet_length the
> > product of character_octet_length and the maximum octet length of a
> > single character in the selected server encoding. So for UTF-8, this
> >
Greg Stark writes:
> On Tue, Jul 7, 2009 at 4:49 PM, Tom Lane wrote:
>> This design seems totally wrong to me.
>> ...
> But this conflicts with earlier discussions where we were concerned
> about the length of the path wal has to travel between the master and
> the slaves. We want slaves to be ab
On Tue, Jul 7, 2009 at 6:22 PM, Tom Lane wrote:
>
> This seems a bit pointless. There is certainly not any use case for a
> constraint without an enforcement mechanism (or at least none the PG
> community is likely to consider legitimate ;-)). And it's not very
> realistic to suppose that you'd c
On Tuesday 07 July 2009 19:45:44 Tom Lane wrote:
> Greg Stark writes:
> > We should benchmark the planner on increasingly large sets of
> > relations on a typical developer machine and set geqo to whatever
> > value the planner can handle in that length of time. I suspect even at
> > 10s you're ta
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > On Mon, 2009-07-06 at 18:27 +0100, Simon Riggs wrote:
> >> In many cases, people add unique indexes solely to allow replication to
> >> work correctly. The index itself may never be used, especially in high
> >> volume ap
Greg Stark writes:
> We should benchmark the planner on increasingly large sets of
> relations on a typical developer machine and set geqo to whatever
> value the planner can handle in that length of time. I suspect even at
> 10s you're talking about substantially larger values than the current
>
Heikki Linnakangas writes:
> Itagaki Takahiro wrote:
>> CREATE TYPE encrypted_text (
>> INPUT = pgp_sym_encrypt_text(textin($1), passward(), options()),
>> OUTPUT = textout(pgp_sym_decrypt_text($1, passward(), options())),
>> LIKE bytea
>> );
>>
>> passward() and options() are SQL functions and w
On Tue, Jul 7, 2009 at 5:58 PM, Tom Lane wrote:
> So while I don't doubt that geqo was absolutely essential when it was
> written, it's fair to question whether it still provides a real win.
> And we could definitely stand to take another look at the default
> thresholds
The whole point of these p
On Tue, 2009-07-07 at 13:22 -0400, Tom Lane wrote:
> ALTER TABLE tab ADD CONSTRAINT UNIQUE (col1, col2) USING index
This would be very useful, though perhaps only because we do not have
REINDEX CONCURRENTLY.
It is likely to be useful in the future to allow an index with N
columns, yet which can
On Tue, 2009-07-07 at 11:16 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > I would like to see
> > GRANT ... ON ALL OBJECTS ...
>
> This seems inherently broken, since different types of objects
> will have different grantable privileges.
>
> > (I'm sure we can do something intelligent with
Robert Haas writes:
> One possibility would be to remove join_collapse_limit entirely, but
> that would eliminate one possibily-useful piece of functionality that
> it current enables: namely, the ability to exactly specify the join
> order by setting join_collapse_limit to 1. So one possibility
Jeff Davis writes:
> On Mon, 2009-07-06 at 18:27 +0100, Simon Riggs wrote:
>> In many cases, people add unique indexes solely to allow replication to
>> work correctly. The index itself may never be used, especially in high
>> volume applications.
> Interesting. Maybe we should at least try to le
On Tue, Jul 7, 2009 at 4:49 PM, Tom Lane wrote:
> This design seems totally wrong to me. It's confusing the master's
> pg_xlog directory with the archive. We should *not* use pg_xlog as
> a long-term archive area; that's terrible from both a performance
> and a reliability perspective. Performan
David E. Wheeler wrote:
> On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
>
>> One thing I think we really should do is give prominent public notice
>> of any EOL for a branch. At least a couple of months, preferably. If
>> the lifetime were absolutely fixed it might not matter so much, but as
On Tue, Jul 7, 2009 at 4:16 PM, Tom Lane wrote:
>
>> (I'm sure we can do something intelligent with privileges that don't
>> apply to all object types rather than just fail. e.g. UPDATE privilege
>> should be same as USAGE on a sequence.)
>
> Anything you do in that line will be an ugly kluge, and
"Kevin Grittner" writes:
> I guess the question is whether there is anyone who has had a contrary
> experience. (There must have been some benchmarks to justify adding
> geqo at some point?)
The CVS history shows that geqo was integrated on 1997-02-19, which
I think means that it must have been
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public
notice of any EOL for a branch. At least a couple of months,
preferably. If the lifetime were absolutely fixed it might not
matter so much, but as it isn't I think we owe that to
Peter Eisentraut writes:
> On Sunday 10 May 2009 03:05:48 dam...@dalibo.info wrote:
>> Here's a second version. Main changes are :
>>
>> * Child tables are sorted by name
>> * \d only shows the number of child tables
>> * \d+ shows the full list
> Committed.
I looked at this patch. I'm a bit d
Brendan Jurd wrote:
> Maybe you could describe the symptoms you observed? Was the
> webserver totally uncontactable, or was it an error in the web app
> itself?
When I clicked the link to edit the comment, it clocked until the
browser timed out. So then I tried the URL for the main page, an
2009/7/8 Kevin Grittner :
> Oh, sure -- I post about it being down, and seconds after I hit send
> it comes up again. :-/
>
> Do we know that cause?
Well, no, since I've never observed it being "down" and I really have
no idea what you mean by that.
Maybe you could describe the symptoms you obs
Brendan Jurd wrote:
> If you think the app is fundamentally less useful than the wiki,
> please say so and we'll work out whether we can resolve your
> objection in time for the start of the CF.
Oh, sure -- I post about it being down, and seconds after I hit send
it comes up again. :-/
Do
Brendan Jurd wrote:
> If you think the app is fundamentally less useful than the wiki,
> please say so and we'll work out whether we can resolve your
> objection in time for the start of the CF.
It's been down for a while now. I don't know if this is causal, but
the failure seemed to start w
David E. Wheeler wrote:
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote:
I'd personally be perfectly happy with a community decision to desupport
7.4 now, or perhaps after the next set of update releases (which we're
probably overdue for, BTW). We cannot support an indefinitely large set
of back
On Tuesday 07 July 2009 17:40:50 Tom Lane wrote:
> Andres Freund writes:
> > I cannot reasonably plan some queries with join_collapse_limit set to 20.
> > At least not without setting the geqo limit very low and a geqo_effort to
> > a low value.
> > So I would definitely not agree that removing j_
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote:
I'd personally be perfectly happy with a community decision to
desupport
7.4 now, or perhaps after the next set of update releases (which we're
probably overdue for, BTW). We cannot support an indefinitely large
set
of back branches, and a five-y
On Jul 7, 2009, at 12:49 AM, Albe Laurenz wrote:
Is this a known issue in 8.3? If so, is there a known workaround?
The change is probably here:
http://archives.postgresql.org/pgsql-committers/2008-10/msg00110.php
So I think it is safe to argue that this is not a bug in 8.3, but an
improveme
Andrew Dunstan wrote:
I think we need to float a bug upstream to the perl guys on this, but
as a holding position I suggest that we alter the #ifdef test to avoid
calling PERL_SYS_INIT3() where MYMALLOC is defined. It's ugly, but I
can't think of another simple way around it (and we've done
Fujii Masao writes:
> On Tue, Jul 7, 2009 at 12:16 AM, Tom Lane wrote:
>> I confess to not having paid much attention to this thread so far, but ...
>> what is the rationale for having such a capability at all?
> If the XLOG files which are required for recovery exist only in the
> primary server
Andres Freund writes:
> I cannot reasonably plan some queries with join_collapse_limit set to 20. At
> least not without setting the geqo limit very low and a geqo_effort to a low
> value.
> So I would definitely not agree that removing j_c_l is a good idea.
Can you show some specific examples
Hi Kevin, Hi all,
On Tuesday 07 July 2009 16:31:14 Kevin Grittner wrote:
> Robert Haas wrote:
> > I'm interested in hearing from anyone who has practical experience
> > with tuning these variables, or any ideas on what we should test to
> > get a better idea as to how to set them.
>
> I don't rem
Simon Riggs writes:
> I would like to see
> GRANT ... ON ALL OBJECTS ...
This seems inherently broken, since different types of objects
will have different grantable privileges.
> (I'm sure we can do something intelligent with privileges that don't
> apply to all object types rather than just f
On Jul 7, 2009, at 9:31 AM, "Kevin Grittner" > wrote:
Robert Haas wrote:
I'm interested in hearing from anyone who has practical experience
with tuning these variables, or any ideas on what we should test to
get a better idea as to how to set them.
I don't remember any clear resolution to t
Dave Page writes:
> On Tue, Jul 7, 2009 at 8:28 AM, Heikki
> Linnakangas wrote:
>> Hmm, I thought we dropped support for 7.4 a while ago, and there's no
>> download link for it on www.postgresql.org anymore. But looking at the
>> CVS history, I see that others are still committing fixes to 7.4 bra
Robert Haas wrote:
> I'm interested in hearing from anyone who has practical experience
> with tuning these variables, or any ideas on what we should test to
> get a better idea as to how to set them.
I don't remember any clear resolution to the wild variations in plan
time mentioned here:
Peter Eisentraut writes:
> On Monday 06 July 2009 23:00:18 Tom Lane wrote:
>> It seems to me that the right fix here is not so much to tweak the
>> message wording as to put in an error location cursor. In more
>> complicated cases (eg, multiple FOREIGN KEY clauses) the suggested
>> wording chang
1 - 100 of 123 matches
Mail list logo
