Peter Eisentraut wrote:
I would also extend this system to removed configuration settings, e.g.,
max_fsm_*. We should make these deprecated for one release, so (1)
configuration files can be upgraded without manual work (relevant to
in-place upgrade), and (2) users are alerted that their
Hi,
Peter Eisentraut wrote:
I have been thinking, with a semi-formal deprecation policy, we could
make these decisions with more confidence.
+1 (I'm reading this as a very general proposal also targeting C APIs,
not only GUCs).
Comments?
With the proposed policy we'd have to recommend
Tom Lane wrote:
So it seems we have a couple of problems here. Using xlc_r or xlC_r
or adding -q64 to CC (rather than CFLAGS which is where it really
belongs) will confuse this check.
Correction: Flags that determine the architecture usually belong in CC,
not in CFLAGS.
Test case for when
Hi everyone,
I've been recently testing PostgreSQL 8.3.4 (upgrade to 8.3.6 is
scheduled) with a large number of connections from separate boxes each
using a locally installed pgpool-II set in connection pooling mode, for
up to 2500 concurrent open connections.
Given I was using 8.3, it seemed
Thanks for valuable info!
I'm going to add a caution to pgpool-II's docs. DISCARD ALL will
cause serious performance degration.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Hi everyone,
I've been recently testing PostgreSQL 8.3.4 (upgrade to 8.3.6 is
scheduled) with a large number of connections
Joshua D. Drake wrote:
On Tue, 2009-02-10 at 10:15 +0900, Tatsuo Ishii wrote:
Hi,
Is there any way to stop autovacuum temporarily?(other than edit
postgresql.conf and reload it) Pgpool-II does not want autovacuum
running while doing onlie recovery.
It would be a significant hack but you
Hello
some years ago there was some plans about parser's extensibility. I am
able write bison extensions, but I thing, so lot of work should be
done via hooking of transform stage.
I did small example - real implementation of Oracle's decode function.
It's based on hooking transformExpr
Fernando Ike wrote:
I know that this moment is inappropriate to submit patch, with the
discussions about features for 8.4. But, if can added for commitfest
to 8.5 version. I'm appreciate.
Yes, please add it to the first 8.5 commit fest. You can edit the wiki
yourself.
--
Sent via
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Note that it introduces a LEFT JOIN on pg_class to itself that's always
present, even for server versions that do not support reloptions.
Personally I'd be more worried about the unnest(). Also, please
schema-qualify that
On Feb 11, 2009, at 12:12 AM, Andrew Chernow a...@esilo.com wrote:
Robert Haas wrote:
I am not in love with the idea of using PQinitSSL(SOME_MAGIC_VALUE)
The issue I see is the inability to toggle crypto initialization.
I think crypto init and ssl init are 2 different things. Thus, I
On Tue, Feb 10, 2009 at 08:12:56PM -0500, Jonah H. Harris wrote:
On Tue, Feb 10, 2009 at 8:09 PM, Jonah H. Harris
jonah.har...@gmail.comwrote:
On Tue, Feb 10, 2009 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote (in response to Kevin Grittner's recent issues):
Reflecting on
On Wed, Feb 11, 2009 at 2:47 AM, Peter Eisentraut pete...@gmx.net wrote:
We often discuss changing user-visible behavior of various kinds and are
usually clueless on the question of someone might rely on this or how
many people are still using this etc. Still, it is clearly often useful to
Looking through the code again, gin_compare_prefix_##type looks a little
confusing.
Is there a reason for using:
(data-strategy == BTLessStrategyNumber ||
data-strategy == BTLessEqualStrategyNumber ) ?
PointerGetDatum(data-datum) : a
rather than just using:
Hi all,
How can I copy the PlannerInfo structure?
I have *root variable that is PlannerInfo and I would like to pass this
value to another variable that I created (the same type - PlannerInfo).
Can you help me? I only found function that copies PlannedStmt structure.
Thanks,
Ana Carolina
Bruce Momjian wrote:
Peter Eisentraut wrote:
While regress/GNUmakefile appears to make an effort to run the regressions
tests with or without locale depending on the users choice, .e.g.,
# locale
NOLOCALE =
ifdef NO_LOCALE
NOLOCALE += --no-locale
endif
the pg_regress.c implementation spoils
Robert Haas wrote:
On Feb 11, 2009, at 12:12 AM, Andrew Chernow a...@esilo.com wrote:
Robert Haas wrote:
I am not in love with the idea of using PQinitSSL(SOME_MAGIC_VALUE)
The issue I see is the inability to toggle crypto initialization. I
think crypto init and ssl init are 2 different
On Wed, Feb 11, 2009 at 8:05 AM, David Fetter da...@fetter.org wrote:
As has been discussed here many, many times, the only kind of person
who should be doing a patent search is a company's IP attorney, which
you are not, and even if you were, under no circumstances would such a
person paste
I'm currently facing with a strange behavior during HotStandby Testing.
That's what i'm actually doing:
MASTER:
CREATE DATABASE foo;
do something in there, e.g. restoring a dump
wait until xlog segments get consumed by standby node (using
archive_timeout)
STANDBY:
postgres=# SELECT oid,
On Wed, 11 Feb 2009 09:47:25 +0200
Peter Eisentraut pete...@gmx.net wrote:
1. In release N, an interface is declared obsolete, which means that
[...]
2. In release N+1, obsolete interfaces are declared deprecated, which
I like the idea but aren't these two terms reversed? In fact, isn't
Peter Eisentraut pete...@gmx.net writes:
Tom Lane wrote:
Personally I'd be more worried about the unnest(). Also, please
schema-qualify that function name; you can't assume anything about
the search path here.
Maybe it would be more elegant to put the search_path into proconfig?
This is
But the real bottom line is: if autovacuum is working properly, it
should clean up the index before the list ever gets to the point where
it'd be sane to turn off indexscans. So I don't see why we need to hack
the planner for this at all. If any hacking is needed, it should be
in the direction
What would be wrong with letting it degrade to lossy? I suppose the
reason it's trying to avoid that is to avoid having to recheck all the
rows on that page when it comes time to do the index insertion; but
surely having to do that is better than having arbitrary, unpredictable
failure
I believe that user could get GIN's error about work_mem only intentionally:
- turn off autovacuum
Meanwhile, in the other thread, we're having a discussion about people
wanting to do exactly this on a database-wide basis during peak load
hours...
- set big work_mem
- populate table with GIN
Ana Carolina Brito de Almeida ana...@ig.com.br writes:
How can I copy the PlannerInfo structure?
There's no support for that. If you want a shallow copy it's just a
memcpy; a deep copy is a bit of a problem because of the circular
linkages in some of the planner data structures (meaning a
On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis pg...@j-davis.com wrote:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
Can you clarify the circumstances in which this patch would show a
benefit over the current system?
...Robert
--
Sent via
Did this change hashtext() visible to users? We have been using it quite
widely for partitioning our databases. If so then it should be marked quite
visibly in release notes as there might be others who will be hit by this.
regards
Asko
On Mon, Feb 9, 2009 at 11:22 PM, Tom Lane
On Tue, Feb 10, 2009 at 8:53 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I'm not sure that this calls for a change in autovacuum itself; it seems
to be that whatwe really need is the ability to change postgresql.conf
settings from the SQL interface. This has been discussed at length
On Wed, Feb 11, 2009 at 09:36:38AM -0500, Jonah H. Harris wrote:
On Wed, Feb 11, 2009 at 8:05 AM, David Fetter da...@fetter.org wrote:
As has been discussed here many, many times, the only kind of
person who should be doing a patent search is a company's IP
attorney, which you are not,
Asko Oja asc...@gmail.com writes:
Did this change hashtext() visible to users? We have been using it quite
widely for partitioning our databases. If so then it should be marked quite
visibly in release notes as there might be others who will be hit by this.
The hash functions are undocumented,
D'Arcy J.M. Cain da...@druid.net wrote:
On Wed, 11 Feb 2009 09:47:25 +0200
Peter Eisentraut pete...@gmx.net wrote:
1. In release N, an interface is declared obsolete, which means
[...]
2. In release N+1, obsolete interfaces are declared deprecated,
I like the idea but aren't these two
Pavel Stehule pavel.steh...@gmail.com writes:
some years ago there was some plans about parser's extensibility. I am
able write bison extensions, but I thing, so lot of work should be
done via hooking of transform stage.
This strikes me as next door to useless, because it can only handle
Matteo Beccati p...@beccati.com writes:
Given I was using 8.3, it seemed quite right to set the reset statement
to ABORT; DISCARD ALL. Everything works fine, until a load spike
happens and pgpool-II reset queries start to lag behind, with DISCARD
ALL failing to acquire an exclusive locks on
On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis pg...@j-davis.com wrote:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
Can you clarify the circumstances in which this patch would show a
D'Arcy J.M. Cain da...@druid.net writes:
Peter Eisentraut pete...@gmx.net wrote:
I would also extend this system to removed configuration settings, e.g.,
max_fsm_*. We should make these deprecated for one release, so (1)
configuration files can be upgraded without manual work (relevant to
On Wed, Feb 11, 2009 at 11:19 AM, David Fetter da...@fetter.org wrote:
This is a very big deal, as you are exposing every US PostgreSQL
contributor to triple damages for knowing infringement. Are you
saying you're going to pay all that out of your own pocket? Are you
making a legal
Hi Tom,
Given I was using 8.3, it seemed quite right to set the reset statement
to ABORT; DISCARD ALL. Everything works fine, until a load spike
happens and pgpool-II reset queries start to lag behind, with DISCARD
ALL failing to acquire an exclusive locks on the pg_listen system table,
David,
* David Fetter (da...@fetter.org) wrote:
On Wed, Feb 11, 2009 at 09:36:38AM -0500, Jonah H. Harris wrote:
Secondly, I don't believe there's any restriction of explicitly what
can and cannot be posted on a public Postgres mailing list.
We have plenty of such restrictions. Take the
2009/2/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
some years ago there was some plans about parser's extensibility. I am
able write bison extensions, but I thing, so lot of work should be
done via hooking of transform stage.
This strikes me as next door to
Pavel Stehule pavel.steh...@gmail.com writes:
2009/2/11 Tom Lane t...@sss.pgh.pa.us:
This strikes me as next door to useless, because it can only handle
things that look like valid expressions to the existing grammar.
So pretty much all you can do is weird sorts of functions, which are
Hello,
On Tue, Feb 10, 2009 at 09:41:46PM +0100, Dimitri Fontaine wrote:
Hi,
Le 10 févr. 09 à 21:10, Tom Lane a écrit :
I wrote (in response to Kevin Grittner's recent issues):
Reflecting on this further, I suspect there are also some bugs in the
planner's rules about when semi/antijoins
David Fetter da...@fetter.org writes:
On Wed, Feb 11, 2009 at 09:36:38AM -0500, Jonah H. Harris wrote:
Secondly, I don't believe there's any restriction of explicitly what
can and cannot be posted on a public Postgres mailing list.
We have plenty of such restrictions. Take the Nazi spammer,
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Note that it introduces a LEFT JOIN on pg_class to itself that's always
present, even for server versions that do not support reloptions.
Personally I'd be more worried about the unnest(). Also, please
schema-qualify that
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
Can you clarify the circumstances in which this patch would show a
benefit over the current system?
In the current code, if the process is always holding at least one
snapshot, the process' xmin never
Peter Eisentraut wrote:
Joshua D. Drake wrote:
It would be a significant hack but you could update pg_autovacuum to set
all relations to false.
Which will no longer work in 8.4.
More generally, it was pointed out to me that users apparently do
updates of pg_autovacuum to change settings
Gianni Ciolli gianni.cio...@2ndquadrant.it writes:
On Tue, Feb 10, 2009 at 09:41:46PM +0100, Dimitri Fontaine wrote:
I don't know how easy it would be to do, but maybe the Coq formal proof
management system could help us here:
http://coq.inria.fr/
The harder part in using coq might well be
Alvaro Herrera alvhe...@commandprompt.com writes:
This version should fix these issues. I refrained from adding more ? :
expressions because it starts getting ugly for my taste.
I think you might as well just introduce two separate code paths to
produce the 8.4 and pre-8.4 queries, so that you
On Wed, 2009-02-11 at 14:21 -0300, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Joshua D. Drake wrote:
It would be a significant hack but you could update pg_autovacuum to set
all relations to false.
Which will no longer work in 8.4.
More generally, it was pointed out to me that
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
This version should fix these issues. I refrained from adding more ? :
expressions because it starts getting ugly for my taste.
I think you might as well just introduce two separate code paths to
produce the 8.4 and
Alvaro Herrera alvhe...@commandprompt.com writes:
Peter Eisentraut wrote:
More generally, it was pointed out to me that users apparently do
updates of pg_autovacuum to change settings on a bunch of tables at
once. We might get some complaints if we remove that facility.
Hmm, argh.
On Wed, Feb 11, 2009 at 1:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Peter Eisentraut wrote:
More generally, it was pointed out to me that users apparently do
updates of pg_autovacuum to change settings on a bunch of tables at
once. We might
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
IMHO the cut-and-paste way that we usually
do it in pg_dump is a whole lot easier to read and maintain than this
sort of ?: spaghetti.
Hmm, so should we try to get rid of them in a more consistent fashion?
If you've got the
Peter Eisentraut pete...@gmx.net writes:
I have been thinking, with a semi-formal deprecation policy, we could
make these decisions with more confidence. My proposed policy goes like
this:
I've been thinking about this for a couple of hours, and I keep coming
back to the conclusion that if
Robert Haas wrote:
I believe that user could get GIN's error about work_mem only intentionally:
- turn off autovacuum
Meanwhile, in the other thread, we're having a discussion about people
wanting to do exactly this on a database-wide basis during peak load
hours...
- decrease work_mem for at
Hi Bernd,
On Wed, Feb 11, 2009 at 03:49:24PM +0100, Bernd Helmle wrote:
I'm currently facing with a strange behavior during HotStandby Testing.
That's what i'm actually doing:
it seems that this was a known bug (snapshot bug), which as noted in
Hi,
[...]
In my understanding, the row-level ACLs feature (plus a bit enhancement)
can
help your requirements. I developed it with SE-PostgreSQL in parallel,
but also postponed to v8.5 series.
It enables to assign database ACLs on individual tuples, and filter out
violated tupled from the
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
IMHO the cut-and-paste way that we usually
do it in pg_dump is a whole lot easier to read and maintain than this
sort of ?: spaghetti.
Hmm, so should we try to get rid of them in a more consistent
Teodor Sigaev teo...@sigaev.ru writes:
Robert Haas wrote:
Why would the new work_mem need to be 10x smaller than the old work mem?
That is is way to get GIN's error emitted. Work_mem should be decreased
to catch a chance to get lossy tidbitmap.
But it only has to be marginally lower, not
On Wed, 2009-02-11 at 19:48 +0100, Gianni Ciolli wrote:
Probably you are running an old version: it's not your fault, since in
the same page I can read that 9g is the last published version (I know
that Simon is having some difficulties with git).
I did publish v9h to Hackers on 27 Jan, but
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
I tested this changes and found two issues:
1. fillfactor.* options are silently ignored when the table doesn't have
toast relation. Should we notice the behabior to users?
ex. NOTICE: toast storage parameters are ignored
--On Mittwoch, Februar 11, 2009 19:27:51 + Simon Riggs
si...@2ndquadrant.com wrote:
I did publish v9h to Hackers on 27 Jan, but did not put a new version
onto the Wiki at that time. Sorry Bernd.
Great! I just thought its worth reporting it. Sorry for the noise and
missing the new patch
Alvaro Herrera alvhe...@commandprompt.com writes:
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
1. fillfactor.* options are silently ignored when the table doesn't have
toast relation. Should we notice the behabior to users?
ex. NOTICE: toast storage parameters are ignored
You mean toast.*
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
1. fillfactor.* options are silently ignored when the table doesn't have
toast relation. Should we notice the behabior to users?
ex. NOTICE: toast storage parameters are
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
1. fillfactor.* options are silently ignored when the table doesn't have
toast relation. Should we notice the behabior to users?
ex. NOTICE: toast storage
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
I tend to think this isn't a very good idea. It's difficult for
applications to know whether a toast table will be created or not.
They should be able to just set the toast options and not worry.
The problem is where do we
Peter Eisentraut pete...@gmx.net writes:
Tom Lane wrote:
Would it be reasonable to change the test quoted above to
elif test $PORTNAME = aix; then ...
that is try -qnoansialias anytime the compiler isn't gcc and the
platform is aix? Is xlc used on any platform other than aix?
That
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
I tend to think this isn't a very good idea. It's difficult for
applications to know whether a toast table will be created or not.
They should be able to just set the toast options and not worry.
The problem is where do we
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
I tend to think this isn't a very good idea. It's difficult for
applications to know whether a toast table will be created or not.
They should be able to just set the toast options and not worry.
The
Alvaro Herrera alvhe...@commandprompt.com writes:
However, Takahiro-san and Euler's position is that if you do this:
create table foo (f1 int) with (toast.fillfactor = 70);
alter table foo add column f2 text;
Then the toast table should have the fillfactor setting.
Well, that might look
Tom Lane wrote:
Or to put it another way: it seems to me that the use-case being argued
here is really for being able to adjust the default toast reloptions.
Not to have action at a distance on a table that doesn't exist and you
have no way to know when you set the option what will be in it
Alvaro Herrera alvhe...@commandprompt.com writes:
Since we don't have a way to set default reloptions for main tables
either, I don't think we should be pushing very hard for having one to
set default reloptions for toast tables.
Even if we were to argue that we should have both, it doesn't
On Wed, Feb 11, 2009 at 3:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
However, Takahiro-san and Euler's position is that if you do this:
create table foo (f1 int) with (toast.fillfactor = 70);
alter table foo add column f2 text;
Then the toast
Robert Haas robertmh...@gmail.com writes:
FWIW, I don't really buy this argument. I can't see that it's all
that implausible to think that the user might be able to prognosticate
a reasonable value for a future TOAST table.
Well, it still seems to me that such a user is really more interested
On Wed, Feb 11, 2009 at 4:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
FWIW, I don't really buy this argument. I can't see that it's all
that implausible to think that the user might be able to prognosticate
a reasonable value for a future TOAST table.
Tom Lane Wrote:
David Rowley dgrow...@gmail.com writes:
My report contained a full re-creation script to reproduce the problem
and
tonight I'm having the same problem with CVS Head. To my untrained eye
it
looks like the planner is not properly pushing down the row count.
It looks more
2009/2/11 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/2/11 Tom Lane t...@sss.pgh.pa.us:
This strikes me as next door to useless, because it can only handle
things that look like valid expressions to the existing grammar.
So pretty much all you can do is
Peter Eisentraut pete...@gmx.net writes:
Bruce Momjian wrote:
Has this been resolved?
Since nobody spoke up, I have changed it now so it runs with locale by
default. Let's see if we get away with that.
Buildfarm member heron doesn't like it, for one.
regards, tom
All,
I've been working on some scripts (for pgfoundry) which help in
cleaning up databases which have TSearch and other contrib modules
installed to schema public. However, I ran into this odd issue:
ERROR: btree operators must return boolean
STATEMENT: CREATE OPERATOR CLASS
Peter,
3. In release N+2, if there were no protests in response to step 2,
deprecated features are removed.
The main issue I can see with this is that most production sites only
upgrade once every 2-3 years. So they'd tend to miss warnings entirely.
I would also extend this system to
David Rowley dgrow...@gmail.com writes:
I thought about this after sending my reply to this last night. I remembered
when I created my test case I had to add the other tables to get the nest
loop behaviour. I'm not sure your guess about the multicolumn selectivity
issue is correct. I re-tested
Josh Berkus j...@agliodbs.com writes:
I've been working on some scripts (for pgfoundry) which help in
cleaning up databases which have TSearch and other contrib modules
installed to schema public. However, I ran into this odd issue:
ERROR: btree operators must return boolean
Is that the
On Wed, 11 Feb 2009, Josh Berkus wrote:
I did actually give some thought to a config file converter, but the number
of options which are new, changed names, changed names and changed meanings,
changed options, or went away makes it an n^2 issue and not really worth
solving.
My next big push
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
I've been working on some scripts (for pgfoundry) which help in
cleaning up databases which have TSearch and other contrib modules
installed to schema public. However, I ran into this odd issue:
ERROR: btree operators must return
Greg Smith gsm...@gregsmith.com writes:
Anyway, I read Peter's suggestion as aiming more at SQL features and API
changes, rather than configuration file ones. In trivial cases like
sort_mem-work_mem, adding some backward compatibility concessions might
make sense.
[ rolls eyes ... ]
$
Tom Lane t...@sss.pgh.pa.us wrote:
I wrote (in response to Kevin Grittner's recent issues):
Reflecting on this further, I suspect there are also some bugs in
the planner's rules about when semi/antijoins can commute with
other joins;
After doing some math I've concluded this is in fact
Josh Berkus j...@agliodbs.com writes:
Tom Lane wrote:
Is that the actual error message? The closest string I can find in 8.3
or HEAD is index operators must return boolean.
Oh! Sorry, this is 8.2.12.
Oh, OK. It's the same case though. Look for operator definitions that
specify a
I wrote:
A6.
[less coherent version of a question already asked and answered]
Got that part on a reread of the thread. Sorry for asking that after
it had been addressed. No need to answer again.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
A6. (A antijoin B on (Pab)) leftjoin C on (Pbc)
= A antijoin (B leftjoin C on (Pbc)) on (Pab)
How do you get the first form as a starting point?
Not sure if you can in SQL, but the point of the
Alvaro Herrera alvhe...@commandprompt.com wrote:
I'm not sure that this calls for a change in autovacuum itself; it seems
to be that whatwe really need is the ability to change postgresql.conf
settings from the SQL interface.
Sure. 'SET GLOBAL autovacuum = off' is a TODO item.
I have
[ forgot to respond to this earlier, sorry ]
Robert Haas robertmh...@gmail.com writes:
On a related note, I have some vague unease about planning A SEMI JOIN
B as A INNER JOIN (UNIQUE B), as make_one_rel currently attempts to
do. For a merge join or nested loop, I don't see how this can ever
On Wed, 2009-02-11 at 12:20 -0500, Tom Lane wrote:
You pointed out the case of opening a cursor in a read-committed
transaction, and then closing it before end of transaction, as a
place where your patch could hope to improve matters. Are there
others? Could your application be made to
On Wed, Feb 11, 2009 at 8:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
[ forgot to respond to this earlier, sorry ]
Thanks for responding now.
Robert Haas robertmh...@gmail.com writes:
On a related note, I have some vague unease about planning A SEMI JOIN
B as A INNER JOIN (UNIQUE B), as
While fooling around with the GIN fast insert patch tonight, I managed
to hang my test database. :-(
I'm going to try to reproduce this, but here's approximately what I did.
create table foo (id serial, x int[], primary key (id));
create index foo_gin on foo using gin (x);
insert into foo (x)
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I have been thinking, with a semi-formal deprecation policy, we could
make these decisions with more confidence. My proposed policy goes like
this:
I've been thinking about this for a couple of hours, and I keep coming
back to
Peter Eisentraut wrote:
Bruce Momjian wrote:
Now that pg_migrator is BSD licensed, and already in C, I am going to
spend my time trying to improve pg_migrator for 8.4:
http://pgfoundry.org/projects/pg-migrator/
What is the plan now? Get pg_upgrade working, get pg_migrator
On Wed, Feb 11, 2009 at 10:03 PM, Robert Haas robertmh...@gmail.com wrote:
I'm going to try to reproduce this, but here's approximately what I did.
OK, I've managed to build a reproducible test case. Initial setup is
just as I had before:
create table foo (id serial, x int[], primary key
I did this four times, sometimes with the variant of adding set
enable_bitmapscan to false; before the explain analyze. In three
cases the database recovered succesfully after the immediate shutdown;
in the other case, it crapped out much as described in my original
email.
Sorry to keep
Jeff Davis pg...@j-davis.com writes:
I could imagine some situations that this could be more useful in the
future. For instance, Hot Standby will increase the consequences of not
advancing xmin when it's possible to do so.
The question wasn't really about the consequences; it was about whether
On Wednesday 11 February 2009 20:10:46 Tom Lane wrote:
AFAIR we pointed out from day one that pg_autovacuum was a temporary
API that we were not promising to keep around. Anybody who was coding
against it with the expectation that they'd not have to change that code
later was willfully
With reloption patch, we can set WITH options to toast tables.
However, fillfactor for toast tables is useless, no?
(autovacuum options will work as expected, though.)
Tuples in toast tables are never updated. When the main tuple is updated,
old toast tuples are deleted and new ones are inserted.
One independent change included in the Hot Standby patch is the change
to the way subtransaction cache works. With the patch, only
subtransactions that don't fit in the subxid cache in PGPROC are marked
in pg_subtrans. To make that work, XidInMVCCSnapshot() always scans the
subxid array in the
100 matches
Mail list logo
