I wrote:
> I think that it would work for BufferAlloc to share-lock the victim
> buffer before calling FlushBuffer; we'd have to add a bool parameter to
> FlushBuffer telling it the lock was already acquired.
I've applied a patch for this.
> BTW, it looks to me like this deadlock potential has ex
Simon Riggs <[EMAIL PROTECTED]> writes:
> The situation where another backend requests the block immediately
> before the I/O is fairly common AFAICS, especially since
> StrategyGetBuffer ignores the BM_DIRTY flag in selecting victims.
How do you figure that? StrategyGetBuffer won't return the sa
Simon Riggs <[EMAIL PROTECTED]> writes:
> I think the proposal sounds safe, though I worry about performance.
There is no performance loss; we are just changing the order in which
we acquire two locks. If there were some risk of blocking for a
measurable time while holding the BufMgrLock, then th
I wrote:
> A possible fix for this is to reorder the operations in FlushBuffer
> so that we share-lock the buffer before releasing BufMgrLock ... but
> I'm not sure that doesn't introduce other deadlock risks.
That's too simplistic, since at least one caller of FlushBuffer is
trying to write pages
Michael Wildpaner <[EMAIL PROTECTED]> writes:
> two concurrent clients try to 'COPY ... FROM ...' to the same table,
> "feature_link".
> The second one (pid 17983) is waiting for an ExclusiveLock on the table's
> primary key index, "key__idpk__flink".
> The first one (pid 17980) is inserting into
Michael Wildpaner <[EMAIL PROTECTED]> writes:
> two concurrent clients try to 'COPY ... FROM ...' to the same table,
> "feature_link".
> The second one (pid 17983) is waiting for an ExclusiveLock on the table's
> primary key index, "key__idpk__flink".
You didn't show a stack trace for this one ..
Hi,
two concurrent clients try to 'COPY ... FROM ...' to the same table,
"feature_link".
The second one (pid 17983) is waiting for an ExclusiveLock on the table's
primary key index, "key__idpk__flink".
The first one (pid 17980) is inserting into the index's btree, waiting
for a buffer lock. This
