On 16/12/2009 10:31 AM, Mark Williamson wrote:
What is the most ideal/optimal platform for postgresql? Linux
(distro?), freebsd, windows, etc.
Pg has been around on UNIX-like platforms for longer than Windows, and
is better tested on those platforms. Its design is also more friendly
toward U
What is the most ideal/optimal platform for postgresql? Linux
(distro?), freebsd, windows, etc.
consider memory management, file system performance, threading model
etc.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgre
Robert Haas writes:
> On Tue, Dec 15, 2009 at 3:45 PM, Tom Lane wrote:
>> Put a ulimit command in the server start script? Depending on the
>> details of the start script you might need to put it in the postgres
>> user's .profile instead, but it's certainly doable.
> This may be a stupid quest
On Tue, Dec 15, 2009 at 3:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> Err, sorry, I quoted the wrong part. I meant, how would you rlimit
>> the server memory usage?
>
> Put a ulimit command in the server start script? Depending on the
> details of the start script you might need to put it i
Robert Haas writes:
> Err, sorry, I quoted the wrong part. I meant, how would you rlimit
> the server memory usage?
Put a ulimit command in the server start script? Depending on the
details of the start script you might need to put it in the postgres
user's .profile instead, but it's certainly
On Tue, Dec 15, 2009 at 2:42 PM, Alvaro Herrera
wrote:
> "This bug report form can be used for reporting bugs and problems with
> the PostgreSQL database, for problems with database connectors such as
> ODBC and JDBC, graphical administration tools such as pgAdmin or other
> external projects do n
On Tue, Dec 15, 2009 at 04:42:06PM -0300, Alvaro Herrera wrote:
> Stefan Kaltenbrunner escribió:
> > Alvaro Herrera wrote:
>
> > >I think it's a good idea to mention some specific more problematic names
> > >like the three listed.
> >
> > yeah maybe - but afaik the products are not named "psql-od
On Tue, Dec 15, 2009 at 1:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Dec 15, 2009 at 1:23 PM, Tom Lane wrote:
>>> Alvaro Herrera writes:
If we're to do anything about this, it is spilling the trigger queue so
it doesn't eat an unbounded amount of memory.
>>>
>>> Of course
Stefan Kaltenbrunner escribió:
> Alvaro Herrera wrote:
> >I think it's a good idea to mention some specific more problematic names
> >like the three listed.
>
> yeah maybe - but afaik the products are not named "psql-odbc" or
> "pgsql-jdbc" - those are more or less list names and likely not of
>
On Tue, Dec 15, 2009 at 08:34:14PM +0100, Stefan Kaltenbrunner wrote:
> Alvaro Herrera wrote:
> >Stefan Kaltenbrunner escribió:
> >
> >>hmm - not sure that is too clear especially because I don't think
> >>ther is only JDBC/ODBC or pgadmin (nor do I think you names match up
> >>with how they are re
postgres bee wrote:
> insertion time is increasing as the data in the table is growing.
You have given no indication that there is a bug. Please re-post to
the performance list, but first you should read these pages (both
referenced in the description of the performance list):
http://wiki.p
Alvaro Herrera wrote:
Stefan Kaltenbrunner escribió:
hmm - not sure that is too clear especially because I don't think
ther is only JDBC/ODBC or pgadmin (nor do I think you names match up
with how they are really called). what about doing it the other way
round like:
"This bug report form can
We have seen a strange situation with postgres 8.3.6 taking longer times for
inserting a fixed amount of data. The insertion time is increasing as the data
in the table is growing. We tried to use COPY command but to no avail. The
increase is also not linear. Insert is one of the basic oper
Stefan Kaltenbrunner escribió:
> hmm - not sure that is too clear especially because I don't think
> ther is only JDBC/ODBC or pgadmin (nor do I think you names match up
> with how they are really called). what about doing it the other way
> round like:
>
> "This bug report form can be used for r
Robert Haas wrote:
On Tue, Dec 15, 2009 at 12:22 PM, Magnus Hagander wrote:
And to the list: can we PLEASE, PRETTY PLEASE add a note about this on
the bug submission page? I asked for this before and Tom concurred,
but I'm not aware that anything has been done about it. What do I
have to do t
Robert Haas writes:
> On Tue, Dec 15, 2009 at 1:23 PM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> If we're to do anything about this, it is spilling the trigger queue so
>>> it doesn't eat an unbounded amount of memory.
>>
>> Of course, the reason nothing much has been done about that is tha
On Tue, Dec 15, 2009 at 12:22 PM, Magnus Hagander wrote:
>> And to the list: can we PLEASE, PRETTY PLEASE add a note about this on
>> the bug submission page? I asked for this before and Tom concurred,
>> but I'm not aware that anything has been done about it. What do I
>> have to do to make thi
On Tue, Dec 15, 2009 at 1:23 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> If we're to do anything about this, it is spilling the trigger queue so
>> it doesn't eat an unbounded amount of memory.
>
> Of course, the reason nothing much has been done about that is that
> by the time your trigger
Alvaro Herrera writes:
> If we're to do anything about this, it is spilling the trigger queue so
> it doesn't eat an unbounded amount of memory.
Of course, the reason nothing much has been done about that is that
by the time your trigger queue is long enough to cause such an issue,
you're screwed
Robert Haas escribió:
> On Tue, Dec 15, 2009 at 11:02 AM, Greg Stark wrote:
> > On Tue, Dec 15, 2009 at 3:44 PM, Robert Haas wrote:
> >> This is an
> >> issue that other people have run into in the past, and I don't think
> >> we have a good solution. I wonder if we should put some kind of a
>
On Tue, Dec 15, 2009 at 5:18 PM, Robert Haas wrote:
> I suppose that I could fix this by getting rid of my swap partition
> altogether, but that seems a rather extreme solution, and it's
> certainly not the way most UNIX/Linux systems I run across are
> configured, if for no other reason than that
On Tue, Dec 15, 2009 at 18:21, Robert Haas wrote:
> On Mon, Dec 14, 2009 at 2:57 AM, Gerhard Lutz
> wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5242
>> Logged by: Gerhard Lutz
>> Email address: gerhard.l...@mbtech-group.com
>> PostgreSQL version:
On Mon, Dec 14, 2009 at 2:57 AM, Gerhard Lutz
wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5242
> Logged by: Gerhard Lutz
> Email address: gerhard.l...@mbtech-group.com
> PostgreSQL version: 8.4.1
> Operating system: Windows XP
> Description:
On Tue, Dec 15, 2009 at 12:07 PM, Greg Stark wrote:
> On Tue, Dec 15, 2009 at 4:16 PM, Robert Haas wrote:
>> I didn't know that, but it I think by the time malloc returns 0
>> usually other bad things are happening. I don't think that's really
>> an answer.
>
> Only if, as Craig said and you dis
On Tue, Dec 15, 2009 at 4:16 PM, Robert Haas wrote:
> I didn't know that, but it I think by the time malloc returns 0
> usually other bad things are happening. I don't think that's really
> an answer.
Only if, as Craig said and you disputed, you have overcommit enabled
or lots of swap.
There is
On Mon, Dec 14, 2009 at 11:15 PM, Philip Graham wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5244
> Logged by: Philip Graham
> Email address: phi...@lightbox.org
> PostgreSQL version: 8.3.8
> Operating system: Linux
> Description: Attempting t
On Tue, Dec 15, 2009 at 11:02 AM, Greg Stark wrote:
> On Tue, Dec 15, 2009 at 3:44 PM, Robert Haas wrote:
>> This is an
>> issue that other people have run into in the past, and I don't think
>> we have a good solution. I wonder if we should put some kind of a
>> limit in place so that queries
On Tue, Dec 15, 2009 at 3:44 PM, Robert Haas wrote:
> This is an
> issue that other people have run into in the past, and I don't think
> we have a good solution. I wonder if we should put some kind of a
> limit in place so that queries like this will at least fail relatively
> gracefully with a
The following bug has been logged online:
Bug reference: 5245
Logged by: Brian Krug
Email address: bk...@usatech.com
PostgreSQL version: 8.4.1
Operating system: Solaris 10
Description:Full Server Certificate Chain Not Sent to client
Details:
I setup a postgres serve
I upgraded to 8.4.2, did a full reindex and vacuum (there were
no errors). But it segfaults as well:
Core was generated by `postgres: randir lovehunter 127.0.0.1(48268)
SELECT '.
Program terminated with signal 11, Segmentation fault.
[New process 7262]
#0 slot_deform_tup
On Tue, Dec 15, 2009 at 12:09 AM, Craig Ringer
wrote:
> On 15/12/2009 12:35 PM, Mark Williamson wrote:
>
>> So what happened is, the above update never completed and the Postgresql
>> service consumed all available memory. We had to forcefully reboot the
>> machine
>
> That means your server is m
Andrew Gierth writes:
> BTW, did #4907 ever get fixed in the back branches?
No, I didn't think it was prudent to back-patch it. Also, #5240
represents an actual regression (cases that worked before 8.4 now
fail) whereas the plpgsql cases never have worked.
regards, tom l
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> I don't think it's particularly closely related to #4907.
Tom> Yeah.
BTW, did #4907 ever get fixed in the back branches?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
33 matches
Mail list logo
