Re: Extending the volume size of the data directory volume

From: Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com>
To: panam <panam(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Extending the volume size of the data directory volume
Date: 2011-11-29 20:00:06
Message-ID: CAP_rww=Dej=GvM3QEqmRbw4z=-RFyW2EZcwpC-vTw5sVmNHaJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

here's what I would do to analyze this first:

- vmstat 1

- iostat -k -x 3

- look into system logs, maybe something actually happened there...

- look at the process list. find if some of Pg processes are in D state

- strace -f -v <PID of the "hanging" writer process>

2011/11/29 panam <panam(at)gmx(dot)net>:
> Hi,
>
> as I am importing gigabytes of data and the space on the volume where the
> data dictionary resides just became to small during that process, I resized
> it dynamically (it is a LVM volume) according to this procedure:
> http://www.techrepublic.com/blog/opensource/how-to-use-logical-volume-manager-lvm-to-grow-etx4-file-systems-online/3016
> Everything went without any problems and the import continued. Now, it is
> suddenly stuck (pgAdmin shows it as idle (piped connection)) and there is a
> good chance (as estimated from the space used) it just started using one of
> the added LE-Blocks (HDD space that was added to the volume). The db
> imported so far can be accessed just fine.
> So from the postmaster architecture, is there something that would explain
> this behaviour based on the hypothesis that newly added space was used? Any
> chance to revive the import somehow?
>
> Thanks
>
> --
> View this message in context: http://postgresql.1045698.n5.nabble.com/Extending-the-volume-size-of-the-data-directory-volume-tp5030663p5030663.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2011-11-29 20:34:14 Re: Query Optimizer makes a poor choice
Previous Message Filip Rembiałkowski 2011-11-29 19:44:34 Re: Limiting number of connections to PostgreSQL per IP (not per DB/user)?