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
When a select/update by ctid comes along it needs to do one step to the
and use that tuple instead.

As Pavan pointed out, that's more or less what he ended up doing originally. You need to mark the stub with the current most recent xid, and wait until that's no longer running. Only after that you can remove the stub.

It needs a second vacuum (or a per page vacuum during update) to remove
the extra stub when it is dead and not recently dead.

Requiring two vacuums to remove the tuple sounds bad at first, but it's actually not so bad since both steps could by done by retail vacuum, or even normal scans while.

I fail to see the hole.

The only potential problem I can see is how to make sure that a heap scan or a bitmap heap scan doesn't visit the tuple twice. If we make sure that the page is scanned in one go while keeping the buffer pinned, we're good. We already do that except for system catalogs, so I believe we'd have to forbid hot updates on system tables, like we forbid bitmap scans.

To me this sounds like the best idea this far.

  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to