On Wed, Dec 15, 2010 at 4:06 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Sat, 2010-11-13 at 20:55 -0500, Robert Haas wrote:
>> I think that would be a recipe for bugs. Look at the three new macros
>> I introduced. If you keep relistemp around, then any code which
>> relies on it is likely testing for one of those three things, or maybe
>> even something subtly different from any of them, as in the cases
>> where I needed to add a switch statement. The way I see it, this is
>> ultimately a four-level hierarchy
>
> That argument isn't clear enough to avoid me agreeing so far with Tom
> and Andrew that logged-ness is separate from temp-ness. As you say
> though, it might be a recipe for bugs, so please explain a little more.
Sure. Most of the existing checks for rd_istemp were actually
checking whether the relation required WAL-logging. If there's any
third-party code out there that is checking rd_istemp, it likely also
needs to be revised to check whether WAL-logging is needed, not
whether the relation is temp. The way I've coded it, such code will
fail to compile, and can be very easily fixed by substituting a call
to RelationNeedsWAL() or RelationUsesLocalBuffers() or
RelationUsesTempNamespace(), depending on which property the caller
actually cares about. That's better than having the code compile, but
then not work as expected.
As of today, RelationNeedsWAL() always gives an answer which is
directly opposite to the answer given by RelationUsesLocalBuffers()
and RelationUsesTempNamespace(). But the main unlogged tables patch
changes that. RelationNeedsWAL() will return true for permanent
tables and false for unlogged and temp tables, while
RelationUsesLocalBuffers() and RelationUsesTempNamespace() will return
false for permanent and unlogged tables and true for temp tables.
When and if we get global temporary tables, there will be a further
split between RelationUsesLocalBuffers() and
RelationUsesTempNamespace(). The former will return true for both
global and local temporary tables, and the latter only for local
temporary tables.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company