Gregory Stark <[EMAIL PROTECTED]> writes:
> I had another thought. Perhaps in use_assert_checking mode we should have it
> start from a random position every time. Or perhaps just a random position
> from amongst the first n pages.
Interesting idea, but I fear it'd make a lot of the regression tes
"Jeff Davis" <[EMAIL PROTECTED]> writes:
> On Mon, 2008-01-14 at 22:10 -0500, Tom Lane wrote:
>> It's a tossup from here. Anybody have a strong opinion one way or the
>> other?
>
> To me a heapscan means "read all the tuples" (without implying order)
> and an ordered heap scan is a special case t
On Mon, 2008-01-14 at 22:10 -0500, Tom Lane wrote:
> It's a tossup from here. Anybody have a strong opinion one way or the
> other?
>
To me a heapscan means "read all the tuples" (without implying order)
and an ordered heap scan is a special case that should be made explicit.
But this is not a s
On Mon, Jan 14, 2008 at 10:10:54PM -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> I went through all of the heap_beginscan calls in the code last night.
> >> pgstattuple was broken but AFAICS none of the other callers care about
>
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I went through all of the heap_beginscan calls in the code last night.
>> pgstattuple was broken but AFAICS none of the other callers care about
>> the visitation order. I wonder though about third-party add-ons
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Jeff Davis <[EMAIL PROTECTED]> writes:
>> On Sun, 2008-01-13 at 18:52 -0500, Tom Lane wrote:
>>> I wonder whether there are any other places that are silently assuming
>>> that heapscans start from page zero ...
>
>> I considered that question when implemen
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Sun, 2008-01-13 at 18:52 -0500, Tom Lane wrote:
>> I wonder whether there are any other places that are silently assuming
>> that heapscans start from page zero ...
> I considered that question when implementing sync scans, but I could not
> think of any
On Sun, 2008-01-13 at 18:52 -0500, Tom Lane wrote:
> The scan is done using the regular heapscan code, which in 8.3 has been
> modified to enable "synchronized scanning", which means it might start
> from the middle of the table and wrap around. If that happens, the
> "merge join" will get totally
Tom Lane wrote:
I wrote:
I think it's okay for CREATE INDEX CONCURRENTLY to use bulk-read access
strategy (that is, seqscan using a limited number of buffers), but it
has to be able to force the scan to start at page zero.
I've committed a patch to do that. Please test CVS HEAD and see if you
Hannes Dorbath <[EMAIL PROTECTED]> writes:
> In the meantime let me report that the cluster issue happens with GIST
> as well. ...
> But as far as I understood this is already covered by your thesis.
Right, the bug is independent of which index AM you use (though the
symptoms may vary).
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Oooh ... I can't be sure that this is what's biting you, but I
> definitely see a bug that seems to match the symptoms. As the comments
> in index.c point out, CREATE INDEX CONCURRENTLY works like this:
>
> * validate_index() works by first gathering all
Tom Lane wrote:
I've committed a patch to do that. Please test CVS HEAD and see if you
still see problems.
I'm happy to hear you found something and I will try CVS HEAD in a minute.
In the meantime let me report that the cluster issue happens with GIST
as well. I have load 5 million rows in
I wrote:
> I think it's okay for CREATE INDEX CONCURRENTLY to use bulk-read access
> strategy (that is, seqscan using a limited number of buffers), but it
> has to be able to force the scan to start at page zero.
I've committed a patch to do that. Please test CVS HEAD and see if you
still see pro
I wrote;
> Hannes Dorbath <[EMAIL PROTECTED]> writes:
>> I have the bad feeling that I need to correct this into "It happens when
>> autovacuum is active on the table".
> Ah-hah, I realize how to explain that too, now.
Hmm, no, scratch that: neither VACUUM nor ANALYZE use a standard
heapscan, so
Hannes Dorbath <[EMAIL PROTECTED]> writes:
> I have the bad feeling that I need to correct this into "It happens when
> autovacuum is active on the table".
Ah-hah, I realize how to explain that too, now. If you start the CREATE
INDEX CONCURRENTLY while an autovacuum is in progress on that table,
Oooh ... I can't be sure that this is what's biting you, but I
definitely see a bug that seems to match the symptoms. As the comments
in index.c point out, CREATE INDEX CONCURRENTLY works like this:
* validate_index() works by first gathering all the TIDs currently in the
* index, using a bulkd
Hannes Dorbath wrote:
Currently all I can say is: It happens the first time after I bulk load data
into that table.
I have the bad feeling that I need to correct this into "It happens when
autovacuum is active on the table".
Is it by any chance possible that CREATE INDEX CONCURRENTLY might
Tom Lane wrote:
Hannes Dorbath <[EMAIL PROTECTED]> writes:
This is a general thing I'd like to ask. If the creation of an index
fails, why is it nevertheless there?
It's a rather ugly consequence of the fact that CREATE INDEX
CONCURRENTLY requires more than one transaction. If the later ones
Hannes Dorbath <[EMAIL PROTECTED]> writes:
> This is a general thing I'd like to ask. If the creation of an index
> fails, why is it nevertheless there?
It's a rather ugly consequence of the fact that CREATE INDEX
CONCURRENTLY requires more than one transaction. If the later ones
fail, the inval
Hannes Dorbath wrote:
ERROR: relation "ts_test_tsv" already exists
test=# drop INDEX ts_test_tsv ;
DROP INDEX
This is a general thing I'd like to ask. If the creation of an index
fails, why is it nevertheless there? No matter if deadlock or my GIN
error, why isn't the whole operation "rolled
Guillaume Smet wrote:
On Jan 13, 2008 7:50 PM, Hannes Dorbath <[EMAIL PROTECTED]> wrote:
I started from scratch to put up a test case. I cannot trigger "ERROR:
item pointer (0,1) already exists" again as the deadlock issue reported
by Gregory Stark hit me every time. Is this fixed in RC1? Can I
Hannes Dorbath wrote:
Guillaume Smet wrote:
On Jan 13, 2008 7:50 PM, Hannes Dorbath <[EMAIL PROTECTED]>
wrote:
I started from scratch to put up a test case. I cannot trigger "ERROR:
item pointer (0,1) already exists" again as the deadlock issue reported
by Gregory Stark hit me every time. Is th
On Jan 13, 2008 7:50 PM, Hannes Dorbath <[EMAIL PROTECTED]> wrote:
> I started from scratch to put up a test case. I cannot trigger "ERROR:
> item pointer (0,1) already exists" again as the deadlock issue reported
> by Gregory Stark hit me every time. Is this fixed in RC1? Can I retry
> with that?
Gregory Stark wrote:
"Gregory Stark" <[EMAIL PROTECTED]> writes:
On the other hand we can't just ignore all vacuums because someone could issue
a manual vacuum inside a transaction (I think?).
Doh, ignore this. sigh.
I started from scratch to put up a test case. I cannot trigger "ERROR:
Gregory Stark wrote:
> I am hoping our other things which ignore VACUUM such as the globalxmin
> calculation are careful not to ignore VACUUM ANALYZE processes?
It doesn't matter -- the ANALYZE is done in a separate transaction (so
the VACUUM part is ignored, the ANALYZE part is not).
--
Alvaro
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Now an unindexed dead tuple is not a problem from vacuum's point of
>> view, nor does ANALYZE care, so AFAICS there is no need for this step
>> to wait for autovacuum processes --- nor indeed for manual vacuums.
"Tom Lane" <[EMAIL PROTECTED]> writes:
> It cannot be one of the first two, because those only block
> for xacts that *already have* a conflicting lock. The problem must be
> at the third wait step, which waits out all xacts that might conceivably
> be interested in recently-dead tuples that are
Gregory Stark <[EMAIL PROTECTED]> writes:
> The pid it's waiting on is long since gone but looks like it was probably an
> autovacuum process. I have a vague recollection that you had rigged CREATE
> INDEX CONCURRENTLY to ignore vacuum processes when checking for conflicting
> processes. Since any
Gregory Stark <[EMAIL PROTECTED]> writes:
> Further poking around shows that the "unrecognized locktag" is because
> lmgr.c:DescribeLockTag was never taught about virtual xids.
That's fixed, thanks for the patch.
> The pid it's waiting on is long since gone but looks like it was probably an
> aut
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> On the other hand we can't just ignore all vacuums because someone could issue
> a manual vacuum inside a transaction (I think?).
Doh, ignore this. sigh.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> I didn't have any luck reproducing either of these behaviors --- maybe
>> it's data-dependent. Can you extract a test case?
>
> I haven't been able to reproduce this either but I produced an entirely
> diffe
31 matches
Mail list logo
