Στις Πέμπτη 08 Μάρτιος 2007 22:02, ο/η Lukas έγραψε:
> Hello,
>
> we have one table in database (db has over 200 tables), which has one
> byteA filed for storing user photos. We are making backup every night, but
> it is now too large because of photos. We do not need to make backup of
> photos ev
Hello,
pg_dump can avoid bloob fields (it can dumb without blobs), but as I
understand byteA is not bloob, so in this case what is blob? I did not
found such type as blob..
Lukas
> Στις Πέμπτη 08 Μάρτιος 2007 22:02, ο/η Lukas
> έγραψε:
>> Hello,
>>
>> we have one table in database (db has ove
Στις Παρασκευή 09 Μάρτιος 2007 11:00, ο/η Lukas έγραψε:
> Hello,
>
> pg_dump can avoid bloob fields (it can dumb without blobs), but as I
> understand byteA is not bloob, so in this case what is blob? I did not
> found such type as blob..
>
Take a look at
http://www.postgresql.org/docs/7.4/inter
Achilleas Mantzios wrote:
> Στις Παρασκευή 09 Μάρτιος 2007 11:00, ο/η Lukas έγραψε:
>> Hello,
>>
>> pg_dump can avoid bloob fields (it can dumb without blobs), but as I
>> understand byteA is not bloob, so in this case what is blob? I did not
>> found such type as blob..
>>
>
> Take a look at
>
Στις Παρασκευή 09 Μάρτιος 2007 15:05, ο/η Milen A. Radev έγραψε:
> Achilleas Mantzios wrote:
> > Στις Παρασκευή 09 Μάρτιος 2007 11:00, ο/η Lukas έγραψε:
> >> Hello,
> >>
> >> pg_dump can avoid bloob fields (it can dumb without blobs), but as I
> >> understand byteA is not bloob, so in this case wh
Achilleas Mantzios wrote:
> Στις Παρασκευή 09 Μάρτιος 2007 15:05, ο/η Milen A. Radev έγραψε:
>> Achilleas Mantzios wrote:
>>> Στις Παρασκευή 09 Μάρτιος 2007 11:00, ο/η Lukas έγραψε:
Hello,
pg_dump can avoid bloob fields (it can dumb without blobs), but as I
understand byteA is
-b
--blobs
Include large objects in dump.
Examples
To dump a database:
$ pg_dump mydb > db.out
To dump a database called mydb that contains large objects to a tar file:
$ pg_dump -Ft -b mydb > db.tar
> Achilleas Mantzios wrote:
>> Στις Παρασκευή 09 Μάρτιος 2007 15:05, ο/η Milen A.
>> Rad
On 09/03/07, Achilleas Mantzios <[EMAIL PROTECTED]> wrote:
[...]
maybe with --format=p (plain text sql) ?
[...]
And to miss all the advantages of the custom format?
--
Milen A. Radev
---(end of broadcast)---
TIP 4: Have you searched our list ar
Lukas wrote:
> -b
> --blobs
> Include large objects in dump.
>
> Examples
>
> To dump a database:
> $ pg_dump mydb > db.out
>
> To dump a database called mydb that contains large objects to a tar file:
> $ pg_dump -Ft -b mydb > db.tar
Please read what I've written. This was the case up to
Lukas napisał(a):
Hello,
we have one table in database (db has over 200 tables), which has one
byteA filed for storing user photos. We are making backup every night, but
it is now too large because of photos. We do not need to make backup of
photos every night, but the question is how to backup
Hello,
After upgrading from 8.1.6 to 8.1.8 (using Debian testing packages) I
started to get a really strange error, and I have not been able to gain
any insights into this from the list archives.
When I SELECT any records from a certain table ("Acquisitions"), I get:
acqlibdb=> select * from
"Milen A. Radev" <[EMAIL PROTECTED]> writes:
> ... In the docs for pg_dump for versions after 8.1 the large objects are
> not even mentioned.
Not so: -b came back in 8.2.
-b
--blobs
Include large objects in the dump. This is the default behavior
except when --schema, --table, or --sche
"Glen W. Mabey" <[EMAIL PROTECTED]> writes:
> When I SELECT any records from a certain table ("Acquisitions"), I get:
> acqlibdb=> select * from "Acquisitions";
> ERROR: relation "Acquisitions" does not exist
> acqlibdb=> select * from public."Acquisitions";
> ERROR: relation "pu
Tom Lane wrote:
> "Milen A. Radev" <[EMAIL PROTECTED]> writes:
>> ... In the docs for pg_dump for versions after 8.1 the large objects are
Doh, I meant "versions after 8.0" but I believe you understood me.
>> not even mentioned.
>
> Not so: -b came back in 8.2.
That's nice. A change I haven't n
On Fri, Mar 09, 2007 at 11:41:23AM -0500, Tom Lane wrote:
> "Glen W. Mabey" <[EMAIL PROTECTED]> writes:
> > When I SELECT any records from a certain table ("Acquisitions"), I get:
>
> > acqlibdb=> select * from "Acquisitions";
> > ERROR: relation "Acquisitions" does not exist
> > acql
Hi Everybody,
We are using postgres 8.1.0. I want to do some maintenance work.
Hence, I want to run postgres in single user mode so that external people
won't be able to access the database.
How can I run the postgres in single user mode?. Any idea?
Regards
skarthi
Remove other users' entries in pg_hba.conf so it only allows your
username from your machine.
Andy.
Karthikeyan Sundaram wrote:
Hi Everybody,
We are using postgres 8.1.0. I want to do some maintenance work.
Hence, I want to run postgres in single user mode so that external
people won'
On 3/9/07, Karthikeyan Sundaram <[EMAIL PROTECTED]> wrote:
Hi Everybody,
We are using postgres 8.1.0. I want to do some maintenance work.
Hence, I want to run postgres in single user mode so that external people
won't be able to access the database.
How can I run the postgres in singl
http://www.postgresql.org/docs/8.2/interactive/app-postgres.html
On Fri, 2007-03-09 at 18:17 +, Andy Shellam wrote:
> Remove other users' entries in pg_hba.conf so it only allows your
> username from your machine.
>
> Andy.
>
> Karthikeyan Sundaram wrote:
> > Hi Everybody,
> >
> > We ar
On Fri, Mar 09, 2007 at 11:01:08AM -0600, Glen W. Mabey wrote:
> On Fri, Mar 09, 2007 at 11:41:23AM -0500, Tom Lane wrote:
> > "Glen W. Mabey" <[EMAIL PROTECTED]> writes:
> > > When I SELECT any records from a certain table ("Acquisitions"), I get:
> >
> > > acqlibdb=> select * from "Acquisiti
Why wouldn't you look at the definition of the view which is based on
this table (and which you claim is still working), and how it references
basic table?
M.b. it'll point you to the actual table location.
Igor
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Beha
The definition of the View refers to just "Acquisitions".
Glen
On Fri, Mar 09, 2007 at 03:20:51PM -0500, Igor Neyman wrote:
> Why wouldn't you look at the definition of the view which is based on
> this table (and which you claim is still working), and how it references
> basic table?
> M.b. it'
Hash: RIPEMD160
> > > When I SELECT any records from a certain table ("Acquisitions"), I get:
> >
> > > acqlibdb=> select * from "Acquisitions";
> > > ERROR: relation "Acquisitions" does not exist
..>
> Humm. I don't think so, since I've never altered the search_path
> settings, nor
On Fri, Mar 09, 2007 at 08:51:44PM +, Greg Sabino Mullane wrote:
>
> Hash: RIPEMD160
>
>
> > > > When I SELECT any records from a certain table ("Acquisitions"), I get:
> > >
> > > > acqlibdb=> select * from "Acquisitions";
> > > > ERROR: relation "Acquisitions" does not exist
> ..
"Glen W. Mabey" <[EMAIL PROTECTED]> writes:
> What I see is a bunch of stuff related to the Acquisitions table,
> including a relation for the primary key, which was created back when
> the table was named "Acquisition" (not plural), and two different views
> which draw on Acquisitions, both of whi
Monika Cernikova <[EMAIL PROTECTED]> writes:
> Can you help me how to stop index growing or reindex database if I CAN'T
> STOP writing records?
I think you have max_fsm_pages set too small.
> max_fsm_pages = 40
That corresponds to about 3Gb, or a tenth the size of your DB. Not en
26 matches
Mail list logo
