G Dutton wrote:
> Hello all,
>
> I've seen some rather tangential postings about means of filtering log
> messages, but none quite match up to (what I believe to be) my
> requirement, so here goes:
>
> As a means of auditing our database server, I would like to use the
> PostgreSQL 'log_statement
Chris Roffler wrote:
> Are there any guidelines for XML performance tuning ?
Uh, no, I have never seen any.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
--
Manlio Perillo wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi.
>
> I think the following behaviour is not intuitive:
>
> manlio=> DROP TABLE IF EXISTS foo.bar;
> ERROR: schema "foo" does not exist
>
> The statement should not fail if the schema does not exist
Hmm. Well, it s
Scott Ribe writes:
>> OK, what probably happened was that the data was loaded okay and then
>> you got these errors from the commands that attempted to create unique
>> indexes.
> Isn't it also possible that she was not restoring into an empty database?
Maybe, but then she should have seen compl
> OK, what probably happened was that the data was loaded okay and then
> you got these errors from the commands that attempted to create unique
> indexes.
Isn't it also possible that she was not restoring into an empty database?
--
Scott Ribe
scott_r...@killerbytes.com
http://www.killerbytes.co
"Wang, Mary Y" writes:
> Actually I got that type of error during the restore process( I used pg_dump
> --insert option when doing the dump). But the interesting thing is that even
> though it flagged as an error, those rows of inserts still made to the table
> with the correct bug_id. So I'm
"Wang, Mary Y" writes:
> Because the current value is 6818, during the restore process, it
> complained about "duplicate key value violates unique constraint
> "bug_pkey, because the value of bug_pk_seq for a insert has been
> already been used. So what is the best way to resolve this? Should I
Actually I got that type of error during the restore process( I used pg_dump
--insert option when doing the dump). But the interesting thing is that even
though it flagged as an error, those rows of inserts still made to the table
with the correct bug_id. So I'm not too worried about it right n
"Wang, Mary Y" writes:
> After a restore, I got a lot errors like this one : "duplicate key value
> violates unique constraint "bug_pkey"". After looking at the dump file, it
> has
> ...
> Because the current value is 6818, during the restore process, it
> complained about "duplicate key value
Noah Misch writes:
> I understand that 9.0 will have a new implementation of VACUUM FULL that
> follows
> a rewrite strategy like CLUSTER or ALTER TABLE. What differences will remain
> between VACUUM FULL and a no-op ALTER TABLE that rewrites? Will there remain
> situations in which to prefer t
Heyho!
On Friday 05 March 2010 20.18:46 Greg Smith wrote:
> The short version is that ext3 combined with regular hard drives has
> never been safe for database use by default, [...]
> The change in ext4 [...] eliminating the source for that cheat.
Tangentially related: how is the behaviour [1]
Hi!
The data types of tableout.c1 and tablein.c1 are both bytea. I first export
tableout.c1 to a file:
db1=# COPY (SELECT c1 FROM tableout LIMIT 1) TO '/tmp/t';
Then I try to import the file to another table.
This works without flaw:
db1=# COPY tablein FROM '/tmp/t';
However, I get the follo
On 6 March 2010 12:11, wrote:
>
> Hello All,
>
> I was trying to find some way, to list out all argument details in all
> functions in postgre(input parameter names, types and mode - in/out).
[...]
>
> Please suggest, if some better way is available of achieving this.
> Also, i want to know the w
Hello All,
I was trying to find some way, to list out all argument details in all
functions in postgre(input parameter names, types and mode - in/out).
I found one solution -
--
select r.routine
14 matches
Mail list logo
