On Jan 29, 2007, at 11:28 PM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
I don't actually see that it buys you a darn thing ... you still
won't
be able to delete dead updated tuples because of the possibility of
the LRT deciding to chase ctid chains up from the tuples it can see.
Well, Simon was talking about a serialized LRT, which ISTM shouldn't
be hunting down ctid chains past the point it serialized at.
How you figure that? If the LRT wants to update a tuple, it's got to
chase the ctid chain to see whether the head update committed or not.
It's not an error for a serializable transaction to update a tuple
that
was tentatively updated by a transaction that rolled back.
Nuts. :(
Even if that's not the case, there is also the possibility if a LRT
publishing information about what tables it will hit.
I think we already bought 99% of the possible win there by fixing
vacuum. Most ordinary transactions aren't going to be able to predict
which other tables the user might try to touch.
Presumably a single-statement transaction could do that in most (if
not all) cases.
But even if we didn't support automatically detecting what tables a
transaction was hitting, we could allow the user to specify it and
then bomb out if the transaction tried to hit anything that wasn't in
that list. That would allow users who are creating LRTs to limit
their impact on vacuum. The safe way to perform that check would be
to check each buffer before accessing it, but I'm unsure how large a
performance impact that would entail; I don't know how much code we
run through to pull a tuple out of a page and do something with it
compared to the cost of checking if that buffer belongs to a relation/
file that's in the "approved list".
Perhaps a better way would be to allow users to mark vacuum-critical
tables for "restricted" access. To access a restricted table the user
would need to provide a list of restricted tables that a transaction
is going to hit (or maybe just lump all restricted tables into one
group), and that transaction would log it's XID somewhere that vacuum
can look at. If a transaction that hasn't specified it will touch the
restricted tables tries to do so it errors out. We might want some
way to flag buffers as belonging to a restricted table (or one of
it's indexes) so that transactions that aren't hitting restricted
tables wouldn't have to pay a large performance penalty to figure
that out. But you'd only have to mark those buffers when they're read
in from the OS, and presumably a restricted table will be small
enough that it's buffers should stay put. Logging the XID could prove
to be a serialization point, but we could possibly avoid that by
using per-relation locks.
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
