On Thu, 2007-02-15 at 10:49 +, Heikki Linnakangas wrote:
> Do we actually ever want to remove dead tuples from the middle of the
> chain? If a tuple in the middle of the chain is dead, surely every tuple
> before it in the chain is dead as well, and we want to remove them as
> well. I'm thi
On Fri, 2007-02-16 at 09:36 +0200, Hannu Krosing wrote:
> Ühel kenal päeval, N, 2007-02-15 kell 10:49, kirjutas Heikki
> Linnakangas:
>
> > We already log tuple removals by normal vacuums. We can't use that wal
> > entry as it is: if a dead tuple is in the middle of an update chain, it
> > needs
Ühel kenal päeval, N, 2007-02-15 kell 10:49, kirjutas Heikki
Linnakangas:
> We already log tuple removals by normal vacuums. We can't use that wal
> entry as it is: if a dead tuple is in the middle of an update chain, it
> needs to be unlinked from the chain. But I don't see any particular
> pr
On 2/15/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Do we actually ever want to remove dead tuples from the middle of the
chain? If a tuple in the middle of the chain is dead, surely every tuple
before it in the chain is dead as well, and we want to remove them as
well. I'm thinking, remo
Zeugswetter Andreas ADI SD wrote:
I am still wondering about the "easily" here. Basically this
needs some kind of wal entry to be crash safe.
Else some later tx might reuse the slot:
- some update on page produces page image in wal
- slot removed
- slot reused and comit
Bruce Momjian wrote:
> Just to summarize:
>
> o Every tuple gets a heap ctid
> o Only the root tuple gets an index entry
> o We can easily remove dead tuples that aren't the root because
> by definition, nothing points to them, including backends and
> ind
Zeugswetter Andreas ADI SD wrote:
A few assumptions:
no back pointers
indexes only point at slots marked as roots (and non hot tuples)
During vacuum, you swap the tuples and keep a stub at the slot that the
user's ctid might be pointing at. You mark the stub to detect this
situat
On Wed, Feb 14, 2007 at 01:56:03PM -0500, Bruce Momjian wrote:
> Could we insert index tuples for the live tuple and then remove the root
> tuple, perhaps later? So basically we break the chain at that time.
> The problem there is that we basically have nothing better than what we
> have now ---
Just to summarize:
o Every tuple gets a heap ctid
o Only the root tuple gets an index entry
o We can easily remove dead tuples that aren't the root because
by definition, nothing points to them, including backends and
indexes
The problem is that a
> But now that I think of it, how do we get the root tid of a
> tuple? I suppose we'd be back to having backpointers or
> scanning the whole page... I guess pointer-swinging it is, then.
During vacuum you see a root [stub] not recently dead. You follow
the chain to detect if you find a live tu
> What's the verdict on relaxing the "live tuple's ctid doesn't
> change rule"? If we did allow that within a page, what would
> we need to change?
I already said this, but why would this need to be visible from the
outside ?
A few assumptions:
no back pointers
indexes only poi
On 2/14/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> What's the verdict on relaxing the "live tuple's ctid doesn't change
> rule"?
I think that's unacceptable; it is known that that will break the ODBC
and JDBC drivers, as well as any other programs t
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
What's the verdict on relaxing the "live tuple's ctid doesn't change
rule"?
I think that's unacceptable; it is known that that will break the ODBC
and JDBC drivers, as well as any other programs that make use of the
ctid for re-fin
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> What's the verdict on relaxing the "live tuple's ctid doesn't change
> rule"?
I think that's unacceptable; it is known that that will break the ODBC
and JDBC drivers, as well as any other programs that make use of the
ctid for re-finding a tuple th
Pavan Deolasee wrote:
- We need to find a way to handle DEAD root tuples, either convert them
into
stubs or overwrite them with a new version. We can also perform pointer
swinging from the index. Again there are concerns about crash-safety and
concurrent index-scans working properly. We don't ha
This is a WIP patch based on the recent posting by Simon and discussions
thereafter. We are trying to do one piece at a time and intention is to post
the work ASAP so that we could get early and continuous feedback from
the community. We could then incorporate those suggestions in the next
WIP pat
16 matches
Mail list logo
