Re: [HACKERS] pgindent weirdnessf
Andrew Dunstan wrote:
It's tagged as a structure type by objdump, but not as a typedef:
140055: Abbrev Number: 4 (DW_TAG_typedef)
40056 DW_AT_name: (indirect string, offset: 0x6bf6):
BulkInsertState
4005a DW_AT_decl_file : 30
4005b DW_AT_decl_line : 32
4005c DW_AT_type: 0x40060
140060: Abbrev Number: 7 (DW_TAG_pointer_type)
40061 DW_AT_byte_size : 8
40062 DW_AT_type: 0x40066
140066: Abbrev Number: 13 (DW_TAG_structure_type)
40067 DW_AT_name: (indirect string, offset: 0x66bf):
BulkInsertStateData
4006b DW_AT_byte_size : 16
4006c DW_AT_decl_file : 31
4006d DW_AT_decl_line : 30
4006e DW_AT_sibling : 0x4008b
I can pull out those too if you want them in the list, but it would
possibly add a LOT of names to the list.
I did carefully warn you about the need to check the effects of the
changes when I committed the new list.
It looks like quite a few of the deletions come into this category, for
example just looking at the diff here
https://github.com/postgres/postgres/commit/fe1438da8aa8a45f2cee816eb54841f97d3b2f22#src/tools/pgindent/typedefs.list
I see AggHashEntryData, AggStatePerAggData, AllocBlockData, and
AllocChunkData from among the first few that were deleted and all are in
the same category.
I wondered if this is some sort of optimizer effect, but building with
-O0 doesn't seem to affect it.
I assume you are using -g, right?
The BulkInsertStateData typedef looks pretty normal:
typedef struct BulkInsertStateData
{
BufferAccessStrategy strategy; /* our BULKWRITE strategy
object */
Buffer current_buf;/* current insertion target page */
} BulkInsertStateData;
I tested my BSD machine using src/tools/find_typedefs and it does show
BulkInsertStateData.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
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] pgindent weirdnessf
On 04/20/2011 11:48 AM, Bruce Momjian wrote:
I assume you are using -g, right?
Of course I did. I wouldn't have any symbols at all if I didn't.
The BulkInsertStateData typedef looks pretty normal:
typedef struct BulkInsertStateData
{
BufferAccessStrategy strategy; /* our BULKWRITE strategy
object */
Buffer current_buf;/* current insertion target page */
} BulkInsertStateData;
I tested my BSD machine using src/tools/find_typedefs and it does show
BulkInsertStateData.
You can contribute to the list by running a buildfarm animal on your
machine and running its find_typedefs occasionally. This is not just
about me. I have asked on numerous occasions for other people to
contribute, and the response has been deafening silence. The reason we
got to this place is that people complained that your list was
insufficiently complete, so I added a facility for buildfarm animals to
generate their own lists, so we could get wider platform coverage. So my
response to anyone who says well, it works on my box is then why
isn't your box doing it for the buildfarm?
cheers
andrew
--
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] pgindent weirdnessf
On Wed, Apr 20, 2011 at 12:33 PM, Andrew Dunstan and...@dunslane.net wrote: You can contribute to the list by running a buildfarm animal on your machine and running its find_typedefs occasionally. This is not just about me. I have asked on numerous occasions for other people to contribute, and the response has been deafening silence. The reason we got to this place is that people complained that your list was insufficiently complete, so I added a facility for buildfarm animals to generate their own lists, so we could get wider platform coverage. So my response to anyone who says well, it works on my box is then why isn't your box doing it for the buildfarm? This is all well and good up to a point, but if Bruce's ancient BSDi machine is the only one that can properly find these symbols, then we are courting disaster by relying on it, even if he does run a buildfarm animal there. I can't help thinking there must be some other explanation for this change. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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] pgindent weirdnessf
Robert Haas wrote: On Wed, Apr 20, 2011 at 12:33 PM, Andrew Dunstan and...@dunslane.net wrote: You can contribute to the list by running a buildfarm animal on your machine and running its find_typedefs occasionally. This is not just about me. I have asked on numerous occasions for other people to contribute, and the response has been deafening silence. The ?reason we got to this place is that people complained that your list was insufficiently complete, so I added a facility for buildfarm animals to generate their own lists, so we could get wider platform coverage. So my response to anyone who says well, it works on my box is then why isn't your box doing it for the buildfarm? This is all well and good up to a point, but if Bruce's ancient BSDi machine is the only one that can properly find these symbols, then we are courting disaster by relying on it, even if he does run a buildfarm animal there. I can't help thinking there must be some other explanation for this change. Uh, just a reality check, but our courting disaster means we will have an extra space after some asterisks in the source code. ;-) I do, agree, though, it would be nice to find out what changed that caused this. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] pgindent weirdnessf
On 04/20/2011 01:59 PM, Bruce Momjian wrote: I do, agree, though, it would be nice to find out what changed that caused this. I am 100% certain that it's the tools that have changed. I bet if I were to hunt in my pile of old DVDs and find installation media for Fedora 6 or thereabouts and set it up on a VM I'd be able to reproduce the old list. But it would be a serious waste of my tolerably precious time. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
