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
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.
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 ign
Jeff Davis 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
there was any
> 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 ke
On Wed, Feb 11, 2009 at 10:03 PM, Robert Haas 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 (id));
> create index fo
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_migrat
Tom Lane wrote:
> Peter Eisentraut 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 co
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) se
On Wed, Feb 11, 2009 at 8:24 PM, Tom Lane wrote:
> [ forgot to respond to this earlier, sorry ]
Thanks for responding now.
> Robert Haas 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
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 c
[ forgot to respond to this earlier, sorry ]
Robert Haas 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 be
> a win over tea
Alvaro Herrera 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 another idea that autovacuum
"Kevin Grittner" writes:
> Tom Lane 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 identity is you can
apply the transformati
>>> 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 c
Josh Berkus 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 commutator or nega
>>> Tom Lane 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 the case.
Greg Smith 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 ... ]
$ psql regression
ps
Tom Lane wrote:
Josh Berkus 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
Josh Berkus 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 actual error
"David Rowley" 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 with the fol
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 remov
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 contrib.tsqu
Peter Eisentraut 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 lane
--
2009/2/11 Tom Lane :
> Pavel Stehule writes:
>> 2009/2/11 Tom Lane :
>>> 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
>>> already acc
Tom Lane Wrote:
> "David Rowley" 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 like a
On Wed, Feb 11, 2009 at 4:42 PM, Tom Lane wrote:
> Robert Haas 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 tha
Robert Haas 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 in
a way to set th
On Wed, Feb 11, 2009 at 3:40 PM, Tom Lane wrote:
> Alvaro Herrera 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 sett
Alvaro Herrera 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 seem
> material for 8.4.
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 i
Alvaro Herrera 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 sensible when phrased that w
Tom Lane wrote:
> Alvaro Herrera 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 whe
Alvaro Herrera 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 store the options?
W
Peter Eisentraut 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 wo
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
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera 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 me
Tom Lane wrote:
> Alvaro Herrera 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
>
> >
Alvaro Herrera 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.* options"? I
--On Mittwoch, Februar 11, 2009 19:27:51 + Simon Riggs
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 version.
I am havi
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 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, bu
Teodor Sigaev 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 10x lower. An
Tom Lane wrote:
> Alvaro Herrera 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 y
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 r
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
http://wiki.postgresql.org/wiki/Hot_Stand
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 l
Peter Eisentraut 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 we actually e
Alvaro Herrera 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 time and interest to
On Wed, Feb 11, 2009 at 1:10 PM, Tom Lane wrote:
> Alvaro Herrera 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 t
Alvaro Herrera 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. Maybe we do need the ru
Tom Lane wrote:
> Alvaro Herrera 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
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 pointe
Alvaro Herrera 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 don't need the LEFT
JOIN
Gianni Ciolli 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 to specify the pr
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
Jeff Davis 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 advances.
Tom Lane wrote:
> Alvaro Herrera 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 function name; you
David Fetter 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, for
> examp
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/
Pavel Stehule writes:
> 2009/2/11 Tom Lane :
>> 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
>> already accommodated at less effort wit
2009/2/11 Tom Lane :
> Pavel Stehule 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 hand
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. Tak
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 tab
On Wed, Feb 11, 2009 at 11:19 AM, David Fetter 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 commitment, say, wi
"D'Arcy J.M. Cain" writes:
> 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),
On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
> On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis 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
Matteo Beccati 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 the pg_listen
Pavel Stehule 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
things that look like vali
>>> "D'Arcy J.M. Cain" wrote:
> On Wed, 11 Feb 2009 09:47:25 +0200
> Peter Eisentraut 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 terms reversed
Asko Oja 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, have changed
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 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
On Tue, Feb 10, 2009 at 8:53 AM, Alvaro Herrera
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
> elsewhere, and I think
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 wrote:
> Kenneth
On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis 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 pgsql-hackers mailin
Ana Carolina Brito de Almeida 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 simple
copyObject-lik
> 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
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 conditions
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 o
Peter Eisentraut 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 psql's de
On Wed, 11 Feb 2009 09:47:25 +0200
Peter Eisentraut 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
"obsolete" y
I'm currently facing with a strange behavior during HotStandby Testing.
That's what i'm actually doing:
MASTER:
CREATE DATABASE foo;
archive_timeout)>
STANDBY:
postgres=# SELECT oid, datname FROM pg_database;
oid | datname
---+---
1 | template1
11561 | template0
11562 |
On Wed, Feb 11, 2009 at 8:05 AM, David Fetter 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 that link in
Robert Haas wrote:
On Feb 11, 2009, at 12:12 AM, Andrew Chernow 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
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 th
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
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:
PointerGetDatum(data->
On Wed, Feb 11, 2009 at 2:47 AM, Peter Eisentraut 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
> revise int
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
> wrote:
>
> > On Tue, Feb 10, 2009 at 3:10 PM, Tom Lane wrote:
> >
> >> I wrote (in response to Kevin Grittner's recent issues):
> >> > Reflecting on this further, I suspect there
On Feb 11, 2009, at 12:12 AM, Andrew Chernow 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
proposed the bel
Tom Lane wrote:
Alvaro Herrera 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 function name; you can't assume
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 pgsql-h
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 function.
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 cou
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 connection
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 qui
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 a
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 us
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 caref
100 matches
Mail list logo
