Re: Streaming replication and non-blocking I/O
От | Magnus Hagander |
---|---|
Тема | Re: Streaming replication and non-blocking I/O |
Дата | |
Msg-id | 9837222c1001121037o68ef98abs853e621644fed15f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming replication and non-blocking I/O (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Streaming replication and non-blocking I/O
|
Список | pgsql-hackers |
On Tue, Jan 12, 2010 at 17:58, Fujii Masao <masao.fujii@gmail.com> wrote: > On Tue, Dec 22, 2009 at 8:49 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >>> Umm.., I still cannot find the place where the walreceiver module is >>> loaded by using load_external_function() in your 'replication' branch. >>> Also the compilation of that branch fails. Is the 'pushed' branch the >>> latest? Sorry if I'm missing something. >> >> Ah, I see. The changes were not included in the merge commit after all, >> but I had simple forgot to "git add" them. Sorry about that, should be >> there now. > > This change which moves walreceiver process into a dynamically loaded > module caused the following compile error on my MinGW environment. That sounds strange - it should pick those up from the -lpostgres. Any chance you have an old postgres binary around from a non-syncrep build or something? > --------------------------- > > Though I marked the variables shown in the above message as PGDLLIMPORT, > the "make" still fails in the same way. I struggled with this issue > for some time, but > could not fix it yet :( > > Frankly I'm not familiar with that area. So it would be nice if > someone could analyze > this issue. Do you have an environment to try to build it under msvc? in my experience, that gives you easier-to-understand error messages in a lot of cases like this - it removets the mingw black magic. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: