Re: [HACKERS] PANIC: could not write to log file

2012-11-26 Thread Cyril VELTER
On 23/11/12 17:24:48 mailto:t...@sss.pgh.pa.us wrote : > "Cyril VELTER" writes: > >I follow up on my previous message. Just got two more crash today very > > similar to the first ones : > > > PANIC: could not write to log file 118, segment 237 at o

[Re] [Re] Re: [HACKERS] PANIC: could not write to log file

2012-11-22 Thread Cyril VELTER
On 21/11/12 20:39:01 mailto:cyril.vel...@metadys.com wrote: > On 21/11/12 18:10:12, mailto:jeff.ja...@gmail.com wrote: > > On Wed, Nov 21, 2012 at 8:51 AM, Cyril VELTER > > wrote: > > > > > >After upgrading a pretty big database (serveral hundred gig) from 8

[Re] Re: [HACKERS] PANIC: could not write to log file

2012-11-21 Thread Cyril VELTER
On 21/11/12 18:10:12, mailto:jeff.ja...@gmail.com wrote: > On Wed, Nov 21, 2012 at 8:51 AM, Cyril VELTER > wrote: > > > >After upgrading a pretty big database (serveral hundred gig) from 8.2 to > > 9.2 I'm getting some "PANIC: could not write to log file&

[HACKERS] PANIC: could not write to log file

2012-11-21 Thread Cyril VELTER
on; max_connections = 200 # (change requires restart) shared_buffers = 320MB # min 128kB work_mem = 50MB# min 64kB maintenance_work_mem = 700MB # min 1MB checkpoint_segments = 15 # in logfile segments, min 1, 16MB each Any idea on what might be going on ? Cyril VEL

[Re] Re: [Re] Re: [HACKERS] PREPARE and transactions

2004-06-24 Thread Cyril VELTER
De : mailto:[EMAIL PROTECTED] Emission : 24/06/2004 18:59:15 > On Thu, Jun 24, 2004 at 05:11:48PM +0200, Cyril VELTER wrote: > > > > Just my 2 cents here. I agree with tom that the curent behevior for the v3 > > protocol is the right one. I use "On demand"

[Re] Re: [HACKERS] PREPARE and transactions

2004-06-24 Thread Cyril VELTER
Just my 2 cents here. I agree with tom that the curent behevior for the v3 protocol is the right one. I use "On demand" preparation. The first time a statement is needed for a specific connection, it is prepared and the client keep track of that (reusing the prepared statement for

[HACKERS] Prepared queries and portals

2004-06-10 Thread Cyril VELTER
While adapting an application to make use of the new protocol, I've faced one problem. I cannot execute a prepared query and fetch the result in several time. The multiple fetch is accessible with cursor in SQL but I haven't found any way to execute a prepared query in a cursor. The docum

Re: [HACKERS] Prepared select

2004-04-20 Thread Cyril VELTER
libpq doesn't have enought support to allow executing a prepared statement in a named portal (current libpq only works wuth the unnamed portal). But the V3 protocol have it. I solved this problem by adding the following functions. They let you prepare a named statement, execute this statement in a

Re: [HACKERS] Prepared queries and portals

2004-03-04 Thread Cyril VELTER
"Tom Lane" <[EMAIL PROTECTED]> writes: > "Cyril VELTER" <[EMAIL PROTECTED]> writes: > > so I've modified libpq to handle the case by adding to functions : > > > PQexecPreparedPortal(conn,stmtName,portalName,nParams,paramValues,paramlengt

Re: [HACKERS] Path to PostgreSQL portabiliy

2002-05-09 Thread Cyril VELTER
From: "Jan Wieck" <[EMAIL PROTECTED]> > Joel Burton wrote: > > Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al). We'd > > need the dll, sh, rm, and few other things. I'm not sure if it would need to > > be in the standard cygwin file structure; I know that you can reconfigure >

Re: [HACKERS] Native Windows, Apache Portable Runtime

2002-05-06 Thread Cyril VELTER
> Well, SharedMemoryIsInUse is *not* just about ensuring that the shared > memory gets reaped. The point is to ensure that you can't start a new > postmaster until the last old backend is gone. (Consider situations > where the parent postmaster process crashes, or perhaps is kill -9'd > by a car

Re: [HACKERS] Native Windows, Apache Portable Runtime

2002-05-06 Thread Cyril VELTER
> "Cyril VELTER" <[EMAIL PROTECTED]> writes: > > Also why not do the header fillup outside of PGSharedMemoryCreate ? > > Well, (a) I wasn't really concerned about defining an all-new API for > shmem, and (b) I think the header is largely dependent on t

Re: [HACKERS] Native Windows, Apache Portable Runtime

2002-05-05 Thread Cyril VELTER
Hi Tom, I'll do the necessary change for the BeOS port. On a first look, this will greatly simplify the semaphore layer as the new API map quite well with the BeOS one. I find the semaphore API quite clean but have some question on the Shared memory one. The Id's passed to PGSharedMe

Re: [HACKERS] Final call for platform testing

2001-04-04 Thread Cyril VELTER
> >Here are the up-to-date platforms: > >AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold >BeOS 5.0.4 x86 7.1 2000-12-18, Cyril Velter I just checked RC2 on BeOS and everything is OK except the Horlogy test (regarding previous discussions, it seems to be normal ?)

Re: [HACKERS] How to shoot yourself in the foot: kill -9 postmaster

2001-03-06 Thread Cyril VELTER
BeOS haven't this stat (I have a bunch of others but not this one). If I unsterstand correctly, you want to check if there is some backend still attached to shared mem segment of a given key ? In this case, I have an easy solution to fake the stat, because all segment have an encoded nam

Re: [HACKERS] Initdb not running on beos

2000-11-27 Thread Cyril VELTER
rash after some minutes is it related to the first hack ? or is there something else ? cyril >Cyril VELTER <[EMAIL PROTECTED]> writes: >> FATAL 2: InitReopen(logfile 0 seg 0) failed: No such file or directory > >Does BeOS not support link(2) ? >

[HACKERS] Initdb not running on beos

2000-11-26 Thread Cyril VELTER
I've a problem with initdb on beos with the current tree. (The last one running clean is one month old). when I run initdb, I get the following : $ initdb -d -n Running with debug mode on. Running with noclean mode on. Mistakes will not be cleaned up. Initdb variables: PGDATA=/boot/

Re: [HACKERS] Proposal for fixing IPC key assignment

2000-11-26 Thread Cyril VELTER
>We have to assign PGSEMMAGIC small enough to ensure that it won't fall >foul of SEMVMX, but that probably isn't a big problem. A more serious >potential portability issue is that some implementations might not >support the semctl(GETPID) operation (ie, get PID of last process that >did a semop()