Hi,
I have loaded all my files into the database.Files has to
open like( html,asp,js etc pages) from the database via a
webserver.Please explain me whether there will be any
problem if i open .asp and .js files from the DB.As there will be some insertion
of values at the run time in these
On Apr 25, 2006, at 4:17 PM, Prasanth wrote:
But then my problem is I have to do a text dump to use iconv in which
case I will loose the large objects.
I tried using the iconv on the dump generated using the -Fc option and
then when I try to restore that I am getting the following error
pg_res
Usually a dump is significantly smaller than a live database due to
space taken up by indexes and discarded tuples from MVCC. If it's
significantly smaller you may also want to take a look at your vacuuming
procedure.
But I'm not sure database_size() is.
Jason Minion
[EMAIL PROTECTED]
Title: dbsize & pg_dump
Please
disregard this question. I’m using
pg_dump –F c which compresses the data a it backs it up.
Tim
-Original
Message-
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of mcelroy, tim
Sent: Tuesday, April 25, 2006 4:40
PM
To: 'pgsql-
Hi,
We recently migrated from 7.4.7 to 8.1.3. I did a pg_dumpall & then
pg_restore and it went fine.
Today I realized that the backups I am creating can't be used to reload
my database.
I use pg_dump -Fc to dump the database as I have Large Objects in the
database.
(I used to use pg_dump -b -Fc
Title: dbsize & pg_dump
Good afternoon,
Probably an easy question but why are the file sizes differ so much between these two tools?
For example:
A backup using pg_dump of our largest DB creates a file 384MB in size
Using the following SQL code utilizing dbsize I get the following:
FIX
Hi,
i get the following warning from pg_restore and would like to know if i can
safely ignore it, or some action should be taken.
pg_restore: creating FUNC PROCEDURAL LANGUAGE plpgsql_call_handler()
pg_restore: [archiver] WARNING: don't know how to set owner for object type
FUNC PROCEDURAL LA
"Andy Shellam" <[EMAIL PROTECTED]> writes:
> If this is a bug in 7.3, and it's not in later versions, I doubt the
> developers will be in any hurry to fix it, I don't know - maybe someone
> knows a quick patch fix, or if it was fixed in a later version of the 7.3
> series - as that would only be a
Hi to all,
We just tried to switch out database from LATIN 1
(ISO 8859-1) to UTF-8. After a few tests we found out some
problems:
- the upper and lower functions does not work
for all characters. Especially lower returns nothing if a umlaut is in the
converted string. The umlauts are not
Hi,
I have loaded all my files into the database.Files has to
open like( html,asp,js etc pages) from the database via a
webserver.Please explain me whether there will be any
problem if i open .asp and .js files from the DB.As there will be some insertion
of values at the run time in these fi
Hi Pascal,
If this is a bug in 7.3, and it’s
not in later versions, I doubt the developers will be in any hurry to fix it, I
don’t know – maybe someone knows a quick patch fix, or if it was
fixed in a later version of the 7.3 series – as that would only be a
minor upgrade (e.g. 7.3.2 to
Hi Pascal,
7.3 is now quite out-dated – have you
tried the latest release, 8.1.3, to see if the problem is still present?
Andy
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pascal Tufenkji
Sent: 25 April 2006 10:02 am
To: pgsql-admin@postgresql.org
Sub
Hi,
I just noticed a bug in PostgreSQL 7.3.2
I don't know if it exists in other
versions
If I have a UNICODE database and I make
the following query
SELECT * FROM table where
code like 'abcz%';
Or
SELECT * FROM table where
code like 'abcz_';
(or anything that ends with z% or z
"Gourish Singbal" <[EMAIL PROTECTED]> writes:
> Do we need to Disable the Auto-vacuum deamon when we manually run the
> database-wide vacuum command ?.
No.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' th
14 matches
Mail list logo