Re: embedded list

Tom Lane escribió:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Here's the final version.  I think this is ready to go in.
> 
> I got around to reviewing this today.  I'm pretty seriously annoyed at
> the definition of dlist_delete: it should *not* require the list header.
> The present coding simply throws away one of the primary advantages of
> a doubly-linked list over a singly-linked list, namely that you don't
> have to have your hands on the list header in order to unlink a node.
> This isn't merely academic either, as I see that the patch to catcache
> code actually added a field to struct catctup to support making the
> list header available.  That's a complete waste of 8 bytes (on a 64-bit
> machine) per catalog cache entry.  The only thing it buys for us is
> the ability to run dlist_check, which is something that isn't even
> compiled (not even in an Assert build), and which doesn't actually do
> that much useful even if it is compiled --- for instance, there's no way
> to verify that the nodes were actually in the list claimed.

Oops.  I mentioned this explicitely somewhere in the discussion.  I
assumed you had seen that, and that you would have complained had you
found it objectionable.  (It's hard enough to figure out if people don't
respond because they don't have a problem with something, or just
because they didn't see it.)

On the other hand, it's convenient to remove them, because in
predicate.c there are plenty of SHM_QUEUE node removals which is clearly
easier to port over to dlist if we don't have to figure out exactly
which list each node is in.  (Maybe in other SHM_QUEUE users as well,
but that's the most complex of the bunch.)

> I think we should remove the head argument at least from dlist_delete,
> and probably also dlist_insert_after and dlist_insert_before.

There are more functions that get the list head just to run the check.
Can I assume that you don't propose removing the argument from those?
(dlist_next_node, dlist_prev_node I think are the only ones).

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services