Re: Preliminary patch for FRONTEND
От | Bruce Momjian |
---|---|
Тема | Re: Preliminary patch for FRONTEND |
Дата | |
Msg-id | 200410011220.i91CKnX21626@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Preliminary patch for FRONTEND ("Magnus Hagander" <mha@sollentuna.net>) |
Список | pgsql-patches |
Magnus Hagander wrote: > > > The following patch addresses this issue by making libpgport usable > > > unchanged by client applications, and makes a special > > server version > > > for the backend. > > > > This raises some alarm bells for me. Why does a "port > > support" library need to distinguish whether it is running in > > frontend or backend? > > Just from the problems I've seen with several modules - ereport(). > Several functions use ereport() if !FRONTEND and something else if > FRONTEND. > > I've seen this problem several times when trying to compile things "out > of sync". The main issue is that the port stuff behave differently, > certainly. I originally thought the deal was that anything that relied > on backend stuff would go in backend/port, but there are (and has been > since before I started looking at it) several files in /port/ taht rely > heavily on functions and variables in the backend. The basic issue is ereport and memory allocation for dirmod, ereport for exec.c, thread-safety for getaddrinfo and thread.c. I can't think of how to cleanly abstract them so the backend and libpq have compatibile versions to call so I can use the same object file, so I made new libraries. And as Magnus has pointed out, they do get out of sync too easily without this cleanup. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: