I wrote:
> But I'll happily concede the point, and prove it by knocking
> up a patch for it over the weekend (unless anyone else
> particularly wants to).
Occurs to me I could kill 2 birds with one stone, and also implement another
Win32 sticking point, namely the waitpid changes for the Postma
Claudio Natoli wrote:
>
> I wrote:
> > But I'll happily concede the point, and prove it by knocking
> > up a patch for it over the weekend (unless anyone else
> > particularly wants to).
>
> Occurs to me I could kill 2 birds with one stone, and also implement another
> Win32 sticking point, nam
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As I understand it, the postmaster shared memory idea is good because
> only the postmaster writes to it, and only the backends read from it.
> If the HANDLE works the same way, I think you should put it into the
> shared memory too, hence (b).
But the
[EMAIL PROTECTED] wrote:
> Updated italian po file for psql-current.
Installed.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> Updated italian po file for pg_dump-current.
Installed.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As I understand it, the postmaster shared memory idea is good because
> > only the postmaster writes to it, and only the backends read from it.
> > If the HANDLE works the same way, I think you should put it into the
> > shared memory
Bruce Momjian writes:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > As I understand it, the postmaster shared memory idea is good because
> > > only the postmaster writes to it, and only the backends read from it.
> > > If the HANDLE works the same way, I think you should p
Patch applied. Thanks.
---
Claudio Natoli wrote:
>
> For application to HEAD, pending community review.
>
> Drops in the CreateProcess calls for Win32 (essentially wrapping up the
> fork/exec portion of the port), and fi
