Re: pgsql/src/backend/storage/smgr (md.c)

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: pgsql/src/backend/storage/smgr (md.c)
Дата
Msg-id Pine.BSF.4.21.0007101623470.3314-100000@thelab.hub.org
обсуждение исходный текст
Ответ на Re: pgsql/src/backend/storage/smgr (md.c)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: pgsql/src/backend/storage/smgr (md.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-committers
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?


В списке pgsql-committers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pgsql/src/backend/storage/smgr (md.c)
Следующее
От: Vince Vielhaber
Дата:
Сообщение: [WEBMASTER] 'www/html related.html'