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 ?
There is a function I attached to this mail. this function is s
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
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 ...
"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 fa
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. (Releas
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 sayi
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 'unknown'
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 t
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 g
"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 "" message instead of current_qu
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 modifi
"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 n
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 "" message instead of current_query. :(
>
> It has to be set in the backend y
"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 "" message instead of current_query
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 "" message instead of current_query. :(
Jeroen
---(end of bro
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 t
"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,
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 broad
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 tra
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 fai
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 tra
"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 r
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 ver
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 th
=?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 nea
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'
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
abo
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: syg
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 more
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 Sl
On my german Windows XP Professional, %t in log_line_prefix produces
2004-09-18 14:23:26 Westeuropäische 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
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.
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;
33 matches
Mail list logo
