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
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 instead. We have to
allocate the sa
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
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 one of these,
thus claiming it c
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
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, just on win64), I'm inclined to appl
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
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.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://en
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
The open items list for 8.4 has
* problems with Windows global namespace
I propose we move this over to the TODO list instead. We are no worse
off than we are in previous versions, and we've had *zero* bug reports
related to this issue.
Basically, we have a small window of failed protection if
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
I'm having trouble compiling the current cvs version on windows xp (msvc 2005
express). Compile errors below.
I have bison 1.875 (I can't find 2.2+ for windows) and flex 2.5.4. These tools
seem to generate correct outputs.
It looks like it might be including parse.h from include/parser/parse.h
When building with MSVC 2005 (Express) and the Longhorn Platform SDK
(version 6.0a), it seems that IPPROTO_IPV6 is only defined when
_WIN32_WINNT >= 0x0501. This results in a compiler error when trying to
build pqcomm.c (line 389). According to [1], building for Windows 2000
(that is, _WIN32_WINNT
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
-- Original Message ---
> From: "Trevor Talbot" <[EMAIL PROTECTED]>
> To: pgsql-hackers@postgresql.org
> Sent: 07-11-11, 00:31:59
> Subject: [HACKERS] Win32 shared memory speed
>
> I've seen several comments about shared memory under Windows being
>
I've seen several comments about shared memory under Windows being
"slow", but I haven't had much luck finding info in the archives.
What are the details of this? How was it determined and is there a
straightforward test/benchmark?
---(end of broadcast)---
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
While reading one of the recent -perform threads, it occurred to me to
check, and the 8.2.4 Win32 release binaries aren't marked "large
address aware". This means the process gets a 2GB VM space, which is
normal for 32bit Windows. On x64, my understanding is that each 32
bit process can actually
bruce wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Bruce Momjian wrote:
> > >> OK, maybe /doc or src/tools. A more radical approach would be to put
> > >> the list in our documentation, or have initdb install it.
> >
> > > Why not put it in techdocs or some such?
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
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. These macros are also
> 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
1 - 100 of 994 matches
Mail list logo
