I am about to port a large database application from 7.4.x* to 8.0
(mainly to test 8.0).
There is an interesting thing I have come across:
CREATE OR REPLACE FUNCTION xy(int4) RETURNS SETOF RECORD AS '
DECLARE
v_isALIAS FOR $1;
v_loop int4;
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)
Number of seconds between ARC reports. If
On my german Windows XP Professional, %t in log_line_prefix produces
2004-09-18 14:23:26 Westeuropische Sommerzeit
This is rather long and ugly. It is already on the open item list:
* shorten timezone for %t log_line_prefix
Additionally I would suggest something like %z. Most of the time, time
Quoth [EMAIL PROTECTED] (Tom Lane):
Chris Browne [EMAIL PROTECTED] writes:
We have discovered an interesting locking scenario with Slony-I that
is pointing to a use for the ability to exclude certain schemas from
pg_dump.
The situation is that when a full pg_dump kicks off, a Slony-I
create
Hi everybody,
I have started testing PostgreSQL on windows. Now that I have managed to
import a dump of one of our production databases to postgres on my notebook,
there is one issue that came up immediatly after running VACUUM FULL:
pgwriter is keeping my disks busy and disturbs me :-(. The
Hi all,
I was implement the transaction idle timeout function in PostgreSQL
(version 7.4.5 and 8.0.0beta2)
test=# SET trans_idle_timeout=10;
SET
test=# BEGIN;
BEGIN
(ps)
...
postgres: sygma test [local] idle in transaction (3)
postgres: sygma test [local] idle in transaction (2)
postgres:
On Sep 17, 2004, at 3:55 PM, Tom Lane wrote:
Marc Colosimo [EMAIL PROTECTED] writes:
I'm using 7.4.5 on Mac OS X (G5) and was profiling it to see why it is
SO SLOW at committing inserts and deletes into a large database. One
of the many slowdowns was from MemSet. I found an old (2002) thread
On Wed, 15 Sep 2004 13:50:43 -0400, [EMAIL PROTECTED] (Tom Lane)
wrote:
Well, (a) I ran out of time, and (b) I wasn't sure what the most
convenient API would be. Should we create something that packages
together a Parse and a Describe Statement, or expose those as
separate things?
There's
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
CREATE OR REPLACE FUNCTION xy(int4) RETURNS SETOF RECORD AS '
...
RETURN v_rec;
...
' LANGUAGE 'plpgsql';
ERROR: RETURN cannot have a parameter in function returning set; use
RETURN NEXT at or near v_rec
On Fri, Sep 17, 2004 at 08:47:02AM +0200, Szima G?bor wrote:
I was implement the transaction idle timeout function in PostgreSQL
(version 7.4.5 and 8.0.0beta2)
It sounds interesting to me (for use in libpqxx, the C++ API), but perhaps
for a slightly unusual reason. When a connection to the
Marc Colosimo wrote:
Oops, I used the same setting as in the old hacking message (-O2, gcc
3.3). If I understand what you are saying, then it turns out yes, PG's
MemSet is faster for smaller blocksizes (see below, between 32 and
64). I just replaced the whole MemSet with memset and it is not
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
It sounds interesting to me (for use in libpqxx, the C++ API), but perhaps
for a slightly unusual reason. When a connection to the backend is lost
just as you're waiting for the result of a COMMIT, you can't be sure if the
transaction was rolled
On Sat, Sep 18, 2004 at 12:43:05PM -0400, Tom Lane wrote:
I don't see any reason for guesswork. Remember the PID of the backend
you were connected to. On reconnect, look in pg_stat_activity to see if
that backend is still alive; if so, sleep till it's not. Then check to
see if your
Manfred Spraul [EMAIL PROTECTED] writes:
That's the price you pay for weakly ordered memory access.
Linux on ppc uses eieio, on ppc64 lwsync is used. Could you check if
they are faster?
I recall looking at lwsync and being concerned about portability
problems --- older assemblers will fail to
On Sat, Sep 18, 2004 at 12:43:05PM -0400, Tom Lane wrote:
I don't see any reason for guesswork. Remember the PID of the backend
you were connected to. On reconnect, look in pg_stat_activity to see if
that backend is still alive; if so, sleep till it's not. Then check to
see if your
On Sep 17, 2004, at 6:23 PM, Oliver Jowett wrote:
template1= prepare s1(int) as select typname from pg_type where oid
= $1;
PREPARE
template1= execute s1('16');
typname -
bool
(1 row)
You're still telling it the type via that int.
Regards,
David
---(end of
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Sat, Sep 18, 2004 at 12:43:05PM -0400, Tom Lane wrote:
I don't see any reason for guesswork. Remember the PID of the backend
you were connected to. On reconnect, look in pg_stat_activity to see if
that backend is still alive; if so, sleep till
On Sat, Sep 18, 2004 at 02:32:32PM -0400, Tom Lane wrote:
No, because of the reporting delay. I would recommend waiting for the
backend's row in pg_stat_activity to disappear entirely. Under normal
circumstances that should occur quickly. If there's a communications
problem, it might take
On Sat, Sep 18, 2004 at 02:32:32PM -0400, Tom Lane wrote:
No, stats_command_string need not be set, only stats_start_collector.
BTW, I've got this set (I'm even running as postgres) but still I get
the command string not enabled message instead of current_query. :(
Jeroen
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Sat, Sep 18, 2004 at 02:32:32PM -0400, Tom Lane wrote:
No, stats_command_string need not be set, only stats_start_collector.
BTW, I've got this set (I'm even running as postgres) but still I get
the command string not enabled message instead of
On Sat, Sep 18, 2004 at 03:41:24PM -0400, Tom Lane wrote:
No, stats_command_string need not be set, only stats_start_collector.
BTW, I've got this set (I'm even running as postgres) but still I get
the command string not enabled message instead of current_query. :(
It has to be set in
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Sat, Sep 18, 2004 at 02:32:32PM -0400, Tom Lane wrote:
If there's a communications
problem, it might take awhile to detect connection loss ... but if
there's a communications problem, you probably aren't going to be able
to open a new
David Wheeler wrote:
On Sep 17, 2004, at 6:23 PM, Oliver Jowett wrote:
template1= prepare s1(int) as select typname from pg_type where oid
= $1;
PREPARE
template1= execute s1('16');
typname -
bool
(1 row)
You're still telling it the type via that int.
Well, obviously. I haven't
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
On Sat, Sep 18, 2004 at 03:41:24PM -0400, Tom Lane wrote:
No, stats_command_string need not be set, only stats_start_collector.
BTW, I've got this set (I'm even running as postgres) but still I get
the command string not enabled message instead
On Sat, Sep 18, 2004 at 04:05:26PM -0400, Tom Lane wrote:
Well, I think it would time out quickly --- anyway on the order of
minutes not hours. By hypothesis, the situation you're worried about is
where the backend was unable to send you a COMMIT acknowledgement
message. The kernel is
On Sep 18, 2004, at 1:09 PM, Oliver Jowett wrote:
Well, obviously. I haven't modified the backend code to accept
'unknown' in PREPARE..
Right, and that's what we're looking for.
My point was the client does *not* need to know the type inferred by
the PREPARE in the 'unknown' case to make use of
David Wheeler wrote:
On Sep 18, 2004, at 1:09 PM, Oliver Jowett wrote:
Well, obviously. I haven't modified the backend code to accept
'unknown' in PREPARE..
Right, and that's what we're looking for.
My point was the client does *not* need to know the type inferred by
the PREPARE in the
Oliver Jowett [EMAIL PROTECTED] writes:
Tom reckons that PREPARE (at the SQL level) taking unknown types is not
useful as there is no feedback mechanism along the lines of the V3
protocol Describe messages to let the client find out what types were
inferred by the PREPARE.
I am saying
Developer docs have this (in SAVEPOINT command reference):
SQL requires a savepoint to be destroyed automatically when another
savepoint with the same name is established. In PostgreSQL, the old
savepoint is kept, though only the more recent one will be used when rolling
back or releasing.
Michael Paesold [EMAIL PROTECTED] writes:
If the first example code is used (which I would use if I did not think
about postgresql's exception), the subxact state stack in xact.c will grow
and grow and grow... whereas in the case of compliance with the standard, it
will not.
This is fairly
Michael Paesold wrote:
BEGIN;
SAVEPOINT a;
INSERT INTO ...
SAVEPOINT a;
INSERT INTO ...
SAVEPOINT a;
...
(encountering an error it would just ROLLBACK TO a;)
According to the standard this is exactly the same as:
BEGIN;
SAVEPOINT a;
INSERT INTO ...
RELEASE SAVEPOINT a;
SAVEPOINT a;
INSERT INTO ...
Tom Lane wrote:
This is fairly irrelevant though, as the state stack entry is only a
small part of the resources consumed by an uncommitted subtransaction.
I don't really think it outweighs the argument you quoted about
accidental collisions of savepoint names causing problems.
Perhaps I am
32 matches
Mail list logo
