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 fixes a handful of whitespace issues
(that no doubt I'm to blame for; my apologies) in the source base.
Cheers,
Claudio
---
Certain dis
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >>
> >>+ /*
> >>+* We could lose a signal during this test.
> >>+* In a multi-threaded application, this might
> >>+* be a problem. Do any non-threaded platforms
> >>
> Threaded or non-threaded?
OK, yea, I will use th
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >>
> >>+ /*
> >>+* We could lose a signal during this test.
> >>+* In a multi-threaded application, this might
> >>+* be a problem. Do any non-threaded platforms
> >>
> Threaded or non-threaded?
>
> >>+* lack
Zach Irmen wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > Zach Irmen said:
> > > Can I just ifndef WIN32 and not think about it? I'm not sure how that
> > > would work either.
> > >
> >
> > If we are going to have a Windows port I don't think we should treat it as
> > a poor cousin.
>
>
Joshua D. Drake wrote:
>
> >
> >As I remember, MSDOS uses the "~" to specify short versions of long file
> >names.
> >
> I is not just msdos, it is cmd.exe which exists on (to my knowledge) all
> versions of windows. For example:
> Program Files == progra~1
Yes, I meant it is a hold-over from de
Zach Irmen wrote:
> Bruce Momjian wrote:
> > Here is a patch that handles "~" in all the file cases.
>
> Beat me to it. :)
>
> I do have a few issues that I was trying to sort out myself
> regarding this, but I guess now is as good a time as any to ask
> them here.
>
> First off, there should be
As I remember, MSDOS uses the "~" to specify short versions of long file
names.
I is not just msdos, it is cmd.exe which exists on (to my knowledge)
all versions of windows. For example:
Program Files == progra~1
I think that is enough for us to say that we are best leaving
'~' e
Bruce Momjian wrote:
Joshua D. Drake wrote:
As I remember, MSDOS uses the "~" to specify short versions of long file
names.
I is not just msdos, it is cmd.exe which exists on (to my knowledge) all
versions of windows. For example:
Program Files == progra~1
Yes, I meant it is a ho
Hi!
Here is a first sketch at Win32 signal handling. First a couple of
comments:
* This is just two files. It is not integrated with postgresql yet.
* Uses named pipes. Shared mem was slightly faster, named pipes a lot
cleaner. And the signal handlers themselves should not be performance
critica
Claudio Natoli wrote:
Something after 2003/11/20 enhanced the query cancel handling. Namely,
CVS tip now responds to a query cancel with a postmaster restart
canceling all queries. Could the fork/exec stuff be responsible for this?
Jan
Hi Bruce,
Claudio, where are we on this patch? I see an
Andrew Dunstan wrote:
> >>>As I remember, MSDOS uses the "~" to specify short versions of long file
> >>>names.
> >>>
> >>>
> >>>
> >>I is not just msdos, it is cmd.exe which exists on (to my knowledge) all
> >>versions of windows. For example:
> >>Program Files == progra~1
> >>
> >>
> >
"Korea PostgreSQL Users' Group" <[EMAIL PROTECTED]> writes:
> In 7.4.1, intarray module have a problme about equal operator (=).
> select * from table where intarray_column = '{}';
> above query make error.
Good catch. Patch applied --- thanks!
regards, tom lane
--
> Also, do we want this one #ifdef:ed in every place, or just
> #define it to nothing at all on non-windows platforms?
I imagine the latter will be cleaner.
> Anyway. Comments on these points in particular, and in the whole thing in
general? Workable path?
I think it looks great. Well done!
Jan Wieck <[EMAIL PROTECTED]> writes:
> Something after 2003/11/20 enhanced the query cancel handling. Namely,
> CVS tip now responds to a query cancel with a postmaster restart
> canceling all queries. Could the fork/exec stuff be responsible for this?
Whoever changed this:
status = Proces
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Something after 2003/11/20 enhanced the query cancel handling. Namely,
> > CVS tip now responds to a query cancel with a postmaster restart
> > canceling all queries. Could the fork/exec stuff be responsible for this?
>
> Whoever change
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My guess is that this used to proc_exit the postgres backend, but now
> proc_exits the postmaster, but that is only a guess.
No. This is post-fork (and had better remain so). The change causes
the sub-postmaster that has just finished handling a cancel
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My guess is that this used to proc_exit the postgres backend, but now
> > proc_exits the postmaster, but that is only a guess.
>
> No. This is post-fork (and had better remain so). The change causes
> the sub-postmaster that has jus
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My guess is that this used to proc_exit the postgres backend, but now
> > proc_exits the postmaster, but that is only a guess.
>
> No. This is post-fork (and had better remain so). The change causes
> the sub-postmaster that has jus
> Whoever changed this:
My fault. Thanks for the catch Jan.
>proc_exit(status);
Should be proc_exit(0).
My apologies,
Claudio
PS. I take it there is no regression test for this. Would this be a
difficult one to knock up?
---
Certain disclaimers and policies apply to all email sent
Bruce Momjian <[EMAIL PROTECTED]> writes:
> When you say sub-postmaster, you mean we fork, then process the cancel
> request? Seems we might need special handling in there, yea.
We fork before we even read the request. Otherwise an attacker can
trivially lock up the postmaster by sending a parti
> BTW, how are we going to do cancels in Windows-land? The sub-postmaster
> isn't gonna have access to the postmaster's list of child PIDs and
> cancel keys ...
Good question (the Win32/EXEC_BACKEND case is #def'd out to issue an
altogether unhelpful abort(), so I know it is there).
The only t
Tom Lane wrote:
> I've just noticed another serious bit of breakage in CVS tip (though
> this might be fixed by Claudio's pending patch that reverts a lot of
> the code rearrangements).
It's already been applied. Your push in the SubPostmaster direction was
really useful; a lot cleaner, and fixe
Claudio Natoli wrote:
>
> > BTW, how are we going to do cancels in Windows-land? The sub-postmaster
> > isn't gonna have access to the postmaster's list of child PIDs and
> > cancel keys ...
>
> Good question (the Win32/EXEC_BACKEND case is #def'd out to issue an
> altogether unhelpful abort(),
> Claudio Natoli wrote:
>> The only things I've thought of so far are:
>> a) sticking the PID/cancel key list in shared mem [yeech]
>> b) rearranging the entire cancel handling to occur in the postmaster [double
>> yeech]
(a) seems like the lesser of the available evils (unless someone has a
brigh
Tom Lane wrote:
> > Claudio Natoli wrote:
> >> The only things I've thought of so far are:
> >> a) sticking the PID/cancel key list in shared mem [yeech]
> >> b) rearranging the entire cancel handling to occur in the postmaster [double
> >> yeech]
>
> (a) seems like the lesser of the available evi
Bruce Momjian wrote:
Tom Lane wrote:
> Claudio Natoli wrote:
>> The only things I've thought of so far are:
>> a) sticking the PID/cancel key list in shared mem [yeech]
>> b) rearranging the entire cancel handling to occur in the postmaster [double
>> yeech]
(a) seems like the lesser of the availab
Jan Wieck <[EMAIL PROTECTED]> writes:
> It doesn't hurt to keep the locations and code as much in sync as
> possible. I think Tom's idea to move the information into the PGPROC
> entry is the winner and does not need any OS specific handling.
Actually, on further reflection a separate array to s
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
It doesn't hurt to keep the locations and code as much in sync as
possible. I think Tom's idea to move the information into the PGPROC
entry is the winner and does not need any OS specific handling.
Actually, on further reflection a separate
Tom Lane writes:
> Actually, on further reflection a separate array to store PIDs and
cancel keys is probably a better idea.
[snip]
> I still think it's unnecessary to make a separate shmem segment for it,
though.
Why is that? Don't we need the backends to have access to it to do a cancel
reque
Claudio Natoli wrote:
>
> Tom Lane writes:
> > Actually, on further reflection a separate array to store PIDs and
> cancel keys is probably a better idea.
> [snip]
> > I still think it's unnecessary to make a separate shmem segment for it,
> though.
>
> Why is that? Don't we need the backends t
> I think they are saying put the cancel key inside the existing shared
> memory segment.
Ok. Thanks.
> I don't know when we actually attach to the main shared
> memory sigment in the child, but it would have to be sooner than when we
> need the cancel key.
Yes. Currently, it happens too late
Bruce Momjian wrote:
Claudio Natoli wrote:
Tom Lane writes:
> Actually, on further reflection a separate array to store PIDs and
cancel keys is probably a better idea.
[snip]
> I still think it's unnecessary to make a separate shmem segment for it,
though.
Why is that? Don't we need the backend
Claudio Natoli wrote:
>
> > I think they are saying put the cancel key inside the existing shared
> > memory segment.
>
> Ok. Thanks.
>
> > I don't know when we actually attach to the main shared
> > memory sigment in the child, but it would have to be sooner than when we
> > need the cancel k
I have applied your new pipe.c file, the macros you listed (with
modification), and the configure glue to make it work.
Patch and new file attached and applied.
---
Claudio Natoli wrote:
>
> To go in src/port/ directory.
>
I wrote:
> Just to be clear, this would involve turning the BackendList dlllist into
an
> array in shared memory, right? If so, a couple of questions:
Bruce Momjian wrote:
> I assumed a much simpler solution. I thought we would just have:
>
> struct {
> pid_t pid;
>
Claudio Natoli wrote:
>
> I wrote:
> > Just to be clear, this would involve turning the BackendList dlllist into
> an
> > array in shared memory, right? If so, a couple of questions:
>
> Bruce Momjian wrote:
> > I assumed a much simpler solution. I thought we would just have:
> >
> > s
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Just to be clear, this would involve turning the BackendList dlllist into an
> array in shared memory, right? If so, a couple of questions:
Per Jan's comment, there is no need to mess with the existing
datastructure. I'd think more of *copying* the dll
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Uh, why would you need more than maxbackends? Can't it be indexed by
> slot number --- each backend has a slot? Maybe I am missing something.
The postmaster has no way to know what slot number each backend will
get. For that matter, a sub-postmaster d
Tom Lane:
> Per Jan's comment, there is no need to mess with the existing
> datastructure. I'd think more of *copying* the dllist into some array
> in shared memory. This is code that would only need to exist in the
> Windows port.
(I thought Jan was referring to the PGPROC struct)
This just s
Tom Lane wrote:
> I think the simplest way to make this work is to use an array that's
> 2*MaxBackend items long (corresponding to the max number of children the
> postmaster will fork).
Actually, now that I think about it, is even that big enough. There is a
reason BackendList is a list. In
Claudio Natoli wrote:
>
> Tom Lane:
> > Per Jan's comment, there is no need to mess with the existing
> > datastructure. I'd think more of *copying* the dllist into some array
> > in shared memory. This is code that would only need to exist in the
> > Windows port.
>
> (I thought Jan was referr
Bruce Momjian:
> > Tom Lane:
> > > Per Jan's comment, there is no need to mess with the existing
> > > datastructure. I'd think more of *copying* the dllist into some array
> > > in shared memory. This is code that would only need to exist in the
> > > Windows port.
> >
> > (I thought Jan was r
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Tom Lane:
>> Per Jan's comment, there is no need to mess with the existing
>> datastructure. I'd think more of *copying* the dllist into some array
>> in shared memory. This is code that would only need to exist in the
>> Windows port.
> Also, let's g
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think the simplest way to make this work is to use an array that's
>> 2*MaxBackend items long (corresponding to the max number of children the
>> postmaster will fork).
> Actually, now that I think about it, is even that big enou
Claudio Natoli <[EMAIL PROTECTED]> writes:
> I wasn't suggesting that we somehow put the Dllist in shared memory. I was
> advocating completely replacing the BackendList dlllist with this array,
> under both Win32 and *nix case.
Right, that's what I understood you to be proposing, and I dislike it
Tom Lane wrote:
> What it comes down to is I don't want the postmaster to be keeping its
> own state in shared memory --- that is, the array must be write-only
> memory as far as the postmaster is concerned. If we eliminate the
Ok. Well, I can appreciate things from that point of view.
> post
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Actually, if I was going to argue anything, I'd say that if a backend goes
> nuts and zeroes the whole shmem segment you've probably some bigger things
> to worry about (Aside: Would postgres actually recover from such an
> occurence? BTW, I'd be pretty
47 matches
Mail list logo
