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
't know if that's a valid 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 writes:
> > The owner of the actual table and index is correct, only the
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 post
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 suggeste
> 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 pg_hba.co
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
e information than you require, but I thought I'd
> add it anyway so that the information is in the archives. It took us
> months to solve our problem, even with help from the postgres community, so
> I at least want the basics to be posted while I get my act together and
> wr
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 i
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
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 misbeh
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 thi
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 an
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.
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
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 headach
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 misc
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 th
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 t
On Wed, 2004-01-21 at 09:05, Brian Maguire wrote:
> In my opinion, it really is a critical feature to support and administer
> enterprise databases. All the major databases currently support this
> and it is a compelling enough reason drive big users from away from
> using postgres for their ente
19 matches
Mail list logo
