On Thu, 2004-07-22 at 04:29, Tom Lane wrote:
> 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 a
I am trying to use pg_dumpall to backup my database,
but it is not copying the large objects to the dump
file. I tried to use the --blobs option, but it just
work with pg_dump.
Does somebody could help me?
Thanks a lot!
Eduardo
Hola
Tengo que
convertir una base de datos de MS-Access a PostgreSQL, se que exite un plug
in "Database Migration Tool" de pgAdmin
II. No se de donde obtenerlo ya que lo he buscado y nada, y lo necesito
con urgencia ya que tengo que convertir varias bases Access y no se otra forma
I get the following error message when doing a select on a table:
ERROR: invalid page header in block 295 of relation "reported_titles"
I found some messages that said this means a block of this table is
corrupt. I found some suspicious lines in the server log just before:
ERROR: could not acc
Vou responder em português, pois não conheço muito de
espanhol.
Tive o mesmo problema com o meu banco de dados, que
era em Access 2000. Para exportar, eu utilizei o
próprio Access, usando um driver ODBC. Selecionando a
tabela, clique com o botão direito do mouse sobre o
nome da tabela, e selecione
Ian Burrell <[EMAIL PROTECTED]> writes:
> I get the following error message when doing a select on a table:
> ERROR: invalid page header in block 295 of relation "reported_titles"
> How do I fix this corruption?
You can zap just the failed block by turning on "zero_damaged_pages";
that will at l
First of all, my apologies for posting it to 3 lists: I'm not sure if
this is an admin question, or I only have this question because I'm a
novice, or some combination thereof.
I have a table which appears to be locked on an INSERT. Looking in
pg_locks, I get the result (shown below). I can u
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> 2) Is is possible to make the recovery kick in even though pg_control
> says the database state is shutdown?
Yeah, I think you are right: presence of recovery.conf should force a
WAL scan even if pg_control claims it's shut down. Fix committed.
Si Chen <[EMAIL PROTECTED]> writes:
> Does anyone know of a way to go from transactions identifiers to the
> actual transaction--which tables, which statements, etc. etc.?
See pg_stat_activity.
The pg_locks entries you are looking at do *not* represent table locks
of any kind. This:
> NULL NULL
Tom Lane wrote:
You can zap just the failed block by turning on "zero_damaged_pages";
that will at least allow you to recover the rest of the table. If you
want to try harder, you could look at the damaged page with pg_filedump
(http://sources.redhat.com/rhdb/) or a similar tool and try to intuit
Ian Burrell <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It would probably be worth your while to look at the damaged page with
>> pg_filedump before you zap it. The symptoms of hardware misfeasance and
>> software errors are enough different that you can often tell which
>> theory to believe
Excellent - Just updated and it is all good!
This change makes the whole "how do I do my backup" business nice and
basic - which the right way IMHO.
regards
Mark
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
2) Is is possible to make the recovery kick in even though pg_control
say
unsubscribe
end
On Thu, 2004-07-22 at 21:19, Tom Lane wrote:
> Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > 2) Is is possible to make the recovery kick in even though pg_control
> > says the database state is shutdown?
>
> Yeah, I think you are right: presence of recovery.conf should force a
> WAL scan even if
I have tested the "cold" backup - and retested my previous scenarios
using "hot" backup (just to be sure) . They all work AFAICS!
cheers
Mark
Simon Riggs wrote:
On Thu, 2004-07-22 at 21:19, Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
2) Is is possible to make the recovery
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2004-07-22 at 21:19, Tom Lane wrote:
>> Yeah, I think you are right: presence of recovery.conf should force a
>> WAL scan even if pg_control claims it's shut down. Fix committed.
> This *should* be possible but I haven't tested it.
I did.
It's r
Hi i have a postgresql 7.4 in redhat 9
in postgresql.con
stats_row_level = true
but whe excecute ./pg_autovacuum say
[2004-07-22 11:53:25 PM] Error: GUC variable stats_row_level must be enabled.
please any idea
Thank
--
Ing. Mario Soto Cordones
Venezolana de Avaluos
www.venezolanadeavaluos
17 matches
Mail list logo
