On Fri, May 19, 2006 at 01:39:45PM -0500, Jim C. Nasby wrote:
Do you have any stats on CPU usage? Memory usage?
I've only been taking a look at vmstat from time-to-time, and I have yet
to see the machine get CPU-bound. Haven't really paid much attention to
memory. Is there anything in
Hi All,
While trying to implement a recent TODO item, I noticed this behaviour:
test=# drop table t2; drop table t1;
DROP TABLE
DROP TABLE
test=# create table t1(a int primary key );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
t1_pkey for table t1
CREATE TABLE
test=#
Gurjeet Singh [EMAIL PROTECTED] writes:
Issuing a COMMIT or an END as the last command leads to a
ROLLBACK. Although the behaviour is correct, shouldn't the user be
atleast warned about having issued a wrong command to end the
transaction?
Please see the archives. This has been discussed
On 5/21/06, Gurjeet Singh [EMAIL PROTECTED] wrote:
Hi All,
While trying to implement a recent TODO item, I noticed this behaviour:
test=# drop table t2; drop table t1;
DROP TABLE
DROP TABLE
test=# create table t1(a int primary key );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit
refer: [HACKERS] Commit turns into rollback?
On 3/17/06, Tom Lane [EMAIL PROTECTED] wrote:
So it's not the fact that it rolls back that bugs you, it's the way that
the action is reported? We could talk about changing that maybe --- it
wouldn't break existing scripts AFAICS. It might break
One more question comes to mind. IIRC, Oracle doesn't need you to
rollback the whole transaction if one statement fails (like constarint
violation in this case)!!! Does the standard dictate that an error in
a transaction should force a rollback?
I could be wrong about Oracle; I do not have
On 5/21/06, Gurjeet Singh [EMAIL PROTECTED] wrote:
One more question comes to mind. IIRC, Oracle doesn't need you to
rollback the whole transaction if one statement fails (like constarint
violation in this case)!!! Does the standard dictate that an error in
a transaction should force a
For those that haven't already seen it, this might give some extra
exposure to PostgreSQL wrt vulnerability research. Though I think nobody
will have a chance to find one (I just don't see how you could possibly
get root through postgresql, since we refuse to run as root), other
things might be
On Fri, 19 May 2006, Simon Riggs wrote:
Now I can run my same pg_bench, or do you guys
have any other suggestions on attempting to reproduce the problem?
No. We're back on track to try to reproduce the original error.
I've been futzing with trying to reproduce the original problem for a few
On Sun, 2006-05-21 at 14:16 -0700, Jeff Frost wrote:
On Fri, 19 May 2006, Simon Riggs wrote:
Now I can run my same pg_bench, or do you guys
have any other suggestions on attempting to reproduce the problem?
No. We're back on track to try to reproduce the original error.
I've been
I attempt to execute a COPY test FROM STDIN using PQsendQuery.
Subsequently, after the appropriate poll()/PQconsumeInput/PQisBusy
calls, PQgetResult returns tens of millions of (invalid?) non-null
PGresults. This behavior seems incorrect, and sometimes causes my
application to exhaust memory and
On Thursday 18 May 2006 12:38, Josh Berkus wrote:
Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
make *migration* easier for those who wake up and smell the BS, but
migration can (and probably should) be one-way.
Somebody earlier was mentioning, why no automatic
Jeff Frost [EMAIL PROTECTED] writes:
Well now, will you look at this:
postgres 20228 1 0 May17 ?00:00:00 postgres: archiver process
postgres 20573 1 0 May17 ?00:00:00 postgres: archiver process
postgres 23817 23810 0 May17 pts/11 00:00:00 postgres: archiver
On Sun, 21 May 2006, Simon Riggs wrote:
I've been futzing with trying to reproduce the original problem for a few days
and so far postgres seems to be just fine with a long delay on archiving, so
now I'm rather at a loss. In fact, I currently have 1,234 xlog files in
pg_xlog, but the archiver
On May 19 11:51, [EMAIL PROTECTED] wrote:
if (PQsendQuery(conn, COPY test FROM STDIN) 0) {
retrieve(conn, 20);
Shouldn't you be send()'ing instead of retrieve()'ing? COPY tbl FROM
stdin, requests data from client to COPY FROM stdin TO tbl.
Regards.
---(end of
Mischa,
Somebody earlier was mentioning, why no automatic transformer from
Transact-SQL to PLPGSQL (maybe with a bunch of glue routines). The grammar
is not a problem, though you have to wonder at all the wired-in keywords
(T-SQL always felt like COBOL).
Actually, porting TSQL to PL/pgSQL
[EMAIL PROTECTED] writes:
I attempt to execute a COPY test FROM STDIN using PQsendQuery.
Subsequently, after the appropriate poll()/PQconsumeInput/PQisBusy
calls, PQgetResult returns tens of millions of (invalid?) non-null
PGresults.
You should fix your code to pay some attention to what
Magnus Hagander [EMAIL PROTECTED] writes:
For those that haven't already seen it, this might give some extra
exposure to PostgreSQL wrt vulnerability research. Though I think nobody
will have a chance to find one (I just don't see how you could possibly
get root through postgresql, since we
Try contrib/pg_trgm...
Chris
Mark Woodward wrote:
I have a side project that needs to intelligently know if two strings
are contextually similar. Think about how CDDB information is collected
and sorted. It isn't perfect, but there should be enough information to be
usable.
Think about this:
19 matches
Mail list logo
