Alvaro Herrera wrote:
> Here is a patch pursuant to there ideas. The main change is that in
> GetSnapshotData, a backend is skipped entirely if inVacuum is found to
> be true.
Patch applied.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company -
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> But the patch changes things so that *everyone* excludes the vacuum from
> >> their xmin. Or at least I thought that was the plan.
>
> > We shouldn't do that, because that Xmin is also used to truncate
> > SUBTR
Jim Nasby wrote:
> On Jul 28, 2006, at 5:05 PM, Hannu Krosing wrote:
> >So instead of actually *solving* one problem you suggest *thinking*
> >about solving the general case ?
> >
> >We have been *thinking* about dead-space-map for at least three
> >years by now.
>
> No, I just wanted anyone who
On Jul 28, 2006, at 5:05 PM, Hannu Krosing wrote:
Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby:
There are other transactions to consider: user transactions that will
run a long time, but only hit a limited number of relations. These
are
as big a problem in an OLTP enviro
Ühel kenal päeval, R, 2006-07-28 kell 12:38, kirjutas Jim C. Nasby:
> On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote:
> > > The other POV is that we don't really care about long-running
> > > transaction in other databases unless they are lazy vacuum, a case which
> > > is appropiate
[EMAIL PROTECTED] ("Jim C. Nasby") writes:
> There are other transactions to consider: user transactions that will
> run a long time, but only hit a limited number of relations. These are
> as big a problem in an OLTP environment as vacuum is.
>
> Rather than coming up with machinery that will spec
On Fri, Jul 28, 2006 at 03:08:08AM +0300, Hannu Krosing wrote:
> > The other POV is that we don't really care about long-running
> > transaction in other databases unless they are lazy vacuum, a case which
> > is appropiately covered by the patch as it currently stands. This seems
> > to be the PO
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> But the patch changes things so that *everyone* excludes the vacuum from
>> their xmin. Or at least I thought that was the plan.
> We shouldn't do that, because that Xmin is also used to truncate
> SUBTRANS.
Yeah, but you were going
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Uh, why?
> Because it's used to determine the Xmin that our vacuum will use. If
> there is a transaction whose Xmin calculation included the Xid of a
> transaction running vacuum, we have gained nothing from directly
> excluding said
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Uh, why?
>
> > Because it's used to determine the Xmin that our vacuum will use. If
> > there is a transaction whose Xmin calculation included the Xid of a
> > transaction running vacuum, we have gained nothing
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Good question. Imagine you have a serializable transaction like
> > pg_dump, and then you have lots of newer transactions. If pg_dump is
> > xid=12, and all the new transactions start at xid=30, any row created
> > and expired betwee
Hannu Krosing wrote:
> ?hel kenal p?eval, N, 2006-07-27 kell 22:05, kirjutas Bruce Momjian:
> > Another idea Jan had today was whether we could vacuum more rows if a
> > long-running backend is in serializable mode, like pg_dump.
>
> I don't see how this gives us ability to vacuum more rows, as th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Good question. Imagine you have a serializable transaction like
> pg_dump, and then you have lots of newer transactions. If pg_dump is
> xid=12, and all the new transactions start at xid=30, any row created
> and expired between 12 and 30 can be removed
Ühel kenal päeval, N, 2006-07-27 kell 22:05, kirjutas Bruce Momjian:
> Another idea Jan had today was whether we could vacuum more rows if a
> long-running backend is in serializable mode, like pg_dump.
I don't see how this gives us ability to vacuum more rows, as the
snapshot of a serializable tr
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
> >> version of the computation?
>
> > Hmm, not useless at all really -- only a bug of mine. Turns out the
> > notInVacuumXmin stuff is essenti
Another idea Jan had today was whether we could vacuum more rows if a
long-running backend is in serializable mode, like pg_dump.
---
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> nonI
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
>> version of the computation?
> Hmm, not useless at all really -- only a bug of mine. Turns out the
> notInVacuumXmin stuff is essential, so I put it back.
Uh, why
Ühel kenal päeval, N, 2006-07-27 kell 19:29, kirjutas Alvaro Herrera:
>
> We could either add it anew, beside nonInVacuumXmin, or replace
> nonInVacuumXmin. The difference will be whether we will have something
> to be used to vacuum shared relations or not. I think in general,
> shared relatio
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Hannu Krossing asked me about his patch to ignore transactions running
> > VACUUM LAZY in other vacuum transactions. I attach a version of the
> > patch updated to the current sources.
>
> nonInVacuumXmin seems useless ... perhaps a
19 matches
Mail list logo
