Yuri, You're sure the pg xlogs are going where you expect them to? Have you=
fine-tooth-combed your conf file for log file-related settings? Log files =
may well be directed to fs other than /data/postgres (as is common in our e=
nvironments, e.g.)
Do a $ df -h on the various FSes involved...
Are you using Solaris 10 ACLs? Dig deeper on Tom's point on user-specific q=
uotas. ZFS in use? Various quota settings under Solaris can get you really =
unexpected mileage.
Lou Picciano
----- Original Message -----
From: Yuri Levinsky=20
To: pgsql-bugs@postgresql.org
Sent: Tue, 25 Jun 2013 12:23:00 -0000 (UTC)
Subject: [BUGS] Postgres crash? could not write to log file: No space left =
on device
Dear All, I have the following issue on Sun Solaris 10. PostgreSQL version=
is 9.2.3. The wall logging is minimal and no archiving. The DB restarted s=
everal time, the box is up for last 23 days. The PostgreSQL installation an=
d files under /data/postgres that is half empty. Is it some other destinati=
on that might cause the problem? Can I log the space consumption and direct=
ory name where the problem is happening by some debug level or trace settin=
g? PANIC: could not write to log file 81, segment 125 at offset 13959168=
, length 1392640: No space left on deviceLOG: process 10203 still waiting =
for ShareLock on transaction 3010915 after 1004.113 msSTATEMENT: UPDATE tc=
tuserinfo SET clickmiles =3D clickmiles + $1, periodicalclickmiles =3D peri=
odicalclickmiles + $2, active =3D $3, activeupdatetime =3D $4, activationse=
tby =3D $5, smscid =3D $6, sdrtime =3D $7, simvalue =3D simvalue + $8, tota=
lsimvalue =3D totalsimvalue + $9, firstclick =3D $10, lastclick =3D $11, fi=
rstactivationtime =3D $12, cbchannel =3D $13, clickmilesupdatetime =3D $14,=
ci =3D $15, lac =3D $16, bscid =3D $17, lastlocationupdatetime =3D $18, su=
bscriptiontype =3D $19, contentcategory =3D$20, livechannels =3D $21, conte=
xtclicks =3D $22 WHERE phonenumber =3D $23LOG: WAL writer process (PID 104=
76) was terminated by signal 6LOG: terminating any other active server pro=
cessesFATAL: the database system is in recovery mode But it looks OK: dbne=
tapp:/vol/postgres 90G 44G 46G 49% /data=
/postgres Is it possible that =E2=80=9Cheavy=E2=80=9D queries consuming dis=
k space (as temporary space) and after the crash and recovery it becoming O=
K? =20