On Fri, Sep 15, 2017 at 06:49:06AM -0500, Ron Johnson wrote:
> On 09/15/2017 06:34 AM, Justin Pryzby wrote:
> [snip]
> >But you might consider: 1) looping around tables/indices rather than "REINDEX
> >DATABASE", and then setting a statement_timeout=9s for each REINDEX
> >statement;
>
> Is there a
On 09/15/2017 06:34 AM, Justin Pryzby wrote:
[snip]
But you might consider: 1) looping around tables/indices rather than "REINDEX
DATABASE", and then setting a statement_timeout=9s for each REINDEX statement;
Is there a way to do that within psql? (Doing it from bash is trivial, but
I'd rathe
On Fri, Sep 15, 2017 at 12:25:58PM +0200, s19n wrote:
> 1. with "\set AUTOCOMMIT off" in my psqlrc, issue a
> "SELECT * FROM pg_stat_activity;" and leave it there
This probably obtains a read lock on some shared, system tables/indices..
> 2. in a different connection, issue a database REINDEX (of
On Fri, Sep 15, 2017 at 7:25 PM, s19n wrote:
> Is this expected? I am failing to see the relation between an idle
> transaction in the 'postgres' database, a reindex operation and subsequent
> logins.
REINDEX DATABASE processes as well system indexes, and takes an
exclusive lock on them in order
Hello,
I am experiencing the following while using PostgreSQL
9.6.3-1.pgdg16.04+1 (deb package from official repository):
1. with "\set AUTOCOMMIT off" in my psqlrc, issue a
"SELECT * FROM pg_stat_activity;" and leave it there
2. in a different connection, issue a database REINDEX (of any da
