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 index
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 suggested,
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 mention of the
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 took a
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 created
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
On Wed, Nov 30, 2011 at 3:02 AM, Greg Smith g...@2ndquadrant.com 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
On Wed, Nov 30, 2011 at 8:02 AM, Greg Smith g...@2ndquadrant.com 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
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
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 detailed for
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 st...@mit.edu 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
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
