Dixit Tim Frank <[EMAIL PROTECTED]> (le Tue, 20 Mar 2001 00:14:11 GMT) :
» Have your shell script do
»
» export PGUSER=username
» export PGPASSWORD=password
»
» before you run pg_dumpall in the same script. The user/pass would most
» likely have to be a superuser to have access to all d
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>I am trying to create the user but it was giving folllowing errors
>
>[postgres@ns data]$ su siddharta
>su: user siddharta does not exist
Meaning: there is no Unix user 'siddharta' on your system.
>This is how I created the user
Title: RE: [ADMIN] Backing up postgresql databases
Is there any reason why programs like this could not be given a simple properties file which contains the username and password. This file could then be passed on the command line, but nobody (other than, say, root, or postgres) would have ac
Bengt Månsson <[EMAIL PROTECTED]> wrote:
>I use RH7, Apache, PHP4 and PostgreSQL
Your problem is a RDBMS problem, not a WWW server one. The PostgreSQL
mailing lists (see http://www.postgresql.org/users-lounge/index.html) are a
better place to ask.
>Warning: PostgreSQL query failed: FATAL 1: my b
[EMAIL PROTECTED] (J.H.M. Dassen (Ray)) writes:
> Bengt Månsson <[EMAIL PROTECTED]> wrote:
>> Warning: PostgreSQL query failed: FATAL 1: my bits moved right off the end
>> of the world! Recreate index pg_attribute_relid_attnum_index.
This is an internal "can't happen" failure condition, presumabl
Thierry,
I think you meant to say "ps -e e" (at least that is what it is on my
RedHat Linux servers). I also realise the security issue with this.
However, if you really HAVE to use password authentication and you really
HAVE to dump your data then you are already painted into a corn
Mike,
From a different perspective I toyed around briefly with the idea of
creating a user called "backup" that would merely have SELECT permissions
on all tables in all databases in order to perform a pg_dump or
pg_dumpall. This works fine for a pg_dump as it does a single database
a
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Warning: PostgreSQL query failed: FATAL 1: my bits moved
>> right off the end of the world! Recreate index
>> pg_attribute_relid_attnum_index.
> Just use gdb to prevent parent btree page update after
> split and you'll get that error next time when
> Hmm ... so you think the people who have complained of this are all
> working with databases that have suffered previous crash corruption?
> I doubt it. There's too much consistency to the reports: in
> particular, it's generally triggered by creation of lots of large
> objects, and it's always
Hi,
I have a problem today when I vacuum one table which is vacuumed every
today, I tried re_create index also, didn't work.
urldb=# VACUUM VERBOSE ANALYZE id;
NOTICE: Vacuum: table not found
VACUUM
urldb=# VACUUM VERBOSE ANALYZE ip;
NOTICE: --Relation ip--
NOTICE: Pages 4373: Changed 0, re
> >> Warning: PostgreSQL query failed: FATAL 1: my bits moved
> >> right off the end of the world! Recreate index
> >> pg_attribute_relid_attnum_index.
>
> This is an internal "can't happen" failure condition,
> presumably arising from some weird corner-case bug in btree
> index manipulation. W
Greetings.
Running 7.0.3 under Debian 2.2, I'd like postmaster to start on boot with
the -i option. I've got it working with just the defaults, using
start-stop-daemon, but for some reason it ignores the section after the
--, which the start-stop-daemon documentation claims will be passed as
argu
Jie Liang <[EMAIL PROTECTED]> writes:
> NOTICE: FlushRelationBuffers(ip, 4223): block 4365 is referenced (private
> 0, global 8)
> FATAL 1: VACUUM (vc_vacheap): FlushRelationBuffers returned -2
Try restarting your postmaster.
regards, tom lane
-
13 matches
Mail list logo
