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
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
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&
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
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"
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
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
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
"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
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
>
> 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
> "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
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
>
>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 ?)
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
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) ?
>
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/
>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()
18 matches
Mail list logo