Heikki Linnakangas writes:
> It just occurred to me that the Windows latch implementation goes
> through a lot of trouble to dynamically assign the shared Windows event
> handles to the latches in OwnLatch, but there's really no reason why
> they can't be statically assigned in InitSharedLatch
On Thu, Apr 15, 2010 at 3:48 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Apr 7, 2010 at 21:01, Tom Lane wrote:
>>> ... lack either the note about defaulting to GMT or the hint. I guess
>>> we should add both of those to the failure cases in the Windows version
>>> of identify_syste
On Thu, Apr 15, 2010 at 2:54 AM, Tom Lane wrote:
> [ back to this... ]
>
> Magnus Hagander writes:
>> On Wed, Apr 7, 2010 at 21:06, Tom Lane wrote:
>>> I suppose we had a reason for doing it the first way but I can't see
>>> what. "GMT" seems a fairly English-centric way of referring to UTC
>>>
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 21:01, Tom Lane wrote:
>> ... lack either the note about defaulting to GMT or the hint. I guess
>> we should add both of those to the failure cases in the Windows version
>> of identify_system_timezone. Should we also change the WARNING errlevel
[ back to this... ]
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 21:06, Tom Lane wrote:
>> I suppose we had a reason for doing it the first way but I can't see
>> what. "GMT" seems a fairly English-centric way of referring to UTC
>> anyhow; translators might wish to put in "UTC" instead, or
On Wed, Apr 7, 2010 at 21:01, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> Even if if keep the current fallback behaviour we should at least fix
>> the windows codepath to do the same as the unix codepath does - as in
>> actually logging that the fallback to GMT happened...
>
> +1 for that a
On Wed, Apr 7, 2010 at 21:06, Tom Lane wrote:
> I wrote:
>> ereport(LOG,
>> (errmsg("could not determine system time zone, defaulting to
>> \"%s\"", "GMT"),
>
> BTW, does anyone remember the reason for making "GMT" nonlocalizable
> in these messages? It seems more straigh
On Wed, Apr 7, 2010 at 00:48, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Apr 7, 2010 at 00:02, Tom Lane wrote:
>>> Oh, another thought here: what is the effect of the combination of this
>>> with your other proposal to add more timezones to the list?
>
I've applied the patch to add th
I wrote:
> ereport(LOG,
> (errmsg("could not determine system time zone, defaulting to
> \"%s\"", "GMT"),
BTW, does anyone remember the reason for making "GMT" nonlocalizable
in these messages? It seems more straightforward to do
(errmsg("could not determ
Stefan Kaltenbrunner writes:
> yeah that is one aspect - and in talking to the OP he would have
> prefered the database not starting up at all, logging an error and a
> hint on setting a fixed timezone in the conf.
Well, you started from the statement that this was an embedded copy
of postgres
Magnus Hagander wrote:
On Wed, Apr 7, 2010 at 7:04 PM, Robert Haas wrote:
On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner
wrote:
Tom Lane wrote:
Stefan Kaltenbrunner writes:
hmm all that code makes me wonder a bit about a more general issue - is
the "fallback to GMT if we fail to act
On Wed, Apr 7, 2010 at 7:04 PM, Robert Haas wrote:
> On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner
> wrote:
>> Tom Lane wrote:
>>>
>>> Stefan Kaltenbrunner writes:
hmm all that code makes me wonder a bit about a more general issue - is
the "fallback to GMT if we fail to ac
On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner
wrote:
> Tom Lane wrote:
>>
>> Stefan Kaltenbrunner writes:
>>>
>>> hmm all that code makes me wonder a bit about a more general issue - is
>>> the "fallback to GMT if we fail to actually make sense of the right imezone
>>> to use" actually a
Tom Lane wrote:
Stefan Kaltenbrunner writes:
hmm all that code makes me wonder a bit about a more general issue - is
the "fallback to GMT if we fail to actually make sense of the right
imezone to use" actually a good idea?
What alternative are you proposing? Failing to start the server does
Stefan Kaltenbrunner writes:
> hmm all that code makes me wonder a bit about a more general issue - is
> the "fallback to GMT if we fail to actually make sense of the right
> imezone to use" actually a good idea?
What alternative are you proposing? Failing to start the server doesn't
seem like
Magnus Hagander wrote:
On Wed, Apr 7, 2010 at 00:48, Tom Lane wrote:
Magnus Hagander writes:
On Wed, Apr 7, 2010 at 00:02, Tom Lane wrote:
Oh, another thought here: what is the effect of the combination of this
with your other proposal to add more timezones to the list?
[ none ]
Ah, right
On Wed, Apr 7, 2010 at 00:48, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Apr 7, 2010 at 00:02, Tom Lane wrote:
>>> Oh, another thought here: what is the effect of the combination of this
>>> with your other proposal to add more timezones to the list?
>
>> [ none ]
>
> Ah, right, I hadn
Magnus Hagander writes:
> On Wed, Apr 7, 2010 at 00:02, Tom Lane wrote:
>> Oh, another thought here: what is the effect of the combination of this
>> with your other proposal to add more timezones to the list?
> [ none ]
Ah, right, I hadn't looked closely at the logic before. Still have
two co
On Wed, Apr 7, 2010 at 00:02, Tom Lane wrote:
> Oh, another thought here: what is the effect of the combination of this
> with your other proposal to add more timezones to the list? In
> particular, what happens if we use the extended list in an unpatched
> system that doesn't know about those ne
Oh, another thought here: what is the effect of the combination of this
with your other proposal to add more timezones to the list? In
particular, what happens if we use the extended list in an unpatched
system that doesn't know about those new zone names? I'm wondering
if we *have* to make this
Magnus Hagander writes:
> On Tue, Apr 6, 2010 at 23:44, Tom Lane wrote:
>> I'm not clear on this. Would this patch fix a real seen-in-the-field
>> condition, or is it speculative? In particular, if the loop had kept
>> going in the complainant's machine, would it have found another entry
>> tha
On Tue, Apr 6, 2010 at 23:44, Tom Lane wrote:
> Magnus Hagander writes:
>> When diagnosing a problem for a guy in the german channel (with Stefan
>> as mediator :P), we've found a case where the timezone information in
>> the registry seem to be empty for some timezones. The current timezone
>> m
Magnus Hagander writes:
> When diagnosing a problem for a guy in the german channel (with Stefan
> as mediator :P), we've found a case where the timezone information in
> the registry seem to be empty for some timezones. The current timezone
> matching code will abort scanning when it comes across
On Sun, Jan 10, 2010 at 13:44, Magnus Hagander wrote:
> On Sun, Jan 10, 2010 at 13:33, James Mansion
> wrote:
>> Tom Lane wrote:
>>>
>>> There's another copy of ListenSocket[] in the BackendParameters struct.
>>> I also wonder about postmaster.c's habit of using -1 for empty slots
>>> in ListenSo
On Sun, Jan 10, 2010 at 13:33, James Mansion
wrote:
> Tom Lane wrote:
>>
>> There's another copy of ListenSocket[] in the BackendParameters struct.
>> I also wonder about postmaster.c's habit of using -1 for empty slots
>> in ListenSocket ... how safe is that for Win64?
>>
>
> On Windows, it shoul
Tom Lane wrote:
There's another copy of ListenSocket[] in the BackendParameters struct.
I also wonder about postmaster.c's habit of using -1 for empty slots
in ListenSocket ... how safe is that for Win64?
On Windows, it should be INVALID_SOCKET.
James
--
Sent via pgsql-hackers mailing list
Magnus Hagander writes:
> On Wed, Jan 6, 2010 at 22:42, Tom Lane wrote:
>> Can't think of one, but you could try grepping for the socket-related
>> syscalls to see what variables are referenced there.
> Found two more by going over it again that way.
> Unless there are objections, I will apply
On Wed, Jan 6, 2010 at 22:42, Tom Lane wrote:
> Magnus Hagander writes:
>> Is there a good trick to find out if you've touched every place you
>> need to, because I'm very unsure I have. I don't even get a warning in
>> more than those two places, but there ought to be some way to trick
>> the sy
Magnus Hagander writes:
> On Wed, Jan 6, 2010 at 23:17, Tom Lane wrote:
>> BTW, I trust the non-windows case should be "int".
> Haha, yeah, that was my attempt at producing a warning. Which didn't work :-)
Hmm ... "char *" would provoke warnings, but only in the places that
were using the new d
On Wed, Jan 6, 2010 at 23:17, Tom Lane wrote:
> Magnus Hagander writes:
>> + /* socket has a different definition on WIN32 */
>> + #ifndef WIN32
>> + typedef char pgsocket;
>> + #else
>> + typedef SOCKET pgsocket;
>> + #endif
>
> BTW, I trust the non-windows case should be "int".
Haha, yeah, tha
Magnus Hagander writes:
> + /* socket has a different definition on WIN32 */
> + #ifndef WIN32
> + typedef char pgsocket;
> + #else
> + typedef SOCKET pgsocket;
> + #endif
BTW, I trust the non-windows case should be "int".
regards, tom lane
--
Sent via pgsql-hackers mai
Magnus Hagander writes:
> Is there a good trick to find out if you've touched every place you
> need to, because I'm very unsure I have. I don't even get a warning in
> more than those two places, but there ought to be some way to trick
> the system to tell me?
Can't think of one, but you could t
On Fri, Jan 1, 2010 at 20:55, Magnus Hagander wrote:
> On Fri, Jan 1, 2010 at 20:41, Tom Lane wrote:
>> Magnus Hagander writes:
>>> The win64 port has showed that we have two sockets declared
>>> incorrectly. They are supposed to be declared as SOCKET on win32, but
>>> they are declared as int.
On Sun, Jan 3, 2010 at 17:45, Peter Eisentraut wrote:
> On fre, 2010-01-01 at 20:25 +0100, Magnus Hagander wrote:
>> The win64 port has showed that we have two sockets declared
>> incorrectly. They are supposed to be declared as SOCKET on win32, but
>> they are declared as int. See attached patch.
On fre, 2010-01-01 at 20:25 +0100, Magnus Hagander wrote:
> The win64 port has showed that we have two sockets declared
> incorrectly. They are supposed to be declared as SOCKET on win32, but
> they are declared as int. See attached patch.
>
> Given that SOCKET is actually defined as int on win32
On Fri, Jan 1, 2010 at 20:41, Tom Lane wrote:
> Magnus Hagander writes:
>> The win64 port has showed that we have two sockets declared
>> incorrectly. They are supposed to be declared as SOCKET on win32, but
>> they are declared as int. See attached patch.
>
>> Given that SOCKET is actually defin
Magnus Hagander writes:
> The win64 port has showed that we have two sockets declared
> incorrectly. They are supposed to be declared as SOCKET on win32, but
> they are declared as int. See attached patch.
> Given that SOCKET is actually defined as int on win32 (no warnings or
> anything there, j
bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> (Come to think of it, --link can fail on Unix too, if the user tries to
> > >> put the new database on a different filesystem. Have you got guards in
> > >> there to make sure this is discovered before the point
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > pg_migrator needs hard link() capabiity on Win32 to support its --link
> > > option. Can someone create that and hopefully add it to libpgport?
> >
> > AFAIK hard links simply don't exist on Windows.
>
> Magnus showed me th
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> (Come to think of it, --link can fail on Unix too, if the user tries to
> > >> put the new database on a different filesystem. Have you got guards in
> > >> there to make sure this is discovered before t
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> (Come to think of it, --link can fail on Unix too, if the user tries to
> >> put the new database on a different filesystem. Have you got guards in
> >> there to make sure this is discovered before the point of no return?)
>
> > Of
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> AFAIK hard links simply don't exist on Windows.
> >
> > > Magnus showed me this:
> > > http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
> >
> > Hmm, interesting. Are we requiring our DBs
Bruce Momjian writes:
> Tom Lane wrote:
>> (Come to think of it, --link can fail on Unix too, if the user tries to
>> put the new database on a different filesystem. Have you got guards in
>> there to make sure this is discovered before the point of no return?)
> Of course:
> ...
> though you ha
Tom Lane wrote:
> Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> Hmm, interesting. Are we requiring our DBs to be on NTFS already?
>
> > Oh, yea, we only support tablespaces on Win32 using NTFS.
>
> Well, the important point there is that we fail gracefully if you try to
> use tablespaces whe
Bruce Momjian writes:
>> Tom Lane wrote:
>>> Hmm, interesting. Are we requiring our DBs to be on NTFS already?
> Oh, yea, we only support tablespaces on Win32 using NTFS.
Well, the important point there is that we fail gracefully if you try to
use tablespaces when not on NTFS. So you're going
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> AFAIK hard links simply don't exist on Windows.
>
> > Magnus showed me this:
> > http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
>
> Hmm, interesting. Are we requiring our DBs to be on NTFS already?
I think we re
Bruce Momjian writes:
> Tom Lane wrote:
>> AFAIK hard links simply don't exist on Windows.
> Magnus showed me this:
> http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
Hmm, interesting. Are we requiring our DBs to be on NTFS already?
What are the implications for Cygwin?
Bruce Momjian wrote:
> pg_migrator needs hard link() capabiity on Win32 to support its --link
> option. Can someone create that and hopefully add it to libpgport?
> libpgport currently only has symlink capability for Win32.
Can we use CreateHardLink() ?
http://msdn.microsoft.com/en-us/library
Tom Lane wrote:
> Bruce Momjian writes:
> > pg_migrator needs hard link() capabiity on Win32 to support its --link
> > option. Can someone create that and hopefully add it to libpgport?
>
> AFAIK hard links simply don't exist on Windows.
Magnus showed me this:
http://msdn.microsoft.co
Bruce Momjian writes:
> pg_migrator needs hard link() capabiity on Win32 to support its --link
> option. Can someone create that and hopefully add it to libpgport?
AFAIK hard links simply don't exist on Windows.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Sat, Mar 21, 2009 at 12:15 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> The open items list for 8.4 has
>> * problems with Windows global namespace
>
>> I propose we move this over to the TODO list instead.
>
> Agreed. In general, any issue that already exists in released versions
> shou
Magnus Hagander writes:
> The open items list for 8.4 has
> * problems with Windows global namespace
> I propose we move this over to the TODO list instead.
Agreed. In general, any issue that already exists in released versions
should not be considered a blocker for 8.4. Certainly it wouldn't
On Sat, Mar 21, 2009 at 12:11 PM, Magnus Hagander wrote:
> The open items list for 8.4 has
*) "PQinitSSL broken in some use casesf"
This should be addressed. Andrew C proposed a few different ways to
do it and supplied patches. Pick one and apply it.
*) Re: [HACKERS] patch to fix client only b
On Wed, Feb 27, 2008 at 02:02:29AM -0800, craigp wrote:
> I'm having trouble compiling the current cvs version on windows xp (msvc 2005
> express). Compile errors below.
Did you by any chance use a tree that's been sitting around for a long
time? Like sometime earlier in the 8.3 series. We had a
James Mansion wrote:
> Magnus Hagander wrote:
>> IIRC, there hasn't been any direct benchmark for it (though I've
>> wanted to do that but had no time), but it's been the olnly real
>> explanation put forward for the behaviour we've seen. And it does make
>> sense given the thread-centric view of t
Magnus Hagander wrote:
IIRC, there hasn't been any direct benchmark for it (though I've wanted to do
that but had no time), but it's been the olnly real explanation put forward for
the behaviour we've seen. And it does make sense given the thread-centric view
of the windows mm.
/Magnus
Ho
IIRC, there hasn't been any direct benchmark for it (though I've wanted to do
that but had no time), but it's been the olnly real explanation put forward for
the behaviour we've seen. And it does make sense given the thread-centric view
of the windows mm.
/Magnus
> --- Original Message --
Joshua D. Drake wrote:
> On Fri, 26 Oct 2007 21:58:03 +0100
> Dave Page <[EMAIL PROTECTED]> wrote:
>
>> Magnus Hagander wrote:
>>> I'm leaning towards applying the patch now, and hoping for 2b to
>>> happen.
>> I think we should live with the mingw BF breakage for a day or two.
>> The patch is cle
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> Magnus Hagander wrote:
>>> I'm leaning towards applying the patch now, and hoping for 2b to happen.
>
>> I think we should live with the mingw BF breakage for a day or two. The
>> patch is clearly an important improvement, but it should be
Dave Page <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> I'm leaning towards applying the patch now, and hoping for 2b to happen.
> I think we should live with the mingw BF breakage for a day or two. The
> patch is clearly an important improvement, but it should be as widely
> tested as p
On Fri, 26 Oct 2007 21:58:03 +0100
Dave Page <[EMAIL PROTECTED]> wrote:
> Magnus Hagander wrote:
> > I'm leaning towards applying the patch now, and hoping for 2b to
> > happen.
>
> I think we should live with the mingw BF breakage for a day or two.
> The patch is clearly an important improvement
Magnus Hagander wrote:
> I'm leaning towards applying the patch now, and hoping for 2b to happen.
I think we should live with the mingw BF breakage for a day or two. The
patch is clearly an important improvement, but it should be as widely
tested as possible.
/D
---(end o
Magnus Hagander wrote:
> Dave Page wrote:
>> Magnus Hagander wrote:
>>> Right. You need to look at VM size in *process explorer*. VM size in
>>> task manager has nothing to do with VM size, it's the private bytes :-S
>>> And there is no way to see that info from task manager, I think. PE is
>>> you
Tom Lane <[EMAIL PROTECTED]> wrote:
> server process exited with exit code -1073741819
> from what I suspect is really the equivalent of a SIGSEGV trap,
> ie, attempted access to already-deallocated memory. My calculator
> says the above is equivalent to hex C005, and I say that this
>
Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Anyone want to run down what we should really
>>> be using instead of the above macros?
>
>> The exit code is apparently what is reported from GetExitCodeProcess().
>> For info on that see
>> http://msdn.microsoft
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Anyone want to run down what we should really
>> be using instead of the above macros?
> The exit code is apparently what is reported from GetExitCodeProcess().
> For info on that see
> http://msdn.microsoft.com/library/default.asp?
Tom Lane wrote:
> win32.h says
>
> /*
> *Signal stuff
> *WIN32 doesn't have wait(), so the return value for children
> *is simply the return value specified by the child, without
> *any additional information on whether the child terminated
> *on its own or via a signal. T
> IIRC there is no real SIGINT on Windows, so it can only come
> from a postgres program. The windows shutdown could be
> calling pg_ctl to stop the service, of course.
Well, not quite that, but it will send a service command to the running
pg_ctl (which is our "service supervisor"), which *will
IIRC there is no real SIGINT on Windows, so it can only come from a
postgres program. The windows shutdown could be calling pg_ctl to stop the
service, of course.
cheers
andrew
Joshua D. Drake wrote:
> Magnus Hagander wrote:
That log entry is the last (of consequence) entry before
>>> the
Magnus Hagander wrote:
>>> That log entry is the last (of consequence) entry before
>> the machine says:
>>> 2006-09-28 16:40:36.921 LOG: received fast shutdown request
>> Oh? That's pretty interesting on a Windows machine, because
>> AFAIK there wouldn't be any standard mechanism that might t
> > That log entry is the last (of consequence) entry before
> the machine says:
> > 2006-09-28 16:40:36.921 LOG: received fast shutdown request
>
> Oh? That's pretty interesting on a Windows machine, because
> AFAIK there wouldn't be any standard mechanism that might tie
> into our homegrow
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> O.k. further on this.. the crashing is happening quickly now but not
>> predictably. (as in sometimes a week sometimes 2 days).
>
> OK, that seems to eliminate the GetTickCount-overflow theory anyway.
>
>> That log entry is the la
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> O.k. further on this.. the crashing is happening quickly now but not
> predictably. (as in sometimes a week sometimes 2 days).
OK, that seems to eliminate the GetTickCount-overflow theory anyway.
> That log entry is the last (of consequence) entry b
Joshua D. Drake wrote:
> Tom Lane wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> Yes, unfortunately there isn't much more to be had for another 2
>>> weeks ;)
>>
>> I trust they've got the reboot time and they will know exactly how long
>> from reboot to problem? I'm not all that sold
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Yes I am fully aware of that. I am only relaying what the customer said.
Yeah sorry, I guess what I sent was pretty obvious to you. I should stop
confusing -general with -hackers :)
--
Gregory Stark
EnterpriseDB http://www.enterprise
Joshua D. Drake wrote:
> Gregory Stark wrote:
> >"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >>The only known resolution is to reboot Windows. Using the service
> >>control panel to shutdown postgresql will fail once the message is
> >>received. It is unknown if using the task master to indivi
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
O.k. to recap:
This message will present itself, if connection attempts are made from the Web
Application (Java/JDBC), or locally via PgAdmin. Once the error message is
received, all subsequent connection attempts will also res
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> O.k. to recap:
>
> This message will present itself, if connection attempts are made from the Web
> Application (Java/JDBC), or locally via PgAdmin. Once the error message is
> received, all subsequent connection attempts will also result in that sam
On 6-Sep-06, at 3:27 AM, Magnus Hagander wrote:
Yes they are using a connection pool. A java based one.
Since java has it's own protocol implementation, this is
totally
unrelated to any libpq error messages.
Another important point that we've not been given information
on:
when pgAdmin/li
> > server sent data ("D" message) without prior row description ("T"
> > message)
>
> During the connection attempt? I don't think libpq can report that
> message until it tries to do a regular query (might be wrong
> though).
> Is the client using some application that's going to issue a query
Magnus Hagander wrote:
> Another point that at least I don't know - what kind of connection pool
> is it? Is it an external one (like pgpool) to which the java app
> connects (using FE/BE protocol, emulating a "proper postmaster" but
> pooling access to the database), or is it running inside the a
> Yes they are using a connection pool. A java based one.
> >>> Since java has it's own protocol implementation, this is
> totally
> >>> unrelated to any libpq error messages.
> >> Another important point that we've not been given information
> on:
> >> when pgAdmin/libpq starts failing like t
I'm a bit fear to to engage into this thread, but I've seen also
reproducible case when libpq client stops working and 'vaccuum analyze'
helped. It's happened on Windows Server 2003 and XP with PostgreSQL 8.1.4.
I don't have client source code, so I can't say more, but customer's developer
said th
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Yes, unfortunately there isn't much more to be had for another 2 weeks ;)
I trust they've got the reboot time and they will know exactly how long
from reboot to problem? I'm not all that sold on the "GetTickCount
overflow" theory,
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Yes, unfortunately there isn't much more to be had for another 2 weeks ;)
I trust they've got the reboot time and they will know exactly how long
from reboot to problem? I'm not all that sold on the "GetTickCount
overflow" theory, but certainly we o
On 5-Sep-06, at 7:00 PM, Joshua D. Drake wrote:
Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:
Yes they are using a connection pool. A java based one.
Since java has it's own protocol implementation, this is totally
unrelated to any
It sounds to me like we don't actually know that, because the client
doesn't know how to restart the postmaster without rebooting the OS.
(Josh says "pg_ctl stop" doesn't work in this state, which is a tad
interesting in itself, because that doesn't go through a connection
request.) It would be
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Joshua D. Drake wrote:
>> I already said that ;). The problem IS NOT that we can't restart the
>> system and get postgresql back. It is that it happens at all.
> It is quite different a bug that can only be fixed by "rebooting the
> server" (which to m
Joshua D. Drake wrote:
> The only known resolution is to reboot Windows. Using the service
^^
> control panel to shutdown postgresql will fail once the message is
> received. It is unknown if using the task master to individually kill
> processes wi
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
> >Joshua D. Drake wrote:
> >>Tom Lane wrote:
> >>>Dave Cramer <[EMAIL PROTECTED]> writes:
> On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:
> >Yes they are using a connection pool. A java based one.
> Since java has it's own protocol imple
Hello,
O.k. to recap:
OS: Win2k3 SP1
PostgreSQL: 8.1.2
Application Server: Jboss
Connection Pooler: C3PO
JDBC Version: 8.1.404, Also verified with 8.0.311
Problem:
After 2/3 weeks, PostgreSQL will begin issuing the following message:
server sent data ("D" message) without prior row descriptio
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:
Yes they are using a connection pool. A java based one.
Since java has it's own protocol implementation, this is totally
unrelated to any libp
Joshua D. Drake wrote:
> Tom Lane wrote:
> >Dave Cramer <[EMAIL PROTECTED]> writes:
> >>On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:
> >>>Yes they are using a connection pool. A java based one.
> >
> >>Since java has it's own protocol implementation, this is totally
> >>unrelated to any libpq
-Original Message-
From: "Joshua D. Drake" <[EMAIL PROTECTED]>
To: "Joshua D. Drake" <[EMAIL PROTECTED]>; "Tom Lane" <[EMAIL PROTECTED]>;
"Merlin Moncure" <[EMAIL PROTECTED]>; "Magnus Hagander" <[EMAIL PROTE
Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:
Yes they are using a connection pool. A java based one.
Since java has it's own protocol implementation, this is totally
unrelated to any libpq error messages.
Another important point t
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Alvaro Herrera wrote:
What I've been wondering all along is whether they are using a
connection pool.
Yes they are using a connection pool. A java based one.
It's quite possible that it's the connect
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
> >Tom Lane wrote:
> >>"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >Fail in what way. Hang, not connect, or get an error msg?
> >>>Just verified with customer. Once the problem occurs the first time, the
> >>>customer will continually get the
Dave Cramer <[EMAIL PROTECTED]> writes:
> On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:
>> Yes they are using a connection pool. A java based one.
> Since java has it's own protocol implementation, this is totally
> unrelated to any libpq error messages.
Another important point that we've not
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
> >Joshua D. Drake wrote:
> >>Alvaro Herrera wrote:
> >>>What I've been wondering all along is whether they are using a
> >>>connection pool.
> >>Yes they are using a connection pool. A java based one.
> >
> >It's quite possible that it's the connecti
On 5-Sep-06, at 6:05 PM, Joshua D. Drake wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Fail in what way. Hang, not connect, or get an error msg?
Just verified with customer. Once the problem occurs the first
time, the customer will continually g
1 - 100 of 497 matches
Mail list logo
