Re: [HACKERS] MERGE Specification

2008-04-26 Thread Hannes Dorbath
npredictable restrictions. For example in Oracle you can break any MERGE statement by placing a full text index on the table. So I'd really expect a MERGE in PostgreSQL to be fine with views, rules, tsearch, etc. Just my 2 cent. -- Best regards, Hannes Dorbath -- Sent via pgsql-

Re: [HACKERS] 8.3 / 8.2.6 restore comparison

2008-02-24 Thread Hannes Dorbath
to quantify that? I didn't really have any preconceived ideas about that. I just want to see some raw data to see if something shows up. Isn't blktrace the tool to get that kind of information? Anyway, as the following threads point out the problems seems to be somewhere else.. --

Re: [HACKERS] Index trouble with 8.3b4

2008-01-14 Thread Hannes Dorbath
and see if you still see problems. With some limited testing it seems both cases are indeed fixed. I was unable to reproduce either with current CVS HEAD. Though I'll run some further tests tomorrow to back that up. Thanks for your time and prompt responses. -- Best regards,

Re: [HACKERS] Index trouble with 8.3b4

2008-01-14 Thread Hannes Dorbath
ntains duplicated values. test=# But as far as I understood this is already covered by your thesis. -- Best regards, Hannes Dorbath ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Index trouble with 8.3b4

2008-01-13 Thread Hannes Dorbath
Hannes Dorbath wrote: Currently all I can say is: It happens the first time after I bulk load data into that table. I have the bad feeling that I need to correct this into "It happens when autovacuum is active on the table". Is it by any chance possible that CREATE INDEX CONCURRE

Re: [HACKERS] Index trouble with 8.3b4

2008-01-13 Thread Hannes Dorbath
Tom Lane wrote: Hannes Dorbath <[EMAIL PROTECTED]> writes: This is a general thing I'd like to ask. If the creation of an index fails, why is it nevertheless there? It's a rather ugly consequence of the fact that CREATE INDEX CONCURRENTLY requires more than one transaction. I

Re: [HACKERS] Index trouble with 8.3b4

2008-01-13 Thread Hannes Dorbath
Hannes Dorbath wrote: ERROR: relation "ts_test_tsv" already exists test=# drop INDEX ts_test_tsv ; DROP INDEX This is a general thing I'd like to ask. If the creation of an index fails, why is it nevertheless there? No matter if deadlock or my GIN error, why isn't

Re: [HACKERS] Index trouble with 8.3b4

2008-01-13 Thread Hannes Dorbath
Guillaume Smet wrote: On Jan 13, 2008 7:50 PM, Hannes Dorbath <[EMAIL PROTECTED]> wrote: I started from scratch to put up a test case. I cannot trigger "ERROR: item pointer (0,1) already exists" again as the deadlock issue reported by Gregory Stark hit me every time. Is this fix

Re: [HACKERS] Index trouble with 8.3b4

2008-01-13 Thread Hannes Dorbath
Hannes Dorbath wrote: Guillaume Smet wrote: On Jan 13, 2008 7:50 PM, Hannes Dorbath <[EMAIL PROTECTED]> wrote: I started from scratch to put up a test case. I cannot trigger "ERROR: item pointer (0,1) already exists" again as the deadlock issue reported by Gregory Stark hit m

Re: [HACKERS] Index trouble with 8.3b4

2008-01-13 Thread Hannes Dorbath
7;de_DE.utf8' --lc-collate='C' Only listen_address and pg_hba.conf was touched. Please get the -Fc dump (37MB) from: http://theendofthetunnel.de/dump.bin http://theendofthetunnel.de/glob.sql -- Best regards, Hannes Dorbath ---(end of broadcast)--- TIP 6: explain analyze is your friend