On Fri, Aug 3, 2012 at 01:23:53PM -0400, Bruce Momjian wrote:
> On Fri, Aug 3, 2012 at 12:55:30PM -0400, Álvaro Herrera wrote:
> > Excerpts from Bruce Momjian's message of vie ago 03 09:59:36 -0400 2012:
> > > On Fri, Aug 3, 2012 at 12:26:56AM -0400, Bruce Momjian wrote:
> > > > The concurrent i
On Fri, Aug 3, 2012 at 12:55:30PM -0400, Álvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie ago 03 09:59:36 -0400 2012:
> > On Fri, Aug 3, 2012 at 12:26:56AM -0400, Bruce Momjian wrote:
> > > The concurrent index documentation under discussion above was never
> > > updated, so I
Excerpts from Bruce Momjian's message of vie ago 03 09:59:36 -0400 2012:
> On Fri, Aug 3, 2012 at 12:26:56AM -0400, Bruce Momjian wrote:
> > The concurrent index documentation under discussion above was never
> > updated, so I took a stab at it, attached.
> >
> > Greg, I looked at adding a mentio
On Fri, Aug 3, 2012 at 12:26:56AM -0400, Bruce Momjian wrote:
> The concurrent index documentation under discussion above was never
> updated, so I took a stab at it, attached.
>
> Greg, I looked at adding a mention of the virtual transaction wait to
> the "explicit-locking" section as you sugges
On Wed, Nov 30, 2011 at 09:47:40PM -0800, Greg Smith wrote:
> On 11/30/2011 10:20 AM, Greg Stark wrote:
> >Given your confusion it's clear that we have to explain that it will
> >wait one by one for each transaction that was started before the index
> >was created to finish.
>
> When the index was
On 11/30/2011 10:20 AM, Greg Stark wrote:
Given your confusion it's clear that we have to explain that it will
wait one by one for each transaction that was started before the index
was created to finish.
When the index was created is a fuzzy thing though. It looked to me
like it makes this c
On Wed, Nov 30, 2011 at 8:02 AM, Greg Smith wrote:
Except in the sections talking about locking
internals we don't talk about "shared locks on virtual transactions
identifiers" we just talk about waiting for a transaction to complete.
> What I cannot agree with is that idea that th
On Wed, Nov 30, 2011 at 3:02 AM, Greg Smith wrote:
> I will happily accept that the description there may have suffered from me
> not using all of the terms optimally, and that the resulting commit could be
> improved. Some more feedback to get the description correct and useful
> would be much a
Excerpts from Greg Stark's message of sáb jun 25 21:01:36 -0400 2011:
I think this commit was ill-advised:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
Seems way to implementation-specific and detailed for a user to make
heads or tails
Alvaro Herrera wrote:
> Excerpts from Greg Stark's message of s??b jun 25 21:01:36 -0400 2011:
> > I think this commit was ill-advised:
> > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
>
> > Seems way to implementation-specific and detai
Excerpts from Greg Stark's message of sáb jun 25 21:01:36 -0400 2011:
> I think this commit was ill-advised:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
> Seems way to implementation-specific and detailed for a user to make
> heads or
On Sat, Jun 25, 2011 at 9:01 PM, Greg Stark wrote:
> I think this commit was ill-advised:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
>
> In a concurrent index build, the index is actually entered into the
> system catalogs in
I think this commit was ill-advised:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
In a concurrent index build, the index is actually entered into the
system catalogs in one transaction, then the two table scans occur in a
-
13 matches
Mail list logo
