Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> At 2004-09-20 01:25:56 -0400, [EMAIL PROTECTED] wrote:
> >
> > That means you also need to add a new Execute method that takes a
> > portalName instead of a command.
Oh, it occurs to me I missed a step in my earlier logic. I assumed we would
want a
Jan Wieck" <[EMAIL PROTECTED]>
> > Aside from that I don't believe that the output can answer questions
about
> > the efficiency of bgwriter...
> >
> > DEBUG: ARC T1target= 194 B1len= 779 T1len= 180 T2len= 820 B2len=
208
> > DEBUG: ARC total = 99% B1hit= 18% T1hit= 6% T2hit= 75% B2hit=
At 2004-09-20 01:25:56 -0400, [EMAIL PROTECTED] wrote:
>
> That means you also need to add a new Execute method that takes a
> portalName instead of a command.
Yes, thanks. How about these functions, then?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
Hi,
I'm working on running postgresql in a chrooted filesystem.
/src/backend/commands/dbcommands.c makes use of system(3): as far as I
can see, this is only used to execute rm(1) and cp(1). I'd like to avoid
placing /bin/sh in the root of the filesystem (which system() requires).
I see four opti
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
>
> PGresult *
> PQprepare(PGconn *conn,
> const char *stmtName,
> const char *query,
> int nParams,
> const Oi
On Sep 19, 2004, at 9:13 PM, Abhijit Menon-Sen wrote:
OK, how about adding a PQprepare (PQcreatePrepared?) function like
this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid *paramT
At 2004-09-17 14:28:36 -0700, [EMAIL PROTECTED] wrote:
>
> > Assuming that anyone steps up and does the work, that is.
>
> So...any volunteers?
OK, how about adding a PQprepare (PQcreatePrepared?) function like this?
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
On 9/18/2004 8:38 AM, Michael Paesold wrote:
Tom Lane wrote:
There is some debug output available from the ARC code,
but I dunno if its output is actually useful ;-). Try
http://developer.postgresql.org/docs/postgres/runtime-config.html#GUC-DEBUG-SHARED-BUFFERS
"debug_shared_buffers (integer)
Num
> Mahmoud Taghizadeh wrote:
> > I have already this mail to PATCHES mailing list and nobody replied
> > me !!!., Hope the hackers and the developers send their ideas.
> >
> > Qustion: is this approach is suitable for solving the need for locale
> > per column in PostgreSQL ?
>
> I doubt that, bec
On 9/17/2004 7:32 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
The problem comes and goes. So either I can cause a coredump just on the
snap by running a shellscript that does 100 psql -c "select version()"
calls, or it is next to impossible to crash it at all.
Hmm, that's really biz
Hm, ok, setting up a new database with the Conway implementation I see the
time penalty is not "negligible". However it is quite tolerable:
test=> explain analyze select * from test order by a;
QUERY PLAN
On 19 Sep 2004, Greg Stark wrote:
> I've seen people describe here I think the standard behaviour will be nigh
> useless anyway. From what I understand the standard has you declare a locale
> per column.
Yes, you can define a default collation for a column if you want to but
more important you ca
Greg Stark <[EMAIL PROTECTED]> writes:
> I don't see how this is relevant though. One way or another postgres is going
> to have to sort strings in varying locales chosen at run-time. Comparing
> against strcoll's execution time without changing changing locales is a straw
> man.
No, it's not, bec
On Sun, 19 Sep 2004, Greg Stark wrote:
>
> Dennis Bjorklund <[EMAIL PROTECTED]> writes:
>
> > Still, we want the final solution to be what the sql standard specify. A
> > function as the proposed is however useful until a standard sql solution
> > is implemented. I've used a similar function for
Greg Stark <[EMAIL PROTECTED]> writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> 2) switching the locale at run time is too expensive when using the system
>> library.
> Fwiw I did some experiments with this and found it wasn't true.
Really?
I was just in process of doing experiments usi
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Still, we want the final solution to be what the sql standard specify. A
> function as the proposed is however useful until a standard sql solution
> is implemented. I've used a similar function for some projects and it have
> worked well for me also
On 19 Sep 2004, Greg Stark wrote:
> don't think that's an argument for postgres to reimplement portions of the OS.
> If the OS locale handling is slow on some OS's then postgres should just warn
> its users that using locales on those OS's will be slow.
>
> In any case I suspect more than just th
Tom Lane wrote:
> "Michael Paesold" <[EMAIL PROTECTED]> writes:
> > On the other hand, the scenario of a psql option (read: I have
> > given up the idea of a backend implementation) to rollback only
> > last statement on error is quite different.
>
> Sure (and we already have one for autocommit).
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 2) switching the locale at run time is too expensive when using the system
> library.
Fwiw I did some experiments with this and found it wasn't true. At least with
glibc I could switch the locale to what I wanted and back for every record in
a millio
Oliver Jowett wrote:
> BEGIN
> SAVEPOINT a
> -- work
> SAVEPOINT b
> -- work
> SAVEPOINT a
> -- work
> ROLLBACK TO b
> -- work
>
> This is valid: the standard says that the second "SAVEPOINT a" destroys
> and recreates the savepoint "a", but doesn't say that it destroys
> intervening savepo
Mahmoud Taghizadeh wrote:
> I have already this mail to PATCHES mailing list and nobody replied
> me !!!., Hope the hackers and the developers send their ideas.
>
> Qustion: is this approach is suitable for solving the need for locale
> per column in PostgreSQL ?
I doubt that, because 1) it's non
21 matches
Mail list logo
