Re: [BUGS] Postgres crash? could not write to log file: No space left on device

[Greg Stark]

On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane  wrote:
>  (Though if it is, it's not apparent why such
> failures would only be manifesting on the pg_xlog files and not for
> anything else.)

Well data files are only ever written to in 8k chunks. Maybe these
errors are only occuring on >8k xlog records such as records with
multiple full page images. I'm not sure how much we write for other
types of files but they won't be written to as frequently as xlog or
data files and might not cause errors that are as noticeable.


-- 
greg


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgres crash? could not write to log file: No space left on device

[Andres Freund]

On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
> On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane  wrote:
> >  (Though if it is, it's not apparent why such
> > failures would only be manifesting on the pg_xlog files and not for
> > anything else.)
> 
> Well data files are only ever written to in 8k chunks. Maybe these
> errors are only occuring on >8k xlog records such as records with
> multiple full page images. I'm not sure how much we write for other
> types of files but they won't be written to as frequently as xlog or
> data files and might not cause errors that are as noticeable.

We only write xlog in XLOG_BLCKSZ units - which is 8kb by default as
well...

Yuri, have you compiled postgres with nonstandard configure or
pg_config_manual.h settings?

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgres crash? could not write to log file: No space left on device

[Heikki Linnakangas]

On 26.06.2013 15:21, Andres Freund wrote:

On 2013-06-26 13:14:37 +0100, Greg Stark wrote:

On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane  wrote:

  (Though if it is, it's not apparent why such
failures would only be manifesting on the pg_xlog files and not for
anything else.)


Well data files are only ever written to in 8k chunks. Maybe these
errors are only occuring on>8k xlog records such as records with
multiple full page images. I'm not sure how much we write for other
types of files but they won't be written to as frequently as xlog or
data files and might not cause errors that are as noticeable.


We only write xlog in XLOG_BLCKSZ units - which is 8kb by default as
well...


Actually, XLogWrite() writes multiple pages at once. If all wal_buffers 
are dirty, it can try to write them all in one write() call.


We've discussed retrying short writes before, and IIRC Tom has argued 
that it shouldn't be necessary when writing to disk. Nevertheless, I 
think we should retry in XLogWrite(). It can write much bigger chunks 
than most write() calls, so there's more room for a short write to 
happen there if it can happen at all. Secondly, it PANICs on failure, so 
it would be nice to try a bit harder to avoid that.


- Heikki


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgres crash? could not write to log file: No space left on device

[Andres Freund]

On 2013-06-26 15:40:08 +0300, Heikki Linnakangas wrote:
> On 26.06.2013 15:21, Andres Freund wrote:
> >On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
> >>On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane  wrote:
> >>>  (Though if it is, it's not apparent why such
> >>>failures would only be manifesting on the pg_xlog files and not for
> >>>anything else.)
> >>
> >>Well data files are only ever written to in 8k chunks. Maybe these
> >>errors are only occuring on>8k xlog records such as records with
> >>multiple full page images. I'm not sure how much we write for other
> >>types of files but they won't be written to as frequently as xlog or
> >>data files and might not cause errors that are as noticeable.
> >
> >We only write xlog in XLOG_BLCKSZ units - which is 8kb by default as
> >well...
> 
> Actually, XLogWrite() writes multiple pages at once. If all wal_buffers are
> dirty, it can try to write them all in one write() call.

Oh. Misremembered that.

> We've discussed retrying short writes before, and IIRC Tom has argued that
> it shouldn't be necessary when writing to disk. Nevertheless, I think we
> should retry in XLogWrite(). It can write much bigger chunks than most
> write() calls, so there's more room for a short write to happen t$here if it
> can happen at all. Secondly, it PANICs on failure, so it would be nice to
> try a bit harder to avoid that.

At the very least we should log the amount of bytes actually writen if
it was a short write to make it possible to discern that case from the
direct ENOSPC response.

This might also be caused by the fact that until recently the SIGALRM
handler didn't set SA_RESTART... If a backend decided to write out the
xlog directly it very well might have an active alarm...

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgres crash? could not write to log file: No spaceleft on device

[Yuri Levinsky]

  Sorry for delay, the email somehow went into junk mails folder. I
didn't compiled Postgres, we downloaded the already compiled version for
SUN Solaris 10 64 bit. The same version is working fine on other
installations. On this specific installation we got "buggy kernel" error
during massive data load (copy) from Informix. As result we added "noac"
flag to NFS that looking on NetApp storage. The "noac" means disable NFS
caching, the problem disappeared despite multiple and instant reproduces
before. Unfortunately after site went up we started to see DB reboots
for 2 days. I disabled pg_dump with tar option, that somehow filled up
by 100% the /var directory and freed it after failure. I limited the
temp storage per session as well. Unfortunately I lost the connection to
the site and unable to check today if it helped or not. 

Sincerely yours,


Yuri Levinsky, DBA
Celltick Technologies Ltd., 32 Maskit St., Herzliya 46733, Israel
Mobile: +972 54 6107703, Office: +972 9 9710239; Fax: +972 9 9710222


-Original Message-
From: Andres Freund [mailto:and...@2ndquadrant.com] 
Sent: Wednesday, June 26, 2013 3:21 PM
To: Greg Stark
Cc: Tom Lane; Jeff Davis; Yuri Levinsky; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres crash? could not write to log file: No
spaceleft on device

On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
> On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane  wrote:
> >  (Though if it is, it's not apparent why such failures would only be

> > manifesting on the pg_xlog files and not for anything else.)
> 
> Well data files are only ever written to in 8k chunks. Maybe these 
> errors are only occuring on >8k xlog records such as records with 
> multiple full page images. I'm not sure how much we write for other 
> types of files but they won't be written to as frequently as xlog or 
> data files and might not cause errors that are as noticeable.

We only write xlog in XLOG_BLCKSZ units - which is 8kb by default as
well...

Yuri, have you compiled postgres with nonstandard configure or
pg_config_manual.h settings?

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

This mail was received via Mail-SeCure System.




-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Postgres crash? could not write to log file: No space left on device

[Tom Lane]

Heikki Linnakangas  writes:
> We've discussed retrying short writes before, and IIRC Tom has argued 
> that it shouldn't be necessary when writing to disk. Nevertheless, I 
> think we should retry in XLogWrite(). It can write much bigger chunks 
> than most write() calls, so there's more room for a short write to 
> happen there if it can happen at all. Secondly, it PANICs on failure, so 
> it would be nice to try a bit harder to avoid that.

Seems reasonable.  My concern about the idea in general was the
impossibility of being sure we'd protected every single write() call.
But if we can identify specific call sites that seem at more risk than
most, I'm okay with adding extra logic there.

regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #8255: encoding latin1

[gabriel . ct]

The following bug has been logged on the website:

Bug reference:  8255
Logged by:  gabriel
Email address:  gabriel...@santamonicace.com.br
PostgreSQL version: 8.4.4
Operating system:   windows xp
Description:

Good afternoon, I live in Brazil and I need to create a database with
encoding LATIN1. how can I make this database. I use windows xp and
postgreSQL. please send a tutorial on how to makeThank you.



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #8256: query screen on pgAdmin is show blank

[dmcmillan]

The following bug has been logged on the website:

Bug reference:  8256
Logged by:  Dan
Email address:  dmcmil...@snapadvances.com
PostgreSQL version: 9.2.4
Operating system:   Mac OS version 10.8.4
Description:

pgadmin 1.16.1


java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b12)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)


distribution postgresql-9.2.4-1-osx.dmg


The query window had 3 areas, the scratch area, the main sql area and the
results area. The only pane that shows up for me is the scratch pane. 


It was working when I installed it initially. I didn't make any changes and
do not believe I updated any os software (although I could be mistaken
there). It stopped working about 3 days ago as far as I can tell.



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8256: query screen on pgAdmin is show blank

[Ashesh Vashi]

Try the View -> 'Default View' in the Query window.

On Wed, Jun 26, 2013 at 8:55 PM,  wrote:

> The following bug has been logged on the website:
>
> Bug reference:  8256
> Logged by:  Dan
> Email address:  dmcmil...@snapadvances.com
> PostgreSQL version: 9.2.4
> Operating system:   Mac OS version 10.8.4
> Description:
>
> pgadmin 1.16.1
>
>
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>
>
> distribution postgresql-9.2.4-1-osx.dmg
>
>
> The query window had 3 areas, the scratch area, the main sql area and the
> results area. The only pane that shows up for me is the scratch pane.
>
>
> It was working when I installed it initially. I didn't make any changes and
> do not believe I updated any os software (although I could be mistaken
> there). It stopped working about 3 days ago as far as I can tell.
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>



-- 
--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company



*http://www.linkedin.com/in/asheshvashi*

[BUGS] BUG #8257: Multi-Core Restore fails when containing index comments

[lalbin]

The following bug has been logged on the website:

Bug reference:  8257
Logged by:  Lloyd Albin
Email address:  lal...@fhcrc.org
PostgreSQL version: 9.2.4
Operating system:   SUSE Linux (64-bit)
Description:

I have found the restore will fail when using pg_restore's -j option, with
more than one core, on a dump that contains a COMMENT INDEX.


I have tried this using both Postgres 9.0.12 & 9.2.4


I have created a test case that shows the problem.


Create a database called test_db.


CREATE DATABASE test_db
  WITH OWNER = postgres
ENCODING = 'UTF8'
TEMPLATE = template0;


Run this next section to add the table, index, and index comment to the
test_db database.


CREATE TABLE public.tbl_test (
  pkey TEXT NOT NULL,
  CONSTRAINT tbl_test_pkey PRIMARY KEY(pkey)
);


COMMENT ON INDEX public.tbl_test_pkey
IS 'Index Comment';


Once this test database is created, create a backup of the database.


pg_dump -Fc test_db > test_db.dump


Drop the test database and now lets restore it.


pg_restore -C -j 3 -d postgres -Fc test_db.dump


pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2525; 0 0 COMMENT INDEX
tbl_test_pkey postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation
"tbl_test_pkey" does not exist
Command was: COMMENT ON INDEX tbl_test_pkey IS 'Index Comment';






pg_restore: [archiver] worker process failed: exit code 1


If you use -j 1 or skip the -j option the restore will restore without any
errors.


Lloyd Albin
Statistical Center for HIV/AIDS Research and Prevention (SCHARP)
Vaccine and Infectious Disease Division (VIDD)
Fred Hutchinson Cancer Research Center (FHCRC)




-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #8238: duplicate of bug #6372 on panffs

[Kristopher Kane]

Sorry to replay in this way but I just joined the list based on a
thread I found from a few days ago.  I hit the panfs fsync problem
this morning and it appears the same as what Jim Hughes is reporting.
Initially thought it was SELinux (RHEL 6.4) but it persisted after I
turned it off.

Bug #6372 and Jim's reply reference a patch for copydir.c but I don't
see a patch.  It might have been an attachment that I didn't see
through the archives.  Is this patch available with instructions for
compilation?

Thanks,

Kris


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs