On Fri, 2009-12-04 at 13:31 +0200, Heikki Linnakangas wrote:
> b) seems much simpler to me.
OK. Least ugly wins, but she ain't pretty.
> > 2. (In HS recovery) When we see first commit record for the VF xid we
> > commit the transaction in clog, yet maintain locks and KnownAssigned
> > xids
> >
Simon Riggs wrote:
> ISTM premature to remove all traces of VF from code. We may yet need it
> for some reason, especially if doing so creates complex dependencies on
> important features.
Well, it's still in the repository.
> So modified proposal looks like this
>
> 1. (In normal running) Provi
On Fri, 2009-12-04 at 11:22 +0200, Heikki Linnakangas wrote:
> > My answer is it doesn't, we will still have the problem noted above for
> > catalog tables. So we still have a must-fix issue for HS, though that is
> > no barrier to the new VF patch.
>
> I think the VACUUM FULL patch will have to
On Fri, 2009-12-04 at 11:22 +0200, Heikki Linnakangas wrote:
> Could you just mark the transaction as committed when you see the 1st
> commit record, but leave the XID in the known-assigned list and not
> release locks? That would emulate pretty closely what happens in the master.
OK, works for m
Simon Riggs wrote:
> I've just reviewed the VACUUM FULL patch to see if it does all we need
> it to do, i.e. does the removal of HS code match the new VF patch.
Oh, good!
> My answer is it doesn't, we will still have the problem noted above for
> catalog tables. So we still have a must-fix issue
On Sat, 2009-11-21 at 20:20 +0200, Heikki Linnakangas wrote:
> VACUUM FULL does a peculiar hack: once it's done moving tuples, and
> before it truncates the relation, it calls RecordTransactionCommit to
> mark the transaction as committed in clog and WAL, but the transaction
> is still kept open i
On Wed, 2009-11-25 at 03:12 +, Greg Stark wrote:
> On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane wrote:
> > As long as there's not anything the master actually does differently
> > then I can't see where there'd be any performance testing to do. What's
> > bothering me about this is that it seems
On Wed, Nov 25, 2009 at 3:26 AM, Tom Lane wrote:
> Greg Stark writes:
>> Well the only thing that's been discussed is having vacuum require a
>> minimum age before considering a transaction visible to all to reduce
>> the chance of conflicts on cleanup records.
>
> [ shrug... ] Call me Cassandra
On Wed, 2009-11-25 at 03:12 +, Greg Stark wrote:
> On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane wrote:
> > As long as there's not anything the master actually does differently
> > then I can't see where there'd be any performance testing to do. What's
> > bothering me about this is that it seems
Greg Stark writes:
> Well the only thing that's been discussed is having vacuum require a
> minimum age before considering a transaction visible to all to reduce
> the chance of conflicts on cleanup records.
[ shrug... ] Call me Cassandra. I am not concerned about what has or
has not been discu
On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane wrote:
> As long as there's not anything the master actually does differently
> then I can't see where there'd be any performance testing to do. What's
> bothering me about this is that it seems likely that we'll find places
> where the master has to do t
Simon Riggs writes:
> Tom Lane wrote:
>> There's no equivalent of XLogArchivingActive()?
> We've tried hard to have it "just work". But I wonder whether we should
> have a parameter to allow performance testing on the master? If nobody
> finds any issues then we can remove it again, or at least m
On Sat, 2009-11-21 at 23:00 +0200, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> Tom Lane wrote:
> >>> There's no equivalent of XLogArchivingActive()?
> >
> >> XLogArchivingMode() == false enables us to skip WAL-logging in
> >> operations like CLUSTER or COPY, wh
On Sat, 2009-11-21 at 20:20 +0200, Heikki Linnakangas wrote:
> That causes some headaches for Hot Standby
I say leave HS as it is and we can clean up when we do the VFectomy.
It isn't really a headache, the code works easily enough. I agree its
ugly and it should eventually be removed.
Let's no
On Tue, 2009-11-24 at 09:24 +0200, Heikki Linnakangas wrote:
> Greg Smith wrote:
> > Heikki Linnakangas wrote:
> >> So I guess what I'm asking is: Does anyone see any show-stoppers in
> >> removing VACUUM FULL
> > Here's the disclaimers attached to the new VACUUM REPLACE implementation
> > from Ita
Greg Smith wrote:
> Heikki Linnakangas wrote:
>> So I guess what I'm asking is: Does anyone see any show-stoppers in
>> removing VACUUM FULL
> Here's the disclaimers attached to the new VACUUM REPLACE implementation
> from Itagaki:
>
> "We still need traditional VACUUM FULL behavior for system cat
Itagaki Takahiro wrote:
> VACUUM FULL is still reserved for system catalogs in my patch
> because we cannot modify relfilenodes for the catalog tables.
> Do you have solutions for it?
Tom had an idea on that:
http://archives.postgresql.org/message-id/19750.1252094...@sss.pgh.pa.us
--
Heikki L
Heikki Linnakangas wrote:
> So I guess what I'm asking is: Does anyone see any show-stoppers in
> removing VACUUM FULL, and does anyone want to step up to the plate and
> promise to do it before release?
I'm working on "New VACUUM FULL" patch, that shrinks tables
using CLUSTER-like rewrites.
ht
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> There's no equivalent of XLogArchivingActive()?
>
>> XLogArchivingMode() == false enables us to skip WAL-logging in
>> operations like CLUSTER or COPY, which is a big optimization. I don't
>> see anything like that in Hot Standby
Heikki Linnakangas writes:
> Tom Lane wrote:
>> There's no equivalent of XLogArchivingActive()?
> XLogArchivingMode() == false enables us to skip WAL-logging in
> operations like CLUSTER or COPY, which is a big optimization. I don't
> see anything like that in Hot Standby. There is a few small th
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Tom Lane wrote:
>>> I don't see much problem with rejecting VAC FULL in a HS master,
>>> whether or not it gets removed altogether. Why not just do that
>>> rather than write a lot of kluges?
>
>> Hmm. At the moment, no action is required in the ma
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I don't see much problem with rejecting VAC FULL in a HS master,
>> whether or not it gets removed altogether. Why not just do that
>> rather than write a lot of kluges?
> Hmm. At the moment, no action is required in the master to allow hot
> stand
Tom Lane wrote:
> Heikki Linnakangas writes:
>> So I guess what I'm asking is: Does anyone see any show-stoppers in
>> removing VACUUM FULL, and does anyone want to step up to the plate and
>> promise to do it before release?
>
> I don't see much problem with rejecting VAC FULL in a HS master,
>
Heikki Linnakangas writes:
> So I guess what I'm asking is: Does anyone see any show-stoppers in
> removing VACUUM FULL, and does anyone want to step up to the plate and
> promise to do it before release?
I don't see much problem with rejecting VAC FULL in a HS master,
whether or not it gets remo
Heikki Linnakangas wrote:
So I guess what I'm asking is: Does anyone see any show-stoppers in
removing VACUUM FULL
Here's the disclaimers attached to the new VACUUM REPLACE implementation
from Itagaki:
"We still need traditional VACUUM FULL behavior for system catalog
because we cannot change
25 matches
Mail list logo
