Re: crash-safe visibility map, take three

On Thu, Dec 2, 2010 at 6:37 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>> It seems to me that a COPY command executed in a transaction with no
>> other open snapshots writing to a table created or truncated within
>> the same transaction should be able to write frozen tuples from the
>> get-go, regardless of anything else we do.
>
> Well, some transaction might pick up a snapshot between the time you
> begin the copy and the time it commits. We'd need to prevent such a
> transaction from actually reading the table.

Oh, hmm. That's awkward. I guess under present semantics it can see
the table - but not its contents - once the inserting transaction has
committed. That stinks.

>> I don't think it would be appropriate to hold off
>> making the visibility map crash-safe, on the off chance that our
>> design for so doing might complicate something else we want to do
>> later.
>
> I'm not suggesting we hold off on it at all. To the contrary, I'm
> suggesting that we simply log updates of PD_ALL_VISIBLE as well as VM
> bits, at least until a performance problem presents itself. That will
> _simplify_ the design.
>
> Then, when a performance problem does present itself for a certain use
> case, we can see how to fix it. If many cases are affected, then we
> might choose one of these more creative solutions that breaks the rules
> in controlled ways, understanding the trade-offs. If only bulk loading
> is affected, we might choose to address that case directly.

I don't think that you can seriously suggest that emitting that volume
of FPIs isn't going to be a problem immediately. We have to have some
solution to that problem out of the gate.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company