Alexandre Caneo wrote:
> The following bug has been logged online:
>
> Bug reference: 4322
> Logged by: Alexandre Caneo
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.6
> Operating system: WIN XP
> Description:Problems with field not updatable
> Details:
> work.
>
> Do you have others suggestions?
>
> Tks.
> Alexandre.
>
>
> -Mensagem original-
> De: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Enviada em: segunda-feira, 28 de julho de 2008 08:34
> Para: Alexandre Caneo
> Cc: pgsql-bugs@postgres
Tom Lane wrote:
> "none" <[EMAIL PROTECTED]> writes:
>> I'm programming an application that uses psql (...) -c "ALTER DATABASE
>> \"MyBase\" RENAME TO \"MyBase2\" and it doesn't work because it looks for a
>> "mybase" database name.
>
> Works for me. I speculate that your scripting language is lo
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
Dan Kaminsky wrote:
>
>
> Tom Lane wrote:
>> Dan Kaminsky <[EMAIL PROTECTED]> writes:
>>
>>> My question has been: When you attempt to create an SSL connection
>>> to database.backend.com, do you actually validate that:
>>>
>>
>>
>>> 1) The subject name of the certificate you're connect
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)
Dan Kaminsky wrote:
>
>>> Well, right now, SSL does nothing for you, so you have to do
>>> something. It's OK, SSL isn't doing a lot for a lot of people, but
>>> this is the
>>> beginning of us calling people out on that.
>>>
>>
>> Do feel free to explain how it "does nothing" for you with pr
Dan Kaminsky wrote:
>
>> Good, then we're in agreement that far.
>>
>>
> Cool!
>> (FWIW, I don't think I've ever seen a PostgreSQL server with a
>> certificate off a global root. I've seen plenty off a corporate root
>> though, which could in theory have similar issues - but at least you're
>>
Peter Eisentraut wrote:
> Dan Kaminsky wrote:
1) No roots (but still works for some unknown reason)
2) Explicitly configured corporate roots
3) Explicitly configured corporate roots, AND global roots
4) Global roots (but still works for some unknown reason)
>
>> So, if you do n
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:
>
>
Peter Eisentraut wrote:
> [EMAIL PROTECTED] wrote:
>> 1. Install Perl v5.10
>> 2. Install PG
>> 3. PG does not see that machine has Perl
>> 4. Remove Perl and PG
>> 5. Instll Perl v5.8
>> 6. Install PG
>> 7. PG work fine
>> Problem is that PG does not recognize Perl v5.10 =(
>
> Please provide the
andre kallmeyer wrote:
> The following bug has been logged online:
>
> Bug reference: 4379
> Logged by: andre kallmeyer
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: PostgreSQL 8.0
> Operating system: windows xp
> Description:failt to get system metrics fot
Alvaro Herrera wrote:
> Hi,
>
> There is an announcement at http://pgfoundry.org/projects/pginstaller/
> titled
> Don't look here for announcements
> which contains an URL:
> http://www.postgresql.org/ftp/win32
>
> This URL returns a 404.
Um, yeah, who removed that symlink? And why? If the
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'
Tom Lane wrote:
> Russell Smith <[EMAIL PROTECTED]> writes:
>> Hemavathi B N wrote:
>>> PostgreSQL version: 8.0
>>> Operating system: windows 2003
>>> Description:failed toget system metics for terminal services:87
>
>> My guess is that you are not installing from the console, but are us
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 control files
because 0x1A is an end-of-file marker on Windows.
>>> Well, why is that a bug? If th
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,
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>
>>> Tom Lane wrote:
>>>
Well, why is that a bug? If the platform is so silly as to define text
files that way, who are we to argue?
>>
>>
>>> The problem is that our pg_contr
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
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>> The point being that the config files are opened with AllocateFile(),
>>> which in turn calls fopen(). It doesn't use open(). The proposal was
>>> only to make all *open()* calls do it binary. I was under the impression
>>> that on Unix, that's what
Greg Sabino Mullane wrote:
>
Does it have pg_index.indcheckxmin = true? If so, see README.HOT.
>>> Yes, that was probably it. Is this worth noting in the documentation
>>> somewhere
>>> (other than the technical bowels of HOT)? Perhaps in the CREATE INDEX
>>> docs?
> ...
>> I have attached
Scott V wrote:
> The following bug has been logged online:
>
> Bug reference: 4451
> Logged by: Scott V
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.1
> Operating system: Mac OS X 10.5.4
> Description:initcap() function capitalizes incorrectly
> Details
Jen McCann wrote:
> The following bug has been logged online:
>
> Bug reference: 4447
> Logged by: Jen McCann
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.4
> Operating system: Win2k3 server sp1
> Description:install failed to start; libintl3.dll was no
Andrej Podzimek wrote:
> The following bug has been logged online:
>
> Bug reference: 4455
> Logged by: Andrej Podzimek
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.3
> Operating system: Linux 2.6.26.5
> Description:Valid SSL certificate reported as exp
Tommy Gildseth wrote:
> The following bug has been logged online:
>
> Bug reference: 4572
> Logged by: Tommy Gildseth
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3.x,8.2.x
> Operating system: Linux
> Description:Incorrect error message when using wrong p
brian wrote:
> The following bug has been logged online:
>
> Bug reference: 4618
> Logged by: brian
> Email address: b4kra...@yahoo.com
> PostgreSQL version: 8.3.5 build1400
> Operating system: windows xp
> Description:nolock changes first column name of query result s
Marshall, Steve wrote:
> Any thoughts on whether or not this patch should be included in a future
> PostgreSQL release? If so, any thoughts on additional testing, etc,
> that needs to be done? Should the patch be added to a minor release of
> 8.3, or only included forward in 8.4? In my opinion,
Marshall, Steve wrote:
> What's the timing of the errors? Is there a chance that we are sending
> the kill signal before the signal handling thread has actually started
> *and created the named pipe*?
>
> We set up the signal handling stuff pretty early, but we do seem to let
> the postmaster con
trainee wrote:
> The following bug has been logged online:
>
> Bug reference: 4694
> Logged by: trainee
> Email address: traine...@163.com
> PostgreSQL version: 8.3.6
> Operating system: windows xp
> Description:uppercase path cause postgres can't start
> Details:
>
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.
>
>&
Martin Pitt wrote:
> Peter Eisentraut [2009-04-10 14:56 +0300]:
>> I assume the server has the snakeoil certificate installed? In that case,
>> it
>> is correct that the client refuses to proceed, although the exact manner of
>> breaking could perhaps be improved.
>
> Is it really refusing sel
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
>> have one?
>
> I have digested this thread, and have done two things: improved the
> documentation and posted a
Tom Lane wrote:
> Bruce Momjian writes:
>> In terms of your suggestion about root.crt, I think sslverify != none
>> should error if it can't verify the server's certificate, whether the
>> root.crt file is there or not. If you are asking for sslverify, it
>> should do that or error, not ignore th
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
>
Bruce Momjian wrote:
> Bruce Momjian wrote:
>> It would be nice if 'sslverify' mimicked 'sslmode', which has these
>> values:
>>
>> disable
>> allow
>> prefer
>> require
>>
>> I don't see how we could use 'allow', but 'disable', 'prefer', and
>> 'require' seem to work for sslver
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
Sikkerhed.org ApS wrote:
> The following bug has been logged online:
>
> Bug reference: 4791
> Logged by: Sikkerhed.org ApS
> Email address: supp...@sikkerhed.org
> PostgreSQL version: 8.3.7-0lenny1
> Operating system: Debian GNU/Linux 5.0.1 stable (fully updated)
> Descriptio
Jörg Kiegeland wrote:
> Hi,
> Approx. 2 weeks ago, I posted a bug which got the ID 4784. However I got
> no response to it, and it not occurs in the mbox of April or May.
> This bug is quite important to us, since it was reported by our
> customer. So I would like to know if this bug is still being
rt libpq,
but from your messages it looks like you have gssapi?
Can you show us your pg_hba.conf file, and all lines with krb in them
from postgresql.conf?
Also, can you try it with the server set to log at DEBUG4, and let us
know what output you get?
--
Magnus Hagander
Self: http://www.haga
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
Peter Koczan wrote:
> I don't know if it's much use now, but here you go.
> May 27 15:37:29 mitchell postgres[30609]: [629-1] LOG: provided
> username (koczan) and authenticated username (strivia) don't match
> May 27 15:37:29 mitchell postgres[30609]: [630-1] LOG: connection
> authorized: use
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)
On 22 jun 2009, at 17.46, Tom Lane wrote:
Lars Kanis writes:
Am Montag, 22. Juni 2009 16:38:32 schrieben Sie:
Tom Lane wrote:
IIUC this is a pre-existing bug/limitation in an extremely seldom-
used
feature that we don't have any very good way to test. So I'm not
really
excited about try
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.
se us
to do a short sleep and come back. But we'd have to change the limit
of 5 somehow then, since in theory we should wait forever. Maybe that
outer loop should just be a for(;;), what do you think?
From what I understand, none of you have an environment where you can
reliably reproduce this
ine 318 seems to be a much better location to me. If Windows and
> it's socket logic behaves properly most of the times :), most of the
> calls should come out within the first few tries, so changing 5 to an
> infinite loop shouldn't hurt those normal use cases in theory.
>
>
ode - but it also
>> doesn't show that it's in the kernel or runtime libraries.
>>
>
> AFAICS in the code, the inherited pgStatSock socket FD remains the
> same across the restart of the stats collector process...
Partially correct, I think.
Each backend has it's own
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
res a valid client
> certificate
I think this indicates that pg_ctl is trying to connect to the
database just to see if it's running, but you have set it to require
SSL certificate on connections from localhost. Could that be so? If
so, try setting the requirement for certificates only o
On Wed, Aug 26, 2009 at 15:30, Tom Lane wrote:
> Magnus Hagander writes:
>> I think this indicates that pg_ctl is trying to connect to the
>> database just to see if it's running, but you have set it to require
>> SSL certificate on connections from localhost. Could
1 - 100 of 552 matches
Mail list logo
