Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I had the idea we were doing that already --- at least I'm pretty sure I
>> remember it being discussed. But I see it's not being done in HEAD.
> Patch to do it attached. I am thinking we can do something similar in
> CLUSTER as wel
Pavel Stehule wrote:
>
> >I would argue that we should likewise not allow them in plpgsql's MOVE,
> >although this is more of a judgment call than is the case for FETCH.
> >I just don't think it's a good idea to provide two redundant ways to do
> >the same thing, when we might want to make one of
Jim C. Nasby wrote:
> On Tue, May 15, 2007 at 06:13:47PM -0400, Alvaro Herrera wrote:
> > Tom Lane wrote:
> > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > I suppose it would be pretty trivial to set the relfrozenxid to
> > > > RecentXmin or something during TRUNCATE.
> > >
> > > I had the
What about adding the ability to ask the FSM for a page that's near a
given page? That way if you did have to go to the FSM you could at least
try and insert close to the page you originally wanted.
On Tue, May 15, 2007 at 11:26:51PM +0100, Heikki Linnakangas wrote:
> Ah, thanks! I had forgotten a
On Tue, May 15, 2007 at 03:35:45PM +1200, Mark Kirkwood wrote:
> Alvaro Herrera wrote:
> >Mark Kirkwood wrote:
> >>Alvaro Herrera wrote:
> >
> >>>Except that it also includes diffs for generated files, which tend to be
> >>>huge. To work around that you need to create a list of files to
> >>>exclu
On Tue, May 15, 2007 at 06:13:47PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > I suppose it would be pretty trivial to set the relfrozenxid to
> > > RecentXmin or something during TRUNCATE.
> >
> > I had the idea we were doing that already --
Moving to -performance.
On Mon, May 14, 2007 at 09:55:16PM -0700, daveg wrote:
> Apologies for asking this on the wrong list, but it is at least the right
> thread.
>
> What is the current thinking on bg_writer setttings for systems such as
> 4 core Opteron with 16GB or 32GB of memory and heavy
Ah, thanks! I had forgotten about it as well.
Bruce Momjian wrote:
[ Sorry I found this one only found recently.]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL
[ Sorry I found this one only found recently.]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I suppose it would be pretty trivial to set the relfrozenxid to
> > RecentXmin or something during TRUNCATE.
>
> I had the idea we were doing that already --- at least I'm pretty sure I
> remember it being discussed. But I see it's
Patch applied. Thanks.
---
Gregory Stark wrote:
>
> Caught someone using PG_DETOAST_PACKED and VARDATA_ANY on a structure that
> required alignment so I guess some more prominent warnings are in order. I
> also added a pa
On Tue, 2007-15-05 at 09:07 -0400, Alvaro Herrera wrote:
> I agree, the note should be added there (but it should be a short one
> and refer the reader someplace else for more complete details).
I've applied the attached patch to HEAD and REL8_2_STABLE.
-Neil
Index: doc/src/sgml/config.sgml
"Tom Lane" <[EMAIL PROTECTED]> writes:
> [ greps a bit... ] It looks like the only way that you could expose the
> bug in the current state of the system would be if the sort/limit with
> the outer parameter were the inside of a nestloop join in the subplan.
> nodeNestloop would set EXEC_FLAG_RE
Neil Conway wrote:
> On Mon, 2007-14-05 at 16:22 -0400, Bruce Momjian wrote:
> > I agree with Tom. I don't think the current behavior is a major issue
> > for users for it to be mentioned more than it already is
>
> Are you really suggesting that we shouldn't modify config.sgml to note
> that "au
Greg Smith wrote:
I realized recently the task I should take on here is to run some more
experiments with the latest code and pass along suggested techniques for
producing/identifying the kind of problem conditions I've run into in
the past; then we can see if other people can reproduce them.
15 matches
Mail list logo