pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <jdavis@postgresql.org>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Logical Tape Set: lazily allocate read buffer.
Date: Tue, 18 Feb 2020 13:25:52 -0800
Message-ID: <96262b6442f8f752f42b50e9cc8ee69e0d9b43fc.camel@j-davis.com> (raw)
In-Reply-To: <20351.1581868306@sss.pgh.pa.us>
References: <E1j2JUY-0001ik-Cc@gemulon.postgresql.org>
	<20351.1581868306@sss.pgh.pa.us>

On Sun, 2020-02-16 at 10:51 -0500, Tom Lane wrote:
> Is there a reason for that to be coded in such an obscure and fragile
> fashion, rather than having the test be say "if (lt->buffer ==
> NULL)"?

I did that to match the original behavior, which is to only allocate
the read buffer if the tape is non-empty.

A tape with a NULL buffer is in a valid state after a rewind, though
it's precarious. It raises quite a few questions about what the valid
states of a tape are, and what usages of the API are allowed. That was
all true even before 7fdd919a (or perhaps I made a mistake and moving
the code around was not safe after all).

I think the best fix now is to just allocate the buffer even if the
tape is empty. That would stop Coverity from complaining, and I
couldn't detect any obvious performance regression.

Later, we can document the valid states a little better, and validate
them with Asserts and/or the type system.

Regards,
	Jeff Davis







view thread (3+ messages)

Message-ID: <96262b6442f8f752f42b50e9cc8ee69e0d9b43fc.camel@j-davis.com>
Permalink:  ../96262b6442f8f752f42b50e9cc8ee69e0d9b43fc.camel@j-davis.com/
Also on:    postgresql.org/message-id/96262b6442f8f752f42b50e9cc8ee69e0d9b43fc.camel@j-davis.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-committers@postgresql.org
  Cc: pgsql@j-davis.com, tgl@sss.pgh.pa.us, jdavis@postgresql.org, pgsql-committers@lists.postgresql.org
  Subject: Re: pgsql: Logical Tape Set: lazily allocate read buffer.
  In-Reply-To: <96262b6442f8f752f42b50e9cc8ee69e0d9b43fc.camel@j-davis.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox