Horton

Re: ALTER TABLE lock strength reduction patch is unsafe

Alvaro Herrera <alvherre@commandprompt.com>

View thread
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-17T20:41:08Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add bytea_agg, parallel to string_agg.

  2. Fix ALTER TABLE ONLY .. DROP CONSTRAINT.

Excerpts from Tom Lane's message of vie jun 17 13:22:40 -0400 2011:

> With this approach, we would have no serialization anomalies from single
> transactions committing while a scan is in progress.  There could be
> anomalies resulting from considering an earlier XID to be in-progress
> while a later XID is considered committed (because we didn't observe
> it until later).  So far as I can see offhand, the impact of that would
> be that there might be multiple versions of a tuple that are considered
> good, but never that there would be no version considered good (so long
> as the other XIDs simply updated the tuple and didn't delete it).  I
> think this would be all right, since the scan would just seize on the
> first good version it finds.  As you argue above, if that's not good
> enough for our purposes then the updater(s) should have taken a stronger
> lock.

Hmm, would there be a problem if a scan on catalog A yields results from
supposedly-running transaction X but another scan on catalog B yields
result from transaction Y? (X != Y)  For example, a scan on pg_class
says that there are N triggers but scanning pg_trigger says N-1?

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support