On Friday, January 18, 2013 9:56 PM Andres Freund wrote:
On 2013-01-18 11:16:15 -0500, Tom Lane wrote:
> Andres Freund writes:
>>> > I am still stupefied nobody noticed that locking in HS (where just about
>>> > all locks are going to be fast path locks) was completely broken for
>>> > nearly two
Andres Freund writes:
> On 2013-01-18 11:16:15 -0500, Tom Lane wrote:
>> I wonder if it'd be practical to, say, run all the contrib regression
>> tests concurrently in different databases of one installation.
> I think it would be a good idea, but I don't immediately have an idea
> how to impleme
On 2013-01-18 17:26:00 +0100, Andres Freund wrote:
> On 2013-01-18 11:16:15 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > I am still stupefied nobody noticed that locking in HS (where just about
> > > all locks are going to be fast path locks) was completely broken for
> > > nearly two ye
On 2013-01-18 11:16:15 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I am still stupefied nobody noticed that locking in HS (where just about
> > all locks are going to be fast path locks) was completely broken for
> > nearly two years.
>
> IIUC it would only be broken for cases where activi
Andres Freund writes:
> I am still stupefied nobody noticed that locking in HS (where just about
> all locks are going to be fast path locks) was completely broken for
> nearly two years.
IIUC it would only be broken for cases where activity was going on
concurrently in two different databases, w
On 2013-01-18 10:15:20 -0500, Robert Haas wrote:
> On Thu, Jan 17, 2013 at 9:00 PM, Andres Freund wrote:
> >> > I think it might also be a dangerous assumption for shared objects?
> >>
> >> Locks on shared objects can't be taken via the fast path. In order to
> >> take a fast-path lock, a backend
On Thu, Jan 17, 2013 at 9:00 PM, Andres Freund wrote:
>> > I think it might also be a dangerous assumption for shared objects?
>>
>> Locks on shared objects can't be taken via the fast path. In order to
>> take a fast-path lock, a backend must be bound to a database and the
>> locktag must be for
On 2013-01-17 20:36:43 -0500, Robert Haas wrote:
> On Thu, Jan 17, 2013 at 6:22 PM, Andres Freund wrote:
> > That only made the bug more visible - the real bug is somewhere
> > else. Which makes it even scarrier, the bug was in in the fast path
> > locking patch from the start...
> >
> > It assume
On Thu, Jan 17, 2013 at 6:22 PM, Andres Freund wrote:
> That only made the bug more visible - the real bug is somewhere
> else. Which makes it even scarrier, the bug was in in the fast path
> locking patch from the start...
>
> It assumes conflicting fast path locks can only ever be in the same
>
On 2013-01-17 23:56:16 +0100, Andres Freund wrote:
> On 2013-01-17 22:46:21 +0100, Andres Freund wrote:
^
> > Note the conflicting locks held on relation foo by 28048 and 28068.
> >
> > I don't immediately know which patch to blame here? Looks a bit like
> > broken fastpath locking,
On 2013-01-17 22:46:21 +0100, Andres Freund wrote:
> Hi,
>
>
> While checking whether I could reproduce the replication delay reported
> by Michael Paquier I found this very nice tidbit:
>
> In a pretty trivial replication setup of only streaming replication I
> can currently easily reproduce th
Hi,
While checking whether I could reproduce the replication delay reported
by Michael Paquier I found this very nice tidbit:
In a pretty trivial replication setup of only streaming replication I
can currently easily reproduce this:
standby# BEGIN;SELECT * FROM foo;
BEGIN
id | data
+-
12 matches
Mail list logo
