Tom Lane wrote:
Gunasekaran Balakrishnan [EMAIL PROTECTED] writes:
creating conversions... ERROR: could not access file
"$libdir/ascii_and_mic": No such file or directory
What does "pg_config --pkglibdir" report? Is ascii_and_mic.so actually
present in that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
How about plugging in more memory ?
40MB seems a bit low for a database server footprint - well, certainly depends
on what you do.
But if your machine starts swapping with an extra 40 MB of memory consumption
I'd say the machine is undersized for
sferriol [EMAIL PROTECTED] writes:
and i create a rule for deleting using the view:
CREATE RULE ALL_CENTERS_DEL AS ON DELETE TO all_centers
DO INSTEAD (
DELETE FROM center_var WHERE
center_id = OLD.center_id;
DELETE FROM center WHERE
center_id = OLD.center_id;
);
I apologize for my original post being unclear. I'm
running vacuum analyze and seeing the behavior
mentioned. Does specifying the analyze option imply
vacuum full?
On a hunch I just ran analyze really big table and
the backend's memory usage soared up to 100+ megs. I
suspect that means it
I agree in principle that the solution is to run on a
server with more memory instead of my local
development box. However, I'm not going to be able to
simply request that additional memory be installed as
these are standard boxes that IT distributes to
employees.
Regardless, I'm more curious
Gunasekaran Balakrishnan [EMAIL PROTECTED] writes:
So, is this path configurable at runtime ?
No.
This was not the case with 7.2.2 where I could place the
binaries/libraries in a different place than where it was installed
during compilation.
We have never supported moving stuff around from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 25 March 2004 09:12 am, Shelby Cain wrote:
I agree in principle that the solution is to run on a
server with more memory instead of my local
development box. However, I'm not going to be able to
simply request that additional memory
You can make it interactive if you are working from a unix box.
[EMAIL PROTECTED]:~$ more zip.sql
\echo -n 'Zip to search for: '
\set value `read input; echo $input`
select * from zipcode where zip = :value
Not sure how/if you could do this on a windows box.
Take Care,
James
On Thursday 25
Shelby Cain [EMAIL PROTECTED] writes:
I apologize for my original post being unclear. I'm
running vacuum analyze and seeing the behavior
mentioned. Does specifying the analyze option imply
vacuum full?
No; I just figured you were probably using FULL without saying so.
However ...
On a
Bas Scheffers [EMAIL PROTECTED] writes:
2) You will need 1/3 team size that does it in 1/3 of the time, which means
less billable hours and re-inforces point 1 as banking clients like
expensive, over-engineered projects.
(Obnit: fewer for countable objects like hours)
/sarcasm
I'm
Currently my default is 300 (yes - very large I know)
but overriding default_statistics_target with a value
of 1 and re-running vacuum analyze on the same large
table results in no change in maximum memory
consumption during the process that I can see. It
should be noted that I see this behavior
Changing config.status, now that's what I call a quick and dirty hack.
The attached diff against 7.4.2 incorporates Joe Conway's checks for
getqwuid_r() has 4/5 arguments with a pthread compile autoconf check
that I found a while back in the gnu autoconf archives.
I think we should change
SW == Steve Wampler [EMAIL PROTECTED] writes:
SW Hi,
SW I just discovered that perl module: DBIx::SearchBuilder 0.97
SW has a LoadByCols() method that builds a generic SELECT
SW query that seems to assume '' is a valid value to test on
SW any field. (The code is :
All such bugs should be out
I had thought that I had dropped and reloaded this
table but apparently I hadn't and I had set the
statistics target for one column to 500 while
experimenting. Resetting it to -1 and running with a
default of 300 gets ~ 70 megs memory footprint during
the analyze now.
Thanks Tom for indulging my
Michael Meskes wrote:
On Thu, Mar 25, 2004 at 08:07:04AM -0600, [EMAIL PROTECTED] wrote:
I verified last night that this problem also occurs with 7.4.2. I did some
Hmm, I know some fix was discussed. But maybe it just went into HEAD.
Yes, please download CVS HEAD or the nightly snapshots
Why don't you apply a cascading delete on center?
See bottom of
http://www.postgresql.org/docs/7.4/interactive/ddl-constraints.html :
... shipping_address text,
...
);
CREATE TABLE order_items (
product_no integer REFERENCES products ON DELETE RESTRICT,
order_id integer
On Thursday 25 March 2004 12:19, Manfred Koizar wrote:
On Tue, 23 Mar 2004 22:25:17 +0100, Rob Hoopman [EMAIL PROTECTED] wrote:
What solutions are there to storing a wide/shallow self referencing tree
in a database?
contrib/ltree (http://www.sai.msu.su/~megera/postgres/gist/ltree/) or
Joe's
[EMAIL PROTECTED] wrote:
We had this in the past. I'm not sure and would have to search the
archives but I vaguely remember that this has been a threading bug in
the Solaris version. Could you please try using 7.4.2 or cvs head where
this should be fixed. Alternatively you could try with
David Garamond wrote:
Is there anyone using object table in Oracle? How does it differ from
table inheritance in PG (aside from the declaration syntax).
I actually just found out about table inheritance today, and absolutely
love it! However, it's a shame if this feature is totally
I'm confused, where was the sarcasm?
Sarcasm: A form of wit that is marked by the use of sarcastic language
and is intended to make its victim the butt of contempt or ridicule.
The banks, an corporations that act just like them, being the victim,
obviously...
Bas.
Thanks Pascal. You just helped me :o)
On Tuesday 17 February 2004 06:39 am, Pascal Polleunus saith:
I hope it will at least help some one...
Pascal
--
Work: 1-336-372-6812
Cell: 1-336-363-4719
email: [EMAIL PROTECTED]
---(end of
On 3/25/04 3:43 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I assume you were using 7.4.0, rather than 7.4.2. Current CVS has in
template/solaris:
# tools/thread/thread_test must be run
# -D_POSIX_PTHREAD_SEMANTICS enables 5-arg getpwuid_r, among other
things
if test $GCC = yes
then
Yep. As I said in a previous email, this is fixed in current CVS and
will be fixed in 7.4.3. Here is the template/solaris file you need:
---
if test $GCC != yes ; then
CC=$CC -Xa # relaxed ISO C mode
[EMAIL PROTECTED] wrote:
On 3/25/04 7:27 AM, Jan Wieck [EMAIL PROTECTED] wrote:
One other problem I am looking into (and why I tried to compile with
thread safety in the first place) is that this somehow did not turn on
-D_REENTRANT in the CFLAGS for libpq. And that leads to libpq not
Jan Wieck wrote:
This problem was just recently fixed in cvs and will go out in the 7.4.3
release. For no your best bet is to checkout the 7.4 branch from cvs, or
search the pgsql-committers archives to find the patch you need to apply.
Isn't that funny ... I just yesterday ran into
Jan Wieck wrote:
Changing config.status, now that's what I call a quick and dirty hack.
The attached diff against 7.4.2 incorporates Joe Conway's checks for
getqwuid_r() has 4/5 arguments with a pthread compile autoconf check
that I found a while back in the gnu autoconf archives.
I
26 matches
Mail list logo
