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=
0%
DEBUG:
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 separate
There was some previous discussion of whether DBD:pg should continue
using libpq or implement the wire protocol in Perl, and whether ODBC
should move to using libpq.
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
The only argument against it, that I'm aware of, is that
system() is ANSI, while execve() is POSIX: i.e.
portability... does windows have execve()? That could be done
the way the current preprocessor conditionals yield rmdir
instead of rm.
Windows does have execve(), though it's named
(I apologise in advance if anyone receives multiple copies of this post.
I posted from the wrong address earlier.)
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
I assumed we would want a separate Bind and execute call. Do we?
Yes, we do. (See below.)
Personally I find it annoying
Tom F said:
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()
hi!
I apologize for mailing on the hackers list but I posted on the general list and did not get a good answer.
I have two independent issues, but am addressing them together.
1.
Oracle has package level variables which are not mappable to any postgres equivalent.
could we have something like
sorry my last mail went incomplete
please read through this and ignore my last mail
paraM
- Forwarded by Paramveer Singh/Trilogy on 20/09/2004 05:21 PM -
Paramveer Singh
20/09/2004 05:56 PM
To:[EMAIL PROTECTED]
cc:
Subject:schema level variables and
Hi list,
When I try to create a user using the create user SQL command, where
the command is being executed using the PQexecParams function from
libpq, and the username and password are passed as text (oid 0x19)
parameters (binary), I get a syntax error. The command I'm doing is:
create user
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
(I apologise in advance if anyone receives multiple copies of this post.
I posted from the wrong address earlier.)
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
I assumed we would want a separate Bind and execute call. Do we?
I
Interesting. So it times out a transaction to release its locks. Does
it time from the start of the transaction? I assume so. We do have
statment_timeout so maybe transaction_timeout would be the proper name.
Timing out on just the idle state seems strange to me.
Bruce Momjian wrote:
Interesting. So it times out a transaction to release its locks. Does
it time from the start of the transaction? I assume so. We do have
statment_timeout so maybe transaction_timeout would be the proper name.
Timing out on just the idle state seems strange to me.
Timing
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
Execute can be told to return no more than n rows of results. If there
are more rows available, the server returns PortalSuspended and awaits
another Execute message. The default of 0 imposes no limit.
Because it's sometimes required to call Execute
At 2004-09-20 10:20:03 -0400, [EMAIL PROTECTED] wrote:
What you should be concerned with right now is providing an API for
Parse + Describe Statement, to substitute for the existing approach
of setting up statement objects via PQexec(PREPARE foo ...).
Fair enough. That's why my original
[EMAIL PROTECTED] writes:
Oracle has package level variables which are not mappable to any postgres
equivalent.
could we have something like schema scope variables which could be
directly referred from let's say plpgsql functions?
Can someone give me some pointers on how to go about
Shachar Shemesh [EMAIL PROTECTED] writes:
create user $1 with encrypted password $2
Any idea why this is not working?
Parameters are only supported in plannable statements
(SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
CURSOR these days too).
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
PGresult *
PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid *paramTypes);
Should I go ahead and do that?
(1) What about preparing an unnamed statement ... will you
At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote:
(1) What about preparing an unnamed statement ...
stmtName == will work.
(2) What about discovering the actually resolved parameter types?
I'm not sure what to do about that.
I could extend PGresult to hold ParameterDescription
On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
jdbc/java.
I think having all interfaces take advantage of libpq improvements and
features is a major win. If we need
Hi,
I have recently downloaded, PostgreSql 8.0-beta2-dev3 windows version. I am a newbie to postgresql, i have one question, How can i import or export the existing postgresql database running under unix flavour to windows based postgresql (8.0-beta2-dev3). Is there any facility under the new
Sudhakar Kurumella wrote:
Hi,
I have recently downloaded, PostgreSql 8.0-beta2-dev3 windows version.
I am a newbie to postgresql, i have one question, How can i import or
export the existing postgresql database running under unix flavour to
windows based postgresql (8.0-beta2-dev3). Is there
Tom Lane wrote:
Parameters are only supported in plannable statements
(SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
CURSOR these days too).
That's a shame.
Aside from executing prepared statements, parameters are also useful for
preventing SQL injections. Under those
David Wheeler [EMAIL PROTECTED] writes:
On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
I think we should favor libpq usage wherever possible and only
re-implement it in the native language when required, like for
jdbc/java.
I don't normally post me too posts, but I think that what Bruce
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Oracle has package level variables which are not mappable to any postgres
equivalent.
could we have something like schema scope variables which could be
directly referred from let's say plpgsql functions?
Can someone give me some pointers on how to go
Abhijit Menon-Sen [EMAIL PROTECTED] writes:
At 2004-09-20 11:02:50 -0400, [EMAIL PROTECTED] wrote:
(2) What about discovering the actually resolved parameter types?
Do you have any suggestions?
It depends on whether you think that PQprepare should bundle the
Describe Statement operation or
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
Parameters are only supported in plannable statements
(SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
CURSOR these days too).
That's a shame.
Aside from executing prepared statements, parameters are also useful
Hi there ,
i have this scenario :
- postgresql 7.5 ( with modified heap_* functions to retrieve data
from another dbms)
- the tuple's data is allocated in memory via palloc
(the tuple table slot and the heap tuple hold a pointer to the
data and not to the buffer pages nor hard
Andre wrote:
Package variables are not transactional, additionaly they are
session based - each session has it's own variables(values).
You can assign initial(defult) values in package spec.
Using table for them would also imply several columns
for each datatype or several tables for them.
I did a
Joe Conway wrote:
Andre wrote:
Package variables are not transactional, additionaly they are
session based - each session has it's own variables(values).
You can assign initial(defult) values in package spec.
Using table for them would also imply several columns
for each datatype or several
Hi all,
I'm using the RSS on Mozilla Thundebird and I'm noticing that all
entries are with the date: 01/01/1970 other sites are not affected
by this issue.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 8: explain analyze is your friend
On 9/20/2004 2:02 AM, Michael Paesold wrote:
The bgwriter always flushes the oldest dirty buffers, and every buffer
touched (hit or faulted in). The output above doesn't tell you how many
buffers are really dirty. But if the system is under load, that is
pretty much the same as the distance
Jan Wieck [EMAIL PROTECTED] writes:
bgwriter_delay = 50 (now default 200)
bgwriter_percent = 2(now default 1)
bgwriter_maxpages = 200 (now default 100)
Just what I was having the best TPC-C results with.
I'm a bit hesitant to reduce the default bgwriter_delay, since AFAICS
that will
Hi!
I have a error callback function registered to run each time an SQL
error occurs. The problem is that the errfinish() calls it both if the
executed SQL statement was wrong, and if the statem,ent or plan logging
is enabled, and it seems elog.h doesn't provide the API to find out the
reason
What about the original request to turn off the bgwriter? Would setting
the delay to a very high value do that?
---
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
bgwriter_delay = 50 (now default 200)
Laszlo Hornyak [EMAIL PROTECTED] writes:
I have a error callback function registered to run each time an SQL
error occurs. The problem is that the errfinish() calls it both if the
executed SQL statement was wrong, and if the statem,ent or plan logging
is enabled, and it seems elog.h doesn't
Gaetano Mendola wrote:
Hi all,
I'm using the RSS on Mozilla Thundebird and I'm noticing that all
entries are with the date: 01/01/1970 other sites are not affected
by this issue.
Of course I'm speaking about www.postgresql.org :-)
Watching at the two RSS:
http://www.postgresql.org/news.rss
Shachar Shemesh wrote:
Tom Lane wrote:
Parameters are only supported in plannable statements
(SELECT/INSERT/UPDATE/DELETE; I think there is some hack for DECLARE
CURSOR these days too).
That's a shame.
Aside from executing prepared statements, parameters are also useful for
preventing SQL
On Fri, Sep 17, 2004 at 07:32:30PM -0400, Tom Lane wrote:
involve consulting DNS? If so, try to correlate the crash probability
with changes in your DNS zone contents ...
No changes. The systems in question have no access to DNS.
/etc/hosts only.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
On Fri, 2004-09-17 at 13:18, Tom Lane wrote:
In my mind this is just a clearer statement of what the policy always
was ;-). The patch review/application load was never supposed to fall
entirely on Bruce. The list he maintains is just there to ensure that
nothing slips through the cracks.
CC'ing pgsql-www, in the future please direct these kind of emails to that
group.
On Monday 20 September 2004 20:46, Gaetano Mendola wrote:
Gaetano Mendola wrote:
Hi all,
I'm using the RSS on Mozilla Thundebird and I'm noticing that all
entries are with the date: 01/01/1970 other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another point is that since the ODBC driver is C anyway, there are no
cross-language issues for it in relying on libpq. This is quite
different IMHO from the situation for JDBC, or DBD::Pg, where there are
advantages in having a
Neil Conway [EMAIL PROTECTED] writes:
On Fri, 2004-09-17 at 13:18, Tom Lane wrote:
In my mind this is just a clearer statement of what the policy always
was ;-). The patch review/application load was never supposed to fall
entirely on Bruce. The list he maintains is just there to ensure that
42 matches
Mail list logo
