[HACKERS] ecpg test runs out of disk space
Just had a rather disturbing event happen on platypus.. [EMAIL PROTECTED]:07]~/buildfarm/HEAD/pgsql.39276/src/interfaces/ecpg/test/results:271>ll preproc-variable.* -rw-r--r-- 1 buildfarm decibel 6328 May 26 23:42 preproc-variable.c -rw-r--r-- 1 buildfarm decibel 76460670919 May 27 02:18 preproc-variable.stderr -rw-r--r-- 1 buildfarm decibel 14668726272 May 27 03:07 preproc-variable.stdout The processes that were running (I'd already killed 39276 without thinking...): [EMAIL PROTECTED]:11]~/buildfarm/HEAD/pgsql.39276/src/interfaces/ecpg/test/results:282>ps auxww USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND buildfarm 65843 94.5 0.1 20848 3056 ?? RN 11:42PM 204:15.00 preproc/variable buildfarm 61647 0.0 0.0 5776 1012 ?? IN 11:42PM 0:00.01 gmake -j4 NO_LOCALE=1 check buildfarm 61654 0.0 0.0 5784 1032 ?? IN 11:42PM 0:00.01 gmake -C test check buildfarm 61876 0.0 0.0 5224 1624 ?? IN 11:42PM 0:00.09 sh ./pg_regress --dbname=regress1 --temp-install --top-builddir=../../../.. --temp-port=55678 --multibyte=SQL_ASCII --load-language=plpgsql --no-locale buildfarm 65430 0.0 0.1 54168 4656 ?? IN 11:42PM 0:00.21 [postgres] buildfarm 65846 0.0 0.1 54232 3720 ?? SNs 11:42PM 0:01.55 postmaster: writer process(postgres) buildfarm 65847 0.0 0.1 17884 3244 ?? SNs 11:42PM 0:00.11 postmaster: stats collector process(postgres) buildfarm 65848 0.0 0.1 54452 3508 ?? INs 11:42PM 0:00.05 postmaster: autovacuum launcher process(postgres) buildfarm 69673 0.0 0.1 30584 3676 ?? S 3:03AM 0:00.07 sshd: [EMAIL PROTECTED] (sshd) buildfarm 69674 0.0 0.1 9452 3284 p3 Ss3:03AM 0:00.07 -tcsh (tcsh) buildfarm 69886 0.0 0.0 4740 1040 p3 R+3:11AM 0:00.00 ps auxww preproc-variable.stdout contains the following line, over and over: ?, born 140737488349640, age = -5704, married (null), children = 4196007 Here's the interesting bits from .stderr: [EMAIL PROTECTED]:10]~/buildfarm/HEAD/pgsql.39276/src/interfaces/ecpg/test/results:277>head -n 100 preproc-variable.stderr [NO_PID]: ECPGdebug: set to 1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGconnect: opening database regress1 on port [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 46: QUERY: set datestyle to iso on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 46 Ok: SET [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 49: QUERY: create table family ( name char ( 8 ) , born integer , age smallint , married date, children integer ) on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 49 Ok: CREATE TABLE [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 52: QUERY: insert into family ( name , married , children ) values ( 'Mum' , '19870714' , 3 ) on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: terminating connection because of crash of another server process[NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: raising sqlcode 0 [NO_PID]: sqlca: code: 0, state: 57P02 [NO_PID]: ECPGexecute line 52: error: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. [NO_PID]: sqlca: code: 0, state: 57P02 [NO_PID]: raising sqlstate YE000 (sqlcode: -400) in line 52, ''server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. ' in line 5'. [NO_PID]: sqlca: code: -400, state: YE000 sql error 'server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. ' in line 5 [NO_PID]: ECPGexecute line 53: QUERY: insert into family ( name , born , married , children ) values ( 'Dad' , '19610721' , '19870714' , 3 ) on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 53: error: no connection to the server [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: raising sqlstate YE000 (sqlcode: -400) in line 53, ''no connection to the server ' in line 53.'. [NO_PID]: sqlca: code: -400, state: YE000 sql error 'no connection to the server ' in line 53. [NO_PID]: ECPGexecute line 54: QUERY: insert into family ( name , age ) values ( 'Child 1' , 16 ) on connection regress1 [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ECPGexecute line 54: error: no connection to the server [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: raising sqlstate YE000 (sqlcode: -400) in line 54, ''no connection to the server ' in line 54.'. [NO_PID]: sqlca: code: -400, state: YE000 sql error 'no connection to the server ' in line 54. [NO_PID]: ECPGexecute line 55: QUERY: insert into family ( name , age ) values ( 'Child 2' , 14 ) on connection regress1 [NO_PID]: sqlca: c
Re: [HACKERS] buildfarm failures after pgstat patch
On Sun, May 27, 2007 at 01:45:45AM -0400, Tom Lane wrote: > Yeah, just saw that myself. Fixed the backend-side problem, but it > would be interesting to find out what ECPG is doing that wasn't exposed > by the core regression tests ... maybe we need another regression test. Don't see anything that special before the backend crashes. Seems to crash on the very first insert that is done after settign datestyle to iso. > Also, for me the ecpg "variable" test case seemed to go into an infinite > loop when the backend dies at this stage; that seems like a lack of > robustness on ECPG's part. Don't worry, it's not an ECPG problem. The regression test just had a bad way to check for errors. I might have to check all tests again, because they were doen to check the stuff in ecpg and might not take a backend crash into regard at all. Simple problem this time was that the test only printed out errors and not stopped. Fixed in HEAD. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ecpg test runs out of disk space
On Sun, May 27, 2007 at 03:18:36AM -0500, Jim C. Nasby wrote: > Just had a rather disturbing event happen on platypus.. Should be fixed now. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Prepare/Declare
On Thu, May 24, 2007 at 04:07:27PM -0400, Tom Lane wrote: > Michael Meskes <[EMAIL PROTECTED]> writes: > > PREPARE p AS > > SELECT * FROM foo; > > DECLARE c CURSOR for p; > > > AFAIRC the standard says this group of statements are perfectly legal > > I'd be interested to see where you draw that conclusion, since > (a) PREPARE statements of that form are not in the standard, and > (b) DECLARE CURSOR is clearly defined as taking a . Sorry, should have been more precise. I was talking about embedded SQL standard. Just look for "dynamic cursors". > You can achieve something approximating this at the protocol level, > since you can do partial fetches from a portal created by Bind'ing > the prepared statement. That won't let you fetch backwards nor > persist the cursor past end of transaction, but maybe you don't > need those things. I could also keep my old simultaing code for this special case, which is probably the best way to do it. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Prepare/Declare
Michael Meskes <[EMAIL PROTECTED]> writes: > On Thu, May 24, 2007 at 04:07:27PM -0400, Tom Lane wrote: >> I'd be interested to see where you draw that conclusion, since >> (a) PREPARE statements of that form are not in the standard, and >> (b) DECLARE CURSOR is clearly defined as taking a . > Sorry, should have been more precise. I was talking about embedded SQL > standard. Just look for "dynamic cursors". Oh, I see what you're looking at. But my point here is that this version of PREPARE has zip to do with ours: it seems more akin to plpgsql's EXECUTE, since AFAICT you are supposed to give it a string value that then gets parsed as a SQL statement. Also it lacks any way to define parameters for the statement. > I could also keep my old simultaing code for this special case, which is > probably the best way to do it. Yeah, I think keeping this version of PREPARE on the ecpg side is probably best. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] buildfarm failures after pgstat patch
Michael Meskes <[EMAIL PROTECTED]> writes: > On Sun, May 27, 2007 at 01:45:45AM -0400, Tom Lane wrote: >> Yeah, just saw that myself. Fixed the backend-side problem, but it >> would be interesting to find out what ECPG is doing that wasn't exposed >> by the core regression tests ... maybe we need another regression test. > Don't see anything that special before the backend crashes. Actually, what was provoking it was that several of the ECPG tests disconnect in the middle of a transaction, which was exposing the fact that pgstat's on_proc_exit hook ran before we'd performed the abort in ShutdownPostgres. The Asserts I'd sprinkled in there to test the transaction-awareness logic were unhappy. The visible failure would be at some random later point, when the crash-recovery logic killed the backend running the next test. Is it worth adding something to the regular regression tests to exercise that code path? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Reviewing temp_tablespaces GUC patch
On Friday 25 May 2007 12:39, Jaime Casanova wrote:
> On 5/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Bernd Helmle <[EMAIL PROTECTED]> writes:
> > > --On Freitag, Mai 25, 2007 10:49:29 + Jaime Casanova
> > >
> > > <[EMAIL PROTECTED]> wrote:
> > >> No, because the RemovePgTempFiles() call in PostmasterMain() will
> > >> remove all tmp files at startup.
> >
> > I believe we do not call RemovePgTempFiles during a crash recovery
> > cycle; this is intentional on the theory that the temp files might
> > contain useful debugging clues.
>
> ah, i forgot that
>
> > So there is a potential problem there.
> > Not sure how important it really is though --- neither crashes nor
> > tablespace drops ought to be so common that we need a really nice
> > solution.
>
> the only semi-sane solution i can think of, is to have a superuser
> only function that acts as a wrapper for RemovePgTempFiles(), but
> still exists a chance for shoot yourself on the foot...
If there was a way for DBA's to know they could safely delete the left-over
files (maybe the files timestamp is older than postmaster start; though not
sure how you measure that), then I think this would be enough to give them a
way out. Of course maybe that level of smarts could be put into drop
tablespace itself?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
