Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Actually, 8.2 initializes it to InvalidTransactionId too, so it doesn't
> seem like there's a problem there either. Since the problem stems from
> using it as initializer for the Min() calculation, there's no actual bug
> on 8.2 either. The bug only ap
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On Wed, Sep 10, 2008 at 9:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> On reflection I'm not even sure that this is strictly an autovacuum
>> bug. It can be cast more generically as "RecentGlobalXmin getting
>> used without ever having been set", and
On Wed, Sep 10, 2008 at 9:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> On reflection I'm not even sure that this is strictly an autovacuum
> bug. It can be cast more generically as "RecentGlobalXmin getting
> used without ever having been set", and it sure looks to me like the
> HOT patch may h
Tom Lane wrote:
> BTW, I did a quick look at all the uses of RecentGlobalXmin in the back
> branches, and I think we might be all right before 8.2. The older
> branches do in fact init RecentGlobalXmin to InvalidTransactionId,
> and the only thing they use it for is "is this tuple dead to everyon
I wrote:
> Yeah, this looks like exactly what I had in mind for HEAD. I'm not too
> sure about the back branches though. I think we could apply all of it
> to 8.3, but further back is going to require a separate investigation
> for each branch. Will you take that on?
BTW, I did a quick look at
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Anyway I think we are on the same page about the rest of the issues.
> >> Did you want to work on fixing them, or shall I?
>
> > Is this more or less what you had in mind?
>
> Yeah, this looks like exactly what
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Anyway I think we are on the same page about the rest of the issues.
>> Did you want to work on fixing them, or shall I?
> Is this more or less what you had in mind?
Yeah, this looks like exactly what I had in mind for HEAD. I'm not
On Wed, 2008-09-10 at 16:11 -0400, Tom Lane wrote:
> If there were a serious performance argument against that, then yeah,
> but I don't see one.
Maybe! Just finishing other patch then I'll be starting Hot Standby
discussions, so we'll see.
--
Simon Riggs www.2ndQuadrant.com
Postgre
Tom Lane wrote:
> Sorry, I got a bit confused there. The vacuum's intentional pruning
> will use its own OldestXmin variable, which is known current at the
> start of the vacuum (and I think there were even proposals to advance
> it more frequently than that). However, a vacuum could require som
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2008-09-10 at 11:52 -0400, Tom Lane wrote:
>> I'm thinking that maybe an appropriate fix is to insert a
>> GetTransactionSnapshot call at the beginning of InitPostgres'
>> transaction, thus ensuring that every backend has some vaguely sane
>> value
On Wed, 2008-09-10 at 11:52 -0400, Tom Lane wrote:
> I'm thinking that maybe an appropriate fix is to insert a
> GetTransactionSnapshot call at the beginning of InitPostgres'
> transaction, thus ensuring that every backend has some vaguely sane
> value for RecentGlobalXmin before it tries to do a
Alvaro Herrera wrote:
I didn't know we were doing HOT pruning during vacuum; does
it make sense?
Removing HOT-updated, dead tuples is a bit complicated. It needs to be
done one HOT-chain at a time, and the root line pointer needs to be
updated to the next live tuple in the chain. lazy_scan_he
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm worried about keeping RecentGlobalXmin up to date during the
>> vacuums, not only at the end, because it will be used for HOT page
>> pruning during the vacuums.
> Oh, I see. I didn't know we were doing HOT pruning during vacuum;
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Lastly, now that we have the PROC_IN_VACUUM test in GetSnapshotData,
> >> is it actually necessary for lazy vacuum to avoid setting a snapshot?
> >> It seems like it might be a good idea for it to do so in order
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I observed a curious bug in autovac just now. ...
> Maybe we should boot RecentGlobalXmin with InvalidOid, and ensure where
> it's going to be used that it's not that.
Good idea --- an Assert at the use sites should be sufficient.
Tom Lane wrote:
> I observed a curious bug in autovac just now. Since plain vacuum avoids
> calling GetTransactionSnapshot, an autovac worker that happens not to
> analyze any tables will never call GetTransactionSnapshot at all.
> This means it will arrive at vac_update_datfrozenxid with
> Recent
16 matches
Mail list logo
