Re: Restart after poweroutage - Mailing list pgsql-general

Tom Lane wrote:
> Jon Lapham <lapham@jandr.org> 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@jandr.org>                Rio de Janeiro, Brasil
  Personal: http://www.jandr.org/
***-*--*----*-------*------------*--------------------*---------------