On Mon, 2005-01-03 at 17:14, Tom Lane wrote:
> 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 d
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
On Sat, 2005-01-01 at 18:55, Tom Lane wrote:
> 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
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
On Sat, 2005-01-01 at 00:42, Tom Lane wrote:
> 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
On Fri, 31 Dec 2004, Tom Lane wrote:
> 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"
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
11 matches
Mail list logo
