On 22 August 2015 at 15:14, Andres Freund wrote:
> TransactionIdSetPageStatus() calls TransactionIdSetStatusBit(), which
> writes an 8 byte variable (the lsn). That's not safe.
>
This point was the main sticking point here.
It turns out that we don't need to store the LSN (8 bytes).
WAL is fs
On Fri, Sep 18, 2015 at 11:31 PM, Jesper Pedersen <
jesper.peder...@redhat.com> wrote:
> On 08/31/2015 07:34 AM, Amit Kapila wrote:
>
>> I have updated the patch (attached with mail) to show
>> you what I have in mind.
>>
>>
> I havn't been able to get a successful run with _v5 using pgbench.
>
>
On 08/31/2015 07:34 AM, Amit Kapila wrote:
I have updated the patch (attached with mail) to show
you what I have in mind.
I havn't been able to get a successful run with _v5 using pgbench.
TransactionIdSetStatusBit assumes an exclusive lock on CLogControlLock
when called, but that part is re
On Wed, Aug 26, 2015 at 4:18 PM, Simon Riggs wrote:
>
> On 26 August 2015 at 11:40, Amit Kapila wrote:
>>
>> On Tue, Aug 25, 2015 at 2:21 PM, Simon Riggs
wrote:
>>>
>>> On 22 August 2015 at 15:14, Andres Freund wrote:
>>
>>
TransactionIdSetPageStatus() calls TransactionIdSetStatusBit(
On 26 August 2015 at 11:40, Amit Kapila wrote:
> On Tue, Aug 25, 2015 at 2:21 PM, Simon Riggs
> wrote:
>
>> On 22 August 2015 at 15:14, Andres Freund wrote:
>>
>
>
>> TransactionIdSetPageStatus() calls TransactionIdSetStatusBit(), which
>>> writes an 8 byte variable (the lsn). That's not safe.
On Tue, Aug 25, 2015 at 2:21 PM, Simon Riggs wrote:
> On 22 August 2015 at 15:14, Andres Freund wrote:
>
> TransactionIdSetPageStatus() calls TransactionIdSetStatusBit(), which
>> writes an 8 byte variable (the lsn). That's not safe.
>>
>
> Agreed, thanks for spotting that.
>
> I see this as t
On 22 August 2015 at 15:14, Andres Freund wrote:
> On 2015-06-30 08:02:25 +0100, Simon Riggs wrote:
> > Proposal for improving this is to acquire the ClogControlLock in Shared
> > mode, if possible.
>
> I find that rather scary. That requires for all read and write paths in
> clog.c and slru.c t
On 12 August 2015 at 04:49, Amit Kapila wrote:
> On Tue, Aug 11, 2015 at 7:27 PM, Simon Riggs
> wrote:
> >
> > On 11 August 2015 at 14:53, Amit Kapila wrote:
> >
> >>
> >> One more point here why do we need CommitLock before calling
> >> SimpleLruReadPage_ReadOnly() in the patch and if it is no
Hi,
Amit pinged me about my opinion of this patch. I don't really have
time/energy for an in-depth review right now, but since I'd looked
enough to see some troublesome points, I thought I'd write those.
On 2015-06-30 08:02:25 +0100, Simon Riggs wrote:
> Proposal for improving this is to acquire
On Tue, Aug 11, 2015 at 7:32 PM, Simon Riggs wrote:
>
> On 11 August 2015 at 11:39, Amit Kapila wrote:
>
Another thing is that in this flow, with patch there will be three
locks
(we take per-buffer locks before doing I/O) that will get involved
rather than
two, so one effect o
On Tue, Aug 11, 2015 at 7:27 PM, Simon Riggs wrote:
>
> On 11 August 2015 at 14:53, Amit Kapila wrote:
>
>>
>> One more point here why do we need CommitLock before calling
>> SimpleLruReadPage_ReadOnly() in the patch and if it is not required,
>> then can we use LWLockAcquire(shared->buffer_locks
On 11 August 2015 at 11:39, Amit Kapila wrote:
> On Tue, Aug 11, 2015 at 3:44 PM, Simon Riggs
> wrote:
>
>> On 11 August 2015 at 10:55, Amit Kapila wrote:
>>
>>> > What "tricks" are being used??
>>> >
>>> > Please explain why taking 2 locks is bad here, yet works fine
>>> elsewhere.
>>> >
>>>
>
On 11 August 2015 at 14:53, Amit Kapila wrote:
> One more point here why do we need CommitLock before calling
> SimpleLruReadPage_ReadOnly() in the patch and if it is not required,
> then can we use LWLockAcquire(shared->buffer_locks[slotno], LW_EXCLUSIVE);
> instead of CommitLock?
>
That preve
On Tue, Aug 11, 2015 at 4:09 PM, Amit Kapila
wrote:
>
> On Tue, Aug 11, 2015 at 3:44 PM, Simon Riggs
wrote:
>>
>>>
>>> Another thing is that in this flow, with patch there will be three locks
>>> (we take per-buffer locks before doing I/O) that will get involved
rather than
>>> two, so one effect
On Tue, Aug 11, 2015 at 3:44 PM, Simon Riggs wrote:
> On 11 August 2015 at 10:55, Amit Kapila wrote:
>
>> > What "tricks" are being used??
>> >
>> > Please explain why taking 2 locks is bad here, yet works fine
>> elsewhere.
>> >
>>
>> One thing that could be risky in this new scheme of locking
On 11 August 2015 at 10:55, Amit Kapila wrote:
> On Wed, Jul 1, 2015 at 3:49 PM, Simon Riggs wrote:
> >
> > On 1 July 2015 at 11:14, Andres Freund wrote:
> >>
> >> On 2015-07-01 09:08:11 +0100, Simon Riggs wrote:
> >> > On 1 July 2015 at 09:00, Amit Kapila wrote:
> >> >
> >> > > On Tue, Jun 30
On Wed, Jul 1, 2015 at 3:49 PM, Simon Riggs wrote:
>
> On 1 July 2015 at 11:14, Andres Freund wrote:
>>
>> On 2015-07-01 09:08:11 +0100, Simon Riggs wrote:
>> > On 1 July 2015 at 09:00, Amit Kapila wrote:
>> >
>> > > On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs
>> > > a. the semantics of new
On Wed, Jul 1, 2015 at 6:21 AM, Andres Freund wrote:
> On 2015-07-01 11:19:40 +0100, Simon Riggs wrote:
>> What "tricks" are being used??
>>
>> Please explain why taking 2 locks is bad here, yet works fine elsewhere.
>
> I didn't say anything about 'bad'. It's more complicated than one
> lock. Sud
On 2015-07-01 11:19:40 +0100, Simon Riggs wrote:
> What "tricks" are being used??
>
> Please explain why taking 2 locks is bad here, yet works fine elsewhere.
I didn't say anything about 'bad'. It's more complicated than one
lock. Suddenly you have to care about lock ordering and such. The
algori
On 1 July 2015 at 11:14, Andres Freund wrote:
> On 2015-07-01 09:08:11 +0100, Simon Riggs wrote:
> > On 1 July 2015 at 09:00, Amit Kapila wrote:
> >
> > > On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs
> > > a. the semantics of new LWLock (CommitLock) introduced
> > > by patch seems to be diffe
On 1 July 2015 at 11:11, Amit Kapila wrote:
> On Wed, Jul 1, 2015 at 1:38 PM, Simon Riggs wrote:
> >
> > On 1 July 2015 at 09:00, Amit Kapila wrote:
> >>
> >>
> >> I think it will be better to partition it or use it in some other way
> to avoid
> >> two concurrent writers block at it, however i
On 2015-07-01 09:08:11 +0100, Simon Riggs wrote:
> On 1 July 2015 at 09:00, Amit Kapila wrote:
>
> > On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs
> > a. the semantics of new LWLock (CommitLock) introduced
> > by patch seems to be different in the sense that it is just taken in
> > Exclusive mo
On Wed, Jul 1, 2015 at 1:38 PM, Simon Riggs wrote:
>
> On 1 July 2015 at 09:00, Amit Kapila wrote:
>>
>>
>> I think it will be better to partition it or use it in some other way to
avoid
>> two concurrent writers block at it, however if you want to first see the
>> test results with this, then th
On 1 July 2015 at 09:00, Amit Kapila wrote:
> On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs
> wrote:
> >
> > ClogControlLock contention is high at commit time. This appears to be
> due to the fact that ClogControlLock is acquired in Exclusive mode prior to
> marking commit, which then gets starv
On Tue, Jun 30, 2015 at 12:32 PM, Simon Riggs wrote:
>
> ClogControlLock contention is high at commit time. This appears to be due
to the fact that ClogControlLock is acquired in Exclusive mode prior to
marking commit, which then gets starved by backends running
TransactionIdGetStatus().
>
> Propo
On Tue, Jun 30, 2015 at 12:52 PM, Simon Riggs wrote:
>
> On 30 June 2015 at 08:13, Michael Paquier
wrote:
>>
>>
>> Could it be possible to see some performance numbers? For example with a
simple pgbench script doing a bunch of tiny transactions, with many
concurrent sessions (perhaps hundreds).
>
On 30 June 2015 at 08:22, Simon Riggs wrote:
> This contention is masked by contention elsewhere, e.g. ProcArrayLock, so
> the need for testing here should come once other patches ahead of this are
> in.
>
Let me explain more clearly.
Andres' patch to cache snapshots and reduce ProcArrayLock w
On 30 June 2015 at 08:13, Michael Paquier wrote:
>
>
> On Tue, Jun 30, 2015 at 4:02 PM, Simon Riggs
> wrote:
>
>> ClogControlLock contention is high at commit time. This appears to be due
>> to the fact that ClogControlLock is acquired in Exclusive mode prior to
>> marking commit, which then get
On Tue, Jun 30, 2015 at 4:02 PM, Simon Riggs wrote:
> ClogControlLock contention is high at commit time. This appears to be due
> to the fact that ClogControlLock is acquired in Exclusive mode prior to
> marking commit, which then gets starved by backends running
> TransactionIdGetStatus().
>
> P
ClogControlLock contention is high at commit time. This appears to be due
to the fact that ClogControlLock is acquired in Exclusive mode prior to
marking commit, which then gets starved by backends running
TransactionIdGetStatus().
Proposal for improving this is to acquire the ClogControlLock in S
30 matches
Mail list logo
