The following bug has been logged on the website:
Bug reference: 6312
Logged by: Magnus hagander
Email address: mag...@hagander.net
PostgreSQL version: Unsupported/Unknown
Operating system: Linux
Description:
This is a test bug report. It seems bug reporting got
The following bug has been logged on the website:
Bug reference: 7640
Logged by: Magnus Hagander
Email address: mag...@hagander.net
PostgreSQL version: 9.2.1
Operating system: Web
Description:
This is just a test to make sure that the bug reporting form has been
.CursorType = adOpenDynamic
> mo_Record.LockType = adLockOptimistic
>
> mo_Record.Open mo_Command
>
> One more thing.
> I don't need update the table's b column, just show them.
If you don't need updating, you should open your cursor as either
adOpenSt
Can't say that I do. I think you need to get the ODBC folks to look at
it, the problem appears to be there rather than in the server product.
//Magnus
Alexandre Caneo wrote:
> Magnus,
>
> I've tried open cursor with adOpenStatic or adOpenForwardOnly, but it didn't
the command string would probably
> cause such a problem.
Most likely you're bit by the completely insane rules of quoting in the
windows commandshell. See for example the comments around it in
src/port.h in the PostgreSQL distribution.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Bruce Momjian wrote:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> Thomas H. wrote:
>>>> so at least that explains the "changed" behaviour. nevertheless,
>>>> LC_MESSAGES seems to be defunct - with the "lo
server certificate itself with
the application, in which case it will only ever connect to that server
(self-signed cert). Or they have a dedicated CA for this purpose. Is it
perfect? Far from. But it's certainly not worthless.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> (I don't believe OpenSSL does this verification either, because AFAICS
>> OpenSSL only ever sees the IP address of the server, and not the FQDN)
>
> In common usages libpq doesn't have the FQDN o
Dan Kaminsky wrote:
>
>
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>
>>> (I don't believe OpenSSL does this verification either, because AFAICS
>>> OpenSSL only ever sees the IP address of the server, and not the FQDN)
oday. If you are willing to do it in the application,
>> just verify the certificate DN and you're done.
>>
>> Yes, it would certainly be a lot better to do the validation earlier in
>> the chain (if you're sending plaintext password, you'll end up sendin
rts.
OTOH, if your firewall lets your clients (or even worse - your webserver
or so) connect out to arbitrary machines on the PostgreSQL port, it can
easily be argued that you have a lot of homework to do elsewhere as well
;-) But that's just a mitigating factor, and not a solution.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
e peer name and the
certificate. When "verifycert" we just verify the certificate, fail if
we can't find a root certificate, but ignore the common name. "off"
should be self-explaining.
I'd set the default to "verifypeer" in 8.4 and up, but backpatch
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I'd set the default to "verifypeer" in 8.4 and up, but backpatch it with
>> a default of "off". That way we don't break existing setups, but give
>> users the ability to verify
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> The code is there, actually, it's just #ifdef NOT_USED :-) From a *long*
>> time ago, and the commit message just says "silence compiler warnings",
>> so I've not managed to figure ou
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I think the commit you're looking for is this one:
>>> 2002-09-26 00:41 momjian
>
>> No, that's not the one. It's the one after that one, at:
>
>
your
> description.
I think he is talking about the Windows binary distribution. In which
case, the answer is no - the binary windows distribution of 8.3 does
*not* work with perl 5.10.
Other platforms, and build-from-source on Windows should, AFAIK.
//Magnus
--
Sent via pgsql-bugs maili
o get system metrics fot terminal services : 87
> Details:
>
> I can not install the Programm.
PostgreSQL 8.0 is no longer supported on Windows. You need to be using
8.2 or 8.3 (8.3 is really the recommended choice here)
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgr
emoved that symlink? And why? If there was a good reason,
we should change the links into it. If it was done by mistake, the
symlink should just be put back :-)
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Dave Page wrote:
> On Thu, Aug 28, 2008 at 8:30 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> Alvaro Herrera wrote:
>>> Hi,
>>>
>>> There is an announcement at http://pgfoundry.org/projects/pginstaller/
>>> titled
>>> Don'
gt; less than a week ago:
> http://archives.postgresql.org/pgsql-bugs/2008-08/msg00241.php
> I believe this is something that's fixed as of 8.2.
Yes, IIRC that whole codepath has been rewritten. And 8.0 isn't
supported anymore (on windows), so you really sholdn't be installing
that
0
>> #define PG_BINARY_A "a"
>> #define PG_BINARY_R "r"
>> #define PG_BINARY_W "w"
>> #endif
>
> I don't see anything wrong with the patch, but I wonder if there's more
> open() calls that need the same treatment? Like the
Magnus Hagander wrote:
> Heikki Linnakangas wrote:
>> ITAGAKI Takahiro wrote:
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
>>>
>>>> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
>>>>> We probably need to add PG_BINARY when we open co
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> I had a chat with Heikki about this, and the proper way to fix it.
>>
>> Should there actually be any reason not to *always* open our files with
>> O_BINARY? That seems to be what should mimic what Unix does,
reason why this might be a bad idea, consider the
>> idea that someone is examining postgresql.conf with a text editor that
>> stops reading at control-Z. He might not be able to see items that the
>> postmaster is treating as valid.
>>
>>
>>
>
Magnus Hagander wrote:
> Andrew Dunstan wrote:
>>
>> Tom Lane wrote:
>>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>>
>>>> Tom Lane wrote:
>>>>
>>>>> Well, why is that a bug? If the pl
specify it. (PG_BINARY is a no-op on all other platforms than Windows,
btw, because there is no way to specify anything other than binary mode
for open() on Unix)
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the way HOT chains work. For more information, please see
> ."
I think putting links in the user documentation directly to development
README files that require you to look in the source code is a bad thing...
> It might be nice to upgrade README.HOT to a real documentation page
> as
function appears to be incorrectly interpreting the two-byte chars as
> non-alphamueric characters. They are in fact alphanumerics, they just have
> diacritical markings.
What's your setting for lc_collate?
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
when attempting to install v8.3.3
Strange. You are using the MSI installer from our ftp site? Or are you
using the binaries-no-installer?
Also, please verify using "depends.exe" that all the DLL files that
libintl3.dll requires are also present.
//Magnus
--
Sent via pgsql-bugs mailing
andom number
problem? It may be that OpenSSL gives an incorrect error message in this
case...
If not, please try with the OpenSSL s_client/s_server applications with
the same certificates and see if it works there.
Also, check if there may be some kind of date issue with the CRL.
//Magnus
--
ssage, connect
with PGSSLMODE=require (or put sslmode=require in the connection string)
- that way you will prevent the attempt to reconnect without SSL.
We can't easily backpatch this since it may break existing applications
that aren't equipped to deal with multiline errors.
/
gt; ERROR: column "movieid" does not exist
> LINE 2: select * from netflix.ratings with (nolock) where movieid = ...
I don't know where you got "with (nolock)" from, but that's not
PostgreSQL syntax - and AFAIK it's not standard SQL at all. Just remove
it and you should be
et the postmaster continue it's work before
it's up...
Going back to your tests, did it ever require more than one retry?
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
my
> tests, and in the patch I sent.
I have applied a modified version (no functional changes, just
stylistic) of this patch to head and backpatched to 8.2 which is as far
back as we support win32.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
is to always include the full path to the pg_ctl
command when you register the service.
That said, I have applied a patch that makes the check that fails case
insensitive, which should fix the most common cases of this happening.
It will be included in the next version (in both 8.2/
Tom Lane wrote:
> Martin Pitt writes:
>> I do see the benefit of failing to connect to an SSL-enabled server
>> *if* I have a root.crt which doesn't match. But why fail if I don't
>> have one?
>
> I think I agree with Martin on this. The server doesn't fail if you
> don't provide it a root cert;
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> It is not apparent why the client should be stricter than
>>> that, and definitely not apparent why such strictness should be the
>>> default behavior.
>
>> It's "secure b
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> In my experience ssh itself isn't this strict. Why should libpq be?
>
>> ssh prompts the user when this happens. We don't have a mechanism for
>> prompting the user.
>
> In
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> In the first place, I have never seen such a prompt, despite the fact
>>> that I use ssh constantly to connect to machines that I know do not have
>>> properly signed certificates.
>
>&
> (which, BTW, seems like a strange place to default to, and thus keep
> it).
That has just been brought up from previous versions. Perhaps we need to
have a system wide root store as well - then you could point that to
whatever snakeoil store you have, and it would find the cert correctly?
//M
Inventing a switch that makes it more or less impossible to figure out
if you are going to be secure or not makes no sense. When dealing with
security, maybe is the same as no, and you have to *know*.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
villagers become ...
The option is there already, it's called "none". That's what people are
asking for - they don't care who they are connecting to, just that the
traffic is encrypted (be it legitimate or hacked traffic, at least it's
encrypted).
It's just a
Tom Lane wrote:
> Magnus Hagander writes:
>> Bruce Momjian wrote:
>>> The only other approach would be to add an sslverify value of
>>> 'try' that tries only if root.crt exists.
>
>> Doesn't "try" make the whole check pretty pointles
Tom Lane wrote:
> Magnus Hagander writes:
>> Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and
>> something like "maybe" or "external" or "file". I'd find it very bad i
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Bruce Momjian wrote:
>>> Martin Pitt wrote:
>>>> I do see the benefit of failing to connect to an SSL-enabled server
>>>> *if* I have a root.crt which doesn't match. But why fail if I don't
>
is a bad thing, but if it's controlled by the same connection
string, it makes a lot more sense.
So I think +1 for different defaults based on sslmode, but -1 on the
strange naming. (not to say we can't fix the naming that's there now,
but this specific suggestion makes it worse)
/Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 12 apr 2009, at 11.13, Peter Eisentraut wrote:
On Sunday 12 April 2009 01:58:26 Magnus Hagander wrote:
"sslmode=prefer" honestly makes no sense - if I don't care if it
ends up
encrypted or not (which it means), then why not just run with SSL off
and not have to deal wi
Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> One random idea is to fold both of these settings into sslmode, with
>>> the
>>> following progression:
>>>
>>> disable, allow, prefer, require, require-cert, require-cn
>>>
>>>
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Hiroshi Inoue wrote:
>>> Magnus Hagander wrote:
>>>> Bruce Momjian wrote:
>>>>> Martin Pitt wrote:
>>>>>> I do see the benefit of failing to connect to an SSL-enabled server
>>>
On 14 apr 2009, at 04.33, Bruce Momjian wrote:
Magnus Hagander wrote:
I would actually call the two parameters 'verify-cert' and 'verify-
cn',
and document that they also have "require" behavior. Obviously you
can't verify certificates unless you require S
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On 14 apr 2009, at 04.33, Bruce Momjian wrote:
>>
>>> Magnus Hagander wrote:
>>>>> I would actually call the two parameters 'verify-cert' and 'verify-
>>>>> cn',
>>>
Tom Lane wrote:
> Magnus Hagander writes:
>> Patch also changes the default from "prefer" to "disable", per discussion.
>
> I confess to not having paid attention to this thread for awhile.
> I have to violently object to this conclusion --- it is thro
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> Having a connection that
>>> was encrypted in 8.3 silently become clear-text after installing 8.4
>>> is just plain NOT acceptable.
>>>
>>> I think the patch would be fine if we
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander writes:
>>> Tom Lane wrote:
>>>> Having a connection that
>>>> was encrypted in 8.3 silently become clear-text after installing 8.4
>>>> is just plain NOT acceptable.
>>&
Magnus Hagander wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander writes:
>>>> Tom Lane wrote:
>>>>> Having a connection that
>>>>> was encrypted in 8.3 silently become clear-text after installing 8.4
>>>&g
"immutable script" part that you are missing.
Any particular reason why you are not using the pgcrypto installation
script?
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ndard mailinglist, so
it's subject to the same antispam as other posts). We did have some
issues with the spamfilter a couple of weeks ago, so it may have been
lost then.
Please resubmit the bugreport.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make cha
we *had* been doing that, but can't claim to have read
> that code closely. Magnus?
We are certainly *supposed* to do that. And we have been doing that. So
if that's not done, it's been broken in 8.4 (most likely by me).
Peter, are you using gssapi or krb5? Only krb5 has changed w
Magnus Hagander wrote:
> Tom Lane wrote:
>> Peter Koczan writes:
>>> This is trust authentication with one rather inconsequential bit of
>>> verification, that's a fundamental breakage. One of the major points
>>> of Kerberos is that, for anything that tal
G: connection
> authorized: user=strivia database=postgres
This seems to confirm my suspicions. We detect that the username is
wrong, but we still don't reject the connection.
//Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom, or someone else... auth.c line 1076. I'm pretty sure that should be
>> "return ret" not "return STATUS_OK".
>
> Doh.
yeah. WIll apply patch.
>> Wow, that's a bad bug :-O
>
> H
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander writes:
>>> Tom, or someone else... auth.c line 1076. I'm pretty sure that should be
>>> "return ret" not "return STATUS_OK".
>> Doh.
>
> yeah. WIll apply patch.
And
ssume they should also go
outside the error path, per the attached patch - or will that break
their usage?
Can you test that and verify that it doesn't break for you?
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/src/interfaces/libpq/f
lose_SSL() should be the right place for ENGINE_finish() and ENGINE_free() ?
Yup.
How about the attached patch? Does it work for you?
A question from that then, for others, is it Ok to add a field to the
PGconn structure during RC? :-) It's only in libpq-int.h, but? Comments?
Tom, perhaps
Tom Lane wrote:
> Magnus Hagander writes:
>> A question from that then, for others, is it Ok to add a field to the
>> PGconn structure during RC? :-) It's only in libpq-int.h, but? Comments?
>
> Changing PGconn internals doesn't bother me, but ...
>
> IIUC
On 22 jun 2009, at 18.05, Tom Lane wrote:
Magnus Hagander writes:
How about the attached patch? Does it work for you?
The existing references to typedef ENGINE and associated functions are
wrapped in
#if (SSLEAY_VERSION_NUMBER >= 0x00907000L) && !defined
(OPENSSL_NO_ENGINE)
ater if someone did, but I don't see the scenario...) in fact, this
is a but in an advertised feature in previous versions, so should
maybe even consider backpatching it base on that
/Magnus
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your sub
Tom Lane wrote:
> Magnus Hagander writes:
>> On 22 jun 2009, at 17.46, Tom Lane wrote:
>>> It seems like there is large potential for failure in
>>> contexts other than the one or two you are going to be able to test
>>> right now. Is there anything that can
ted
> engines are initialized (so can work), engines aren't freed (memory leak), no
> changes to PGconn only in engine code path
>
> 3. the current patch
> engines are initialized, engines are freed, but problematic changes to PGconn
>
>
> Maybe version 2 (my initial
Tom Lane wrote:
> Magnus Hagander writes:
>> Lars Kanis wrote:
>>> Maybe version 2 (my initial patch) could be an alternative ?
>
>> Well, based on the "we don't know which different versions of openssl
>> it'll break with", version 2 is no be
Tom Lane wrote:
> Magnus Hagander writes:
>> Lars Kanis wrote:
>>> Maybe version 2 (my initial patch) could be an alternative ?
>
>> Well, based on the "we don't know which different versions of openssl
>> it'll break with", version 2 is no be
Tom Lane wrote:
> Magnus Hagander writes:
>> On 22 jun 2009, at 18.05, Tom Lane wrote:
>>> I'm also a bit concerned about wrapping a struct
>>> field inside such an #if, as that's likely to cause hard-to-debug
>>> problems if two compil
t; return TRUE;
>
> Also, AddUserToDacl() line 807
>
> FreeSid(psidUser) should be HeapFree(GetProcessHeap(), 0, psidUser)
>
> in order to work with my suggested changes in GetUserSid().
How about something like this? I switched to using LocalAlloc() in all
places to
Tom Lane wrote:
> Magnus Hagander writes:
>> Attached is an updated patch that does both of these.
>
> This looks reasonably sane to me, and I'm satisfied with the testing
> that's been done. No objection from here.
Applied.
//Magnus
--
Sent via pgsql-b
ve no use for GPL code. We also
already have implementations of SHA256 and SHA512 that are BSD licensed
in our codebase.
> one possibility is that you could make the MD5 function actually return a
> SHA-512 hash.
That seems like a horrible idea.
--
Magnus Hagander
Self: http://www.haga
rrectly produces an error and the logon fails.
Since this is a security related report, it should have been reported to
secur...@postgresql.org, as specified on the web form you used.
For this reason, we will follow this up on that forum, and post a public
followup once the issue has been investi
ched is a mix of our two patches. How does that look to you?
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
*** a/src/port/exec.c
--- b/src/port/exec.c
***
*** 56,62 static int resolve_symlinks(char *path);
static char *pipe_read_l
8.5?
The only issue now is a small leak of memory in a function that is only
called a fixed (and very small) number of times per process. Given this,
I'm inclined to say we should put it on hold for 8.5. Thoughts?
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redp
; Doesn't sound urgent to me. If it were my decision, I'd punt it to 8.5.
Ok. Agreed then - added to the commitfest page.
> Hard to keep that win32 acl stuff leak free. There is always a cleanup
> goto because you need 6 billion objects to answer any question :o
Yeah, true.
ases, the fully qualified hostname will
be the same as the fully qualified interface name for the only
interface that's configured.
Anyway, the whole reason for moving the krb_server_hostname parameter
into pg_hba.conf is to make it *more* flexible to configure situations
like this.
--
Mag
On Wed, Jul 22, 2009 at 17:29, Peter Much wrote:
> On Wed, Jul 22, 2009 at 11:52:32AM +0200, Magnus Hagander wrote:
> ! On Wed, Jul 22, 2009 at 11:42, Peter Much
> wrote:
>
> Now understanding it, I bow in respect - this is indeed a fine
> improvement!
Than
up and working
> again, i.e. I have also now tried to uninstall 8.3 but get the same message
> of invalid password?
You can do this using the user management functions in the operating
system, or using the "NET USER" command on the commandprompt.
--
Magnus Hagander
Self: http
onnection pooling. Is there
> some more variants to use connection pooling without using postgres users?
Not that I know of.
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chan
assword request when installing
> postgreSQL 8.4 ??
You can create a new service account with a different name.
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Wed, Jun 24, 2009 at 16:01, Magnus Hagander wrote:
> Andrew Chernow wrote:
>>
>>> The only issue now is a small leak of memory in a function that is only
>>> called a fixed (and very small) number of times per process. Given this,
>>> I'm incline
ommon to all 32-bit microsoft compilers is the __int64 type.
You seem to be focused on the Windows platform there. There are a
whole lot more platforms needed. But we already have generic types for
64-bit available in our headers, in the form of int64 and uint64.
--
Magnus Hagander
Self: ht
w
packet is sent in, WaitForMultipleObjectsEx() should return right
away. And given that backends regularly send packets over, it
shouldn't be an issue even if we miss one...
To generate packets, you should be able to use for example "nc" that
is available as a win32 binary as well.
ally is a should-never-happen thing. As soon as a new
>> packet is sent in, WaitForMultipleObjectsEx() should return right
>> away. And given that backends regularly send packets over, it
>> shouldn't be an issue even if we miss one...
>>
>
> And this fact should len
firewall software or such things involved. I have seen a couple
>>>> of reports from the field though.
>>>>
>>>> Anyway, this really is a should-never-happen thing. As soon as a new
>>>> packet is sent in, WaitForMultipleObjectsEx() should return right
>>&
On Mon, Aug 3, 2009 at 16:20, Nikhil
Sontakke wrote:
> Hi,
>
>>>>>
>>>>> And this fact should lend credence to Alvaro's (as well as mine)
>>>>> suspicions that it seems to be a Windows kernel issue.
>>>>>
>>>>>
ine? They are known to cause just this type of
issues. If so, try uninstalling them (not just disabling, but actually
uninstalling is often required) and see if the problem goes away.
--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
als emulation
code, but certainly not all of it.
If I just move those two lines into the #ifndef WIN32 block just
around it, it compiles and doesn't crash on running-with-no-arguments.
I haven't tried to actually use it though - can someone confirm if
this will actually make pg_standby not wo
On Mon, Aug 10, 2009 at 20:44, Tom Lane wrote:
> Magnus Hagander writes:
>> If I just move those two lines into the #ifndef WIN32 block just
>> around it, it compiles and doesn't crash on running-with-no-arguments.
>> I haven't tried to actually use it though - can
Yeah, the patch I think breaks things isn't included in 8.3.7 - it
will be in 8.3.8 though...
//Magnus
On Wed, Aug 12, 2009 at 11:08, wader2 wrote:
> I can't compile nor read source, but can tell you that
> pg_standby.exe in 8.3.7 works fine.
>
> Magnus Hagander wrote:
>
On Wed, Aug 12, 2009 at 19:08, Fujii Masao wrote:
> Hi,
>
> On Tue, Aug 11, 2009 at 3:10 AM, Magnus Hagander wrote:
>> I have reproduced this. The problem is:
>> (void) signal(SIGUSR1, sighandler);
>> (void) signal(SIGINT, sighandler); /* deprecated, u
On Wed, Aug 19, 2009 at 08:38, Fujii Masao wrote:
> On Thu, Aug 13, 2009 at 2:24 AM, Magnus Hagander wrote:
>> Not sure. Potentially pure luck. SIGINT has never *worked*, though, it
>> just hasn't crashed.
>
> OK.
>
>> We could implement the same type of chec
do,
> for example, the Performance Logs and Alerts service.
^ This says 8.0.
It looks like you have two different versions installed that are
somehow conflicting with each other. Possibly because they are trying
to listen on the same port, or something like that.
--
Magnus Hagand
On Wed, Aug 19, 2009 at 11:45, Heikki
Linnakangas wrote:
> Magnus Hagander wrote:
>> This would amount to fairly major surgery for pg_standby on Win32. Is
>> that something we'd want to backpatch, or do we want to backpatch just
>> the removal of the signal() calls
of type 'System.OutOfMemoryException' was thrown
>
> That's probably a bug in their application caused by failure to properly
> handle a connection problem.
Yes, or possibly npgsql having the bug, though I haven't heard of it
there. The stacktrace should probably tell
en server starts with SSL configuration changes following process are
> created and running in system - postgres.exe (6 instances). This time
> pg_ctl.exe process is absent.
>
> 3) Server starts properly when "clientcert=1" is removed from pg_hba.conf
> file. But if we want ser
1 - 100 of 556 matches
Mail list logo
