Alvaro Herrera wrote:
In any case the change is a very small patch, which I attach but I
haven't tested. This only works if the new rewriteheap stuff actually
changes Xids to follow OldestXmin, i.e. all tuples that have older
Xmin/Xmax are frozen (or marked with the current Xid). Heikki, can
Tom Lane wrote:
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
Gregory Stark wrote:
Attached is a small patch which fixes this case. It also makes the check
slightly more liberal -- we don't need to resort if the previous sort was
unbounded or the bound was greater than or equal to the new bound.
Huh, can you clarify this comment:
+* XXX It
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Attached is a small patch which fixes this case. It also makes the check
slightly more liberal -- we don't need to resort if the previous sort was
unbounded or the bound was greater than or equal to the new bound.
Huh, can you
Alvaro Herrera wrote:
However, given that Heikki just confirmed that CLUSTER does not freeze
tuples, it's not really possible to do this, so I'll drop the CLUSTER
patch for now.
This means that people using CLUSTER to compact tables won't have the
benefit of advancing relfrozenxid, so they will
Do we have a patch to make this consistent?
no, not yet. It's topic for discussion and ToDo
Regards
Pavel Stehule
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to
On Wed, May 16, 2007 at 09:12:23AM +0100, Heikki Linnakangas wrote:
Jim C. Nasby wrote:
BTW, is there some trick to getting cvs diff to ignore files that
aren't in the repo?
Trick? That's what it does by default.
I suspect he's talking about all the lines starting with '?' that diff
On Wed, May 16, 2007 at 09:12:23AM +0100, Heikki Linnakangas wrote:
Jim C. Nasby wrote:
BTW, is there some trick to getting cvs diff to ignore files that aren't
in the repo?
Trick? That's what it does by default.
Well, it throws a notice that they're there...
[EMAIL
Jim C. Nasby wrote:
On Wed, May 16, 2007 at 09:12:23AM +0100, Heikki Linnakangas wrote:
Jim C. Nasby wrote:
BTW, is there some trick to getting cvs diff to ignore files that aren't
in the repo?
Trick? That's what it does by default.
Well, it throws a notice that they're there...
Jim C. Nasby wrote:
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.
Yeah, there's always room for improvement. I made the patch when I was
David Fetter [EMAIL PROTECTED] writes:
On Wed, May 16, 2007 at 09:12:23AM +0100, Heikki Linnakangas wrote:
Jim C. Nasby wrote:
BTW, is there some trick to getting cvs diff to ignore files that
aren't in the repo?
Trick? That's what it does by default.
I suspect he's talking about all the
On Wed, May 16, 2007 at 03:53:22PM +0100, Gregory Stark wrote:
David Fetter [EMAIL PROTECTED] writes:
On Wed, May 16, 2007 at 09:12:23AM +0100, Heikki Linnakangas wrote:
Jim C. Nasby wrote:
BTW, is there some trick to getting cvs diff to ignore files
that aren't in the repo?
Trick?
David Fetter wrote:
cvs diff [list of files here] |grep -v '^?' the_file.diff
Those lines go to stderr.
Not when I do cvs diff. Is there something I should (un)set in my
.cvsrc?
No. (The lines that go to stderr are the directory names). But I don't
see why there's a
On May 16, 2007, at 9:38 , Alvaro Herrera wrote:
That said, check this out:
http://www.ubiobio.cl/~gpoo/pgsql/settings/
Sadly, usage instructions are in spanish only currently, but I claim
that this script is extremely useful for Pg development (sure, I wrote
it and tailored to my needs).
Michael Glaesemann wrote:
On May 16, 2007, at 9:38 , Alvaro Herrera wrote:
That said, check this out:
http://www.ubiobio.cl/~gpoo/pgsql/settings/
Sadly, usage instructions are in spanish only currently, but I claim
that this script is extremely useful for Pg development (sure, I wrote
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
However, given that Heikki just confirmed that CLUSTER does not freeze
tuples, it's not really possible to do this, so I'll drop the CLUSTER
patch for now.
This means that people using CLUSTER to compact tables won't have the
benefit of
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 --- at least I'm pretty sure I
remember it being
So based on the feedback and suggestions here this is the interface I suggest:
\connect - to open a new connection keeping the existing one
\g - to submit a command asynchronously (like in the shell)
\S [Sess#] - to _S_witch to a different _S_ession
- if no connection #
Hello,
I just made this patch so I could debug and otherwise
poke around.
It allows elog_node_display() and friends to show
INSERT parse trees.
AFIK it works, in my use and after applying
to the latest cvs with:
./configure --enable-cassert ; make check
The patch does not have a
Heikki Linnakangas [EMAIL PROTECTED] writes:
Now that I think this a bit more, I think CLUSTER should freeze the
tuples.
I disagree with that...
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Now that I think this a bit more, I think CLUSTER should freeze the
tuples.
I disagree with that...
Ok. Why?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of
I'm not interested in pushing for inclusion, this is
just an observation.
On 05/16/2007 03:20:54 PM, Tom Lane wrote:
This seems rather pointless unless we were going to undertake to make
outfuncs.c support *all* raw-grammar node types.
Isn't having something better than having nothing?
It's
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Now that I think this a bit more, I think CLUSTER should freeze the
tuples.
I disagree with that...
Ok. Why?
It's removing potentially-important data without any notice or recourse
Tom Lane wrote:
It's removing potentially-important data without any notice or recourse
to the user. There seems to be a contingent around here that thinks
that as soon as xmin is older than GlobalXmin it is no longer of
interest to anyone, but I have lost count of how often I have found it
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
... I have resisted having VACUUM freeze
tuples before they've reached a quite-respectable age, and I object to
having CLUSTER do it either.
How about freezing anything older than vacuum_freeze_min_age, just like
VACUUM does?
I
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
... I have resisted having VACUUM freeze
tuples before they've reached a quite-respectable age, and I object to
having CLUSTER do it either.
How about freezing anything older than vacuum_freeze_min_age, just
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
How about freezing anything older than vacuum_freeze_min_age, just like
VACUUM does?
I suppose that'd be OK, but is it likely to be worth the trouble?
I think so, because it means that
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
How about freezing anything older than vacuum_freeze_min_age, just like
VACUUM does?
I suppose that'd be OK, but is it likely to be worth the trouble?
I think
Gregory Stark [EMAIL PROTECTED] writes:
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.
I
Alvaro Herrera [EMAIL PROTECTED] writes:
Here is my proposed patch.
Actually, the original patch in this series was fairly horrid, and
things haven't been made better by the subsequent changes. It lacked
any comment explaining what it was doing; failed to comment on the way
it was abusing
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.
---
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tomas Doran wrote:
On 10 May 2007, at 03:09, Alvaro Herrera wrote:
FWIW I think you should still provide
Tom Lane [EMAIL PROTECTED] writes:
This patch makes what was already a hack into a full-fledged crock (and
it's not just the self-doubting comments that make me distrust it).
I think we need to rip out this ad-hoc parameter change signaling code
and make it work through the regular chgParam
33 matches
Mail list logo
