Streaming replication, loose ends
in [PgSql]
|
From: Tom Lane on 15 Jan 2010 11:03 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Yep. What's happening is that "make -j" starts building libpq and > walreceiver.so simultaneously, because of the above line in the > Makefile. We actually have the same problem in src/bin/*/Makefile, but > we don't notice it there because src/interfaces is listed before src/bin > in src/Makefile, so when you do "make -j" at the top-level, libpq is > built first. I'm actually fairly uncomfortable with the notion that something buried deep within the src/backend tree is going to reach over and cause libpq to get built. Maybe the real answer is that you put walreceiver in the wrong place, and it ought to be under src/bin/. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 15 Jan 2010 11:47 Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: >> Yep. What's happening is that "make -j" starts building libpq and >> walreceiver.so simultaneously, because of the above line in the >> Makefile. We actually have the same problem in src/bin/*/Makefile, but >> we don't notice it there because src/interfaces is listed before src/bin >> in src/Makefile, so when you do "make -j" at the top-level, libpq is >> built first. > > I'm actually fairly uncomfortable with the notion that something buried > deep within the src/backend tree is going to reach over and cause libpq > to get built. Maybe the real answer is that you put walreceiver in the > wrong place, and it ought to be under src/bin/. That feels even more wrong to me. Walreceiver is a postmaster subprocess, tightly integrated with the rest of the backend. One can argue that it shouldn't be, and walreceiver process should call libpq through some new API, and the builtin implementation of that API which uses libpq would be a loadable module that could be in src/bin/ or contrib. Greg Stark requested that earlier. But I don't want to start designing such an API at this point. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 15 Jan 2010 12:00 On Fri, Jan 15, 2010 at 11:47 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Tom Lane wrote: >> Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: >>> Yep. What's happening is that "make -j" starts building libpq and >>> walreceiver.so simultaneously, because of the above line in the >>> Makefile. We actually have the same problem in src/bin/*/Makefile, but >>> we don't notice it there because src/interfaces is listed before src/bin >>> in src/Makefile, so when you do "make -j" at the top-level, libpq is >>> built first. >> >> I'm actually fairly uncomfortable with the notion that something buried >> deep within the src/backend tree is going to reach over and cause libpq >> to get built. Maybe the real answer is that you put walreceiver in the >> wrong place, and it ought to be under src/bin/. > > That feels even more wrong to me. Walreceiver is a postmaster > subprocess, tightly integrated with the rest of the backend. The major problem with having one part of the tree depend on a completely different part of the tree is that it's easy for the dependencies to be wrong. If the backend depends on libpq, then it depends implicitly on all the things on which libpq depends. If something that libpq depends on, but that the backend does not depend on directly, gets updated, does the backend get rebuilt? It's easy to get this wrong. On the other hand, it's also possible to get it right. If we can decide what we want to happen, I'm willing to take a crack at it, though if you or Tom or Peter prefer to do it that is certainly OK with me too. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 15 Jan 2010 12:03 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Tom Lane wrote: >> I'm actually fairly uncomfortable with the notion that something buried >> deep within the src/backend tree is going to reach over and cause libpq >> to get built. Maybe the real answer is that you put walreceiver in the >> wrong place, and it ought to be under src/bin/. > That feels even more wrong to me. Walreceiver is a postmaster > subprocess, tightly integrated with the rest of the backend. [ shrug... ] pg_dump, to take one example, is considerably more "tightly integrated" with the backend than walreceiver is. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 15 Jan 2010 12:07 Robert Haas wrote: > On Fri, Jan 15, 2010 at 11:47 AM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> Tom Lane wrote: >>> Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: >>>> Yep. What's happening is that "make -j" starts building libpq and >>>> walreceiver.so simultaneously, because of the above line in the >>>> Makefile. We actually have the same problem in src/bin/*/Makefile, but >>>> we don't notice it there because src/interfaces is listed before src/bin >>>> in src/Makefile, so when you do "make -j" at the top-level, libpq is >>>> built first. >>> I'm actually fairly uncomfortable with the notion that something buried >>> deep within the src/backend tree is going to reach over and cause libpq >>> to get built. Maybe the real answer is that you put walreceiver in the >>> wrong place, and it ought to be under src/bin/. >> That feels even more wrong to me. Walreceiver is a postmaster >> subprocess, tightly integrated with the rest of the backend. > > The major problem with having one part of the tree depend on a > completely different part of the tree is that it's easy for the > dependencies to be wrong. If the backend depends on libpq, then it > depends implicitly on all the things on which libpq depends. If > something that libpq depends on, but that the backend does not depend > on directly, gets updated, does the backend get rebuilt? The backend doesn't get rebuilt, and it doesn't need to be. The fact that walreceiver is a dynamically loaded module should isolate changes in libpq or its dependencies from affecting the rest of the backend. I moved the line for src/backend/replication/walreceiver in src/Makefile further down, after src/interfaces. That should fix the build failures for now, but I'm all ears if there's better suggestions. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: attoptions Next: [HACKERS] missing data in information_schema grant_* tables? |