pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jan Lentfer <Jan.Lentfer@web.de>
To: pgsql-admin@postgresql.org
Subject: Re: Create Index CONCURRENTLY Hangs Indefinitely.
Date: Tue, 19 May 2015 12:45:49 +0200
Message-ID: <62cfc7c5688f59b16d257b9dbfb382d3@imap.lan.net> (raw)
In-Reply-To: <CAFe9ZTquML6VTu=QA+0fEheNr-LnJC-yTU_yrL12wRL5BXVdbA@mail.gmail.com>
References: <CAFe9ZTquML6VTu=QA+0fEheNr-LnJC-yTU_yrL12wRL5BXVdbA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>

Am 2015-05-19 12:30, schrieb Wei Shan:
> Hi all,
>
> Today I tried to create an index online, however it took far too long
> that I cancelled the query.
>
> 1. psql version => 9.2.4
> 2. Table structure as follows. (7.5GB in size)
>
> evocsp=# d certificatedata
>        Table "public.certificatedata"
>         Column        |  Type   | Modifiers
> ----------------------+---------+-----------
>  fingerprint          | text    | not null
>  base64cert           | text    |
>  cafingerprint        | text    |
>  certificateprofileid | integer | not null
>  expiredate           | bigint  | not null
>  issuerdn             | text    | not null
>  revocationdate       | bigint  | not null
>  revocationreason     | integer | not null
>  rowprotection        | text    |
>  rowversion           | integer | not null
>  serialnumber         | text    | not null
>  status               | integer | not null
>  subjectdn            | text    | not null
>  subjectkeyid         | text    |
>  tag                  | text    |
>  type                 | integer | not null
>  updatetime           | bigint  | not null
>  username             | text    |
> Indexes:
>     "certificatedata_pkey" PRIMARY KEY, btree (fingerprint)
>     "certificatedata_idx7" btree (certificateprofileid)
>
> 3. The query ran was => CREATE INDEX CONCURRENTLY 
> certificatedata_idx2
> ON CertificateData (username) tablespace tablespace_index;
> 4. After it took more than 2hrs+, I went to terminate the session via
> Ctrl-C, it returned the following error.
>
> WARNING:  canceling wait for synchronous replication due to user
> request
> DETAIL:  The transaction has already committed locally, but might not
> have been replicated to the standby.
> ^CCancel request sent
> ERROR:  canceling statement due to user request
>
> Any input or ideas are welcome.


Was your SR slave actually online consuming changes? What does "select 
* from pg_stat_replication" tell you?

Jan


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



view thread (5+ messages)  latest in thread

Message-ID: <62cfc7c5688f59b16d257b9dbfb382d3@imap.lan.net>
Permalink:  ../62cfc7c5688f59b16d257b9dbfb382d3@imap.lan.net/
Also on:    postgresql.org/message-id/62cfc7c5688f59b16d257b9dbfb382d3@imap.lan.net

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: Jan.Lentfer@web.de
  Subject: Re: Create Index CONCURRENTLY Hangs Indefinitely.
  In-Reply-To: <62cfc7c5688f59b16d257b9dbfb382d3@imap.lan.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox