Re: [HACKERS] Backend Stats Enhancement Request

Robert Treat <xzilla@users.sourceforge.net> writes:
> On Friday 20 June 2008 10:49:49 Tom Lane wrote:
>> Be specific:
>> "Sets the maximum length of pg_stat_activity.current_query."

> I think there are other places this might manifest itself besides
> pg_stat_activity...

No, there aren't.

I'm struggling to come up with something other than our
> custom dtrace prob... ah, well, this will also control the size of statement
> written into the logfile right?

And *certainly* not that.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [SQL] Cross Tab Functions

I wrote a real simple trunc() function fashioned after oracles but
used some simple rules to let me have modulo date_trunc. I don't have
the code anymore. I might sit down and refigure it out...

On Fri, Jun 20, 2008 at 8:54 PM, Decibel! <decibel@decibel.org> wrote:
> Try using extract instead of to_char. date_trunc might also be of use.
>
> On Jun 20, 2008, at 8:05 AM, Chris Preston wrote:
>
>> Hello All,
>> I have used the cross tab function to setup tables that display months'
>> data, however i need to display years data instead of the months.. so i
>> would display 2006 as a column, 2007 as a colum and 2008 as a column. when i
>> tried to modify the simple example of the cross tab (shown below)
>> SELECT i.item_name::text As row_name, to_char(if.action_date,
>> 'year')::text As bucket,
>> SUM(if.num_used)::integer As bucketvalue
>> FROM inventory As i INNER JOIN inventory_flow As if
>> ON i.item_id = if.item_id
>> WHERE (if.num_used <> 0 AND if.num_used IS NOT NULL)
>> AND action_date BETWEEN date '2007-01-01' and date '2008-12-31 23:59'
>> GROUP BY i.item_name, to_char(if.action_date, 'year'), date_part('year',
>> if.action_date)
>> ORDER BY i.item_name, date_part('year', if.action_date);
>>
>> basically i changed the mon and the month to be year.. the system
>> displayed something that i am not sure about. is there a command that
>> converts the year similar to the mon
>>
>> Help again...Please
>
> --
> Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
> Give your computer some brain candy! www.distributed.net Team #1828
>
>
>

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [NOVICE] table oids and comments

Mija Lee wrote:
> I think I'm a little confused about the something in the documentation:
>
> - I think table oids have been deprecated
> (http://www.postgresql.org/docs/8.2/interactive/runtime-config-compatible.html)
>
> - It looks like the only way to retrieve the comments associated with a
> table is to use the function obj_descritption(object_oid, catalog_name).
> (http://www.postgresql.org/docs/8.2/interactive/functions-info.html#FUNCTIONS-INFO-COMMENT-TABLE)
>
> Is this a different oid?

17.12: The use of OIDs in user tables is considered deprecated

9.19: System Information Functions

System functions access system tables; they do not access user tables.

--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

Re: [pgsql-es-ayuda] Duda en necesidad de bloquear tablas

2008/6/20 Arturo Munive [pgsql-es-ayuda] <arturomunive@gmail.com>:
>
> los pagos pueden ser parciales para cada compra , es decir una compra puede
> ser cancelada(pagada) por uno o mas pagos
> el procedimiento lógico para efectuar un pago es el siguiente:
>
> 1. verifico que la compra no esta pagada.
> 2. calculo cuanto suman los pagos anteriores que se le hicieron a la compra
> 3. verifico que el valor del nuevo pago mas los pagos anteriores no superan
> al monto de la compra.
> 4. inserto el pago en su tabla
> 5. si la suma de los pagos es igual a el valor la compra, actualizo la
> compra estableciendo el campo pagada = TRUE.
>
[...]
>
> A. Como puedo asegurar que entre el instante que verifico la suma de los
> pagos anteriores (paso 3)y la inserción del pago que yo
> quiero hacer (paso 4) nadie inserte (borre o modifique) otro pago para la
> misma compra.

una forma es usar transacciones serializables (estas simulan ir en
serie una tras otra)
http://www.postgresql.org/files/developer/transactions.pdf

> ¿debo bloquear la tabla para no permitir inserciones?

Esta es otra opcion, pero en vez de bloquear toda la tabla podrias
usar SELECT .. FOR UPDATE para bloquear solo los registros
involucrados

> ¿la debo bloquear incluso antes de leer los montos de los pagos anteriores,
> antes del paso 3?

En el caso de la tabla de compras es posible que tengas que hacerlo
porque tienes un campo calculado ahi... a menos que uses transacciones
serializables

> Y si es asi como la bloqueo.
>

SELECT ... FOR UPDATE

> B. Si estos 5 pasos los hiciera dentro de un procedimiento almacenado, como
> haria para forzar que el procedimiento
> termine y haga un rollback de cualquier dato actualizado es decir si tengo:
> BEGIN
> -- hago algun insert
> -- hago algun update
> IF (ocurre una condicion no deseada)
> THEN
> ROLLBACK
> END IF;
>
> Cuando hago algo como lo anterior me da el siguiente mensaje:
>
> ERROR: SPI_execute_plan failed executing query "ROLLBACK":
> SPI_ERROR_TRANSACTION
>
> Cual seria la forma de dada una condicion deshacer los cambios en un
> procedimiento.
>

RAISE EXCEPTION

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 5: ¿Has leído nuestro extenso FAQ?

http://www.postgresql.org/docs/faqs.FAQ.html

Re: [pgadmin-hackers] Enabling SQL text field in the SQL tab of object dialog

On Fri, Jun 20, 2008 at 12:48 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Done. I thought we didn't hide UI objects, only disable them, to get a more
> consistant UI.

On a single dialogue we disable objects so that dialogue will always
have the same layout no matter what server you're connected to. The
design from dialogue to dialogue may change as appropriate however.

> The button text doesn't please me. Neither do the message box text. If one
> has a better idea, I'll be glad to know about it.

How about 'Lock DDL' for the checkbox? The message box could be something like:

Locking the DDL will replace it with generated SQL. Are your sure you
wish to lose the changes you have made?

I can't help thinking that 'Lock DDL' is unnecessarily obscure though.
Maybe 'Read only' is better.

In anycase, there are still some sizing issues to resolve - see the
attach screenshots for examples.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Re: [GENERAL] Need to update all entries of one table based on an earlier backup

Thomas Pundt wrote:
>
> On Freitag, 20. Juni 2008, Gregory Williamson wrote:
<...snip...>
> Does
>
> update foo
>    set foo.foo_name2 = foo_old.foo_name2
>   from foo_old
>  where foo.foo_id = foo_old.foo_id;
>
> work for you?

Thanks to all for pointing out the FROM clause.!

"UPDATE foo set foo_name2 = foo_old.foo_name2 FROM foo_old WHERE foo.foo_id = foo_old.foo_id;" did the trick. 

For some reason I keep forgetting that bit. Especially when under stress in the wee hours of the morn. Back to sleep ... ZZZzzzzZZZZ

And thanks again !

GSW

Re: [PERFORM] Which hardware ?

"Scott Marlowe" wrote:
> We had a reporting server with about 80G of data on a machine with 4G
> ram last place I worked, and it could take it a few extra seconds to
> hit the old data, but the SW RAID-10 on it made it much faster at
> reporting than it would have been with a single disk.

Would this be a nice choice ?

HP Proliant DL320 G5p Xeon DC 3 GHz - 8 Go RAM DDR2 ECC
- 4 x 146 Go SAS 15k rpm - RAID-10 HP Smart Array (128 Mo cache)

I finally choose to have 2 data tables:
- one with pre aggregated (dividing size by 10), unpartitionned (=the
database they currently use)
- one with original data, yearly partitionned

I will choose before each statement which table will be used depending on
which select/joins/where/groupby the user choosed.
The aggregated datas will allow me to maintain actual performances (and even
improve it using the new hardware twice more powerfull).

I think lines aggregation will be handled by the java application (excel/csv
file loaded in memory),
which will be much faster than using a trigger on insertion in the full
table.

Thanks.

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [pgadmin-support] Bug: vertical bar and plus don't work when keyboard is set to Polish Pro on Mac OS X

On Fri, Jun 20, 2008 at 11:01 AM, Wiktor Latanowicz True Solutions
<wiktor@truesolutions.pl> wrote:
> When I set keyboard to Polish Pro in Input Menu in International in System
> Preferences - SQL editor doesn't allow to enter + and | characters ( =
> and \ work ) - nothing happens when I press one of those keys.
> To use | or + I have to copy-paste them from other editor.
> When I change keyboard settings to U.S. those keys work.

It seems this is a wxWidgets bug. I've reported it to them and noted
it in our BUGS file

http://trac.wxwidgets.org/ticket/9607

Thanks, Dave

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[pgadmin-hackers] SVN Commit by dpage: r7382 - trunk/pgadmin3

Author: dpage

Date: 2008-06-20 11:44:05 +0100 (Fri, 20 Jun 2008)

New Revision: 7382

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7382&view=rev

Log:
Add Polish Mac keyboard bug

Modified:
trunk/pgadmin3/BUGS

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [GENERAL] Need to update all entries of one table based on an earlier backup

On Freitag, 20. Juni 2008, Gregory Williamson wrote:
| For reasons best left unmentioned, I need to update entries in a table from
| a backup; I need to do all entries.
|
| For reasons eluding my sleep deprived eyes this fails in every variation I
| can think of:
|
| update foo set foo.foo_name2=foo_old.foo_name2 where foo.foo_id =
| foo_old.foo_id; ERROR: missing FROM-clause entry for table "foo_old"

Does

update foo
set foo.foo_name2 = foo_old.foo_name2
from foo_old
where foo.foo_id = foo_old.foo_id;

work for you?

| Could someone please hit me with a clue-stick ? This is crucial and yet I
| am stumbling over something. Since I am not updating foo_old I am baffled
| as to what this messsage really means. I've tried "where foo_old.foo_id =
| foo.foo_id ... same message.

Ciao,
Thomas

--
Thomas Pundt <thomas.pundt@rp-online.de> ---- http://rp-online.de/ ----

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Need to update all entries of one table based on an earlier backup

Hi!

 

You're missing a table declaration for the table foo_old. You might try this:

 

update foo set foo.foo_name2= (SELECT foo_old.foo_name2 FROM foo_old where foo.foo_id = foo_old.foo_id);

 

Kind regards

 

  Markus

---

Von: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] Im Auftrag von Gregory Williamson
Gesendet: Freitag, 20. Juni 2008 12:30
An: pgsql-general@postgresql.org
Betreff: [GENERAL] Need to update all entries of one table based on an earlier backup

For reasons best left unmentioned, I need to update entries in a table from a backup; I need to do all entries.

For reasons eluding my sleep deprived eyes this fails in every variation I can think of:

update foo set foo.foo_name2=foo_old.foo_name2 where foo.foo_id = foo_old.foo_id;
ERROR:  missing FROM-clause entry for table "foo_old"

Could someone please hit me with a clue-stick ? This is crucial and yet I am stumbling over something. Since I am not updating foo_old I am baffled as to what this messsage really means. I've tried "where foo_old.foo_id = foo.foo_id ... same message.

TIA,

Greg Williamson
Senior DBA
DigitalGlobe

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

(My corporate masters made me say this.)

Re: [HACKERS] ecpg generated files ignorable?

On Wed, Jun 18, 2008 at 09:26:24PM -0400, Tom Lane wrote:
> > ? src/interfaces/ecpg/compatlib/libecpg_compatddll.def
> > ? src/interfaces/ecpg/ecpglib/libecpgddll.def
> > ? src/interfaces/ecpg/pgtypeslib/libpgtypesddll.def

IIRC these are for MS VC++.

> > I am not sure if these should stay on the source dir (i.e. are they
> > needed in the tarball). If they are supposed to, then I think they
> > should be listed in the corresponding .cvsignore file.
>
> Makefile.shlib builds these in the distprep action, so I suppose
> they're supposed to be there. libpq .cvsignore's its equivalent
> files, so I'd agree with doing that. It looks like there should be
> three such files in each directory, though, not just one?

Well, in my source tree I have two, one for MS VC++ and one for Borland
C++ Builder. And yes, I can build a third one for MS VC++ as well by
just issuing the corresponding make call. However, I have no idea
whether we need both, the only differ in the lib name:
--- libecpgddll.def 2008-06-20 12:33:29.000000000 +0200
+++ libecpgdll.def 2008-06-20 12:33:16.000000000 +0200
@@ -1,5 +1,5 @@
; DEF file for MS VC++
-LIBRARY LIBECPGD
+LIBRARY LIBECPG
EXPORTS
ECPGallocate_desc @ 1
ECPGconnect @ 2

Maybe someone with more Windows knowledge can explain this? Magnus?

Michael

--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[GENERAL] Need to update all entries of one table based on an earlier backup

For reasons best left unmentioned, I need to update entries in a table from a backup; I need to do all entries.

For reasons eluding my sleep deprived eyes this fails in every variation I can think of:

update foo set foo.foo_name2=foo_old.foo_name2 where foo.foo_id = foo_old.foo_id;
ERROR:  missing FROM-clause entry for table "foo_old"

Could someone please hit me with a clue-stick ? This is crucial and yet I am stumbling over something. Since I am not updating foo_old I am baffled as to what this messsage really means. I've tried "where foo_old.foo_id = foo.foo_id ... same message.

TIA,

Greg Williamson
Senior DBA
DigitalGlobe

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

(My corporate masters made me say this.)

Re: [PATCHES] posix advises ...

Greg Smith írta:
> On Thu, 19 Jun 2008, Zoltan Boszormenyi wrote:
>
>> This patch (revisited and ported to current CVS HEAD) is indeed using
>> Greg's original patch and also added another patch written by Mark Wong
>> that helps evicting closed XLOGs from memory faster.
>
> Great, that will save me some trouble. I've got a stack of Linux
> performance testing queued up (got stuck behind a kernel bug impacting
> pgbench) for the next couple of weeks and I'll include this in that
> testing. I think I've got a similar class of hardware as you tested
> on for initial evaluation--I'm getting around 200MB/s sequential I/O
> right now out of my small RAID setup,.
>
> I added your patch to the queue for next month's CommitFest and listed
> myself as the initial reviewer, but a commit that soon is unlikely.
> Performance tests like this usually take a while to converge, and
> since this is using a less popular API I expect a round of portability
> concerns, too.
>
> Where did Marc's patch come from? I'd like to be able to separate out
> that change from the rest if necessary.

That patch was posted here:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00000.php

> Also, if you have any specific test cases you ran that I could start
> by trying to replicate a speedup on, those would be handy as well.

We experienced synchronized seqscans slowing down after some (10+) clients
which seems to be strange as it should be a strong selling point of 8.3.
With the posix_fadvise() patchs, the dropoff was pushed further.
The query involved multiple tables, it was not a trivial one table
seqscan case.
Without the patch, both a simpler SATA system (each disk at ~63MB/sec)
and a hw RAID with 400+ MB/sec showed slowdown.
The initial 60-63MB/sec with 1-3 clients on the single SATA disk system
quickly dropped to 11-17MB/sec with more clients.
With the patch, it only dropped to 40-47MB/sec.
I cannot recall the RAID figures.

> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
>

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Re: [pgadmin-hackers] SVN Commit by dpage: r7377 - in trunk/pgadmin3/pgadmin: dlg ui

On Fri, Jun 20, 2008 at 10:50 AM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:

> I really need to be able to build pgAdmin on Windows. I'll prepare a
> virtualbox for this.

It does make debugging a *lot* easier, but even if only for testing,
that would be a good thing.

> When I modify a .xrc file, should I also commit the xrcDialogs.cpp file?
> (modified after executing embed-xrc)

Yes.

I've been playing with cmake recently though, and if/when I get round
to replacing the pgAdmin build system, I'll remove xrcdialogs.cpp from
SVN altogether and make it a build target.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [pgadmin-support] Error set CLRF in SqlEditor on Windows

On Fri, Jun 20, 2008 at 7:43 AM, "Соболь А.Е." <gen_dir@infogroup.ru> wrote:
> Version pgadmin-III 1.8.4.
> Operating System Windows 2000
> RussianWin1251
>
> Errors:
> 1. I am seting mode [CLRF Dos] in "Sql editor", text is coverting Ok. But
> when am starting to type new text, new text is inputing with [LF] symbol.

Fixed in SVN for 1.8.5.

> 2. When I open new work session on "Sql editor", setting [CLRF Dos] reset on
> [LF]. :( Need save this setting in options menu. My Cvs system not made
> compare when .sql include [LF] in text file :(

I've committed a change along these lines for the next major release.
It will remember whatever setting you manually select form the menu,
and set any new instances of the text control to use that setting from
then on. If you open a file that happens to be in a different format
however, it won't update the saved default.

> I want New Enhancements:
> 1. Set Lock mode on 'Sql Editor' when file is ReadOnly mode.

You mean you want the SQL editor to be read-only if the file is? I
find that extremely annoying in other editors that do it. You may not
be able to edit the original file, but there's no reason not to edit
it and then use Save As.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[pgadmin-support] Bug: vertical bar and plus don't work when keyboard is set to Polish Pro on Mac OS X

When I set keyboard to Polish Pro in Input Menu in International in
System Preferences - SQL editor doesn't allow to enter + and |
characters ( = and \ work ) - nothing happens when I press one of
those keys.
To use | or + I have to copy-paste them from other editor.
When I change keyboard settings to U.S. those keys work.

My OS: Mac OS X 10.5.3 ( same problem occurred on every 10.5 and some
later 10.4 - not tested all 10.4 )
Language is set to: English
pgAdmin: 1.8.4 ( problem occurs since 1.8.2 - not tested earlier
versions )

Best Regards,
Wiktor Latanowicz

--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

[pgadmin-hackers] SVN Commit by dpage: r7381 - in trunk/pgadmin3: . pgadmin/ctl pgadmin/frm pgadmin/include/frm pgadmin/include/utils

Author: dpage

Date: 2008-06-20 10:58:42 +0100 (Fri, 20 Jun 2008)

New Revision: 7381

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7381&view=rev

Log:
Save and restore the user-selected line ending type in styled text controls.

Modified:
trunk/pgadmin3/CHANGELOG
trunk/pgadmin3/pgadmin/ctl/ctlSQLBox.cpp
trunk/pgadmin3/pgadmin/frm/frmQuery.cpp
trunk/pgadmin3/pgadmin/include/frm/frmQuery.h
trunk/pgadmin3/pgadmin/include/utils/sysSettings.h

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[HACKERS] Not valid dump [8.2.9, 8.3.1]

Hi all,
we have faced lately dumps not valid, the bug can be replicated using a 8.2.9 or
a 8.3.1 server.

These are the steps to create the database that will generate a not valid dump:

-------------------------------------------------------
CREATE TABLE t_public (
a integer
);

CREATE OR REPLACE FUNCTION sp_public ( )
RETURNS INTEGER AS'
BEGIN
PERFORM * FROM t_public LIMIT 1;
RETURN 0;
END;
' LANGUAGE 'plpgsql'
IMMUTABLE;

CREATE SCHEMA my_schema;
CREATE TABLE my_schema.table_ref(x integer primary key);
CREATE TABLE my_schema.table_test(x integer references my_schema.table_ref (x));

CREATE INDEX idx ON my_schema.table_test (x) WHERE x = sp_public();
--------------------------------

Briefly: in the public schema we have a function that uses a table.
In another schema we have a table with a foreign key to another table, and an partial
index that uses the function in the public schema.

The function is immutable because in our case the table being used inside the function
is a lookup table (readonly).

When the dump is restored the index idx is created but the foreign key is not.
This is the error we obtain during the restore:

psql:test.dump:143: ERROR: relation "t_public" does not exist
CONTEXT: SQL statement "SELECT * FROM t_public LIMIT 1"
PL/pgSQL function "sp_public" line 2 at perform
SQL statement "SELECT fk."x" FROM ONLY "my_schema"."table_test" fk LEFT
OUTER JOIN ONLY "my_schema"."table_ref" pk ON (pk."x"=fk."x") WHERE pk."x"
IS NULL AND (fk."x" IS NOT NULL)"

Regards

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgadmin-hackers] SVN Commit by dpage: r7377 - in trunk/pgadmin3/pgadmin: dlg ui

svn@pgadmin.org a écrit :
> Author: dpage
>
> Date: 2008-06-20 09:57:38 +0100 (Fri, 20 Jun 2008)
>
> New Revision: 7377
>
> Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7377&view=rev
>
> Log:
> Fix colour dialogue on Windows
>
>
> Modified:
> trunk/pgadmin3/pgadmin/dlg/dlgServer.cpp
> trunk/pgadmin3/pgadmin/ui/dlgServer.xrc
> trunk/pgadmin3/pgadmin/ui/xrcDialogs.cpp
>

I really need to be able to build pgAdmin on Windows. I'll prepare a
virtualbox for this.

When I modify a .xrc file, should I also commit the xrcDialogs.cpp file?
(modified after executing embed-xrc)

Thanks.

--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] SVN Commit by dpage: r7380 - in branches/REL-1_8_0_EDB/pgadmin3: . pgadmin/ctl pgadmin/frm

Author: dpage

Date: 2008-06-20 10:39:08 +0100 (Fri, 20 Jun 2008)

New Revision: 7380

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7380&view=rev

Log:
Fix colour dialogue on WindowsEnsure that line endings stay consistent when editing in styled text controls.

Modified:
branches/REL-1_8_0_EDB/pgadmin3/CHANGELOG
branches/REL-1_8_0_EDB/pgadmin3/pgadmin/ctl/ctlSQLBox.cpp
branches/REL-1_8_0_EDB/pgadmin3/pgadmin/frm/frmQuery.cpp

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] SVN Commit by dpage: r7379 - in branches/REL-1_8_0_PATCHES/pgadmin3: . pgadmin/ctl pgadmin/frm

Author: dpage

Date: 2008-06-20 10:38:15 +0100 (Fri, 20 Jun 2008)

New Revision: 7379

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7379&view=rev

Log:
Ensure that line endings stay consistent when editing in styled text controls.

Modified:
branches/REL-1_8_0_PATCHES/pgadmin3/CHANGELOG
branches/REL-1_8_0_PATCHES/pgadmin3/pgadmin/ctl/ctlSQLBox.cpp
branches/REL-1_8_0_PATCHES/pgadmin3/pgadmin/frm/frmQuery.cpp

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[pgadmin-hackers] SVN Commit by dpage: r7378 - in trunk/pgadmin3: . pgadmin/ctl pgadmin/frm

Author: dpage

Date: 2008-06-20 10:37:49 +0100 (Fri, 20 Jun 2008)

New Revision: 7378

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7378&view=rev

Log:
Ensure that line endings stay consistent when editing in styled text controls.

Modified:
trunk/pgadmin3/CHANGELOG
trunk/pgadmin3/pgadmin/ctl/ctlSQLBox.cpp
trunk/pgadmin3/pgadmin/frm/frmQuery.cpp

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Re: [HACKERS] Backend Stats Enhancement Request

Hi,

I'm new to the postgresql source, thought I'd try my hand at
implementing the change suggested (i.e. the GUC-ification of the
PGBE_ACTIVITY_SIZE constant) to get my hands dirty with the code.

How does this sound:

* A new GUC variable -- "activity_message_size" -- will be introduced
* The PGBE_ACTIVITY_SIZE #define becomes PGBE_DEFAULT_ACTIVITY_SIZE
* Minimum value of PGBE_DEFAULT_ACTIVITY_SIZE, maximum value of INT_MAX?

I'm struggling a little to come up with a decent description of the GUC
variable -- something along the lines of "Sets the maximum length of
backend status messages". Any suggestions?

Also: how should we allocate the memory for PgBackendStatus.st_activity?
I'm guessing it's going to be necessary to keep this in shmem ...

Cheers,
T

David Miller wrote:
>> That's not where the problem is. The people who will be left holding
>> the short end of the stick are the ones who can't raise their SHMMAX
>> setting past a couple of megabytes.
>>
>> It might be feasible to make pg_stat_activity's max string length
>> a postmaster-start-time configuration option.
>>
>
> I am fine with a postmaster-start-time configuration option. It is not as flexible as I would like, but would serve the immediate need and keep me from having to
> patch every release of Postgres we install on boxes.
>
> The load on our production servers really prohibits any kind of processing of the log files locally. We have tried using several log shipping methods to process the
> logs on a machine with fewer running processes. These large queries are generated by a third party tool that we have very limited control over. Some of the queries
> captured are as large 16K. The queries are poorly written/generated.
>
>
> David Miller
> River Systems, Inc.
>
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[JDBC] preprocessing of sql in the jdbc driver

Hi to all,

I'm developing a standard java web application using postgres as dbms.
I'm using postgres 8.2.4 on RHEL and the 8.2-504 jdbc driver

I use an mda tool which generates both java and sql code. The problem
is that the sql code generated is not so compliant with postgres
syntax.

Specifically, the SELECT ... FOR UPDATE statement is generated with this syntax:

SELECT T1.column_1, ..., T1.column_N
FROM table_name AS T1
WHERE ...
FOR UPDATE OF T1.column_1, ..., T1.column_n

instead of

SELECT T1.column_1, ..., T1.column_N
FROM table_name AS T1
WHERE ...
FOR UPDATE

So the generator qualifies columns in the FOR UPDATE clause. When I
submit this SQL to the dbms I receive a syntax error:

ERROR: syntax error at or near "." at character 119
LINE 5: FOR UPDATE OF T1.TABLENAME, T1.SURROGATE

We can't patch the generator (we don't have the code!) but we can
modify the jdbc driver to insert a sort of preprocessing of the sql in
order to adjust the syntax.

So my question is, which is the right place to do such operation? I
analyzed the call stack and I've found that the method called before
the execution of "for update" queries is
org.postgresql.jdbc3.Jdbc3Connection.prepareStatement(String , int ,
int , int ).

Maybe I can pre process the sql string in this method, before the
construction of the PreparedStatement. Is this correct?

Thank you for yor attention and thanks in advance

Andrea

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

[pgadmin-hackers] SVN Commit by dpage: r7377 - in trunk/pgadmin3/pgadmin: dlg ui

Author: dpage

Date: 2008-06-20 09:57:38 +0100 (Fri, 20 Jun 2008)

New Revision: 7377

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7377&view=rev

Log:
Fix colour dialogue on Windows

Modified:
trunk/pgadmin3/pgadmin/dlg/dlgServer.cpp
trunk/pgadmin3/pgadmin/ui/dlgServer.xrc
trunk/pgadmin3/pgadmin/ui/xrcDialogs.cpp

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

[PORTS] PGSQL non installer for linux

Hi,

Does pgsql have anything like non-installer for linux i.e tar-gzipped bundle (as is available for linux in the form of zip file) which I can untar /unzip in the target machine? Basically I do not want to use rpm to install as it might fail due to dependency issues. So, if I have a custom built (for various flavours and versions of linux) bundle, I can just unbundle the same in a specified directory and start using it. Right now, if I use rpm for installing pgsql, it installs the files in various directories (like in /usr/bin, /var/lib/pgsql etc). Basically I wanted all the libraries, binaries and the database to come under a common parent directory.

Hope I have made sense. Any help is highly appreciated.
Thanks for any help.
Regards
- Siva

Always do right. This will gratify some people and astonish the rest.
- Mark Twain
(Home page: http://rushto_siva.tripod.com)

Re: [PATCHES] doc patch - archive/restore_command on windows

ITAGAKI Takahiro wrote:
> I found the examples of documentation about archive_command and
> restore_command for Windows are incorrect or improper.
>
> - "copy" doesn't accept / (slash) as a path separator.
> We should use \\ (double backslash) for the purpose.
> - Windows path is typically starts with a drive letter (C:\\).
> - We'd better to quote a whole path, not only the last filename
> with double-quotes. It can work, but is not a windows manner.
>
>
>
>

As previously discussed, we should probably stop recommending use of the
Windows copy command altogether, and recommend use of GnuWin32 cp
instead, for archive_command. The latter does behave sanely w.r.t.
forward slashes.

cheers

andrew

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[ADMIN] pgAdmin + COPY

Hi,

I wonder why pgAdmin's query tool can't process the COPY commands generated by a BACKUP (pg_dump) in plain text dumps (COPY table (column1, column2) FROM stdin). Is it just that it's from standard input? Is there a way to make it work?

Thank you very much,

Peter

--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [PATCHES] doc patch - archive/restore_command on windows

Sorry, this is a correct patch.

Index: doc/src/sgml/backup.sgml
===================================================================
--- doc/src/sgml/backup.sgml (HEAD)
+++ doc/src/sgml/backup.sgml (working copy)
@@ -1122,7 +1122,7 @@
when so asked. Examples:
<programlisting>
restore_command = 'cp /mnt/server/archivedir/%f "%p"'
-restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
+restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</programlisting>
</para>
</listitem>
Index: doc/src/sgml/config.sgml
===================================================================
--- doc/src/sgml/config.sgml (HEAD)
+++ doc/src/sgml/config.sgml (working copy)
@@ -1698,7 +1698,7 @@
and only if it succeeds. Examples:
<programlisting>
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
-archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
+archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows
</programlisting>
</para>
</listitem>

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[PATCHES] doc patch - archive/restore_command on windows

I found the examples of documentation about archive_command and
restore_command for Windows are incorrect or improper.

- "copy" doesn't accept / (slash) as a path separator.
We should use \\ (double backslash) for the purpose.
- Windows path is typically starts with a drive letter (C:\\).
- We'd better to quote a whole path, not only the last filename
with double-quotes. It can work, but is not a windows manner.

Index: doc/src/sgml/backup.sgml
===================================================================
--- doc/src/sgml/backup.sgml (HEAD)
+++ doc/src/sgml/backup.sgml (working copy)
@@ -1122,7 +1122,7 @@
when so asked. Examples:
<programlisting>
restore_command = 'cp /mnt/server/archivedir/%f "%p"'
-restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
+restore_command = 'copy "C:\\server\\archivedir/%f" "%p"' # Windows
</programlisting>
</para>
</listitem>
Index: doc/src/sgml/config.sgml
===================================================================
--- doc/src/sgml/config.sgml (HEAD)
+++ doc/src/sgml/config.sgml (working copy)
@@ -1698,7 +1698,7 @@
and only if it succeeds. Examples:
<programlisting>
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
-archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
+archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows
</programlisting>
</para>
</listitem>

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

[HACKERS] ...Roll Back issue in PGSQL..

Hi

I am trying to create a TRIGGER function,that populates values to another table upon inserting a value into a table. The issue is,if there is a exception(in Table 2) everything gets rolled back including Table1.I dont want this to happen.i want the value of table1 to stay.
I tried "try....except" and introduced SAVEPOINT.But resulted in runtime error.

Can anyone please help me out

--
Deepak

Re: [SQL] "TZ"/"tz" not supported

Are you basically saying that "TZ" can be used in an "output template
string", but not in an "input template string" (in the terminology of
the documentation)? If this is the case, shouldn't this be mentioned
in the documentation? Also, is there a fundamental reason for this
limitation or is it just the implementation waiting to be completed
(nobody has had an itch intensive enough to scratch it)?

Thanks
Peter

On Fri, Jun 20, 2008 at 8:50 AM, A. Kretschmer
<andreas.kretschmer@schollglas.com> wrote:
> am Fri, dem 20.06.2008, um 8:35:10 +0200 mailte Peter Kovacs folgendes:
>> Thank you, Andreas! Your advice is very useful to me.
>>
>> I would still be interested why "TZ" is not accepted in the format string.
>
> I think because TZ is only useful for displaying a timestamptz and not
> for internal representation and/or calculation.
>
> For displaying you can use to_char(timestamptz, format-string).
>
>
> Andreas
> --
> Andreas Kretschmer
> Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
> GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA

http://wwwkeys.de.pgp.net
>
> --
> Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-sql
>

--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

Re: [ADMIN] Major upgrade advice

Why not simply,
SELECT * FROM xxx WHERE <timestamp_column>::date = '2008-05-20'::date;

Στις Thursday 19 June 2008 21:56:09 ο/η Roberto Garcia έγραψε:
> We changed it because 8.3 doesn't allow the operator LIKE on timestamp
> columns. Your syntax works fine but we weren't used to use as u do.
> There weren't any specific reason, only another way to do that.
>
> I think when we read that operator LIKE and timestamp values were
> incompatible we assumed that timestamp values couldn't be compared to
> any char value, opposed as your syntax is.
>
> We've tried to do "select * from X where <timestamp column> =
> '2008-05-20 10:'", expecting that the result would be any minute from 10
> o'clock (10:15, 10:30, 10:45, etc) of the specific date, but this syntax
> retrieves only 10:00 from that date.
>
> Tks for the new syntax.
>
> Regards
> Roberto Garcia
>
> Gregory S. Youngblood wrote:
> > That's a pretty substantial change. Why did you have to make this change?
> > Was it causing syntax errors or to get better performance on those types of
> > queries? Actually, now that I think about it, didn't:
> > select * from X where <timestamp column> between '2008-05-20 00:00:00' and
> > '2008-05-20 23:59:59'
> > work? I could have sworn I have used that syntax in 8.2 without having to
> > arbitrarily cast the arguments... now I'm going to have to go look. :)
> >
> > Yup, confirmed, 8.2.7 and no casting on the date arguments when I was using
> > between.
> >
> > I'm just curious if there was a specific reason (i.e. better performance,
> > better use of indexes, etc.) for your syntax.
> >
> > Thanks,
> > Greg
> >
> > -----Original Message-----
> > From: pgsql-admin-owner@postgresql.org
> > [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Roberto Garcia
> > Sent: Wednesday, June 18, 2008 12:01 PM
> > Cc: pgsql-admin@postgresql.org
> > Subject: Re: [ADMIN] Major upgrade advice
> >
> > Just to mention one issue we had here:
> >
> > In 8.1 we did this to retrieve all data from a specific date:
> > SELECT * FROM xxx
> > WHERE <timestamp_column> LIKE '2008-05-20%'
> >
> > In 8.3 we had to change to:
> > SELECT * FROM xxx
> > WHERE <timestamp_column> >= CAST('2008-05-20' as timestamp) AND
> > <timestamp_column> < CAST('2008-05-21' as timestamp)
> >
> > Regards
> > Roberto Garcia
> >
> >
> >
>
>
> Roberto Garcia
> Banco de Dados, MSc
> Fone: (12) 3186-8405
> --
> A luta contra o aquecimento global depende de cada um de nós, faça sua parte, economize recursos naturais.
> --
> http://www.cptec.inpe.br
> http://www.inpe.br

>
>

--
Achilleas Mantzios

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin