Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-14 Thread Alvaro Herrera
Robert Haas wrote: > On Tue, Feb 14, 2017 at 2:54 PM, Andres Freund wrote: > >> Thoughts, comments, objections, better ideas? > > > > No better ideas. I'm a bit concerned about declarations needed both by > > normal and xlog related routines, but I guess that can be solved by

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-14 Thread Robert Haas
On Tue, Feb 14, 2017 at 2:54 PM, Andres Freund wrote: >> Thoughts, comments, objections, better ideas? > > No better ideas. I'm a bit concerned about declarations needed both by > normal and xlog related routines, but I guess that can be solved by a > third header as you did.

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-14 Thread Andres Freund
Hi, On 2017-02-13 22:42:00 -0500, Robert Haas wrote: > I dug into the problem and discovered that pg_waldump is slurping up a > tremendous crapload of backend headers. It includes gin.h, > gist_private.h, hash_xlog.h, nbtree.h, and spgist.h, which all end up > including amapi.h, which includes

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-14 Thread Robert Haas
On Tue, Feb 14, 2017 at 8:15 AM, Fabien COELHO wrote: >> I believe that what was agreed was to eliminate "xlog" from >> user-facing parts of the system, not internal details. [...] > Ok, I get it. So xlog stays xlog if it is hidden from the user, eg file > names and probably

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-14 Thread Fabien COELHO
I believe that what was agreed was to eliminate "xlog" from user-facing parts of the system, not internal details. [...] Ok, I get it. So xlog stays xlog if it is hidden from the user, eg file names and probably unexposed functions names, structures or whatever, but everything else has been

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-14 Thread Robert Haas
On Tue, Feb 14, 2017 at 2:45 AM, Fabien COELHO wrote: >> You may want to name the new headers dedicated to WAL records with _xlog.h >> as suffix though, like gin_xlog.h instead of ginxlog.h. > > Should not it be more consistent to use "*_wal.h", after all these efforts > to

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-14 Thread Robert Haas
On Tue, Feb 14, 2017 at 12:23 AM, Michael Paquier wrote: > On Tue, Feb 14, 2017 at 12:42 PM, Robert Haas wrote: >> Therefore, I proposed the attached patch, which splits spgxlog.h out >> of spgist_private.h, nbtxlog.h out of nbtree.h, gistxlog.h

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-13 Thread Fabien COELHO
You may want to name the new headers dedicated to WAL records with _xlog.h as suffix though, like gin_xlog.h instead of ginxlog.h. Should not it be more consistent to use "*_wal.h", after all these efforts to move "xlog" to "wal" everywhere? -- Fabien. -- Sent via pgsql-hackers mailing

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-13 Thread Michael Paquier
On Tue, Feb 14, 2017 at 12:42 PM, Robert Haas wrote: > Therefore, I proposed the attached patch, which splits spgxlog.h out > of spgist_private.h, nbtxlog.h out of nbtree.h, gistxlog.h out of > gist_private.h, and ginxlog.h and ginblock.h out of gin_private.h. > These new

[HACKERS] pg_waldump's inclusion of backend headers is a mess

2017-02-13 Thread Robert Haas
Dilip complained on another thread about the apparent difficulty of getting the system to compile after adding a reference to dsa_pointer to tidbitmap.c: https://www.postgresql.org/message-id/CAFiTN-u%3DBH_b0QE9FG%2B%2B_Ht6Q%3DF84am%3DJ-rt7fNbQkq3%2BqX3VQ%40mail.gmail.com I dug into the problem