Howard Bagcat wrote:
> How can I execute my BKI script?
I suggest that you don't, and you explain us your problem from in more
general terms.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 5: Have you c
Quoting Peter Eisentraut <[EMAIL PROTECTED]>:
> > How can I execute my BKI script?
>
> I suggest that you don't, and you explain us your problem from in more
> general terms.
Thanks for the reply.
My problem was I can not get into any of my local databases, including template1.
Postmaster kee
Am Mittwoch, 21. Juli 2004 11:28 schrieb Howard Bagcat:
> Now, my problem pg_dump and pg_dumpall displayed a lot of WARNING messages,
> like:
>
> "pg_dump: WARNING: owner of table "triggers" appears to be invalid."
Then you need to manually recreate all those users with the right user IDs.
The u
Hello. I am having a problem with a locked table that causes postmaster
to hang on inserts. I went to pg_locks and got:
transaction 6536720
pid 15992
mode ExclusiveLock
granted t
How do I go from this transaction identifier to finding out which
transaction caused it to lock, so I can resolve
Here is one for the 'idiot proof' category:
1) initdb and set archive_command
2) shutdown
3) do a backup
4) startup and run some transactions
5) shutdown and remove PGDATA
6) restore backup
7) startup
Obviously this does not work as the backup is performed with the
database shutdown.
This got me
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Here is one for the 'idiot proof' category:
> 1) initdb and set archive_command
> 2) shutdown
> 3) do a backup
> 4) startup and run some transactions
> 5) shutdown and remove PGDATA
> 6) restore backup
> 7) startup
> Obviously this does not work as the b
I think we should push the partially complete WAL file to the archive
location before shutdown. I talked to you or Jan about it and you (or
Jan) wouldn't bite either, but I think when someone shuts down, they
assume they have things fully archived and can recover fully with a
previous backup and
Well that is interesting :_)
Here is what I am doing on the removal front (I am keeping pg_xlog *now*):
$ cd $PGDATA
$ pg_ctl stop
$ ls|grep -v pg_xlog|xargs rm -rf
The contents of the archive directory just before recovery starts:
$ ls -l $PGDATA/../7.5-archive
total 49212
-rw---1 postgres
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think we should push the partially complete WAL file to the archive
> location before shutdown. ...
> When you are running and finally fill up the WAL file it would then
> overwrite the one in the archive but I think that is OK.
I don't think this can
Agreed, it might not be possible, but your report does point out a
limitation in our implementation --- that a shutdown database contains
more information than a backup and the archive logs. That is not
intuitive.
In fact, if you shutdown your database and want to reproduce it on
another machine
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed, it might not be possible, but your report does point out a
> limitation in our implementation --- that a shutdown database contains
> more information than a backup and the archive logs. That is not
> intuitive.
That's only because you are cling
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed, it might not be possible, but your report does point out a
> > limitation in our implementation --- that a shutdown database contains
> > more information than a backup and the archive logs. That is not
> > intuitive.
>
> Tha
12 matches
Mail list logo
