[HACKERS] FailedAssertion
Hi together,
I'm currently debugging my developed AM and are running into this problem:
TRAP: FailedAssertion("!(((bool) (((void*)(tid) != ((void *)0)) &&
((tid)->ip_posid != 0", File: "indexam.c", Line: 488)
Can anybody explain what it means? I'm having difficulties to understand
what went wrong.
Regards, Yves
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not write block & xlog flush request 3FD/0 is not satisfied
All right, what would we be the best way to debug such a problem? Yves -Original Message- From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Greg Stark Sent: Sunday, May 08, 2011 6:36 PM To: weis...@rbg.informatik.tu-darmstadt.de Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] could not write block & xlog flush request 3FD/0 is not satisfied On Sun, May 8, 2011 at 4:18 PM, Yves Weißig wrote: > ERROR: xlog flush request 3FD/0 is not satisfied --- flushed only to > 0/20E2DC4 > That's a pretty big difference in log positions. It seems likely you've overwritten the block header writing garbage to the LSN. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not write block & xlog flush request 3FD/0 is not satisfied
Am 08.05.2011 17:38, schrieb Kevin Grittner: > Yves Weißig wrote: > >> my experimental index which I am developing still has some >> problems. Perhaps the list has some advices or hints where this >> error might occur: >> >> WARNING: could not write block 6 of base/459204/483963 >> DETAIL: Multiple failures --- write error might be permanent. >> >> directly followed by an: >> >> ERROR: xlog flush request 3FD/0 is not satisfied --- flushed only >> to 0/20E2DC4 >> CONTEXT: writing block 6 of relation base/459204/483963 >> >> So far my index worked for small relations, up to 1.000 tuples, now >> with a relation of 1.000.000 tuples I am running into these >> problems. > > Is there any chance you're running out of disk space? > > If not, what OS is this? What sort of storage system do you have? > > -Kevin > Thanks for the reply. I think disk space shouldn't be the problem: postgres@farnsworth:/usr/local/pgsql/data/pg_log$ df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 7.5G 4.1G 3.1G 58% / none 496M 228K 496M 1% /dev none 501M 140K 501M 1% /dev/shm none 501M 100K 501M 1% /var/run none 501M 0 501M 0% /var/lock It is an Ubuntu 10.10 running in a VirtualBox. The storage is located locally on my HDD, no SAN or network access. I'm afraid it is an error in my code... Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] could not write block & xlog flush request 3FD/0 is not satisfied
Hi again pgsql-hackers, my experimental index which I am developing still has some problems. Perhaps the list has some advices or hints where this error might occur: WARNING: could not write block 6 of base/459204/483963 DETAIL: Multiple failures --- write error might be permanent. directly followed by an: ERROR: xlog flush request 3FD/0 is not satisfied --- flushed only to 0/20E2DC4 CONTEXT: writing block 6 of relation base/459204/483963 So far my index worked for small relations, up to 1.000 tuples, now with a relation of 1.000.000 tuples I am running into these problems. I think I might be lacking some knowledge to really solve the problem. I am happy about any suggestions or advices you can make. Best wishes, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Best way to construct Datum out of a string?
Am 28.04.2011 05:52, schrieb Tom Lane: > =?ISO-8859-15?Q?Yves_Wei=DFig?= > writes: >> Am 27.04.2011 16:11, schrieb Heikki Linnakangas: >>> What kind of a Datum do you want it to be? What data type? See >>> CStringGetDatum, or perhaps CStringGetTextDatum(). Or perhaps you want >>> to call the input function of some other datatype, with InputFunctionCall. > >> Ok, but how do I do that? > >> Currently I am using: > >> _ebi_mtab_insert(rel, CStringGetTextDatum(BVEC_NULL), bin_enc); > >> This function does not mere than hashing the 2nd passed argument (with >> the internal hash functions of hash.c) but each time a different hash >> value is returned, so I am thinking I might pass a pointer and not the >> real Datum. I am highly irritated now... as for now I thought I >> understood Datum... > > Well, it's hard to say for sure when you haven't shown us either what > BVEC_NULL means or what _ebi_mtab_insert is doing with the value it gets > ... but in fact a text Datum *is* a pointer, as is the Datum value for > any other pass-by-reference type. Datum isn't magic, it's only a > pointer-sized integer type. For anything bigger than that, the Datum > value is a pointer to some data somewhere else. > > regards, tom lane > Sorry for giving so little information. I found the bug myself, I was trying to hash a Datum created with CStringGetTextDatum with hashint4, I certainly noticed this when I looked at the function which was actually called by: hash_value = DatumGetUInt32(FunctionCall1(procinfo, value)); Thanks for trying to help! Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] new AM, best way to obtain new block at end of index?
Hi list, currently I am obtaining a new block at the end of an index with: buf = ReadBuffer(rel, P_NEW); but it throws: ERROR: unexpected data beyond EOF in block 0 of relation base/11874/156053 HINT: This has been seen to occur with buggy kernels; consider updating your system. system is up to date: $ uname -r 2.6.35-28-generic Is there another way to do it? What could be the source of the problem? Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] new AM, build returns error
Hi, my new AM starts working..., calling something like CREATE INDEX idx ON films USING ebi (did) returns now: ERROR: unexpected EBI relation size: 3, should be 4294967295 The second argument looks for me like max uint32... there might be somehting wrong here I think? Is there somehting wrong with: estimate_rel_size(heap, NULL, &relpages, &reltuples); The state is passed to the build callback again and again... and result->heap_tuples = reltuples; takes the estimated number of tuples. Where is the error? I know that this is a rather complicated question, due to no source code. Greetz, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Best way to construct Datum out of a string?
Am 27.04.2011 16:11, schrieb Heikki Linnakangas: > On 27.04.2011 17:06, Yves Weißig wrote: >> Hi, >> >> sadly, so far my search in the source code wasn't very successfull on >> this topic. >> So, how can I construct a Datum out of a string? > > What kind of a Datum do you want it to be? What data type? See > CStringGetDatum, or perhaps CStringGetTextDatum(). Or perhaps you want > to call the input function of some other datatype, with InputFunctionCall. > Ok, but how do I do that? Currently I am using: _ebi_mtab_insert(rel, CStringGetTextDatum(BVEC_NULL), bin_enc); This function does not mere than hashing the 2nd passed argument (with the internal hash functions of hash.c) but each time a different hash value is returned, so I am thinking I might pass a pointer and not the real Datum. I am highly irritated now... as for now I thought I understood Datum... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Best way to construct Datum out of a string?
Hi, sadly, so far my search in the source code wasn't very successfull on this topic. So, how can I construct a Datum out of a string? Greetz, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] new AM, catalog entries
Am 26.04.2011 17:07, schrieb Alvaro Herrera: > Excerpts from Yves Weißig's message of mar abr 26 11:32:31 -0300 2011: > >> I keep getting: ERROR: there is no built-in function named "ebibuild" >> This error message somehow leads me to fmgr.c where the contents of an >> array are inspected (in line 134). This array fmgr_builtins is built by >> fmgr_builtins "Gen_fmgrtab.pl" from pg_proc.h (when? during make?) > > Yes, during make. > >> Do I have to edit pg_proc.h manually to add my methods for the new AM? > > Yes. Or maybe you can try using language C instead of internal (if you > have it in a shared library). > Thanks for the answer and a little bit more insight into pg! Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator classes for index?
Am 26.04.2011 17:37, schrieb Tom Lane: > =?ISO-8859-1?Q?Yves_Wei=DFig?= > writes: >> Am 26.04.2011 14:28, schrieb Robert Haas: >>> On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig >>> wrote: >>>> CREATE OPERATOR CLASS abstime_ops >>>> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS >>>> OPERATOR 1 = (abstime,abstime), >>>> FUNCTION 1 hashint4(abstime,abstime); > >>>> it yields: ERROR: function hashint4(abstime, abstime) does not exist > >>> My copy of PostgreSQL has a hashint4(integer) function, but no >>> hashint4(abstime, abstime) function. > >> Yes, I know, maybe my question wasn't clear enough. Following statement: >> ... >> I get: >> "hash";"abstime_ops";"hashint4";2227;702;702;1;"hashint4";"abstime";"abstime" >> as an entry and suppose that hashint4 also takes "abstime" >> How is it done? How is hashint4 used to hash a value of "abstime"? > > Cheating ;-). That entry is hard-wired in pg_amproc.h so it does not > pass through the same kind of error checking that CREATE OPERATOR CLASS > applies. It works, physically, because abstime and integer are binary > compatible (both 4-byte int-aligned pass-by-value types), but the > catalog entries are a bit inconsistent. If we wanted to make this look > completely clean, we'd have to create an alias function that was > declared to take abstime. For instance you could do it like this: > > create function hashabstime(abstime) returns int4 > as 'hashint4' language internal strict immutable; > > and then say FUNCTION 1 hashabstime(abstime) in CREATE OPERATOR CLASS. > > You might find this extract from the opr_sanity regression test > instructive: > > -- For hash we can also do a little better: the support routines must be > -- of the form hash(lefttype) returns int4. There are several cases where > -- we cheat and use a hash function that is physically compatible with the > -- datatype even though there's no cast, so this check does find a small > -- number of entries. > SELECT p1.amprocfamily, p1.amprocnum, p2.proname, p3.opfname > FROM pg_amproc AS p1, pg_proc AS p2, pg_opfamily AS p3 > WHERE p3.opfmethod = (SELECT oid FROM pg_am WHERE amname = 'hash') > AND p1.amprocfamily = p3.oid AND p1.amproc = p2.oid AND > (amprocnum != 1 > OR proretset > OR prorettype != 'int4'::regtype > OR pronargs != 1 > OR NOT physically_coercible(amproclefttype, proargtypes[0]) > OR amproclefttype != amprocrighttype) > ORDER BY 1; > amprocfamily | amprocnum |proname | opfname > --+---++- > 435 | 1 | hashint4 | date_ops > 1999 | 1 | timestamp_hash | timestamptz_ops > | 1 | hashchar | bool_ops > 2223 | 1 | hashvarlena| bytea_ops > 2225 | 1 | hashint4 | xid_ops > 2226 | 1 | hashint4 | cid_ops > (6 rows) > > regards, tom lane > Thanks so much Tom, I was really loosing my mind on this one... now it works! Awesome. Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] new AM, catalog entries
Hi list, I really have problems with the catalog entries for my AM. In the doc (http://developer.postgresql.org/pgdocs/postgres/index-catalog.html) it says "anyone able to write a new access method is expected to be competent to insert an appropriate row for themselves." :-) This is true so far for me as I know how to insert a new row in pg_am, but I don't know how to fill in the entries in pg_proc. When I try to register my AM methods (http://developer.postgresql.org/pgdocs/postgres/index-functions.html) with: CREATE FUNCTION ebibuild(internal, internal, internal) RETURNS internal AS 'ebibuild' LANGUAGE internal STRICT; I keep getting: ERROR: there is no built-in function named "ebibuild" This error message somehow leads me to fmgr.c where the contents of an array are inspected (in line 134). This array fmgr_builtins is built by fmgr_builtins "Gen_fmgrtab.pl" from pg_proc.h (when? during make?) Do I have to edit pg_proc.h manually to add my methods for the new AM? I am a little bit to highly confused. Greetz, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator classes for index?
Am 26.04.2011 14:28, schrieb Robert Haas: > On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig > wrote: >> CREATE OPERATOR CLASS abstime_ops >> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS >> OPERATOR 1 = (abstime,abstime), >> FUNCTION 1 hashint4(abstime,abstime); >> >> it yields: ERROR: function hashint4(abstime, abstime) does not exist >> though it exists (it is part of the hash AM), do I have to note the > > My copy of PostgreSQL has a hashint4(integer) function, but no > hashint4(abstime, abstime) function. > Sorry. Yes, I know, maybe my question wasn't clear enough. Following statement: SELECT am.amname AS index_method, opfamily.opfname AS opfamily_name, proc.proname AS procedure_name, amproc.*, typel.typname AS left_typname, typer.typname AS right_typname FROM pg_am am, pg_amproc amproc, pg_proc proc, pg_opfamily opfamily, pg_type typel, pg_type typer WHERE amproc.amprocfamily = opfamily.oid AND amproc.amproc = proc.oid AND opfamily.opfmethod = am.oid AND am.amname = 'hash' AND amproc.amproclefttype = typel.oid AND amproc.amprocrighttype = typer.oid ORDER BY opfamily_name, procedure_name; I get: "hash";"abstime_ops";"hashint4";2227;702;702;1;"hashint4";"abstime";"abstime" as an entry and suppose that hashint4 also takes "abstime" How is it done? How is hashint4 used to hash a value of "abstime"? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator classes for index?
Am 26.04.2011 01:15, schrieb Tom Lane: > =?ISO-8859-15?Q?Yves_Wei=DFig?= > writes: >> But anyway I am having trouble creating an operator class: > >> CREATE OPERATOR CLASS abstime_ops >> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS >> OPERATOR 1 = , >> FUNCTION 1 abstimeeq(abstime,abstime); > >> yields: ERROR: invalid procedure number 1, must be between 1 and 0 > > Apparently you've got zero in pg_am.amsupport for your new index AM. > You need to set that to the number of support-procedure types your AM > defines. Have you been through > http://developer.postgresql.org/pgdocs/postgres/indexam.html > and the docs and source code for the pg_am, pg_amop, pg_amproc catalogs? > See > http://developer.postgresql.org/pgdocs/postgres/catalogs.html > as well as the src/include/catalog/ files for those catalogs. > >> Additional, I don't know yet how to create index method support >> routines. I want to re-use the hash functions from hashfunc.c (because I >> do kind of a mapping). Is this possible? > > Just list them in your CREATE OPERATOR CLASS commands. Alright, now I starting to get the point. Still I have a problem, when I am trying to execute CREATE OPERATOR CLASS abstime_ops DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS OPERATOR 1 = (abstime,abstime), FUNCTION 1 hashint4(abstime,abstime); it yields: ERROR: function hashint4(abstime, abstime) does not exist though it exists (it is part of the hash AM), do I have to note the namespace or something else? pg_proc has a row for hashint4, but of course with different parameter types, int4 namely. Where do I cast them? Or is a implict conversion performed? Thanks again! > >> How does index_getprocinfo(); >> now which support routine belongs to my index? > > It looks in pg_amproc to find the routines that are entered for the > opclass associated with the index. This is a pretty direct > representation of the FUNCTION entries from your previous CREATE > OPERATOR CLASS (or if you prefer, CREATE OPERATOR CLASS is designed to > provide the information needed to populate pg_amop and pg_amproc). > > regards, tom lane > Greetz, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator classes for index?
Am 24.04.2011 23:33, schrieb Tom Lane: > =?ISO-8859-15?Q?Yves_Wei=DFig?= > writes: >> again index access methods, can somebody shed some light into operator >> classes for indexes? The documentation is an entry point, but after >> reading I still don't have a clue how exactly they are used and created? >> Perhaps somebody with great knowledge can supply an 101 on opeartor >> classes? Because I keep getting the hint: You must specify an operator >> class for the index or define a default operator class for the data type. > > Have you read > http://developer.postgresql.org/pgdocs/postgres/indexes-opclass.html > http://developer.postgresql.org/pgdocs/postgres/xindex.html > and the reference pages for CREATE OPERATOR CLASS/FAMILY? Thanks Tom, those links helped me understanding! Especially the contrib modules served as good examples. But anyway I am having trouble creating an operator class: CREATE OPERATOR CLASS abstime_ops DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS OPERATOR 1 = , FUNCTION 1 abstimeeq(abstime,abstime); yields: ERROR: invalid procedure number 1, must be between 1 and 0 SQL Status:42P17 I couldn't find additional information to the error via google, what is wrong with the create statement? Additional, I don't know yet how to create index method support routines. I want to re-use the hash functions from hashfunc.c (because I do kind of a mapping). Is this possible? How does index_getprocinfo(); now which support routine belongs to my index? > > If it's still not coming together for you, there are numerous examples > of creating operator classes in the contrib modules. The GIST and GIN > documentation might be relevant as well: > http://developer.postgresql.org/pgdocs/postgres/gist.html > http://developer.postgresql.org/pgdocs/postgres/gin.html > > regards, tom lane > Greetz, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] operator classes for index?
Hi, again index access methods, can somebody shed some light into operator classes for indexes? The documentation is an entry point, but after reading I still don't have a clue how exactly they are used and created? Perhaps somebody with great knowledge can supply an 101 on opeartor classes? Because I keep getting the hint: You must specify an operator class for the index or define a default operator class for the data type. Greets, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] best way to test new index?
Thanks for the answer Kevin! I am developing an encoded bitmap index, as proposed in http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.7570&rank=1 Automated, in my words, would have meant... some SQL-Statements which create tables, do inserts, deletes, selects and so on and the results can be compared to a master file or whatsoever. On low level I tend to go your way and debug with elog, I just thought somebody might have a different approach on debugging such code. Yves Am 22.04.2011 18:30, schrieb Kevin Grittner: > Yves Weißig wrote: > >> Ok, but I thought more like an automated test, or a test which >> checks if the interface is correctly implemented. > > I'm not aware of any automated tests which would test whether a new > index type is correctly implemented. For starters, how would the > test know when the AM should be used, or what correct results would > be? Perhaps if this was a drop-in replacement for btree you could > cobble something together so that the standard regression tests > (`make check` and such) would use your index type instead of btree, > yielding similar results; but you haven't given us the slightest > clue whether that's the sort of index you're developing. > >> what would be the best way to debug in pg? elog? asserts? > > If there are clear guidelines on this anywhere, I've missed it or > forgotten it. Here's what I tend to go by: > > (1) If it's a message which is expected enough to warrant > translation to all the supported languages, use ereport. > > (2) If it's something which should be rare and technical enough not > to warrant burdening the translators, use elog. > > (3) If it's something which "should never happen" unless there is a > programming error within the PostgreSQL code, it should not normally > be checked in production (just development and through beta > testing), and it is sane to panic (effectively restarting > PostgreSQL) when the condition is encountered, use Assert. > > That's all independent of what logging level you use. You may want > to sprinkle your code with elog calls at the DEBUG level during > development, and consider which might be worth keeping at which > debug levels later on. Sometimes debug calls are conditioned on > #ifdef conditions so that they're not in the executable without a > special build option. > > -Kevin > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] What Index Access Method Functions are really needed?
That is exactly the point, Kevin, I read the documentation and found out that "amgettuple" and "amgetbitmap" are optional. I just wondered if there is more information about this topic? Additionally, I can not find "amcostestimate" in hash.h or anywhere, or am I missing something? So "All of them" lacks some exceptions, or? Am 22.04.2011 17:27, schrieb Kevin Grittner: > Leonardo Francalanci wrote: another question regarding indexes. Sadly I can't find enough info in the documentation. Which of the functions are needed in order for a index to work? >>> >>> All of them. >> >> >> Maybe I completely misunderstood the question, but some functions >> are "optionals", such as amgetbitmap, right? >> >> http://www.postgresql.org/docs/9.0/static/index-functions.html > > Browsing that page, I think these are the two relevant bits > regarding exceptions to the rule: > > | The amgettuple function need only be provided if the access method > | supports "plain" index scans. If it doesn't, the amgettuple field > | in its pg_am row must be set to zero. > > | The amgetbitmap function need only be provided if the access > | method supports "bitmap" index scans. If it doesn't, the > | amgetbitmap field in its pg_am row must be set to zero. > > I have no idea which of these would be useful for the AM being > discussed. > > -Kevin > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] What Index Access Method Functions are really needed?
Hi, another question regarding indexes. Sadly I can't find enough info in the documentation. Which of the functions are needed in order for a index to work? I am developing a prototype so it would be great if not all of the functions have to be implemented. E.g. are amcostestimate or amoptions needed? Greets, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] best way to test new index?
Ok, but I thought more like an automated test, or a test which checks if the interface is correctly implemented. By the way, tho broaden the topic, what would be the best way to debug in pg? elog? asserts? Am 22.04.2011 01:26, schrieb Josh Berkus: > On 4/21/11 1:28 PM, Kevin Grittner wrote: >> That said, I would start by making sure that basic things like >> CREATE INDEX and DROP INDEX work. Then I would test that INSERT, >> UPDATE, and DELETE do the right things with the index. Then I would >> make sure that vacuum did the right thing. Then I would make sure >> that the optimizer was doing a reasonable job of knowing when it was >> usable and what it cost, so that it would be chosen when >> appropriate. Once everything seemed to be behaving I would >> benchmark it against the reasonable alternatives. > > ... And then finally, kill -9 the database server while updating the > index to test crash-safeness. > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] best way to test new index?
Yes I do! Am 21.04.2011 20:56, schrieb Kevin Grittner: > Yves Weißig wrote: > >> what is the best way to test a new developed index structure? > > Are you talking about a new AM (like btree, hash, GiST, or GIN)? > > -Kevin > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] best way to test new index?
Hello pgsql-hackers, what is the best way to test a new developed index structure? Greets, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
