Skip site navigation (1) Skip section navigation (2)

pgsql: Clean up smgr.c/md.c APIs as per discussion a couple months ago.

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Clean up smgr.c/md.c APIs as per discussion a couple months ago.
Date: 2007-01-03 18:11:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committers
Log Message:
Clean up smgr.c/md.c APIs as per discussion a couple months ago.  Instead of
having md.c return a success/failure boolean to smgr.c, which was just going
to elog anyway, let md.c issue the elog messages itself.  This allows better
error reporting, particularly in cases such as "short read" or "short write"
which Peter was complaining of.  Also, remove the kluge of allowing mdread()
to return zeroes from a read-beyond-EOF: this is now an error condition
except when InRecovery or zero_damaged_pages = true.  (Hash indexes used to
require that behavior, but no more.)  Also, enforce that mdwrite() is to be
used for rewriting existing blocks while mdextend() is to be used for
extending the relation EOF.  This restriction lets us get rid of the old
ad-hoc defense against creating huge files by an accidental reference to
a bogus block number: we'll only create new segments in mdextend() not
mdwrite() or mdread().  (Again, when InRecovery we allow it anyway, since
we need to allow updates of blocks that were later truncated away.)
Also, clean up the original makeshift patch for bug #2737: move the
responsibility for padding relation segments to full length into md.c.

Modified Files:
        hashpage.c (r1.61 -> r1.62)
        nbtsort.c (r1.107 -> r1.108)
        tablecmds.c (r1.208 -> r1.209)
        md.c (r1.123 -> r1.124)
        smgr.c (r1.101 -> r1.102)
        smgr.h (r1.55 -> r1.56)

pgsql-committers by date

Next:From: Tom LaneDate: 2007-01-03 18:57:19
Subject: pgsql: Fix btree_gist for new larger money type.
Previous:From: Bruce MomjianDate: 2007-01-03 14:35:25
Subject: pgsql: Attempt to return proper overflow/underflow messages for

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group