Streaming replication and non-blocking I/O
in [PgSql]
|
Prev: Sought after architectures for the PostgreSQL buildfarm?
Next: [HACKERS] 答复: questions about concurrency control in Postgresql
From: Andrew Dunstan on 15 Jan 2010 14:48 Heikki Linnakangas wrote: > Do people still use MinGW for any real work? Could we just drop > walreceiver support from MinGW builds? > > Or maybe we should consider splitting walreceiver into two parts after > all. Only the bare minimum that needs to access libpq would go into the > shared object, and the rest would be linked with the backend as usual. > > I use MinGW when doing Windows work (e.g. the threading piece in parallel pg_restore). And I think it is generally desirable to be able to build on Windows using an open source tool chain. I'd want a damn good reason to abandon its use. And I don't like the idea of not supporting walreceiver on it either. Please find another solution if possible. cheers andrew -- 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: Magnus Hagander on 15 Jan 2010 14:51 2010/1/15 Andrew Dunstan <andrew(a)dunslane.net>: > > > Heikki Linnakangas wrote: >> >> Do people still use MinGW for any real work? Could we just drop >> walreceiver support from MinGW builds? >> >> Or maybe we should consider splitting walreceiver into two parts after >> all. Only the bare minimum that needs to access libpq would go into the >> shared object, and the rest would be linked with the backend as usual. >> >> > > I use MinGW when doing Windows work (e.g. the threading piece in parallel pg_restore). And I think it is generally desirable to be able to build on Windows using an open source tool chain. I'd want a damn good reason to abandon its use. And I don't like the idea of not supporting walreceiver on it either. Please find another solution if possible. > Yeah. FWIW, I don't use mingw do do any windows development, but definitely +1 on working hard to keep support for it if at all possible. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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: Heikki Linnakangas on 15 Jan 2010 15:19 Magnus Hagander wrote: > 2010/1/15 Andrew Dunstan <andrew(a)dunslane.net>: >> >> Heikki Linnakangas wrote: >>> Do people still use MinGW for any real work? Could we just drop >>> walreceiver support from MinGW builds? >>> >>> Or maybe we should consider splitting walreceiver into two parts after >>> all. Only the bare minimum that needs to access libpq would go into the >>> shared object, and the rest would be linked with the backend as usual. >>> >> I use MinGW when doing Windows work (e.g. the threading piece in parallel pg_restore). And I think it is generally desirable to be able to build on Windows using an open source tool chain. I'd want a damn good reason to abandon its use. And I don't like the idea of not supporting walreceiver on it either. Please find another solution if possible. > > Yeah. FWIW, I don't use mingw do do any windows development, but > definitely +1 on working hard to keep support for it if at all > possible. Ok. I'll look at splitting walreceiver code between the shared module and backend binary slightly differently. At first glance, it doesn't seem that hard after all, and will make the code more modular anyway. -- 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: Tom Lane on 15 Jan 2010 15:25 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Magnus Hagander wrote: >> Yeah. FWIW, I don't use mingw do do any windows development, but >> definitely +1 on working hard to keep support for it if at all >> possible. > Ok. I'll look at splitting walreceiver code between the shared module > and backend binary slightly differently. At first glance, it doesn't > seem that hard after all, and will make the code more modular anyway. This is probably going in the wrong direction. There is no good reason why that module should be failing to link, and I don't think it's going to be "more modular" if you're forced to avoid any global variable references at all in some arbitrary portion of the code. I think it's a tools/build process problem and should be attacked that way. 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: Aidan Van Dyk on 15 Jan 2010 15:27
* Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> [100115 15:20]: > Ok. I'll look at splitting walreceiver code between the shared module > and backend binary slightly differently. At first glance, it doesn't > seem that hard after all, and will make the code more modular anyway. Maybe an insane question, but why can postmaster just not "exec" walreceiver? I mean, because of windows, we already have that code around, and then walreceiver could link directly to libpq and not have to worry at all about linking all of postmaster backends to libpq... But I do understand that's a radical change... a. -- Aidan Van Dyk Create like a god, aidan(a)highrise.ca command like a king, http://www.highrise.ca/ work like a slave. |