| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Steeve Lennmark <steevel(at)handeldsbanken(dot)se>, Andreas Karlsson <andreas(at)proxel(dot)se>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Relocation of tablespaces in pg_basebackup |
| Date: | 2014-01-16 14:30:53 |
| Message-ID: | 20140116143053.GC4498@alap3.lan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2014-01-16 11:25:59 -0300, Alvaro Herrera wrote:
> Eyeballing this patch, three thoughts:
>
> 1. I wonder whether ilist.c/h should be moved to src/common so that
> frontend code could use it.
Sounds like a good idea. There's some debugging checks that elog, but
that should be fixable easily.
> 2. I wonder whether ilist.c should gain the ability to have
> singly-linked lists with a pointer to the tail node for appending to the
> end. This code would use it, and also the code doing postgresql.conf
> parsing which has head/tail pointers all over the place. I'm sure there
> are other uses.
I am not generaly adverse to it, but neither of those usecases seems to
warrant that. They just should use a doubly linked list, it's not like
the memory/runtime overhead is significant. And the implementation
overhead doesn't count either if they use ilist.h.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-01-16 14:34:51 | Re: Changeset Extraction v7.0 (was logical changeset generation) |
| Previous Message | Alvaro Herrera | 2014-01-16 14:25:59 | Re: [PATCH] Relocation of tablespaces in pg_basebackup |