Search Postgresql Archives

Re: Restart after poweroutage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tom Lane wrote:
Jon Lapham <lapham@xxxxxxxxx> writes:
To stress test, I turned off the power while actively processing db operations, such as: loading data into a database, create a new database, delete contents of a large table within a transaction. Anyway, in every case I could not reproduce the issue, postgresql came back flawlessly. I am willing to run any power outage simulation tests people may have.

It seems unlikely to me that this issue has anything to do with what
the database was doing at the time of the system crash.  More likely
the critical variable is some other software on your system.  What
other shared memory segments besides Postgres' exist when your system
is operating normally?

So, you want the output of "sudo ipcs -m"? Just looking at the information, I can't imagine that this is useful to you... but, it is attached below.

Is it important for you to know that at the time of the power outage, I *did* have 2 closed source kernel modules loaded, vmware's and NVidia's. (This is a development machine, not production...). Could one of these modules screwed up somehow and trampled on postgres's shared memory space? Anyway, just thought I'd mention it.

lapham@bilbo > sudo ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 0          root      777        94208      0
0x00000000 98305      gdm       600        393216     0
0x00000000 41517058   lapham    600        393216     2          dest
0x6a6b6cbd 53411843   lapham    600        384        0
0x12ac1925 53444612   lapham    600        131072     0
0x000a1de2 41451525   lapham    600        1          0
0x6499077f 41484294   lapham    600        1          0
0x00000000 41549831   lapham    600        393216     2          dest
0x00000000 41582600   lapham    600        393216     2          dest
0x00000000 41615369   lapham    600        393216     2          dest
0x00000000 41648138   lapham    600        393216     2          dest
0x00000000 41680907   lapham    600        393216     2          dest
0x00000000 41713676   lapham    600        393216     2          dest
0x00000000 41746445   lapham    600        393216     2          dest
0x00000000 41779214   lapham    600        393216     2          dest
0x00000000 41844751   lapham    600        393216     2          dest
0x00000000 41877520   lapham    600        393216     2          dest
0x00000000 41910289   lapham    600        393216     2          dest
0x00000000 59539474   lapham    666        28800      1          dest
0x00000000 43450387   lapham    600        393216     2          dest
0x00000000 44990484   lapham    600        393216     2          dest
0x00000000 48234517   lapham    600        12288      2          dest
0x00000000 43483158   lapham    600        393216     2          dest
0x00000000 59277335   lapham    600        393216     2          dest
0x0052e2c1 8192026    postgres  600        10461184   2
0x00000000 49086493   lapham    600        393216     2          dest
0x00000000 48267296   lapham    600        393216     2          dest
0x00000000 48300065   lapham    600        12288      2          dest


--
-**-*-*---*-*---*-*---*-----*-*-----*---*-*---*-----*-----*-*-----*---
 Jon Lapham  <lapham@xxxxxxxxx>                Rio de Janeiro, Brasil
 Personal: http://www.jandr.org/
***-*--*----*-------*------------*--------------------*---------------



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux