On Monday 06 April 2009 02:10:59 James Pye wrote:
> Any thoughts on the acceptability of a complete rewrite for Python 3?
http://www.joelonsoftware.com/articles/fog69.html
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Sun, May 3, 2009 at 3:13 PM, Robert Haas wrote:
> On Mon, Apr 6, 2009 at 11:15 AM, Robert Haas wrote:
>> So based on this comment and Stephen's remarks, I'm going to assume
>> that I'm succumbing to a fit of unjustified paranoia and re-implement
>> as you suggest.
>
> OK, new version of patch,
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> If you're really intent on doing something about this, my inclination
> >> would be to get rid of the dependence on DLNewElem altogether. Add
> >> a Dlelem field to the Backend struct and use DLInitElem (compare
> >> the way catcac
Andrew Dunstan writes:
> Now presumably we sleep for 1 sec between the CloseHandle() call and the
> CreateFileMapping() call in that code for a reason.
I'm not sure. Magnus never did answer my question about why the sleep
and retry was put in at all; it seems not unlikely from here that it
was
Tom Lane wrote:
The quick try would be to stick a SetLastError(0) in there, just to be
sure... Could be worth a try?
I kinda think we should do that whether or not it can be proven to
have anything to do with Andrew's report. It's just like "errno = 0"
for Unix --- sometimes you have to
Alvaro Herrera writes:
> Tom Lane wrote:
>> If you're really intent on doing something about this, my inclination
>> would be to get rid of the dependence on DLNewElem altogether. Add
>> a Dlelem field to the Backend struct and use DLInitElem (compare
>> the way catcache uses that module).
> Hmm
Alvaro Herrera writes:
> FWIW there is (or there was, last time I looked) an exit(1) call in the
> guts of the PHP library that PL/php uses, which is triggered when the
> memory used goes over the configured memory limit. It was very easily
> triggered with some of the test functions we had on ou
Tom Lane wrote:
> Up to now we've always just dismissed the above possibility as
> "superusers should know better", but I think there's a reasonable case
> to be made that this is an obvious failure mode and we should put a bit
> more effort into being robust against it. With more and more extern
Fujii Masao writes:
> Current pg_resetxlog doesn't remove any archive status files. This
> may cause continuous failure of archive command since .ready file
> remains even if a corresponding XLOG segment is removed. And,
> .done file without XLOG segment cannot be removed by checkpoint,
> and woul
I wrote:
> The first idea that comes to mind is to have some sort of "dead man
> switch" that flags an active backend and is reset by proc_exit() after
> it's finished cleaning up everything else. If the postmaster sees
> this flag still set after backend exit, then it treats the backend as
> havi
justin wrote:
Stupid thought why can the some clueless code set the exit status to
crashed status??? Would it not be more prudent to remove that ability???
You're missing the point. The danger comes from code that we don't control.
cheers
andrew
--
Sent via pgsql-hackers mailing list (
Zdenek Kotala writes:
> When postgreSQL is compiled with --thread-safe that libpq should be
> thread safe. But it is not true when somebody call fork(). The problem
> is that fork() forks only active threads and some mutex can stay locked
> by another thread. We use ssl_config mutex which is globa
Fujii Masao writes:
> Here is the revised patch; If stats_temp_directory indicates the symlink,
> we pursue the chain of symlinks and create the referenced directory.
I looked at this patch a bit. I'm still entirely unconvinced that we
should be doing this at all --- if the directory is not ther
Andrew Dunstan wrote:
justin wrote:
Would it not be easy to set the normal exitcode to something other
than 1 to see the difference
ExitProcess()
Not really, as Tom showed later this is an example of a more general
problem. I think his solution of detecting when backends have cleaned
u
justin wrote:
Tom Lane wrote:
Have M$ really been stupid
enough to make an external kill look just like an exit() call?
regards, tom lane
kind of :-(
Would it not be easy to set the normal exitcode to something other
than 1 to see the difference
ExitProcess
On Sat, May 2, 2009 at 11:37 AM, Tom Lane wrote:
> Tobias Zahn writes:
>> I didn't not get any response to my initial message below. Now I am
>> wondering if nobody is into the optimizer or if my question was just too
>> stupid. Could you please give me some clues? Your help would really be
>> ap
Tom Lane wrote:
Have M$ really been stupid
enough to make an external kill look just like an exit() call?
regards, tom lane
kind of :-(
Everything i have read seems to point the Task Manager calls
TerminateProcess() in the kernel32.dll and passes a 1 setting the
exitcode to 1. I
I wrote:
> Andrew Dunstan writes:
>> Well, I can tell you that it is getting an exit code of 1, which is why
>> the postmaster isn't restarting.
> Blech. Count on Windows to find a way to break things.
I reflected on this a bit more. Even if we find a way around this
particular task-manager b
Andrew Dunstan writes:
> Well, I can tell you that it is getting an exit code of 1, which is why
> the postmaster isn't restarting.
Blech. Count on Windows to find a way to break things.
> That raises two questions in my mind. First, is that the behaviour we
> expect when we kill the backend
Tom Lane wrote:
Magnus Hagander writes:
FWIW, this certainly used to work. So we've either broken this recently,
or it's always been broken on Vista (I've never tried it myself on
Vista, only 2000, XP and 2003).
Maybe a quick check if it still works on non-Vista versions would be
in
Magnus Hagander writes:
> FWIW, this certainly used to work. So we've either broken this recently,
> or it's always been broken on Vista (I've never tried it myself on
> Vista, only 2000, XP and 2003).
Maybe a quick check if it still works on non-Vista versions would be
in order, to eliminate one
Here's a small patch to replace a couple of references to files that
no longer exist in the source tree with references to the appropriate
URLs.
...Robert
*** a/src/DEVELOPERS
--- b/src/DEVELOPERS
***
*** 1,3
! Read the Developer's FAQ in pgsql/doc/FAQ_DEV. All the developer tool
Magnus Hagander writes:
> Tom Lane wrote:
>> It says here:
>> http://msdn.microsoft.com/en-us/library/ms885627.aspx
> FWIW, this is the Windows CE documentation. The one for win32 is at:
> http://msdn.microsoft.com/en-us/library/ms679360(VS.85).aspx
Sorry, that was the one that came up first in
Magnus Hagander wrote:
Andrew, just to confirm: you've found a case where this happens
*repeatably*? That's what we've failed to do before - it's happened now
and then, but never during testing...
Well, it happened several times to my client within a matter of hours. I
didn't see any s
Hi Dimitri, list
It seems to me that what you're asking for is addressed indirectly in
the possibility to make your internal data type a full SQL visible
datatype. Then you store this new datatype directly in the table and
index that. Instead of converting from external to internal type at
con
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Now this would only explain problems if there were some code path
>> through the postmaster that could leave the errno set to
>> ERROR_ALREADY_EXISTS (a/k/a EEXIST) when this code is reached. I'm not
>> sure there is one, and I have even less of
Tom Lane wrote:
> Andrew Dunstan writes:
>> I am seeing Postgres 8.3.7 running as a service on Windows Server 2003
>> repeatedly fail to restart after a backend crash because of the
>> following code in port/win32_shmem.c:
>
> On further review, I see an entirely different explanation for possi
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Andrew Dunstan writes:
>>
>>> Tom Lane wrote:
>>>
Ick. Is it possible that the postmaster did get a report, but thought
it was normal session termination? If so, how could we distinguish?
>>
>>
>>> If that were the ca
28 matches
Mail list logo
