These numbers don't even have any demonstrable connection to Postgres,
let alone to an xpath-related memory leak. You're going to need to come
up with a concrete test case if you want anyone to investigate.
regards, tom lane
As I said in the start of this thread, this
Tom Tom wrote:
Tom Tom wrote:
Hello,
We have a very strange problem when restoring a database on Windows XP.
The PG version is 8.1.10
The backup was made with the pg_dump on the same machine.
pg_restore -F c -h localhost -p 5432 -U postgres -d configV3 -v
c:\Share\POSTGRES.backup
Am Wednesday, 6. August 2008 schrieb erithema:
SELECT id_autori , xpath ('/Authority/Nome', testo)
FROM autori
WHERE xpath_bool('/Authority[Nome=ABELARDO]', testo) ;
I get this error:
ERROR : the function xpath_bool(unknown , xml) do not exsist at character
69 HINT: no function matches
Am Wednesday, 6. August 2008 schrieb sagswe:
When i run ' \i /usr/local/pgsql/share/pgxml.sql' in postgre , I get error
saying file or directory named 'MODULE_PATHNAME' doesn't exist. How to get
this MODULE_PATHNAME exist?.
This sounds like your installation is botched? How did you install
Dear Friends,
I have tried to set datestyle to 'DMY'. As per manual and many other posts
related to this point, I have set datestyle to 'DMY' at database. but still
it is needed to execute each time *set datestyle to 'DMY' *before starting
any new connection. Once this is set, there is no problem
C K wrote:
Dear Friends,
I have tried to set datestyle to 'DMY'. As per manual and many other
posts related to this point, I have set datestyle to 'DMY' at database.
but still it is needed to execute each time *set datestyle to 'DMY'
*before starting any new connection. Once this is set,
Hello all,
could you please recommend tools to make diagnostic, admin and
maintenance work easier...
I imagine there are tools (maybe graphical, or browser based) that allow
me to connect to postgres and receive diagnostic data and
pointers/recommendations on how to solve specific problems or
Tom Lane wrote:
Jack Orenstein [EMAIL PROTECTED] writes:
The question is how to check for consistency in the case of
large tables, which are split into multiple segments, (e.g. 123456.1,
123456.2). I.e., how can I find out how many segments there should be?
The kernel-defined EOF is the
Hello all,
I'm finding it very strange that my pg takes 9Giga on disk but
pg_dumpall produces a 250Mega dump. 'VACUUM FULL' was executed
yesterday.
Is this normal ? Should I be worried ?
details bellow:
On Sun, 10 Aug 2008, Scott Marlowe wrote:
The good news is that both Centos 5.2 and Ubuntu 7.10 seem immune to
this particular bug, and have been running 13 hours now without a
hitch.
Not sure if it's relevant here, but you do know that I've been kicking
back to lkml that pgbench has issues
Hello,
The following is the procedure to calculate the disk space occupied by
postgresql from a flat file.
http://www.postgresql.org/docs/faqs.FAQ.html#item4.5
In this I didn't understood some terms
24 bytes: each row header (approximate)
24 bytes: one int field and
On Mon, 11 Aug 2008, Joao Ferreira gmail wrote:
I'm finding it very strange that my pg takes 9Giga on disk but
pg_dumpall produces a 250Mega dump. 'VACUUM FULL' was executed
yesterday.
If you've been running VACUUM FULL, it's probably so-called index bloat.
Try running the query at
On Mon, Aug 11, 2008 at 10:30 AM, Joao Ferreira gmail
[EMAIL PROTECTED] wrote:
Hello all,
I'm finding it very strange that my pg takes 9Giga on disk but
pg_dumpall produces a 250Mega dump. 'VACUUM FULL' was executed
yesterday.
Is this normal ? Should I be worried
I am fairly new to Postgres. I noticed that the stored procedures
written in pgplsql are checked only for syntax errors and nothing more
at compile time. It does not even do that basic error checking like if
the table/field names or variable names used in the procedure are even
valid. This
On Monday 11 August 2008 20:15:37 Mani, Arun wrote:
Is there a configuration setting to increase the error checking level or
any tool available to do the same.
No
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
thank you!!!
=]
2008/8/8 Hiroshi Saito [EMAIL PROTECTED]
Hi.
Is this helpful?
http://winpg.jp/~saito/psqlODBC/psqlODBC64/http://winpg.jp/%7Esaito/psqlODBC/psqlODBC64/
as for AMD64.
http://www.geocities.jp/inocchichichi/psqlodbc/index.html
Regards,
Hiroshi Saito
- Original Message
I'd do
du -sh /var/pgsql/data/base
rather then /var/pgsql/data
depending on how your pgsql server logging is setup, there are other
folders and/or files that might take considerable disk space under
./data/ you may want to exclude those. I find this query useful for
something like this as
Greetings!
Sometimes I need to track down how something happens in the database our
application relies on, but whatever's happening may be buried in some
old function that everybody here has forgotten about long ago. IIRC,
functions are stored internally merely as fields in a table owned by the
Jack Orenstein wrote:
Tom Lane wrote:
All segments before the last one should be exactly 1GB, but the last
one can be anything up to that. Consult the comments in md.c for
more details. (I think 7.4 may treat some corner cases differently
from 8.3 anyway.)
Just to be clear, you mean
I'm startled that I've never done this before, but... I have a PL/
pgSQL function that takes no arguments, returns VOID, and has a bunch
of side effects on the database. The correct way of invoking this
function is:
SELECT my_func();
... yes? Thanks; it seems to work fine, but
Rob Richardson wrote:
Sometimes I need to track down how something happens in the database
our application relies on, but whatever's happening may be buried in
some old function that everybody here has forgotten about long ago.
IIRC, functions are stored internally merely as fields in a table
On Monday 11 August 2008 4:24:17 pm Christophe wrote:
I'm startled that I've never done this before, but... I have a PL/
pgSQL function that takes no arguments, returns VOID, and has a bunch
of side effects on the database. The correct way of invoking this
function is:
SELECT
Christophe [EMAIL PROTECTED] writes:
I'm startled that I've never done this before, but... I have a PL/
pgSQL function that takes no arguments, returns VOID, and has a bunch
of side effects on the database. The correct way of invoking this
function is:
SELECT my_func();
... yes?
On Mon, Aug 11, 2008 at 6:03 PM, Adrian Klaver [EMAIL PROTECTED] wrote:
On Monday 11 August 2008 4:24:17 pm Christophe wrote:
I'm startled that I've never done this before, but... I have a PL/
pgSQL function that takes no arguments, returns VOID, and has a bunch
of side effects on the
In reference to the script below (I know it can be rewritten, that's not the
point), I get 3 rows if the referenced index exists but only two rows if it
does not. This is observable and repeatable just by dropping/creating the
index. Drop the index and two rows are returned. Create the index,
25 matches
Mail list logo
