On Tue, Dec 26, 2017 at 10:03 PM, Jeremy Finzel wrote:
>
>
> Many thanks for the great and simple explanation.
>
> I was able to get this compiled, and ran the test before on stock 9.6.6,
> then on this patched version. I indeed reproduced it on 9.6.6, but on the
> patched version, it indeed fix
Alban Hertroys wrote:
> Does that mean that at step 3 one could issue this?:
>
> ./configure `pg_config —configure`
Not exactly, because pg_config emits the arguments in quotes and the
shell passes them as is to configure which doesn't like that. This
works:
eval ./configure `pg_config --co
On Tue, Dec 26, 2017 at 11:11 AM, Alvaro Herrera
wrote:
> Jeremy Finzel wrote:
> > On Tue, Dec 26, 2017 at 10:28 AM, Alvaro Herrera <
> alvhe...@alvh.no-ip.org>
> > wrote:
> >
> > > Jeremy Finzel wrote:
> > > > >
> > > > >> Each index build needs to wait for all other transactions
> > > > >> (Inc
On Wed, Dec 27, 2017 at 12:27:05AM +0100, Alban Hertroys wrote:
>
>> On 26 Dec 2017, at 18:11, Alvaro Herrera wrote:
>
> …
>
> > 3. configure and make
> > ./configure
> > make
> > make install
>
> …
>
> > For the options in step 3 you could use whatever your current server
> > has; use
> On 26 Dec 2017, at 18:11, Alvaro Herrera wrote:
…
> 3. configure and make
> ./configure
> make
> make install
…
> For the options in step 3 you could use whatever your current server
> has; use "pg_config --configure" to find these out. You're gonna need
> same flags if you want to
Jeremy Finzel wrote:
> On Tue, Dec 26, 2017 at 10:28 AM, Alvaro Herrera
> wrote:
>
> > Jeremy Finzel wrote:
> > > >
> > > >> Each index build needs to wait for all other transactions
> > > >> (Including the ones used by the other index build) to finish.
> > > >> So I don't think a deadlock here i
On Tue, Dec 26, 2017 at 10:28 AM, Alvaro Herrera
wrote:
> Jeremy Finzel wrote:
> > >
> > >
> > >> Each index build needs to wait for all other transactions
> > >> (Including the ones used by the other index build) to finish.
> > >> So I don't think a deadlock here is unexpected.
>
> > Does that m
Jeremy Finzel wrote:
> >
> >
> >> Each index build needs to wait for all other transactions
> >> (Including the ones used by the other index build) to finish.
> >> So I don't think a deadlock here is unexpected.
> Does that mean I should never build more than one concurrent index at
> a time withi
>
> The only thing I can think of is that there's a foreign key from foo to
> bar(id), but the create index on bar shouldn't prevent a share lock on
> foo, even if such a restriction exists.
>
> --
> Martín Marquéshttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, T
>
>
>> Each index build needs to wait for all other transactions (Including the
> ones used by the other index build) to finish. So I don't think a deadlock
> here is unexpected.
>
> Cheers,
>
> Jeff
>
Does that mean I should never build more than one concurrent index at a
time within the entire
On Fri, Dec 22, 2017 at 1:53 PM, Jeremy Finzel wrote:
> I am attempting to build several indexes in parallel, guaranteeing that I
> never build one on the same table twice. I understand I can't build two on
> the same table at once or I will get a deadlock. However, I am also
> getting a deadlo
El 22/12/17 a las 18:53, Jeremy Finzel escribió:
> I am attempting to build several indexes in parallel, guaranteeing that
> I never build one on the same table twice. I understand I can't build
> two on the same table at once or I will get a deadlock. However, I am
> also getting a deadlock when
El 23/12/17 a las 08:08, Alban Hertroys escribió:
>
>> On 22 Dec 2017, at 22:53, Jeremy Finzel wrote:
>>
>> 2017-12-22 15:48:07.669 CST,"CREATE INDEX",2017-12-22 15:48:02
>> CST,8/32,0,ERROR,40P01,"deadlock detected","Process 4470 waits for ShareLock
>> on virtual transaction 4/262; blocked by
> On 22 Dec 2017, at 22:53, Jeremy Finzel wrote:
>
> 2017-12-22 15:48:07.669 CST,"CREATE INDEX",2017-12-22 15:48:02
> CST,8/32,0,ERROR,40P01,"deadlock detected","Process 4470 waits for ShareLock
> on virtual transaction 4/262; blocked by process 4466.
> Process 4466 waits for ShareLock on virt
I am attempting to build several indexes in parallel, guaranteeing that I
never build one on the same table twice. I understand I can't build two on
the same table at once or I will get a deadlock. However, I am also
getting a deadlock when doing several in parallel on different tables.
Here is
15 matches
Mail list logo