Yep, that's it!
---
Joe Conway wrote:
> Bruce Momjian wrote:
> > Allow easy display of usernames in a group (pg_hba.conf uses groups now)
>
> Hows this:
>
> parts=# select * from pg_group ;
> groname | grosysid |gro
Bruce Momjian wrote:
> Allow easy display of usernames in a group (pg_hba.conf uses groups now)
Hows this:
parts=# select * from pg_group ;
groname | grosysid |grolist
-+--+---
grp | 100 | {100,101,102}
grp2| 101 | {102}
(2 rows)
parts=# s
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Any status on this? I know we talked about it but never came to a
> > > good solution. Is it TODO?
> >
> > I think it's more like MUSTFIX ... but it's a bug not a feature
> > addition, so it'd fair game t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Any status on this? I know we talked about it but never came to a
> > good solution. Is it TODO?
>
> I think it's more like MUSTFIX ... but it's a bug not a feature
> addition, so it'd fair game to work on in beta, no?
Yes. I wil
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Any status on this? I know we talked about it but never came to a
> good solution. Is it TODO?
I think it's more like MUSTFIX ... but it's a bug not a feature
addition, so it'd fair game to work on in beta, no?
regards, tom la
Any status on this? I know we talked about it but never came to a
good solution. Is it TODO?
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is this fixed, and if not, can I have some TODO text?
>
> I
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>>> Could the index scan be made to
>>> handle cases where the index tuple it was stopped on is gone?
> Won't it still point to the same heap page and slot ?
Not if it's gone ...
regards, tom lane
-
> > Could the index scan be made to
> > handle cases where the index tuple it was stopped on is gone?
>
> Don't see how. With no equal keys, you could test each tuple you scan
> over to see if it's > the expected key; but that would slow things down
> tremendously I fear. In any case it fails
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Could we just block splits of
> > pages containing pins?
>
> That's not an improvement IMHO. The objection to the fix I suggested is
> that it makes it harder for VACUUM to make progress in the presence of
> contention. Replacing t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Could we just block splits of
> pages containing pins?
That's not an improvement IMHO. The objection to the fix I suggested is
that it makes it harder for VACUUM to make progress in the presence of
contention. Replacing that with an approach that bloc
Tom Lane wrote:
> If a VACUUM running concurrently with someone else's indexscan were to
> delete the index tuple that the indexscan is currently stopped on, then
> we'd get a failure when the indexscan resumes and tries to re-find its
> place. (This is the infamous "my bits moved right off the e
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this fixed, and if not, can I have some TODO text?
It's not fixed. I'd like to fix it for 7.3, but I was hoping someone
would think of a better way to fix it than I did ...
regards, tom lane
> --
Is this fixed, and if not, can I have some TODO text?
---
Tom Lane wrote:
> If a VACUUM running concurrently with someone else's indexscan were to
> delete the index tuple that the indexscan is currently stopped on, then
>
On Mon, 27 May 2002 13:48:43 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> On leaf pages order index tuples by heap item pointer, if otherwise
>> equal. [blah, blah, ...]
>
>Doesn't help, I fear. Finding your place again is only one part
>of the proble
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On leaf pages order index tuples by heap item pointer, if otherwise
> equal. In IndexScanDescData remember the whole index tuple (including
> the heap item pointer) instead of ItemPointerData. Then depending on
> scan direction _bt_next() would look f
On Sat, 25 May 2002 14:21:52 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>I'm somewhat concerned that the more stringent locking will slow down
>VACUUM a good deal when there's lots of concurrent activity, but I don't
>see another answer. Ideas anyone?
Ideas? Always! :-) Don't know if this one
From: "Tom Lane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, May 25, 2002 11:21 AM
Subject: [HACKERS] Think I see a btree vacuuming bug
> If a VACUUM running concurrently with someone else's indexscan were to
> delete the index tuple that the indexscan is
If a VACUUM running concurrently with someone else's indexscan were to
delete the index tuple that the indexscan is currently stopped on, then
we'd get a failure when the indexscan resumes and tries to re-find its
place. (This is the infamous "my bits moved right off the end of the
world" error c
18 matches
Mail list logo
