Horton

Re: [PATCH 04/16] Add embedded list interface (header only)

Andres Freund <andres@2ndquadrant.com>

View thread
From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <peter@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-06-22T14:25:01Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Don't waste the last segment of each 4GB logical log file.

  2. Stamp HEAD as 9.3devel.

  3. Wake WALSender to reduce data loss at failover for async commit.

  4. Make the visibility map crash-safe.

On Friday, June 22, 2012 04:18:35 PM Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On Friday, June 22, 2012 12:23:57 AM Peter Geoghegan wrote:
> >> Why are you using the stdlib's <assert.h>? Why have you used the
> >> NDEBUG macro rather than USE_ASSERT_CHECKING? This might make sense if
> >> the header was intended to live in port, but it isn't, right?
> > 
> > That should probably be removed, yes. I did it that way that it could be
> > tested independently of casserts because the list checking code turns
> > some linear algorithms into quadratic ones which is noticeable even when
> > --enable- cassert is defined.
> 
> As far as that goes, I wonder whether the list-checking code hasn't
> long since served its purpose.  Neil Conway put it in when he redid the
> List API to help catch places that were using no-longer-supported hacks;
> but it's been years since I've seen it catch anything.  I suggest that
> we might want to either remove it, or enable it via something other than
> USE_ASSERT_CHECKING (and not enable it by default).
Oh, I and Peter weren't talking about the pg_list.h stuff, it was about my 
'embedded list' implementation which started this subthread. The 
pg_list.h/list.c stuff isn't problematic as far as I have seen in profiles; 
its checks are pretty simple so I do not find that surprising. We might want 
to disable it by default anyway.

In my code the list checking stuff iterates over the complete list after 
modifications and checks that all prev/next pointers are correct so its linear 
in itself...

Andres
-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services