Re: [HACKERS] Re: Call for platforms
At 12:27 AM 3/28/01 -0500, Tom Lane wrote:
That would fix it for ARM but not for anyplace else with similar
alignment behavior. Would you try this patch instead to see what
happens?
I don't think this solution would be valid on many other platforms. It forces the
structure to not be padded, and assumes that the cpu will be able to fetch from
unaligned boundaries. The only reason this works is that the arm linux kernel contains
an alignment trap handler that catches the fault and does a fixup on the access.
Otherwise it would crash with SIGBUS.
static FormData_pg_attribute a1 = {
! 0x, {"ctid"}, TIDOID, 0, SizeOfIptrData,
SelfItemPointerAttributeNumber, 0, -1, -1, '\0', 'p', '\0', 'i', '\0', '\0'
};
Well, this patch seems to produce attlens of 6 as desired, but it causes many (13) of
the regression tests to fail. Do you want to see the regression.diffs?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
-BEGIN PGP SIGNED MESSAGE- On 26 Mar 2001, at 23:14, Tom Lane wrote: "Mark Knox" [EMAIL PROTECTED] writes: On 25 Mar 2001, at 16:07, Tom Lane wrote: Does that database have any user-created relations in it, or is it just a virgin database? Totally virgin. I created it just for that select you wanted. Okay. Would you create a couple of random tables in it and do the select again? I want to see what ctid looks like in a user-created table. Sure. I created two tables called 'test1' and 'test2'. Test1 has a single field 'field1' of type int4. Test2 has two fields 'field1' and 'field2' of types char(200) and int4 respectively. Here are the results: postgres= select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; oid|attrelid|relname |attname|attlen|attalign|attbyval - -++--+---+--++ 16401|1247|pg_type |ctid | 6|i |f 16415|1262|pg_database |ctid | 6|i |f 16439|1255|pg_proc |ctid | 6|i |f 16454|1260|pg_shadow |ctid | 6|i |f 16464|1261|pg_group |ctid | 6|i |f 16486|1249|pg_attribute |ctid | 6|i |f 16515|1259|pg_class |ctid | 6|i |f 16526|1215|pg_attrdef|ctid | 6|i |f 16537|1216|pg_relcheck |ctid | 6|i |f 16557|1219|pg_trigger|ctid | 6|i |f 16572| 16567|pg_inherits |ctid | 8|i |f 16593| 16579|pg_index |ctid | 8|i |f 16610| 16600|pg_statistic |ctid | 8|i |f 16635| 16617|pg_operator |ctid | 8|i |f 16646| 16642|pg_opclass|ctid | 8|i |f 16678| 16653|pg_am |ctid | 8|i |f 16691| 16685|pg_amop |ctid | 8|i |f 16873| 16867|pg_amproc |ctid | 8|i |f 16941| 16934|pg_language |ctid | 8|i |f 16953| 16948|pg_largeobject|ctid | 8|i |f 16970| 16960|pg_aggregate |ctid | 8|i |f 17038| 17033|pg_ipl|ctid | 8|i |f 17051| 17045|pg_inheritproc|ctid | 8|i |f 17067| 17058|pg_rewrite|ctid | 8|i |f 17079| 17074|pg_listener |ctid | 8|i |f 17090| 17086|pg_description|ctid | 8|i |f 17206| 17201|pg_toast_1215 |ctid | 8|i |f 17221| 17216|pg_toast_17086|ctid | 8|i |f 17236| 17231|pg_toast_1255 |ctid | 8|i |f 17251| 17246|pg_toast_1216 |ctid | 8|i |f 17266| 17261|pg_toast_17058|ctid | 8|i |f 17281| 17276|pg_toast_16600|ctid | 8|i |f 17301| 17291|pg_user |ctid | 8|i |f 17314| 17309|pg_rules |ctid | 8|i |f 17327| 17322|pg_views |ctid | 8|i |f 17342| 17335|pg_tables |ctid | 8|i |f 17355| 17350|pg_indexes|ctid | 8|i |f 18724| 18721|test1 |ctid | 8|i |f 18735| 18731|test2 |ctid | 8|i |f (39 rows) I suspect it might be an alignment problem Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8 rather than 6 as one might expect. Maybe it's padding the structure to a dword boundary? ARM is notorious for such things.. I will rebuild it with __attribute__((packed)) on the struct and see if the size changes.. -BEGIN PGP SIGNATURE- Version: N/A iQCVAwUBOsFDJP+IdJuhyV9xAQEKxQP/YJXTxZppLd7ECk4BSwDZaStP4+bE6acc StT//i/drdPC53DDWqiXLGA0bS384EXxyjvvaO1bTXzVFU/3+X/pY6YN/G3HMoah dbCXRli2Y57yansf1WaVmK1lhiAqLy3iGYFp2nZvO1Sl1u+ba89HtV+G+iaKZSTr U+HWTU3nnOM= =vkY+ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: Call for platforms
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
File information ---
File: arm-alignment.patch
Date: 27 Mar 2001, 21:26
Size: 533 bytes.
Type: Unknown
arm-alignment.patch
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: Call for platforms
-BEGIN PGP SIGNED MESSAGE- On 27 Mar 2001, at 20:49, Mark Knox wrote: I suspect it might be an alignment problem Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8 rather than 6 as one might expect. Maybe it's padding the structure to a dword boundary? ARM is notorious for such things.. I will rebuild it with __attribute__((packed)) on the struct and see if the size changes.. Aha, progress! The packed directive gives attlen of 6 across the board! Type_sanity test passes now too, so the only failing regression test is geometry and that is easily dismissed. The variation is in the last decimal place and probably due to emulated floating point (ARM has no FPU). The patch is attached.. it's tiny but seems to be effective. -BEGIN PGP SIGNATURE- Version: N/A iQCVAwUBOsFeUv+IdJuhyV9xAQE2XAP9FF93ew+6Ml5iZ1jWjcGrs+3zaXIeWef6 SytNtIfyJqmcnyWnMaxBTlChIvBO5A2HVnBkCydM5BjUXdW1eWsEynrd+U79Yc+e yVDGo30CK3lAkTLH3Fo6jR3YZe/TsIyr80WlDeqJiWvDmHTfqvo50jRiDq2h1OL/ LmI4YIQM0rQ= =Vwwp -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Re: Call for platforms
-BEGIN PGP SIGNED MESSAGE- On 25 Mar 2001, at 15:02, Tom Lane wrote: (rounding on the final digit) and this rather troubling output from type_sanity. Most bizarre --- and definitely indicative of trouble. Would you send along the output of this query in that database: select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; I was afraid of that ;) Here's the output: [PostgreSQL 7.1beta6 on armv4l-unknown-linux-gnuoldld, compiled by GCC 2.95.1] type \? for help on slash commands type \q to quit type \g or terminate with semicolon to execute query You are currently connected to the database: postgres postgres= select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; oid|attrelid|relname |attname|attlen|attalign|attbyval - -++--+---+--++ 16401|1247|pg_type |ctid | 6|i |f 16415|1262|pg_database |ctid | 6|i |f 16439|1255|pg_proc |ctid | 6|i |f 16454|1260|pg_shadow |ctid | 6|i |f 16464|1261|pg_group |ctid | 6|i |f 16486|1249|pg_attribute |ctid | 6|i |f 16515|1259|pg_class |ctid | 6|i |f 16526|1215|pg_attrdef|ctid | 6|i |f 16537|1216|pg_relcheck |ctid | 6|i |f 16557|1219|pg_trigger|ctid | 6|i |f 16572| 16567|pg_inherits |ctid | 8|i |f 16593| 16579|pg_index |ctid | 8|i |f 16610| 16600|pg_statistic |ctid | 8|i |f 16635| 16617|pg_operator |ctid | 8|i |f 16646| 16642|pg_opclass|ctid | 8|i |f 16678| 16653|pg_am |ctid | 8|i |f 16691| 16685|pg_amop |ctid | 8|i |f 16873| 16867|pg_amproc |ctid | 8|i |f 16941| 16934|pg_language |ctid | 8|i |f 16953| 16948|pg_largeobject|ctid | 8|i |f 16970| 16960|pg_aggregate |ctid | 8|i |f 17038| 17033|pg_ipl|ctid | 8|i |f 17051| 17045|pg_inheritproc|ctid | 8|i |f 17067| 17058|pg_rewrite|ctid | 8|i |f 17079| 17074|pg_listener |ctid | 8|i |f 17090| 17086|pg_description|ctid | 8|i |f 17206| 17201|pg_toast_1215 |ctid | 8|i |f 17221| 17216|pg_toast_17086|ctid | 8|i |f 17236| 17231|pg_toast_1255 |ctid | 8|i |f 17251| 17246|pg_toast_1216 |ctid | 8|i |f 17266| 17261|pg_toast_17058|ctid | 8|i |f 17281| 17276|pg_toast_16600|ctid | 8|i |f 17301| 17291|pg_user |ctid | 8|i |f 17314| 17309|pg_rules |ctid | 8|i |f 17327| 17322|pg_views |ctid | 8|i |f 17342| 17335|pg_tables |ctid | 8|i |f 17355| 17350|pg_indexes|ctid | 8|i |f (37 rows) -BEGIN PGP SIGNATURE- Version: N/A iQCVAwUBOr5XA/+IdJuhyV9xAQGfOgP6ApV6ia44bxCo/KyIE20knn/1FTysECW9 Rq9mLDhpYKHYtTWz1cgGtxzCEiRAMN+ZuO7u5nydy6TB8dp8iCd9eLAro4GAzqYM aD9V9S3nK3YwV9RaKBWJqHXNPI5enp19YS74GxN0f9VIw/4PXlYVm2tQJLVWNGs+ lFfQnraYEZQ= =Cj2l -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
