On Wed, Jul 15, 2009 at 7:18 PM, Don Fox wrote:
> I am having installation problems with postrgesql on my mac. I'v tried
> MacPorts, your site and PostgreSQLforMac. I've tried 8.3.7 and the most
> current version. After each install I'm unable to locate any actual access
> to the DB. When installi
I am having installation problems with postrgesql on my mac. I'v
tried MacPorts, your site and PostgreSQLforMac. I've tried 8.3.7 and
the most current version. After each install I'm unable to locate any
actual access to the DB. When installing from the disk image I'm told
that the data-
"Jim Michaels" writes:
> 2. pg_restore doesn't seem to do anything but hang when I try to restore.
> I did a pg_dumpall from 8.3.7:
> pg_dumpall --file=c:\pg-jmichae3-7-13-2009.sql --role=postgres
> --host=localhost --port=5432
> then I did a pg_restore to 8.4:
> pg_restore --file=c:\pg-jmichae3-
The following bug has been logged online:
Bug reference: 4924
Logged by: Jim Michaels
Email address: jmich...@yahoo.com
PostgreSQL version: 8.4.0
Operating system: Windows XP Pro SP3
Description:pg_restore hangs, does nothing
Details:
I am on Windows XP Pro SP3.
1.
Yeah, and I don't feel I know enough to answer that.
Thanks for responding! Good luck with your decision.
Regards,
Alan
On Jul 15, 2009, at 11:33 AM, Tom Lane wrote:
Alan Pinstein writes:
The real solution might be to just convert a 0-dim array into "null"
or equivalent and still assert er
Hmm. ltree has always had that ARR_NDIM == 1 check. I think the
reason
the behavior changed is that ARRAY(SELECT ...) used to return a NULL
for
zero rows, and now it returns an empty (zero-dimensional) array.
Ah OK that makes sense, especially given the "hack" I used as a
workaround, whi
Alan Pinstein writes:
> The real solution might be to just convert a 0-dim array into "null"
> or equivalent and still assert error if dims >= 2?
That's my alternative #1. The question is whether there's any real
point in rejecting multi-dimensional arrays here, rather than just
searching all
On 7/15/09, David Wilson wrote:
> On Wed, Jul 15, 2009 at 11:10 AM, Marko Kreen wrote:
> > From security standpoint, wasting more cycles on bad passwords is good,
> > as it decreases the rate bruteforce password scanning can happen.
> >
> > And I cannot imagine a scenario where performance on
David Wilson writes:
> On Wed, Jul 15, 2009 at 11:10 AM, Marko Kreen wrote:
>> From security standpoint, wasting more cycles on bad passwords is good,
>> as it decreases the rate bruteforce password scanning can happen.
>>
>> And I cannot imagine a scenario where performance on invalid logins
>>
On Wed, Jul 15, 2009 at 11:10 AM, Marko Kreen wrote:
> From security standpoint, wasting more cycles on bad passwords is good,
> as it decreases the rate bruteforce password scanning can happen.
>
> And I cannot imagine a scenario where performance on invalid logins
> can be relevant..
DoS attack
"Alan Pinstein" writes:
> ... hierarchy @> ARRAY(select hierarchy from
> feature where description ilike '%pool%this%') ...
> EXPECTED BEHAVIOR:
> - return 0 rows
> ACTUAL BEHAVIOR:
> ERROR: array must be one-dimensional
> Possibly from:
> https://projects.commandprompt.com/public/replicator/
On 7/15/09, Tom Lane wrote:
> Alvaro Herrera writes:
>
> > toruvinn wrote:
> >> I was always wondering, though, why PostgreSQL uses this approach and not
> >> its catalogs.
>
> > It does use the catalog for most things. THe flatfile is used for the
> > situations where the catalogs are not y
Alvaro Herrera writes:
> toruvinn wrote:
>> I was always wondering, though, why PostgreSQL uses this approach and not
>> its catalogs.
> It does use the catalog for most things. THe flatfile is used for the
> situations where the catalogs are not yet ready to be read.
Now that we have SQL-leve
toruvinn wrote:
> On Wed, 15 Jul 2009 16:02:09 +0200, Alvaro Herrera
> wrote:
>> My bet is on the pg_auth flat file. I doubt we have ever tested the
>> behavior of that code with 1 billion users ...
> I was always wondering, though, why PostgreSQL uses this approach and not
> its catalogs.
I
On Wed, 15 Jul 2009 16:02:09 +0200, Alvaro Herrera
wrote:
My bet is on the pg_auth flat file. I doubt we have ever tested the
behavior of that code with 1 billion users ...
I've noticed this behaviour some time ago, on a cluster with 50k+ roles
(not sure about the number now). Restoring the
This issue still seems unaddressed.
Andreas Pflug wrote:
> The installer claimed a non-fatal problem, cluster is up and running.
> Excerpt from install-postgresql.log
>
> Installing pl/pgsql in the template1 databases...
> psql: Warnung: berflssiges Kommandozeilenargument ¯CREATE LANGUAGE
> plp
So as promised - the patch is very stable. No more memory problems,
neither any other issues.
Great job Yamada-san
Dave - can I assume you'll manage this fix to be pushed to official
release?
On 9 Lip, 17:08, wstrzalka wrote:
> Looks very good by now.
>
> I'll test the version f
Lauris Ulmanis wrote:
> Hello again!
>
> I did test on my local test server
>
> I created up 500 000 users in function loop very quickly - within 48
> seconds. I did again this script reaching up to 1 billion users - results
> was the same - 48 seconds. It is very quickly.
>
> But problem seems
Hi
reading google.. i come to here... maybe i can help more about this issue.
on server pglog:
2009-07-15 09:40:27 BRTLOG: could not receive data from client: Unknown
winsock error 10061
2009-07-15 09:40:27 BRTLOG: unexpected EOF on client connection
2009-07-15 09:41:35 BRTLOG: could not rece
Sergey Konoplev escribió:
> We faced this segfault few times during the last couple of days. This days
> our server was extremly loaded. Before and after this period when LA was
> quite normal everything was alright.
I've seen this before. It's a PGQ bug. Please update it; the latest
version fi
Hi Tom,
Op dinsdag 14 juli 2009, schreef Tom Lane:
> I think the attached patch will fix it for you.
Yep, after applying it yesterday evening, we didn't see this problem at all
today, so it definitely looks as if this patch nailed it.
Thanks for the [great|quick] support !
--
Best,
Fra
Hello again!
I did test on my local test server
I created up 500 000 users in function loop very quickly - within 48
seconds. I did again this script reaching up to 1 billion users - results
was the same - 48 seconds. It is very quickly.
But problem seems is with transaction preparation because
2009/7/14 Tom Lane :
> Tom Lane wrote:
I've applied the patch - I hope it will fix our problem. I will ask
users of our application to do those things they did when the error
was thrown. Thanks a lot Tom.
ML
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
The following bug has been logged online:
Bug reference: 4921
Logged by: Alan Pinstein
Email address: apinst...@mac.com
PostgreSQL version: 8.3.6
Operating system: linux/centos 5.3
Description:ltree @> ltree[] operator shouldn't fail if ltree[] is
empty
Details:
The
The following bug has been logged online:
Bug reference: 4922
Logged by: Sergey Konoplev
Email address: gray...@gmail.com
PostgreSQL version: 8.3.5
Operating system: CentOS 5.2 x86-64
Description:Segmentation fault on high-loaded server (+coredump
backtrace)
Details:
25 matches
Mail list logo
