Thread: pgsql/src/backend/storage/smgr (md.c)
Date: Monday, July 10, 2000 @ 00:32:00
Author: tgl
Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/storage/smgr
from hub.org:/home/projects/pgsql/tmp/cvs-serv54321
Modified Files:
md.c
----------------------------- Log Message -----------------------------
Prevent creating a boatload of empty segments when md.c is asked to
access a ridiculously large block number within a relation.
a few questions:
1. back patchable to v7.0.x tree?
2. worth building a v7.0.3 release for?
3. unless it already does so, might it be an idea to generate a warning
or some such in the logs, with the "cause of the request"?
On Mon, 10 Jul 2000, Tom Lane wrote:
> Date: Monday, July 10, 2000 @ 00:32:00
> Author: tgl
>
> Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/storage/smgr
> from hub.org:/home/projects/pgsql/tmp/cvs-serv54321
>
> Modified Files:
> md.c
>
> ----------------------------- Log Message -----------------------------
>
> Prevent creating a boatload of empty segments when md.c is asked to
> access a ridiculously large block number within a relation.
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> a few questions:
> 1. back patchable to v7.0.x tree?
Yes, if you think it's worth the trouble. We don't see that many
trouble reports about it. (The reason I fixed it just now is that
I was having too many occurrences of the misbehavior due to bugs in
my memory management stuff ;-).)
> 2. worth building a v7.0.3 release for?
I doubt it.
> 3. unless it already does so, might it be an idea to generate a warning
> or some such in the logs, with the "cause of the request"?
It logs the bogus block number, which is all that md.c knows ...
>> Prevent creating a boatload of empty segments when md.c is asked to
>> access a ridiculously large block number within a relation.
regards, tom lane
On Mon, 10 Jul 2000, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > a few questions: > > > 1. back patchable to v7.0.x tree? > > Yes, if you think it's worth the trouble. We don't see that many > trouble reports about it. (The reason I fixed it just now is that > I was having too many occurrences of the misbehavior due to bugs in > my memory management stuff ;-).) somehow Tim has hit this condition ... if we could get it backpatched to the v7.0.x tree, then at least we could tell him to grab latest sources from cvsup?
> On Mon, 10 Jul 2000, Tom Lane wrote: > > > The Hermit Hacker <scrappy@hub.org> writes: > > > a few questions: > > > > > 1. back patchable to v7.0.x tree? > > > > Yes, if you think it's worth the trouble. We don't see that many > > trouble reports about it. (The reason I fixed it just now is that > > I was having too many occurrences of the misbehavior due to bugs in > > my memory management stuff ;-).) > > somehow Tim has hit this condition ... if we could get it backpatched to > the v7.0.x tree, then at least we could tell him to grab latest sources > from cvsup? Yes, but it is the cause of the problem that must be fixed. This only prevents errors from creating too many segments. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Mon, 10 Jul 2000, Bruce Momjian wrote: > > On Mon, 10 Jul 2000, Tom Lane wrote: > > > > > The Hermit Hacker <scrappy@hub.org> writes: > > > > a few questions: > > > > > > > 1. back patchable to v7.0.x tree? > > > > > > Yes, if you think it's worth the trouble. We don't see that many > > > trouble reports about it. (The reason I fixed it just now is that > > > I was having too many occurrences of the misbehavior due to bugs in > > > my memory management stuff ;-).) > > > > somehow Tim has hit this condition ... if we could get it backpatched to > > the v7.0.x tree, then at least we could tell him to grab latest sources > > from cvsup? > > Yes, but it is the cause of the problem that must be fixed. This only > prevents errors from creating too many segments. Basically, if I'm understanding the problem from what Tom stated ... how can the client side request 'a block past the end of the table'? I think that is what I'm getting confused on. I don't imagine that this problem is that the client is requesting OID 10,000,00 when the table only contains 10 tuples ... where is the server getting the knowledge about a block that is past the end of the relation?
The Hermit Hacker <scrappy@hub.org> writes:
>> Yes, but it is the cause of the problem that must be fixed. This only
>> prevents errors from creating too many segments.
> Basically, if I'm understanding the problem from what Tom stated ... how
> can the client side request 'a block past the end of the table'?
It can't. This patch just prevents md.c from going crazy as a
consequence of a bug elsewhere in the backend that causes higher
levels of the backend to request a garbage block number.
The patch doesn't fix the underlying problem (ie, whatever higher-level
bug might cause this); it just limits the extent of the bad
consequences...
regards, tom lane
On Mon, 10 Jul 2000, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > >> Yes, but it is the cause of the problem that must be fixed. This only > >> prevents errors from creating too many segments. > > > Basically, if I'm understanding the problem from what Tom stated ... how > > can the client side request 'a block past the end of the table'? > > It can't. This patch just prevents md.c from going crazy as a > consequence of a bug elsewhere in the backend that causes higher > levels of the backend to request a garbage block number. > > The patch doesn't fix the underlying problem (ie, whatever higher-level > bug might cause this); it just limits the extent of the bad > consequences... Okay, so I wasn't misunderstanding ... the bug is in *our* code, not in the client code on Tim's side?
The Hermit Hacker <scrappy@hub.org> writes:
> Okay, so I wasn't misunderstanding ... the bug is in *our* code, not in
> the client code on Tim's side?
Of course.
regards, tom lane