On Tue, 2004-04-13 at 01:44, Michal Hlavac wrote:
Hello,
I am working on web portal. There are some ads. We have about 200 000
ads. Every ad have own directory called ID, where is 5 subdirectories
with various sizes of 5 images.
Filesystem is too slow. But I don't know, if I store these
I'm running 7.4.8 on RHEL 3.0 x86.
Today, on two separate servers, I modified the resolv.conf file to point
from two functioning name servers to two others.
Within 5 minutes, one server would not accept new remote connections. I
could log in fine w/ psql locally.
All name servers involved were
Within 5 minutes, one server would not accept new remote connections. I
could log in fine w/ psql locally.
This is pretty bizarre ... offhand I would not have thought that the
postmaster depended on DNS service at all. Were you maybe using DNS
names instead of IP addresses in
The higher-ups are attempting to force me to run Postgres over NFS at
least temporarily.
Despite giving me a queasy feeling and reading quite a bit of messages
advising against it, running Oracle over NFS with a NAS filer doesn't
seem to be unusual. Is there a reason PG would be more sensitive
On Thu, 2004-08-05 at 07:37, Tom Lane wrote:
No --- the issues are not with Postgres per se but with the reliability
of your NFS setup. On top of the not-infinite reliability of disk drive
hardware you now have to stack risk of failure of the NAS machine itself,
network problems, and
On Tue, 2004-08-24 at 15:01, Greg Donald wrote:
when it obviously was not. The price was right and I knew going in I
wasn't getting a perfectly stable distro, but nevertheless they left me
with a broken machine on several occasions. Having a slightly faster
machine isn't worth the headaches
On Tue, 2004-08-31 at 15:07, Joe Conway wrote:
I suppose there *may* be some fundamental technical difference that
makes Postgres less reliable than Oracle when using NFS, but I'm not
sure what it would be -- if anyone knows of one, please speak up ;-).
Early testing on NFS mounted NAS has
On Tue, 2004-08-31 at 20:37, Joe Conway wrote:
However, my results changed drastically under the 2.6 kernel, when the
NFS results stayed about the same as 2.4, but the SAN jumped about 50%
in transactions per second.
Very interesting. Whose SAN are you using that supports the 2.6
I have come up with a simple query that runs horribly depending on the
number of columns selected.
select order_lines.*
from orders, order_lines
where orders.merchant_order_id = '11343445' and
order_lines.order_id=orders.order_id;
merchant_order_id is indexed.
order_id is indexed.
Tables are
Oops, sorry - guess I left that out - 7.4.5. :)
On Fri, 2004-10-22 at 12:28, Tom Lane wrote:
Cott Lang [EMAIL PROTECTED] writes:
- Sort (cost=nan..nan rows=2023865 width=1257)
What PG version is this? My recollection is we fixed such a thing quite
some time ago
shared_buffers = 16384
sort_mem = 8192
random_page_cost = 2
effective_cache_size = 3932160
On Fri, 2004-10-22 at 13:32, Tom Lane wrote:
Cott Lang [EMAIL PROTECTED] writes:
Oops, sorry - guess I left that out - 7.4.5. :)
Hmm ... I can't duplicate any misbehavior here. Are you using
On Fri, 2004-10-22 at 14:19, Tom Lane wrote:
Cott Lang [EMAIL PROTECTED] writes:
sort_mem = 8192
random_page_cost = 2
effective_cache_size = 3932160
effective_cache_size 30Gb ? Seems a tad high ;-)
It's a 32GB machine with nothing else running on it except PG, buffers
hover around 31GB
ERROR: could not convert UTF-8 character 0x00ef to ISO8859-1
Running 7.4.5, I frequently get this error, and ONLY on this particular
character despite seeing quite a bit of 8 bit. I don't really follow why
it can't be converted, it's the same character (239) in both character
sets. Databases are
act together and
write something with more detail.
- Mike
At 12:12 PM 10/29/2004, Cott Lang wrote:
ERROR: could not convert UTF-8 character 0x00ef to ISO8859-1
Running 7.4.5, I frequently get this error, and ONLY on this particular
character despite seeing quite a bit of 8
We're running 8.3.5 on RHEL4 x86_64.
We removed a user yesterday and were greeted with warnings from pg_dump
this morning. :)
pg_dump: WARNING: owner of data type pg_toast_80075 appears to be
invalid
The usual archives and google searches produced mainly 8.0 and earlier
incidents and suggested
On Fri, 2009-02-20 at 11:25 -0800, Joshua D. Drake wrote:
You can use alter type to change the owner of the type to a valid user
but see above. Something is wrong.
That's what I thought too, but we tried that first with these results:
# alter type pg_toast.pg_toast_80075 OWNER TO
test. If #2 should never happen, I
can see why #1 wouldn't be much of an issue.
I can't recreate #2.
On Fri, 2009-02-20 at 14:32 -0500, Tom Lane wrote:
Cott Lang c...@internetstaff.com writes:
The owner of the actual table and index is correct, only the type has an
invalid owner. I have
On Fri, 2009-02-20 at 16:35 -0500, Tom Lane wrote:
Can you see any pattern or common characteristic to the tables whose
toast pg_type rows failed to change owner? I'm not sure what to look
for exactly, but similarities in the column contents might be a
possibility. Also, can you tell if the
18 matches
Mail list logo
