Re: Patch: Write Amplification Reduction Method (WARM)

Pavan Deolasee <pavan.deolasee@gmail.com>

From: Pavan Deolasee <pavan.deolasee@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Jaime Casanova <jaime.casanova@2ndquadrant.com>, Haribabu Kommi <kommi.haribabu@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-04-05T02:21:17Z
Lists: pgsql-hackers
On Thu, Mar 30, 2017 at 7:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:

>  but
> try to access the TOAST table would be fatal; that probably would have
> deadlock hazards among other problems.


Hmm. I think you're right. We could make a copy of the heap tuple, drop the
lock and then access TOAST to handle that. Would that work?

Thanks,
Pavan

-- 
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Implement SortSupport for macaddr data type

  2. Simplify check of modified attributes in heap_update

  3. Remove direct uses of ItemPointer.{ip_blkid,ip_posid}

  4. Fix CatalogTupleInsert/Update abstraction for case of shared indstate.

  5. Provide CatalogTupleDelete() as a wrapper around simple_heap_delete().

  6. Band-aid fix for incorrect use of view options as StdRdOptions.

  7. Update visibility map in the second phase of vacuum.

  8. Avoid having two copies of the HOT-chain search logic.

  9. Postgres95 1.01 Distribution - Virgin Sources