From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans handling |
Date: | 2004-08-25 11:29:57 |
Message-ID: | 412C7835.7080102@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On 8/25/2004 1:32 AM, Greg Stark wrote:
> A dirty read is a read that includes data that hasn't been committed yet. Or
> as the SQL 92 standard puts it:
[...]
> It could also be useful for referential integrity checks since, for example,
> it would let you see if someone has deleted the referenced record but not
> committed the delete yet.
>
> But that alone wouldn't let you avoid locking the record, TODO items are
> mostly just pointers to old threads on the mailing lists. They don't contain
> the complete story. You could maybe find more information searching the
> pgsql-hackers archive on the web site.
Plus ... wouldn't doing the "on delete" lookup as dirty reads let
referencing rows that have been deleted but still could come back
through a rollback disappear? What you want to see are new tuples of
uncommitted insert/update as well as old tuples of uncommitted
delete/update. I don't think there is any term in the standard for that
read mode, so we should call it dusty-reads because they see everything
vacuum is interested in.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2004-08-25 14:18:52 | Re: pgsql-server: Add ALTER INDEX, particularly for |
Previous Message | Gavin Sherry | 2004-08-25 06:00:49 | Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans |
From | Date | Subject | |
---|---|---|---|
Next Message | ffffceffffac ffffbdffffaa | 2004-08-25 11:47:08 | Re: server crash in very big transaction [postgresql 8.0beta1] |
Previous Message | Gavin Sherry | 2004-08-25 06:00:49 | Re: [COMMITTERS] pgsql-server: Rearrange pg_subtrans |