> I'm been running one backend doing repeated iterations of
>
> CREATE TABLE temptest(col int);
> INSERT INTO temptest VALUES (1);
>
> CREATE TEMP TABLE temptest(col int);
> INSERT INTO temptest VALUES (2);
> SELECT * FROM temptest;
> DROP TABLE temptest;
>
> SELECT * FROM temptest;
> DROP TABL
> Further note: this bug does not arise in 7.0.* because in that code,
> BufferSync will only pin buffers that have been dirtied in the current
> transaction. This cannot affect a concurrent FlushRelationBuffers,
> which should be holding exclusive lock on the table it's flushing.
>
> Or can it?
>> I think the problem is that BufferSync unconditionally does PinBuffer
>> on each buffer, and holds the pin during intervals where it's released
>> BufMgrLock, even if there's not really anything for it to do on that
>> buffer. If someone else is running FlushRelationBuffers then it's
>> possib
> I think the problem is that BufferSync unconditionally does PinBuffer
> on each buffer, and holds the pin during intervals where it's released
> BufMgrLock, even if there's not really anything for it to do on that
> buffer. If someone else is running FlushRelationBuffers then it's
> possible fo
Lamar Owen <[EMAIL PROTECTED]> writes:
> Although I am now much more leery of our regression suite
The regression tests are not at all designed to test concurrent
behavior, and never have been. The parallel form runs some tests
in parallel, true, but those tests are deliberately designed not to
On Tue, 20 Mar 2001, Tom Lane wrote:
> This will not be RC1 :-(
> 'Ive already gotten a
> couple occurrences of Lamar's failure.
Well, I was at least hoping it was a problem here -- particularly since I
haven't been able to reproduce it. But, since it is not a local problem, I'm
glad I caught it
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Okay, I roll'd an RC1 but haven't put it up for FTP yet ... I'll wait for
> a few hours to see if anyone can reproduce this, and, if not, put out what
> I've rolled ...
This will not be RC1 :-(
I'm been running one backend doing repeated iterations
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Hmm, concurrent checkpoint? Probably we could simplify dirty test
> in ByfferSync() - ie test bufHdr->cntxDirty without holding
> shlock (and pin!) on buffer: should be good as long as we set
> cntxDirty flag *before* XLogInsert in access methods. Hav
On Tue, 20 Mar 2001, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > I'm hoping it was a problem on my machine -- educate me on
> > what caused the error
>
> Well, that's exactly what I'd like to know. The direct cause of the
> error is that DROP TABLE is finding that some other bac
On Tue, 20 Mar 2001, Tom Lane wrote:
> Since no other backend should be trying to touch this temp table,
> there's something pretty fishy here.
I see.
> Given that this is a parallel test, you may be looking at a
> low-probability timing-dependent failure. I'd say set up the machine
> and run
> I'm rerunning to see if it is intermittent. Second run -- no
> error. Running a third time..no error. Now I'm confused.
> What would cause such an error, Tom? I'm going to check on my
Hmm, concurrent checkpoint? Probably we could simplify dirty test
in ByfferSync() - ie test bufHdr->cnt
Lamar Owen <[EMAIL PROTECTED]> writes:
> I'm hoping it was a problem on my machine -- educate me on
> what caused the error
Well, that's exactly what I'd like to know. The direct cause of the
error is that DROP TABLE is finding that some other backend has a
reference-count hold on a page of the
On Tue, 20 Mar 2001, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > DROP TABLE temptest;
> > + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0,
>global 1)
> > + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2
> > SELECT * FROM temptest;
Lamar Owen <[EMAIL PROTECTED]> writes:
> DROP TABLE temptest;
> + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0,
>global 1)
> + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2
> SELECT * FROM temptest;
>> Hoo, that's interesting ... Exactly what
On Tue, 20 Mar 2001, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > DROP TABLE temptest;
> > + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0,
>global 1)
> > + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2
> > SELECT * FROM tempte
On Tue, 20 Mar 2001, Lamar Owen wrote:
> Ok, thanks to our snowstorm :-0 I have been working on the beta 6 RPM situation
> on my _slow_ notebook today (power outages for ten minutes at a time happening
> at hour or so intervals due to 45mph+ winds and a foot of snow).
>
> Well, I have prelimi
Lamar Owen <[EMAIL PROTECTED]> writes:
> DROP TABLE temptest;
> + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0,
>global 1)
> + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2
> SELECT * FROM temptest;
Hoo, that's interesting ... Exactly what
Ok, thanks to our snowstorm :-0 I have been working on the beta 6 RPM situation
on my _slow_ notebook today (power outages for ten minutes at a time happening
at hour or so intervals due to 45mph+ winds and a foot of snow).
Well, I have preliminary RPM's built -- just need to work on the cont
18 matches
Mail list logo
