Обсуждение: reverse file descriptor to a file name...
Hi...
I want to add the filename (index) to the error message:
FATAL 1: btree: BTP_CHAIN flag was expected (access = 0)
At least then I can figure out which index to drop and rebuild,
instead of having to do them all :)
Now, looking at _bt_moveright(), it passes Relation, which, as
part of its structure, has 'rd_fd', which I'm assuming is the open file
descriptor for the index file its doing its search on...
Is there a method of taking rd_fd and figuring out the file name
it is associated with? I looked at fstat(), but that only appears to
return everything but the filename :(
Ideas...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
>
> Hi...
>
> I want to add the filename (index) to the error message:
>
> FATAL 1: btree: BTP_CHAIN flag was expected (access = 0)
>
> At least then I can figure out which index to drop and rebuild,
> instead of having to do them all :)
>
> Now, looking at _bt_moveright(), it passes Relation, which, as
> part of its structure, has 'rd_fd', which I'm assuming is the open file
> descriptor for the index file its doing its search on...
>
> Is there a method of taking rd_fd and figuring out the file name
> it is associated with? I looked at fstat(), but that only appears to
> return everything but the filename :(
You can't get a file name from a descriptor, because there can be more
than one. The system just returns information about the inode, not
about the directory entries pointing to the inode.
For your purpose, you want:
Relation->rd_rel->relname
Works like champ.
This is not a trivial question, because the structures in PostgreSQL are
very complicated until you get used to them.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
On Fri, 10 Apr 1998, Bruce Momjian wrote:
> For your purpose, you want:
>
> Relation->rd_rel->relname
>
> Works like champ.
>
> This is not a trivial question, because the structures in PostgreSQL are
> very complicated until you get used to them.
Damn...I knew I should have looked deeper :(
Thanks...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, 10 Apr 1998, The Hermit Hacker wrote:
> On Fri, 10 Apr 1998, Bruce Momjian wrote:
>
> > For your purpose, you want:
> >
> > Relation->rd_rel->relname
> >
> > Works like champ.
> >
> > This is not a trivial question, because the structures in PostgreSQL are
> > very complicated until you get used to them.
>
> Damn...I knew I should have looked deeper :(
Oops...I must be using that wrong...I'm getting:
NOTICE: Message from PostgreSQL backend: The Postmaster has informed me
that some other backend died abnormally and possibly corrupted
shared memory. I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
relname is of type NameData ... NameData is a struct, so shouldn't
it be:
Relation->rd_rel->relname->data
But, NameData only has one component, data...why make it a struct?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> You can't get a file name from a descriptor, because there can be more
> than one. The system just returns information about the inode, not
> about the directory entries pointing to the inode.
>
> For your purpose, you want:
>
> Relation->rd_rel->relname
>
> Works like champ.
>
> This is not a trivial question, because the structures in PostgreSQL are
> very complicated until you get used to them.
Speaking of this, I always considered this comment in
optimizer/plan/planner.c to be a classic:
/* reach right in there, why don't you? */
if (tletype != reln->rd_att->attrs[i - 1]->atttypid)
elog(ERROR, "function declared to return type %s does not retrieve (%s.all)", typeTypeName(typ),
typeTypeName(typ));
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
> > Oops...I must be using that wrong...I'm getting: > > NOTICE: Message from PostgreSQL backend: The Postmaster has informed me > that some other backend died abnormally and possibly corrupted > shared memory. I have rolled back the current transaction and am > going to terminate your database system connection and exit. > Please reconnect to the database system and repeat your query. > > > relname is of type NameData ... NameData is a struct, so shouldn't > it be: > > Relation->rd_rel->relname->data > > But, NameData only has one component, data...why make it a struct? Yep, you are right. They make is a struct so they can pass it around by-value, rather than the normal pointer by-reference for normal arrays. Perhaps I should do a layout for the PostgreSQL data structures as I have done a flowchart for the backend program files. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
On Fri, 10 Apr 1998, Bruce Momjian wrote:
> >
> > Oops...I must be using that wrong...I'm getting:
> >
> > NOTICE: Message from PostgreSQL backend: The Postmaster has informed me
> > that some other backend died abnormally and possibly corrupted
> > shared memory. I have rolled back the current transaction and am
> > going to terminate your database system connection and exit.
> > Please reconnect to the database system and repeat your query.
> >
> >
> > relname is of type NameData ... NameData is a struct, so shouldn't
> > it be:
> >
> > Relation->rd_rel->relname->data
> >
> > But, NameData only has one component, data...why make it a struct?
>
> Yep, you are right. They make is a struct so they can pass it around
> by-value, rather than the normal pointer by-reference for normal arrays.
Well, that would explain *that* problem :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, 10 Apr 1998, Bruce Momjian wrote:
> >
> > Oops...I must be using that wrong...I'm getting:
> >
> > NOTICE: Message from PostgreSQL backend: The Postmaster has informed me
> > that some other backend died abnormally and possibly corrupted
> > shared memory. I have rolled back the current transaction and am
> > going to terminate your database system connection and exit.
> > Please reconnect to the database system and repeat your query.
> >
> >
> > relname is of type NameData ... NameData is a struct, so shouldn't
> > it be:
> >
> > Relation->rd_rel->relname->data
> >
> > But, NameData only has one component, data...why make it a struct?
>
> Yep, you are right. They make is a struct so they can pass it around
> by-value, rather than the normal pointer by-reference for normal arrays.
Odd...rel->rd_rel->relname->data produces:
nbtsearch.c: In function `_bt_moveright':
nbtsearch.c:223: invalid type argument of `->'
But...rel->rd_rel->relname.data works.
Now, I really really hate pointers to start with...always
have...but can someone confirm which is (should be) right? :(
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Odd...rel->rd_rel->relname->data produces: > > nbtsearch.c: In function `_bt_moveright': > nbtsearch.c:223: invalid type argument of `->' > > But...rel->rd_rel->relname.data works. > > Now, I really really hate pointers to start with...always > have...but can someone confirm which is (should be) right? :( Yep, that is right. It takes a little trial-and-error to check the type of each structure member, and reference it accordingly. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)