Hi Sir
What happen process postgress.exe in windows task manager. please
help me check is problem.
Bast Regards.
-
Mr.Attapon Rompor
Customer Service
Thai Trade Net Co.,Ltd
02-5026721,02-5026820-3
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
attapo...@samtel.samartcorp.com wrote:
>
> Hi Sir
> What happen process postgress.exe in windows task manager.
> please help me check is problem.
>
pls refer this link:-
http://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_On_Nat
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.
I think the patch would be fine if we simply keep the default
On Apr 23, 2:25 pm, dp...@pgadmin.org (Dave Page) wrote:
> On Thu, Apr 23, 2009 at 6:43 PM, Kevin Field
> wrote:
> > On Apr 23, 12:13 pm, dp...@pgadmin.org (Dave Page) wrote:
> >> On Thu, Apr 23, 2009 at 4:30 PM, Kevin Field
> >> wrote:
> >> > Is it possible it's looking for Perl in the wrong p
On Fri, Apr 24, 2009 at 1:17 PM, Kevin Field wrote:
> Good to know. And yay for 5.10! That's a welcome upgrade.
>
> So I need to keep my 5.8 around currently for other uses--how can I
> hint at the correct location for it?
In theory, by setting the path for the server only. In practice I'm
not
On Apr 24, 8:40 am, dp...@pgadmin.org (Dave Page) wrote:
> >
> > So I need to keep my 5.8 around currently for other uses--how can I
> > hint at the correct location for it?
>
> In theory, by setting the path for the server only. In practice I'm
> not sure how you could do that, except by possibly
On Fri, Apr 24, 2009 at 2:12 PM, Kevin Field wrote:
> On Apr 24, 8:40 am, dp...@pgadmin.org (Dave Page) wrote:
>> >
>> > So I need to keep my 5.8 around currently for other uses--how can I
>> > hint at the correct location for it?
>>
>> In theory, by setting the path for the server only. In practi
The following bug has been logged online:
Bug reference: 4779
Logged by: Thomas S. Chin
Email address: t...@genx.net
PostgreSQL version: 8.3.7
Operating system: Linux tat 2.6.27-gentoo-r7 #1 SMP Fri Jan 2 08:50:09 EST
2009 i686 Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz GenuineInt
On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote:
>
> I don't know if there is any way we can solve it, except by reverting
> back to 5.8 or advising users to use only one version.
LOL...ah, great. Well, I'd love to move to 5.10 for both.
A note in the docs would be handy either way.
--
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
> is just plain NOT acceptable.
>
> I think the patch would be f
"Thomas S. Chin" writes:
> I noticed that the behavior of queries that involve LIMIT/OFFSET no longer
> return results consistent with the ordering of the same query without
> LIMIT/OFFSET:
No, this is not considered a bug; no such behavior has ever been
promised. Read the fine manual.
(Your ac
On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote:
>
> I don't know if there is any way we can solve it, except by reverting
> back to 5.8 or advising users to use only one version.
I just had an idea--at least in the ActiveState distributions (not
sure about Strawberry or Vanilla) they incl
When I looked at the Windows Event Log I found this:
%t FATAL: bogus data in lock file
"postmaster.pid": ""
So what do I do now? I have already re installed and that didn't
help.
Christine
At 02:45 AM 4/23/2009, you wrote:
Christine,
when PostgreSQL does not start on Windows, the first place to
Ah, okay, found the documentation mentioning this (LIMIT). I was
looking in the wrong place (ORDER BY clause).
Thanks again for the help.
Tom Lane wrote:
"Thomas S. Chin" writes:
I noticed that the behavior of queries that involve LIMIT/OFFSET no longer
return results consistent with the or
"Ted Holzman" wrote:
> AGGREGATE functions don't appear to respond to LIMIT clauses.
Not a bug. LIMIT affects how many rows are in the result set the
LIMIT qualifies.
> select sum(generate_series)
> from generate_series(1,10) limit 3;
> sum
> -
> 55
> (1 row)
>
> I was expecting
The following bug has been logged online:
Bug reference: 4780
Logged by: Ted Holzman
Email address: tholz...@fhcrc.org
PostgreSQL version: 8.3.7
Operating system: SuSE Linux 10.3
Description:Aggregate functions are unaware of LIMIT clauses in
SELECTs
Details:
Hi,
I
The following nonsensical query causes PostgreSQL to fail with ERROR: plan
should not reference subplan's variable. (This was stripped down from an
'useful' query that triggered the same bug). First encountered on 8.3.4,
reproduced on 8.3.7
BEGIN;
CREATE SCHEMA bug_schema;
SET SEARCH_PATH='bug_
Daniel Grace writes:
> The following nonsensical query causes PostgreSQL to fail with ERROR: plan
> should not reference subplan's variable. (This was stripped down from an
> 'useful' query that triggered the same bug). First encountered on 8.3.4,
> reproduced on 8.3.7
Hmmm ... I guess somethin
On Fri, Apr 24, 2009 at 5:38 PM, Tom Lane wrote:
> Daniel Grace writes:
> > The following nonsensical query causes PostgreSQL to fail with ERROR:
> plan
> > should not reference subplan's variable. (This was stripped down from an
> > 'useful' query that triggered the same bug). First encounter
Daniel Grace writes:
> On Fri, Apr 24, 2009 at 5:38 PM, Tom Lane wrote:
>> Hmmm ... I guess something is getting confused about the level of query
>> nesting. FWIW, you can avoid the bug in these two examples by omitting
>> the inner "SELECT" keyword, which is useless anyway. Perhaps it is
>> n
I wrote:
> I'm talking about the underlined SELECT, not the one inside the
> aggregate. AFAICS this one is totally useless.
Oh, wait. It is useless in the query as written, but now that I think
twice about what you're trying to accomplish, you do need three levels
of SELECT keywords. Just not l
No luck there either (runs, but with incorrect results), but since I know
this isn't a support list and is a bugs list I just would like to point out
that: Even though what I was doing that triggered the bug is apparently
incorrect and 'silly', it's still possible that some complicated legitimate
q
Daniel Grace writes:
> No luck there either (runs, but with incorrect results), but since I know
> this isn't a support list and is a bugs list I just would like to point out
> that: Even though what I was doing that triggered the bug is apparently
> incorrect and 'silly', it's still possible that
23 matches
Mail list logo
