Saturday, June 21, 2008

Re: [pgsql-www] archives.postgresql.org not responding

"Joshua D. Drake" <jd@commandprompt.com> writes:
> Stefan Kaltenbrunner wrote:
>> Tom Lane wrote:
>>> I've been seeing connection timeouts for the last little while ...
>>
>> AFAIK - currently there is maintainance work going on at the CMD hosting
>> facility besides archives also search,planet and the buildfarm are down
>> currently ...

> Longer than expected, but everything should be up but buildfarm. I am
> out of caffeine at this point but will look at buildfarm first thing in
> the morning.

Fully understand about lack of caffeine --- but if this was a planned
service outage, some advance notice to pgsql-www would've been
appropriate, no? Or did I just miss it?

regards, tom lane

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

[JDBC] PreparedStatement implementation needet

Hi all,

I can not find the source code of PreparedStatement for postgresql.
I need to transfer some data from oracle db to pg and need to check
the implementation ot setString in pg.

Pls. help me to find the source of setString in pg jdbc source.

many thanks ,
Ivan.

-------------------------------------

Хостинг от 2.60 лв/м | Домейни от 6.90 лв. | Сървъри, VPS от 42.00 лв/м с ДДС
12 GB място, Неограничен трафик, Безплатен домейн – 5.70 лв./м с ДДС!
17 GB място, 700 GB трафик, Безплатен домейн – 11.46 лв./м с ДДС!

http://icn.bg/


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

Re: [pgsql-www] archives.postgresql.org not responding

Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
>> I've been seeing connection timeouts for the last little while ...
>
> AFAIK - currently there is maintainance work going on at the CMD hosting
> facility besides archives also search,planet and the buildfarm are down
> currently ...

Longer than expected, but everything should be up but buildfarm. I am
out of caffeine at this point but will look at buildfarm first thing in
the morning.

Joshua D. Drake

>
>
> Stefan
>


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

Re: [pgsql-es-ayuda] Error en conexion a postgresql desde pgAdmin en ubuntu

Hola José Luis...

On Sat, 21 Jun 2008 14:36:54 -0500, Jose Luis _ wrote
> Saludos, estoy trabando en ubuntu 7 y al al conectarme desde el
> pgAdmin me arroja el siguiente error: Error connecting to the
> server: FATAL: password authentication failed for user "postgres"
> si alguien puede ayudarme con el error , estare muy agradecido.

Espero que no lo tomes a mal, pero estimo que no buscaste en los archivos de
la lista[1]. Es una pregunta respondida muchísimas veces. El problema está en
la contraseña para el usuario "postgres".

Casi seguro que se soluciona retocando el archivo pg_hba.conf (pero asegurate
de saber lo que estás haciendo para que no quede el mundo entero con acceso a
tus bases de datos). Saludos...

[1]
http://www.google.com/search?hl=es&client=iceweasel-a&rls=org.debian%3Aes-AR%3Aunofficial&q=FATAL%3A++password+authentication+failed+for+user+%22postgres%22+site%3Aarchives.postgresql.org&btnG=Buscar&lr=lang_es

p/d: por favor, evita escribir en html a la lista.

-
-------------------------------------------
Sebastián Villalba
A. Gestión Informática
Facultad de Cs. Médicas
U.N.C. - Argentina
-------------------------------------------
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [HACKERS] Hash index build patch has *worse* performance at small table sizes

Did we ever do anything about this?

---------------------------------------------------------------------------

Tom Lane wrote:
> I've been reviewing the hash index build patch submitted here:
> http://archives.postgresql.org/pgsql-patches/2007-10/msg00154.php
>
> Although it definitely helps on large indexes, it's actually
> counterproductive on not-so-large ones. The test case I'm using
> is random integers generated like this:
> create table foo as select (random() * N)::int as f1
> from generate_series(1,N);
> select count(*) from foo; -- force hint bit updates
> checkpoint;
> then timing
> create index fooi on foo using hash(f1);
>
> Using all-default configuration settings on some not-very-new hardware,
> at N = 1E6 I see
>
> 8.3.1: 30 sec
> With pre-expansion of index (CVS HEAD): 24 sec
> With sorting: 72 sec
> To build a btree index on same data: 34 sec
>
> Now this isn't amazingly surprising, because the original argument for
> doing sorting was to improve locality of access to the index during
> the build, and that only matters if you've got an index significantly
> bigger than memory. If the index fits in RAM then the sort is pure
> overhead.
>
> The obvious response to this is to use the sorting approach only when
> the estimated index size exceeds some threshold. One possible choice of
> threshold would be shared_buffers (or temp_buffers for a temp index)
> but I think that is probably too conservative, because in most scenarios
> the kernel's disk cache is available too. Plus you can't tweak that
> setting without a postmaster restart. I'm tempted to use
> effective_cache_size, which attempts to measure an appropriate number
> and can be set locally within the session doing the CREATE INDEX if
> necessary. Or we could invent a new GUC parameter, but that is probably
> overkill.
>
> Comments?
>
> 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

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

Re: [pdxpug] Meeting recap - Logic and Databases with Jeff Davis

On Jun 20, 2008, at 15:04, Selena Deckelmann wrote:

> Last night's meeting was Jeff Davis' last presentation as a Portlander
> (for a while at least!). He is leaving his job at Laika to pursue
> streaming database nirvana at Truviso, a company whose database
> product is based on PostgreSQL. There's a bunch of whip-smart people
> working there, and Jeff will fit right in. If you've got other
> questions about what Truviso does, feel free to ask Jeff.

Congrats on the new job, Jeff!

> We also had cocktails served by Gabrielle. THANK YOU, GAB!

I always miss cocktail nights. :-(

> He used the example of "pending" versus "approved by purchasing but
> not yet received". This sparked a lively debate about the terminology
> - is it accurate to say that "pending" is Context Sensitive, and
> "approved by purchasing..." is Context Insensitive? Most of us seemed
> to agree that the second example was more useful

I think it's more useful, but if you're basing the schema on an
existing terminology used by your purchasing department, you can't go
too far wrong.

> -- although Len
> Shapiro made the case that "pending" wasn't so bad. He made the case
> that we just needed a Data Dictionary to explain it in the
> application. James brought up that programmers and businesses are
> lazy, and are unlikely to keep a piece of documentation like that
> up-to-date.

Excellent points. I've never been anywhere where we had a data
dictionary. Still, "pending" isn't too bad -- especially if you've
ever looked at schemas in commercial products, where there can
sometimes seem to be a use of security through obscurity -- that is,
some vendors seem to try to protect their IP by giving their database
tables and columns completely meaningless names.

> In the third segment, Jeff went over two ways that the SQL standard
> treats NULLs - as UNKNOWN or as NO VALUE. In particular he shared
> these two statements:
>
> test=# select sum(column1) FROM (values (1), (NULL)) t;
> sum
> -----
> 1
> (1 row)

Boy, that sure seems like a bug. This should be legal, though:

try=# select sum(coalesce(column1, 0)) FROM (values (1), (NULL)) t;
sum
-----
1
(1 row)

Even if the above example works, I'd certainly recommend this version
(unless column1 is NOT NULL).

> test=# select (1 + NULL) as plus;
> plus
> ------
>
> (1 row)

This I would expect.

> We chewed on that for a bit. In the first case, NULL is being treated
> as "no value", and just ignored by SUM(). In the second case, NULL is
> being treated as UNKNOWN - as the NULL is not treated as the same data
> type (or domain) as '1', and so the answer is NULL.
>
> (oh boy, i hope i got that right, or there's going to be a long thread
> to explain this :D)

Your explanation makes perfect sense. It's just that the first case
seems wrong (to me, at least).

> So, then James brought up the 17 possible meanings for NULL, and how
> our puny human brains could not compute. Several people made
> exploding brain noises, we continued to talk about NULL and aggregate
> functions and how COUNT() seems to violate ALL the proper rules,
> and... whew.

Yeah. COALESCE() is your friend. This is also why I try to make
columns NOT NULL as often as possible. NULLs are pretty evil.

> Len brought me up to speed on Tom's latest GSOC work, and I said that
> I would help test out his graphical Planner analyzer tool. It's
> something that helps you understand why it is that the Planner chose
> the plan it did. I'm sure that I'll be able to speak more articulately
> about it after I play with it :)

Sounds interesting. Thanks for the summary, Selena, as usual.

Best,

David

>
>
> Thanks all for a great meeting!
>
> --
> Selena Deckelmann
> United States PostgreSQL Association - http://www.postgresql.us
> PDXPUG - http://pugs.postgresql.org/pdx
> Me - http://www.chesnok.com/daily
>
> --
> Sent via pdxpug mailing list (pdxpug@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pdxpug


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

[pgsql-es-ayuda] Problemas con las ñ y las tildes

 

Hola a todos, tengo un problema con las tildes y la ñ y es que no las reconoce. Alguien podría decirme si existe alguna configuración especial de postgresql para esto.

Gracias de antemano.

 

Re: [BUGS] BUG #4257: about unicode extend

very sorry, is i wrong..

the version is 8.0.15.

i just copyed from wrong of server-terminal window.. -_-!

thank you for help.

arli

Michael Fuhr wrote:
> On Sat, Jun 21, 2008 at 01:25:15PM +0000, arli weng wrote:
>
>> PostgreSQL version: 8.3
>>
>
> What does "SELECT version()" return? I'm wondering if the server
> isn't 8.3 but rather an earlier version (see below).
>
>
>> the command (chinese by utf-8):
>> INSERT INTO "title" VALUES(46307243,46307898,'酋鼠𪕨');
>>
>> in sqlite text type, no problem..
>> in postgres report error:
>>
>> invalid byte sequence for encoding "UNICODE": 0xf0
>>
>
> Your INSERT statement works for me in 8.3.3, 8.2.9, and 8.1.13.
> According to the release notes version 8.1 changed UNICODE to UTF8
> and added support for 4-byte characters, so the fact that the error
> says "UNICODE" and your database doesn't appear to support 4-byte
> characters makes me wonder if you're running 8.0 or earlier.
>
>

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

Re: [pgeu-general] European Agenda ?

On Sat, Jun 21, 2008 at 01:36:15PM +0200, damien clochard wrote:
> http://wiki.postgresql.eu/wiki/PostgreSQL_EU_Wiki:Current_events
>
> Now i'm sure we can do better. This is just a "quick and naïve" proposal.
> Feel free to modify or criticize this page. I know that some might find this
> initiative is redundant with :
>
> http://www.postgresql.org/about/eventarchive
>
> Speaking of my own little person, as i don't take airplanes, i'm very little
> concerned by events organized outside Europe and i find it useful to have an
> european-speciifc event page.
>
> My guess is that having this page on the european wiki, will make things
> easier to edit and update.
>
> Any comments ?

My first observation is the duplication of effort. Perhaps it is
possible to categorize the events on
http://www.postgresql.org/about/eventarchive so that you can choose to
only display events near you (wherever that my be)..

Just a though, i do sympathise with the gest, as i myself am not much of
a traveller and would probably never go to, say, the us or canada..

Gr,

Koen

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

Re: [BUGS] BUG #4024: xpath() results lose namespace mappings

Would someone please comment on this bug report from March, 2008?

---------------------------------------------------------------------------

Matt Magoffin wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4024
> Logged by: Matt Magoffin
> Email address: postgresql.org@msqr.us
> PostgreSQL version: 8.3.0
> Operating system: OS X 10.5, Windows XP
> Description: xpath() results lose namespace mappings
> Details:
>
> I was trying to extract XML fragments within a pl/pgsql function by nested
> xpath() function calls, and found that when namespaces are used in the
> XML, only the first xpath() call is able to correctly use namespaces.
>
> First here is an example that works, when no namespaces are used:
>
> BEGIN;
> CREATE TEMPORARY TABLE tmp_xpath_test (x xml) ON COMMIT DROP;
> INSERT INTO tmp_xpath_test VALUES (
> '<foo><bar x="y">bar1</bar><bar x="y">bar2</bar></foo>'::xml);
> SELECT (xpath('/foo/bar[1]', t.x))[1] FROM tmp_xpath_test t;
> SELECT xpath('/bar/@x', (xpath('/foo/bar[1]', t.x))[1]) FROM
> tmp_xpath_test t;
> COMMIT;
>
> The first select is just there to show the result of the inner call to
> xpath() in the second select, and the second select returns:
>
> SELECT xpath('/bar/@x', (xpath('/foo/bar[1]', t.x))[1]) FROM
> tmp_xpath_test t;
> xpath
> -------
> {y}
> (1 row)
>
> Now if I use XML with namespaces, the first SELECT works, but the second
> never returns the expected results:
>
> BEGIN;
> CREATE TEMPORARY TABLE tmp_xpath_test (x xml) ON COMMIT DROP;
> INSERT INTO tmp_xpath_test VALUES (
> '<a:foo xmlns:a="a:urn"><a:bar x="y">bar1</a:bar><a:bar
> x="y">bar2</a:bar></a:foo>'::xml);
> SELECT (xpath('/a:foo/a:bar[1]', t.x, ARRAY[ARRAY['a','a:urn']]))[1] FROM
> tmp_xpath_test t;
> SELECT xpath('/a:bar/@x', (xpath('/a:foo/a:bar[1]', t.x,
> ARRAY[ARRAY['a','a:urn']]))[1],
> ARRAY[ARRAY['a','a:urn']]) FROM tmp_xpath_test t;
> COMMIT;
>
> The select results are
>
> SELECT (xpath('/a:foo/a:bar[1]', t.x, ARRAY[ARRAY['a','a:urn']]))[1] FROM
> tmp_xpath_test t;
> xpath
> ---------------------------
> <a:bar x="y">bar1</a:bar>
> (1 row)
>
> SELECT xpath('/a:bar/@x', (xpath('/a:foo/a:bar[1]', t.x,
> ARRAY[ARRAY['a','a:urn']]))[1],
> lms_kia(> ARRAY[ARRAY['a','a:urn']]) FROM tmp_xpath_test t;
> xpath
> -------
> {}
> (1 row)
>
> For the second select, I expected a single XML text node containing "y",
> just like from the no-namespace result.
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

Re: [pgsql-es-ayuda] Error en conexion a postgresql desde pgAdmin en ubuntu

2008/6/21 Jose Luis _ <josel2820@gmail.com>:
> Saludos, estoy trabando en ubuntu 7 y al al conectarme desde el pgAdmin me
> arroja el siguiente error:
> Error connecting to the server: FATAL: password authentication failed for
> user "postgres"
> si alguien puede ayudarme con el error , estare muy agradecido.
>

tienes que configurar el pg_hba.conf y poner en el postgresql.conf:
listen addresses = '*' (asegurate de descomentar esa linea quitando el
# del inicio de la linea)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [PATCHES] Simplify formatting.c

Index: src/backend/utils/adt/formatting.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v
retrieving revision 1.142
diff -c -c -r1.142 formatting.c
*** src/backend/utils/adt/formatting.c 17 Jun 2008 16:09:06 -0000 1.142
--- src/backend/utils/adt/formatting.c 21 Jun 2008 20:00:45 -0000
***************
*** 1499,1526 ****
if (pg_database_encoding_max_length() > 1 && !lc_ctype_is_c())
{
wchar_t *workspace;
! text *in_text;
! text *out_text;
! int i;

! in_text = cstring_to_text(buff);
! workspace = texttowcs(in_text);

! for (i = 0; workspace[i] != 0; i++)
{
if (wasalnum)
! workspace[i] = towlower(workspace[i]);
else
! workspace[i] = towupper(workspace[i]);
! wasalnum = iswalnum(workspace[i]);
}

! out_text = wcstotext(workspace, i);
! result = text_to_cstring(out_text);

pfree(workspace);
- pfree(in_text);
- pfree(out_text);
}
else
#endif /* USE_WIDE_UPPER_LOWER */
--- 1499,1525 ----
if (pg_database_encoding_max_length() > 1 && !lc_ctype_is_c())
{
wchar_t *workspace;
! int curr_char = 0;

! /* Output workspace cannot have more codes than input bytes */
! workspace = (wchar_t *) palloc((strlen(buff) + 1) * sizeof(wchar_t));

! char2wchar(workspace, strlen(buff) + 1, buff, strlen(buff) + 1);
!
! for (curr_char = 0; workspace[curr_char] != 0; curr_char++)
{
if (wasalnum)
! workspace[curr_char] = towlower(workspace[curr_char]);
else
! workspace[curr_char] = towupper(workspace[curr_char]);
! wasalnum = iswalnum(workspace[curr_char]);
}

! /* Make result large enough; case change might change number of bytes */
! result = palloc(curr_char * MB_CUR_MAX + 1);

+ wchar2char(result, workspace, curr_char * MB_CUR_MAX + 1);
pfree(workspace);
}
else
#endif /* USE_WIDE_UPPER_LOWER */
Index: src/backend/utils/adt/oracle_compat.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/oracle_compat.c,v
retrieving revision 1.80
diff -c -c -r1.80 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c 17 Jun 2008 16:09:06 -0000 1.80
--- src/backend/utils/adt/oracle_compat.c 21 Jun 2008 20:00:45 -0000
***************
*** 467,530 ****
Datum
initcap(PG_FUNCTION_ARGS)
{
! #ifdef USE_WIDE_UPPER_LOWER

! /*
! * Use wide char code only when max encoding length > 1 and ctype != C.
! * Some operating systems fail with multi-byte encodings and a C locale.
! * Also, for a C locale there is no need to process as multibyte.
! */
! if (pg_database_encoding_max_length() > 1 && !lc_ctype_is_c())
! {
! text *string = PG_GETARG_TEXT_PP(0);
! text *result;
! wchar_t *workspace;
! int wasalnum = 0;
! int i;
!
! workspace = texttowcs(string);
!
! for (i = 0; workspace[i] != 0; i++)
! {
! if (wasalnum)
! workspace[i] = towlower(workspace[i]);
! else
! workspace[i] = towupper(workspace[i]);
! wasalnum = iswalnum(workspace[i]);
! }
!
! result = wcstotext(workspace, i);
!
! pfree(workspace);
!
! PG_RETURN_TEXT_P(result);
! }
! else
! #endif /* USE_WIDE_UPPER_LOWER */
! {
! text *string = PG_GETARG_TEXT_P_COPY(0);
! int wasalnum = 0;
! char *ptr;
! int m;
!
! /*
! * Since we copied the string, we can scribble directly on the value
! */
! ptr = VARDATA(string);
! m = VARSIZE(string) - VARHDRSZ;

! while (m-- > 0)
! {
! if (wasalnum)
! *ptr = tolower((unsigned char) *ptr);
! else
! *ptr = toupper((unsigned char) *ptr);
! wasalnum = isalnum((unsigned char) *ptr);
! ptr++;
! }
!
! PG_RETURN_TEXT_P(string);
! }
}


--- 467,482 ----
Datum
initcap(PG_FUNCTION_ARGS)
{
! char *in_string, *out_string;
! text *result;

! in_string = text_to_cstring(PG_GETARG_TEXT_PP(0));
! out_string = str_initcap(in_string);
! pfree(in_string);
! result = cstring_to_text(out_string);
! pfree(out_string);

! PG_RETURN_TEXT_P(result);
}


Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > > I moved str_initcap() over into oracle_compat.c and then had initcap()
> > > > convert to/from TEXT to call it. The code is a little weird because
> > > > str_initcap() needs to convert to text to use texttowcs(), so in
> > > > multibyte encodings initcap converts the string to text, then to char,
> > > > then to text to call texttowcs(). I didn't see a cleaner way to do
> > > > this.
> > >
> > > Why not use wchar2char? It seems there's room for extra cleanup here.
> > >
> > > Also, the prototype of str_initcap in builtins.h looks out of place.
> >
> > I talked to Alvaro on IM, and there is certainly much more cleanup to do
> > in this area. I will work from the bottom up. First, is moving the
> > USE_WIDE_UPPER_LOWER define to c.h, and removing TS_USE_WIDE and using
> > USE_WIDE_UPPER_LOWER instead. Patch attached and applied.
>
> The second step is to move wchar2char() and char2wchar() from tsearch
> into /mb to be easier to use for other modules; also move pnstrdup().

The third step is for oracle_compat.c::initcap() to use
formatting.c::str_initcap(). You can see the result; patch attached
(not applied).

This greatly reduces the size of initcap(), with the downside that we
are making two extra copies of the string to convert it to/from char*.

Is this acceptable? If it is I will do the same for uppper()/lower()
with similar code size reduction and modularity.

If not perhaps I should keep the non-multibyte code in initcap() and
have only the multi-byte use str_initcap().

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

[pgsql-es-ayuda] Error en conexion a postgresql desde pgAdmin en ubuntu

Saludos, estoy trabando en ubuntu 7 y al al conectarme desde el pgAdmin me arroja el siguiente error:
Error connecting to the server: FATAL:  password authentication failed for user "postgres"
si alguien puede ayudarme con el error , estare muy agradecido.

Re: [pgsql-es-ayuda] AYUDA CON TRIGER - URGENTE

Se que esto no ayuda, pero por que es URGENTE?

gb.-

2008/6/20 fulanito detal <fulanito000@hotmail.com>:
>
> HOLA, les pido ayuda con un triger que no me sale..
> Estoy intentando hacer un triger que cuando inserto registros a una tabla,
> que si hay un registro con ciertos campos iguales no inserta el nuevo
> registro, pero modifica un campo del viejo llamado orige , concatenandole el
> origen del nuevo campo...
> el triger compilo pero a la hora de hacer un copy , me sale el siguiente
> error:
>
> ERROR: UPDATE no está permitido en una función no-«volatile»
> CONTEXTO: sentencia SQL: «update imagenfisica set imgfis_origen = $1
> where id = $2 »
> PL/pgSQL function "eliminarepetidos" line 14 at SQL statement
> COPY imagenfisica, línea 1:
> «2450048|N|1738|1933|N19331738000115.TIF|14/05/2008
> 10:15:20|120432|SERVIDOR_4»
>
> alguien tiene idea que quiere decir, y como lo puedo arregla??
>
> aca abajo les dejo el trigger
>
> muchas gracias
>
> jorge
>
> declare
> im imagenfisica%ROWTYPE;
> begin
> SELECT INTO im * FROM imagenfisica i
> WHERE i.imgfis_nomarch = new.imgfis_nomarch
> and i.imgfis_nrolibro = new.imgfis_nrolibro
> and i.imgfis_tpolibro = new.imgfis_tpolibro
> and i.imgfis_anio = new.imgfis_anio;
> IF NOT FOUND THEN
> --RAISE EXCEPTION ''''View '''' || key || '''' not found'''';
> -- RETURN null;
> END IF;
> IF im.imgfis_nomarch is not null THEN
> update imagenfisica
> set imgfis_origen = imgfis_origen || '-'|| new.imgfis_origen
> where id = im.id;
>
> RETURN NULL;
> END IF;
>
> RETURN NEW;
> end;
>
>
> ________________________________
> Tecnología, moda, motor, viajes,.suscríbete a nuestros boletines para estar
> siempre a la última MSN Newsletters

--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [NOVICE] ERROR: could not access status of transaction 575

[ sorry for not responding sooner ]

Brian Hurt <bhurt@janestcapital.com> writes:
> I'm getting an error on a Postgres database when I access a table:

>> template0=# select * from pg_language;
>> ERROR: could not access status of transaction 575
>> DETAIL: could not open file "pg_clog/0000": No such file or directory
>> template0=#
> Unfortunately, as you can tell, this is causing problems, especially
> with creating new databases. I'm wondering if anyone knows what the
> problem could be.

The fact that you're connected to template0, and that it seems to
contain some post-initdb changes, is raising a lot of alarm bells in
my head. Exactly what did you do to this database just after initdb?

The behavior you're seeing indicates a lost hint bit --- that is,
there's a row inserted (or perhaps deleted) by transaction 575,
for which the XMIN_COMMITTED/INVALID (or XMAX_COMMITTED/INVALID)
hint bit never got set before the section of pg_clog containing
XID 575's commit status was thrown away. There are a couple of ways
that could happen in 8.1, but I think the one that bit you is that
8.1 assumes that databases with datallowconn = false do not contain
any unhinted XIDs and so can be ignored while determining where to
truncate pg_clog. So I'm suspicious that you did this:

set template0's datallowconn to true
fool around in template0
set template0's datallowconn to false

without cleaning up after yourself by doing a VACUUM (or better
VACUUM FREEZE) on template0 after mucking with it.

FWIW, 8.2 and up use a different approach that is less vulnerable
to DBA cock-ups ...

regards, tom lane

--
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-www] archives.postgresql.org not responding

Tom Lane wrote:
> I've been seeing connection timeouts for the last little while ...

AFAIK - currently there is maintainance work going on at the CMD hosting
facility besides archives also search,planet and the buildfarm are down
currently ...


Stefan

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

[pgsql-www] archives.postgresql.org not responding

I've been seeing connection timeouts for the last little while ...

regards, tom lane

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

Re: [GENERAL] function question

On Jun 21, 2008, at 8:06 AM, kevin kempter wrote:
> Hi LIst;
> Is there a way to print all the lines being executed for a
> function, like the equivelant of a psql -ef <file> for an sql file ?

No, but you could use a debugger on it if you're running a more
recent version...
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Re: [GENERAL] Abnormal termination of PostgreSQL

Bill Thoen <bthoen@gisnet.com> writes:
> Does anyone know what happened and how I can fix it?

Well, you evidently hit a bug, but there's not nearly enough info here
to guess whether the bug is in Postgres, PostGIS, GEOS, or GDAL, or
perhaps in your custom build process for one of these. I'd suggest
installing the debuginfo RPMs for them if you didn't already, collecting
a coredump (you'll need to ensure the postmaster is started with ulimit
-c unlimited) and getting a stack trace from the dump with gdb.
(Alternatively, since it takes awhile to reach the crash, you could just
attach to the running backend with gdb and let it continue to the crash;
that would save fooling with ulimit.) Then send the trace to
pgsql-bugs. You'll need to provide some details about the table and the
query, too.

regards, tom lane

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

Re: [ADMIN] vacuumdb not enough stack items

On Jun 21, 2008, at 8:47 AM, hjeancha@freesurf.fr wrote:
> i use postgresql version7.4.7 on i386-pc-linux-gnu, autovacuum is
> configured to run on this database.
> But recently, we lost data for a database, we were able to connect
> the database but we couldn't see any table anymore.
> I suspected a transaction ID wraparound, and to fix it, i just
> imported data from a dump file.
> I tried to execute the following query:
> SELECT datname, age(datfrozenxid) FROM pg_database where age
> (datfrozenxid)<0;
> template1=# SELECT datname, age(datfrozenxid) FROM pg_database
> where age(datfrozenxid)<0;
> datname | age
> ------------------------------------------+-------------
> template0 | -597653514
> ez_info1 | -205024652
> XtDB | -205024658
>
>
> Does the negative value of age means that a transaction ID
> wraparound has already occured?

That would be my guess.

> Doing a manual vacuumdb on each database raise an error message
> saying:
> vacuumdb: vacuuming of database "ez_info1" failed: ERREUR: not
> enough stack items

That's probably a bug in vacuum, but even so, you'll want to re-
initdb if you want to just pull back in from a pg_dump.

If you can take the downtime to do a pg_dump/restore, you should
really upgrade to a more recent version. You'll get integrated
autovacuum and code that makes wraparound impossible. I would not
expect you to have any major code issues going to 8.0 or 8.1. Of
course going to 8.3 would be better, but you could run into some
compatibility issues. You'll get a performance gain to boot.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

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

siempre con copia a la lista

2008/6/21 Arturo <arturomunive@gmail.com>:
>>
>>> Ahora que he dormido un poco pensaba, podria poner uan columna en la
>>> compra,
>>> un booleano quiza que se llame en_proceso
>>> y que cuando voy a ejecutar el pago o transaccion lo primero que haga es
>>> marcarla (y hacer un commit) luego ya puedo procesar tranquilo en mi
>>> transaccion normal.
>>>
>>
>> mas campos calculados... :S
>>
>
> Al parecer es una mala idea, por que?
>

Personalmente le tengo fobia a los campos calculados... es algo
adicional de lo que los programadores deben tener presente (y que
pueden olvidar) cuando la base de datos te da formas de evitarlo...

otro punto que pasa si haces el update de tu campo, haces el commit y
entonces se cae el sistema o hay una falla de energia o etc, etc,
etc... (el segundo etc es especialmente preocupante ;)

ademas pensando en tu respuesta anterior...

si haces un SELECT ... FOR UPDATE en la tabla de compras, si alguien
desea insertar un pago no tendra que intentar bloquear los registros
en la tabla de compras? pero como los registros estaran bloqueados no
podra hasta que sueltes el bloqueo en la tabla de compras, solo
entonces podra seguir procesando su insercion y para entonces tu
transacion ya habra hecho COMMIT o ROLLBACK... en esencia es lo mismo
que tu campo "en_proceso" pero con bloqueos y sin datos de que
preocuparse...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

[GENERAL] Abnormal termination of PostgreSQL

I recently installed Fedora Core 9 and included PostgreSQL, built form
source. I also built PostGIS, GEOS and GDAL to work with it. I had no
problems compiling and installing PostgreSQL, but I did have some
problems building GEOS and GDAL, although I think I've resolved those
(FC9 comes with gcc 4.3.0 which has had some changes that affect
building older source.) I'm using the latest versoin of everything.
PostgreSQL is ver 8.3.3.

Anyway, I created a database and "spatialized" it. Then created and
populated a table of about 1.7 million records that have no spatial
component. Then I ran an SQL update command to convert some double
precision columns to 1/100 and 1/10 of their original values. During
this update, about ten minutes into the operation (about when I expected
it would be done) the postgres server shuts down suddenly. It reports
this message:

vfm=> \i update.sql
psql:update.sql:1: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
psql:update.sql:1: connection to server was lost


Nothing very helpful is reported in the serverlog file except the
shutdown message.

In /var/log/messages I get:

Jun 21 10:42:57 sandbox kernel: postmaster[2534]: segfault at b8cfeabf
ip 08081357 sp bfb113c0 error 4 in postgres[8048000+335000]


I tried changing the SQL to only updating one field (e.g. 'update
corn0716 set average_yield = average_yield / 100 ;') and it also failed
in the same manner in about the same time (~10 minutes).

Does anyone know what happened and how I can fix it?

- Bill Thoen


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

[GENERAL] partitioned table insert triggers

I'm trying to create a date-partitioned version of the postgres_log
table that is described here:
http://www.postgresql.org/docs/current/static/runtime-config-logging.html


In lieu of hardcoding the partition table names in the trigger, as shown
in the table partitioning docs, I wanted to dynamically compute the
table name. I tried:

CREATE OR REPLACE FUNCTION postgres_log_insert_trigger()
RETURNS TRIGGER AS $$
DECLARE
c text;
ptable text := 'postgres_log';
ctable text := ptable || '_' ||
to_char(NEW.session_start_time, 'YYYY_MM');
BEGIN
c := 'INSERT INTO ' || ctable || ' VALUES (NEW.*)';
EXECUTE c;
RETURN NULL;
END;
$$
LANGUAGE plpgsql;

I get:
ERROR: NEW used in query that is not in a rule
CONTEXT: SQL statement "INSERT INTO
measurement_postgres_log_2008_05 VALUES (NEW.*)"
PL/pgSQL function "postgres_log_insert_trigger" line 7 at
EXECUTE statement

I didn't really think that would work exactly for the reason given, but
I didn't know what else to try.

Now that my only idea is gone, the question for y'all is: how?

(Okay, I actually do have one more idea: construct the insert values
list with quote_literal. I'm hoping there's a better way.)

Thanks,
Reece

--
Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0


--
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] System in Recovery Mode But No Activity

"Scott Marlowe" <scott.marlowe@gmail.com> writes:
> On Fri, Jun 20, 2008 at 7:56 PM, John Cheng <chonger.cheng@gmail.com> wrote:
>> The state of the server when I sent this e-mail was that there were
>> two remaining connections/postgres subprocesses. I used kill -9 to
>> stop those two subprocesses. Then postgres was able to stop normally.
>> After that, I restarted postgresql normally and it went into recovery
>> mode for about 30 seconds. After that, it started to behave normally
>> again.

> Definitely look into what's causing the oom killer to come out and
> play, and look at turning off overcommit (I think the setting is 2 to
> turn it off)

If you see this again, please get stack backtraces ('bt' command
to gdb). The fact that both stuck processes were in
__lll_mutex_lock_wait() suggests some sort of deadlock, but it's
impossible to guess more without seeing how they got there.

Also, the reference to libpthread is a bit worrisome; we've seen
deadlocks in the past that were a direct result of the backend
unexpectedly becoming multithreaded, eg see this thread:
http://archives.postgresql.org/pgsql-general/2007-11/msg00580.php
You should look into what's causing libpthread to get loaded, and
see if you can stop it. I don't see libperl mentioned in your
gdb output, but maybe something else is pulling it in --- ldd
might help track that down.

regards, tom lane

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

Re: [ADMIN] vacuumdb not enough stack items

hjeancha@freesurf.fr writes:
> i use postgresql version7.4.7 on i386-pc-linux-gnu, autovacuum is
> configured to run on this database.

Hmm ... in theory autovacuum should have kept you out of trouble,
if it was working properly. Were you keeping an eye on its log
output?

> Doing a manual vacuumdb on each database raise an error message saying:
> vacuumdb: vacuuming of database "ez_info1" failed: ERREUR: not enough
> stack items

What probably happened was that this error blocked autovacuum from
completing an anti-wraparound vacuum :-(

[ checks code... ] This appears to indicate a corrupted btree index.
I don't believe we've ever heard of this error occurring in the field
before, so it might be interesting to inquire into exactly what happened
to the index --- but if you just want to get out of trouble I'd suggest
* VACUUM VERBOSE as superuser.
Watch the output to determine which table it fails on.
* REINDEX that table.
* VACUUM VERBOSE again.
This should solve the problem fairly painlessly as long as the
corrupted index isn't on a system catalog. If it is, see the
man page for REINDEX about how to recover.

I'm not sure if vacuuming will get your data back at this point,
but it's certainly worth a try.

Somewhere in here you should think about moving to a more modern
Postgres release. 8.1 and later wouldn't have let you keep going
to the point of wraparound with a critical problem like this.

regards, tom lane

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

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

On Sat, Jun 21, 2008 at 9:03 AM, Arturo <arturomunive@gmail.com> wrote:
>
>>> ¿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
>>
>>
>
> SELECT .. FOR UPDATE bloquea los registros seleccionados eso podria hacerlo
> en la tabla de compras
> pero en la tabla de pagos, no ya que esto impediria modificacion de los
> mismos pero no me evitaria la inserción de un pago extra
>

usa transacciones serializables

> ya se que es muy poco probable que alguien pague de mas, o 2 veces, pero por
> error puede suceder, asi que aunque salte el error quiero mantener integros
> mis datos
> y pregunto coin este ejemplo por que varias operaciones se dan bajo la misma
> forma.
>

o verifica en un trigger BEFORE INSERT que la suma de los registros no
de mas del valor de la compra...

>
> Ahora que he dormido un poco pensaba, podria poner uan columna en la compra,
> un booleano quiza que se llame en_proceso
> y que cuando voy a ejecutar el pago o transaccion lo primero que haga es
> marcarla (y hacer un commit) luego ya puedo procesar tranquilo en mi
> transaccion normal.
>

mas campos calculados... :S

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [DOCS] "Release date" for aborted releases?

Robert Treat <xzilla@users.sourceforge.net> writes:
> On Saturday 07 June 2008 13:02:57 Tom Lane wrote:
>> I am wondering whether to leave the release note pages for 8.3.2, 8.2.8,
>> etc saying "Release date: 2008-06-09", or to change them to something
>> like "Never released". Thoughts?

> At the time, I didn't think anything of this, but was reading through the
> 8.2.x release notes yesterday and the above now feels like an inconsistency
> with what was done with 8.2.2, which we gave an official release date, and
> the subsequent 8.2.3, which was released 2 days later. Now, I supposed 8.2.2
> was further in the release process, but it was pretty much DOA as well.

Well, those cases were different, in that the public announcements had
already gone out. This time was the first time we've ever pulled back
a release prior to announcement. If you read "release date" as meaning
"date of formal announcement email", then "never released" is exactly
the right thing, because you will find no email announcing those
releases in the pgsql-announce archives.

regards, tom lane

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

Re: [BUGS] BUG #4257: about unicode extend

On Sat, Jun 21, 2008 at 01:25:15PM +0000, arli weng wrote:
> PostgreSQL version: 8.3

What does "SELECT version()" return? I'm wondering if the server
isn't 8.3 but rather an earlier version (see below).

> the command (chinese by utf-8):
> INSERT INTO "title" VALUES(46307243,46307898,'酋鼠𪕨');
>
> in sqlite text type, no problem..
> in postgres report error:
>
> invalid byte sequence for encoding "UNICODE": 0xf0

Your INSERT statement works for me in 8.3.3, 8.2.9, and 8.1.13.
According to the release notes version 8.1 changed UNICODE to UTF8
and added support for 4-byte characters, so the fact that the error
says "UNICODE" and your database doesn't appear to support 4-byte
characters makes me wonder if you're running 8.0 or earlier.

--
Michael Fuhr

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

Re: [HACKERS] Not valid dump [8.2.9, 8.3.1]

Tom Lane wrote:
> "Gaetano Mendola" <mendola@gmail.com> writes:
>
>> On Fri, Jun 20, 2008 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (Of course you realize that referencing any table at all in an
>>
>>> "immutable" function is probably a mortal sin...)
>>>
>
>
>> Yes Tom I know, in our case that table is a lookup table, noone update,
>> delete, insert data in it, so from my point of view it is like I have
>> declared a static array inside the function declaration.
>>
>
> No, you'd like to imagine that it is a static array, but that technique
> is just a foot-gun waiting to bite you. As an example, since pg_dump
> has no idea that that function has any dependency on the lookup table,
> there is nothing to stop it from trying to create the index before it's
> populated the lookup table.
>
> (I think it probably works for you at the moment because pg_dump tends
> to fill all the tables before creating any indexes, but the planned
> changes to support multi-threaded restores will certainly break your
> case.)
>
>
>

Purely static lookup tables can also often be replaced by enum types,
often with significant efficiency gains.

cheers

andrew

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

Re: [BUGS] BUG #4257: about unicode extend

"arli weng" <program@163.com> writes:
> the command (chinese by utf-8):
> INSERT INTO "title" VALUES(46307243,46307898,'é…&lsqauo;鼠𪕨');
> in postgres report error:
> invalid byte sequence for encoding "UNICODE": 0xf0

I don't believe this is actually an 8.3 server. In 8.1 or later that
encoding would be referred to as "UTF8"; also, 8.1 and later would show
all bytes of the complained-of character not just the first one.

8.0 and before only support 16-bit Unicode code points (ie, 3-byte
utf8 sequences). We have support for 4-byte sequences in 8.1 and
later. Also, there were some fixes in this area in Jan 2007, so
whichever branch you use, make sure you get a minor release that's
newer than that.

regards, tom lane

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

Re: [HACKERS] Not valid dump [8.2.9, 8.3.1]

"Gaetano Mendola" <mendola@gmail.com> writes:
> On Fri, Jun 20, 2008 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> (Of course you realize that referencing any table at all in an
>> "immutable" function is probably a mortal sin...)

> Yes Tom I know, in our case that table is a lookup table, noone update,
> delete, insert data in it, so from my point of view it is like I have
> declared a static array inside the function declaration.

No, you'd like to imagine that it is a static array, but that technique
is just a foot-gun waiting to bite you. As an example, since pg_dump
has no idea that that function has any dependency on the lookup table,
there is nothing to stop it from trying to create the index before it's
populated the lookup table.

(I think it probably works for you at the moment because pg_dump tends
to fill all the tables before creating any indexes, but the planned
changes to support multi-threaded restores will certainly break your
case.)

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: [ADMIN] PG 8.0.4 - Does Dump + drop_db + reload reset XID to prevent wraparound?

"Bill Bartlett" <bbartlett@softwareanalytics.com> writes:
> In a PostgreSQL 8.0.4 environment, does dropping the database and
> reloading it completely reset the XID information that causes
> transaction ID wraparound?

I gather from the reference to "d:" that you're running on Windows.
You really, really, really need to put an urgent priority on getting
off 8.0.x. (Or get off Windows, but I suppose I'm wasting my breath
suggesting that.) The rename problem that you're hitting is fixed in
8.2 and up, as are a bunch of other Windows-specific problems that
will never be fixed in pre-8.2 branches, because we have abandoned
support for those branches on Windows.

As for the specific question, I think it'd work as long as template0
has never been unfrozen, but an initdb would be a lot more certain
--- and since you apparently have only one user database, there's
no difference in how much reload work you'd have to do.

Lastly, there is no need to use VACUUM FULL for wraparound protection;
plain VACUUM is sufficient. The critical point though is that it has
to be a database-wide VACUUM (and done by a superuser); 8.0 doesn't
track this at a per-table grain, only per-database.

regards, tom lane

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

Re: [DOCS] "Release date" for aborted releases?

On Saturday 07 June 2008 13:02:57 Tom Lane wrote:
> I am wondering whether to leave the release note pages for 8.3.2, 8.2.8,
> etc saying "Release date: 2008-06-09", or to change them to something
> like "Never released". Thoughts?
>

At the time, I didn't think anything of this, but was reading through the
8.2.x release notes yesterday and the above now feels like an inconsistency
with what was done with 8.2.2, which we gave an official release date, and
the subsequent 8.2.3, which was released 2 days later. Now, I supposed 8.2.2
was further in the release process, but it was pretty much DOA as well.
Probably too late to do anything about this now, though I wonder, do we plan
to put 8.3.2 tarballs into the ftp-archives? We have 8.2.2 tarballs
available, though I can't imagine why anyone would need them.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

Re: [pgsql-es-ayuda] AYUDA CON TRIGER - URGENTE

Hola...

On Sat, 21 Jun 2008 15:53:35 +0200, Miguel Rodríguez Penabad wrote
> > ERROR: UPDATE no está permitido en una función no-«volatile»
>
> El error te dice que no puedes usar una función volátil.

En realidad dice exactamente lo contrario. Que no está permitido hacer un
UPDATE en una función *no* volátil. Deberías explicitar que la función es
"VOLATILE" (en lugar de STABLE, ó IMMUTABLE).

http://www.postgresql.org/docs/8.3/static/xfunc-volatility.html

Saludos...

-
-------------------------------------------
Sebastián Villalba
A. Gestión Informática
Facultad de Cs. Médicas
U.N.C. - Argentina
-------------------------------------------

--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

Re: [JDBC] free ETL tool for files, using postgreSQL and jdbc driver

Is there a Unix/Linux version available?

Thanks.

Max Pyziur
pyz@brama.com

On Sat, 21 Jun 2008, Benoît Carpentier wrote:

> Dear all,
>
> Benetl, a free ETL tool for files using postgreSQL is out, in version 2.0 !!!
>
> It is available and freely downloadable at : www.benetl.net
>
> Benetl is developped in Java 5 and uses JDBC driver.
>
> Thanks for your interest.
>
> Regards,
>
> --
> Benoît Carpentier
> www.benetl.net
> Founder of Benetl & Java Developer
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

[JDBC] free ETL tool for files, using postgreSQL and jdbc driver

Dear all,

Benetl, a free ETL tool for files using postgreSQL is out, in version 2.0 !!!

It is available and freely downloadable at : www.benetl.net

Benetl is developped in Java 5 and uses JDBC driver.

Thanks for your interest.

Regards,

--
Benoît Carpentier
www.benetl.net
Founder of Benetl & Java Developer

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

Re: [HACKERS] -head build error report

Joshua D. Drake wrote:
>
> On Sat, 2008-06-21 at 07:53 -0400, Andrew Dunstan wrote:
>>
>>
>>
>> Looks like you do not have the right CVS flags set. You need to use -d
>> when you do a cvs update or you won't pick up new directories.
>>
>> You should really have this set in your .cvsrc file.
>
> Sorry, this is the only project I use dead software for :P (I didn't
> even know there was such a thing as a .cvsrc).
>
> Thanks for the tip :)

http://wiki.postgresql.org/wiki/Working_with_CVS has even more :P


Stefan

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

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

>> ¿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
>
>
SELECT .. FOR UPDATE bloquea los registros seleccionados eso podria
hacerlo en la tabla de compras
pero en la tabla de pagos, no ya que esto impediria modificacion de los
mismos pero no me evitaria la inserción de un pago extra

ya se que es muy poco probable que alguien pague de mas, o 2 veces, pero
por error puede suceder, asi que aunque salte el error quiero mantener
integros mis datos
y pregunto coin este ejemplo por que varias operaciones se dan bajo la
misma forma.


Ahora que he dormido un poco pensaba, podria poner uan columna en la
compra, un booleano quiza que se llame en_proceso
y que cuando voy a ejecutar el pago o transaccion lo primero que haga es
marcarla (y hacer un commit) luego ya puedo procesar tranquilo en mi
transaccion normal.

No se es solo una idea ustedes creen que sea buena, o alguien ya hizo
algo parecido, y le trajo problemas??

--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [HACKERS] [GENERAL] Fragments in tsearch2 headline

Index: src/backend/tsearch/wparser_def.c
===================================================================
RCS file: /home/sushant/devel/pgsql-cvs/pgsql/src/backend/tsearch/wparser_def.c,v
retrieving revision 1.14
diff -c -r1.14 wparser_def.c
*** src/backend/tsearch/wparser_def.c 1 Jan 2008 19:45:52 -0000 1.14
--- src/backend/tsearch/wparser_def.c 21 Jun 2008 07:59:02 -0000
***************
*** 1684,1701 ****
return false;
}

! Datum
! prsd_headline(PG_FUNCTION_ARGS)
{
! HeadlineParsedText *prs = (HeadlineParsedText *) PG_GETARG_POINTER(0);
! List *prsoptions = (List *) PG_GETARG_POINTER(1);
! TSQuery query = PG_GETARG_TSQUERY(2);

! /* from opt + start and and tag */
! int min_words = 15;
! int max_words = 35;
! int shortword = 3;

int p = 0,
q = 0;
int bestb = -1,
--- 1684,1891 ----
return false;
}

! static void
! mark_fragment(HeadlineParsedText *prs, int highlight, int startpos, int endpos)
{
! int i;
! char *coversep = "...";
! int coverlen = strlen(coversep);

! for (i = startpos; i <= endpos; i++)
! {
! if (prs->words[i].item)
! prs->words[i].selected = 1;
! if (highlight == 0)
! {
! if (HLIDIGNORE(prs->words[i].type))
! prs->words[i].replace = 1;
! }
! else
! {
! if (XMLHLIDIGNORE(prs->words[i].type))
! prs->words[i].replace = 1;
! }
!
! prs->words[i].in = (prs->words[i].repeated) ? 0 : 1;
! }
! /* add cover separators if needed */
! if (startpos > 0 && strncmp(prs->words[startpos-1].word, coversep,
! prs->words[startpos-1].len) != 0)
! {
!
! prs->words[startpos-1].word = repalloc(prs->words[startpos-1].word, sizeof(char) * coverlen);
! prs->words[startpos-1].in = 1;
! prs->words[startpos-1].len = coverlen;
! memcpy(prs->words[startpos-1].word, coversep, coverlen);
! }
! if (endpos-1 < prs->curwords && strncmp(prs->words[startpos-1].word, coversep,
! prs->words[startpos-1].len) != 0)
! {
! prs->words[endpos+1].word = repalloc(prs->words[endpos+1].word, sizeof(char) * coverlen);
! prs->words[endpos+1].in = 1;
! memcpy(prs->words[endpos+1].word, coversep, coverlen);
! }
! }
!
! typedef struct
! {
! int4 startpos;
! int4 endpos;
! int2 in;
! int2 excluded;
! } CoverPos;
!
!
! static void
! mark_hl_fragments(HeadlineParsedText *prs, TSQuery query, int highlight,
! int shortword, int min_words,
! int max_words, int max_fragments)
! {
! int4 curlen, coverlen, i, f, num_f;
! int4 stretch, maxstretch;
!
! int4 startpos = 0,
! endpos = 0,
! p = 0,
! q = 0;
!
! int4 numcovers = 0,
! maxcovers = 32;
!
! int4 min, minI = 0;
! CoverPos *covers;
!
! covers = palloc(maxcovers * sizeof(CoverPos));
!
! /* get all covers */
! while (hlCover(prs, query, &p, &q))
! {
! if (numcovers >= maxcovers)
! {
! maxcovers *= 2;
! covers = repalloc(covers, sizeof(CoverPos) * maxcovers);
! }
! covers[numcovers].startpos = p;
! covers[numcovers].endpos = q;
!
! covers[numcovers].in = 0;
! covers[numcovers].excluded = 0;
! numcovers ++;
! /* move p to generate the next cover */
! p++;
! }
!
! /* choose best covers */
! for (f = 0; f < max_fragments; f++)
! {
! min = 0x7fffffff;
! for (i = 0; i < numcovers; i ++)
! {
! coverlen = covers[i].endpos - covers[i].startpos + 1;
! if (!covers[i].in && !covers[i].excluded && min > coverlen)
! {
! min = coverlen;
! minI = i;
! }
! }
! if (min < 0x7fffffff)
! {
! covers[minI].in = 1;
! /* adjust the size of cover
! * if max_words >= len
! * then headline from ext.p - (max_words-len)/2 to ext.q + (maxcoverSize-len) /2
! * if maxcoverSize < len
! * then headline from ext.p to ext.p + maxcoverSize
! */
! startpos = covers[minI].startpos;
! endpos = covers[minI].endpos;
!
! for(curlen = 0, i = startpos; i < endpos && curlen < max_words; i++)
! if (!NONWORDTOKEN(prs->words[i].type))
! curlen++;
! endpos = i;
! if (curlen < max_words)
! {
! /* divide the stretch on both sides of cover */
! maxstretch = (max_words - curlen)/2;
! /* first stretch the startpos */
! stretch = 0;
! for (i = startpos; i >= 0 && stretch < maxstretch; i--)
! {
! if (!NONWORDTOKEN(prs->words[i].type))
! {
! curlen ++;
! stretch ++;
! }
! }
! /* cut back startpos till we find a non short token */
! for ( ; i <= startpos && (NOENDTOKEN(prs->words[i].type) || prs->words[i].len <= shortword); i++)
! {
! if (!NONWORDTOKEN(prs->words[i].type))
! curlen --;
! }
! startpos = i;
! /* now stretch the endpos as much as possible*/
! for (i = endpos; i < prs->curwords && curlen < max_words; i++)
! {
! if (!NONWORDTOKEN(prs->words[i].type))
! curlen ++;
! }
! /* cut back endpos till we find a non-short token */
! for ( ; i >= endpos && (NOENDTOKEN(prs->words[i].type) || prs->words[i].len <= shortword); i--)
! {
! if (!NONWORDTOKEN(prs->words[i].type))
! curlen --;
! }
! endpos = i;
! }
! covers[minI].startpos = startpos;
! covers[minI].endpos = endpos;
!
! /* exclude overlapping covers */
! for (i = 0; i < numcovers; i ++)
! {
! if (i != minI &&
! (covers[i].startpos >= covers[minI].startpos &&
! covers[i].startpos <= covers[minI].endpos))
! covers[i].excluded = 1;
! }
! }
! else
! break;
! }
!
! /* Mark the chosen fragments (covers) */

+ for (num_f = 0, i = 0; i < numcovers; i++)
+ {
+ if (covers[i].in && !covers[i].excluded)
+ {
+ startpos = covers[i].startpos;
+ endpos = covers[i].endpos;
+
+ mark_fragment(prs, highlight, covers[i].startpos, covers[i].endpos);
+ num_f ++;
+ }
+ }
+ /* show at least min_words we have not marked anything*/
+ if (num_f <= 0)
+ {
+ startpos = endpos = curlen = 0;
+ for (i = 0; i < prs->curwords && curlen < min_words; i++)
+ {
+ if (!NONWORDTOKEN(prs->words[i].type))
+ curlen++;
+ endpos = i;
+ }
+ mark_fragment(prs, highlight, startpos, endpos);
+ }
+ pfree(covers);
+ }
+ static void
+ mark_hl_words(HeadlineParsedText *prs, TSQuery query, int highlight,
+ int shortword, int min_words, int max_words)
+ {
int p = 0,
q = 0;
int bestb = -1,
***************
*** 1707,1762 ****
curlen;

int i;
- int highlight = 0;
- ListCell *l;
-
- /* config */
- prs->startsel = NULL;
- prs->stopsel = NULL;
- foreach(l, prsoptions)
- {
- DefElem *defel = (DefElem *) lfirst(l);
- char *val = defGetString(defel);
-
- if (pg_strcasecmp(defel->defname, "MaxWords") == 0)
- max_words = pg_atoi(val, sizeof(int32), 0);
- else if (pg_strcasecmp(defel->defname, "MinWords") == 0)
- min_words = pg_atoi(val, sizeof(int32), 0);
- else if (pg_strcasecmp(defel->defname, "ShortWord") == 0)
- shortword = pg_atoi(val, sizeof(int32), 0);
- else if (pg_strcasecmp(defel->defname, "StartSel") == 0)
- prs->startsel = pstrdup(val);
- else if (pg_strcasecmp(defel->defname, "StopSel") == 0)
- prs->stopsel = pstrdup(val);
- else if (pg_strcasecmp(defel->defname, "HighlightAll") == 0)
- highlight = (pg_strcasecmp(val, "1") == 0 ||
- pg_strcasecmp(val, "on") == 0 ||
- pg_strcasecmp(val, "true") == 0 ||
- pg_strcasecmp(val, "t") == 0 ||
- pg_strcasecmp(val, "y") == 0 ||
- pg_strcasecmp(val, "yes") == 0);
- else
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
- errmsg("unrecognized headline parameter: \"%s\"",
- defel->defname)));
- }

if (highlight == 0)
{
- if (min_words >= max_words)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
- errmsg("MinWords should be less than MaxWords")));
- if (min_words <= 0)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
- errmsg("MinWords should be positive")));
- if (shortword < 0)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
- errmsg("ShortWord should be >= 0")));
-
while (hlCover(prs, query, &p, &q))
{
/* find cover len in words */
--- 1897,1905 ----
***************
*** 1877,1882 ****
--- 2020,2101 ----
prs->words[i].in = (prs->words[i].repeated) ? 0 : 1;
}

+ }
+
+ Datum
+ prsd_headline(PG_FUNCTION_ARGS)
+ {
+ HeadlineParsedText *prs = (HeadlineParsedText *) PG_GETARG_POINTER(0);
+ List *prsoptions = (List *) PG_GETARG_POINTER(1);
+ TSQuery query = PG_GETARG_TSQUERY(2);
+
+ /* from opt + start and and tag */
+ int min_words = 15;
+ int max_words = 35;
+ int shortword = 3;
+ int max_fragments = 0;
+ int highlight = 0;
+ ListCell *l;
+
+ /* config */
+ prs->startsel = NULL;
+ prs->stopsel = NULL;
+ foreach(l, prsoptions)
+ {
+ DefElem *defel = (DefElem *) lfirst(l);
+ char *val = defGetString(defel);
+
+ if (pg_strcasecmp(defel->defname, "MaxWords") == 0)
+ max_words = pg_atoi(val, sizeof(int32), 0);
+ else if (pg_strcasecmp(defel->defname, "MinWords") == 0)
+ min_words = pg_atoi(val, sizeof(int32), 0);
+ else if (pg_strcasecmp(defel->defname, "ShortWord") == 0)
+ shortword = pg_atoi(val, sizeof(int32), 0);
+ else if (pg_strcasecmp(defel->defname, "MaxFragments") == 0)
+ max_fragments = pg_atoi(val, sizeof(int32), 0);
+ else if (pg_strcasecmp(defel->defname, "StartSel") == 0)
+ prs->startsel = pstrdup(val);
+ else if (pg_strcasecmp(defel->defname, "StopSel") == 0)
+ prs->stopsel = pstrdup(val);
+ else if (pg_strcasecmp(defel->defname, "HighlightAll") == 0)
+ highlight = (pg_strcasecmp(val, "1") == 0 ||
+ pg_strcasecmp(val, "on") == 0 ||
+ pg_strcasecmp(val, "true") == 0 ||
+ pg_strcasecmp(val, "t") == 0 ||
+ pg_strcasecmp(val, "y") == 0 ||
+ pg_strcasecmp(val, "yes") == 0);
+ else
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("unrecognized headline parameter: \"%s\"",
+ defel->defname)));
+ }
+
+ if (highlight == 0)
+ {
+ if (min_words >= max_words)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("MinWords should be less than MaxWords")));
+ if (min_words <= 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("MinWords should be positive")));
+ if (shortword < 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("ShortWord should be >= 0")));
+ if (max_fragments < 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("MaxFragments should be >= 0")));
+
+ if (max_fragments == 0)
+ /* call the default headline generator */
+ mark_hl_words(prs, query, highlight, shortword, min_words, max_words);
+ else
+ mark_hl_fragments(prs, query, highlight, shortword, min_words, max_words, max_fragments);
+ }
if (!prs->startsel)
prs->startsel = pstrdup("<b>");
if (!prs->stopsel)
***************
*** 1886,1888 ****
--- 2105,2108 ----

PG_RETURN_POINTER(prs);
}
+
I have an attached an updated patch with following changes:

1. Respects ShortWord and MinWords
2. Uses hlCover instead of Cover
3. Does not store norm (or lexeme) for headline marking
4. Removes ts_rank.h
5. Earlier it was counting even NONWORDTOKEN in the headline. Now it
only counts the actual words and excludes spaces etc.

I have also changed NumFragments option to MaxFragments as there may not
be enough covers to display NumFragments.

Another change that I was thinking:

Right now if cover size > max_words then I just cut the trailing words.
Instead I was thinking that we should split the cover into more
fragments such that each fragment contains a few query words. Then each
fragment will not contain all query words but will show more occurrences
of query words in the headline. I would like to know what your opinion
on this is.

-Sushant.

On Thu, 2008-06-05 at 20:21 +0400, Teodor Sigaev wrote:
> > A couple of caveats:
> >
> > 1. ts_headline testing was done with current cvs head where as
> > headline_with_fragments was done with postgres 8.3.1.
> > 2. For headline_with_fragments, TSVector for the document was obtained
> > by joining with another table.
> > Are these differences understandable?
>
> That is possible situation because ts_headline has several criterias of 'best'
> covers - length, number of words from query, good words at the begin and at the
> end of headline while your fragment's algorithm takes care only on total number
> of words in all covers. It's not very good, but it's acceptable, I think.
> Headline (and ranking too) hasn't any formal rules to define is it good or bad?
> Just a people's opinions.
>
> Next possible reason: original algorithm had a look on all covers trying to find
> the best one while your algorithm tries to find just the shortest covers to fill
> a headline.
>
> But it's very desirable to use ShortWord - it's not very comfortable for user if
> one option produces unobvious side effect with another one.
> `
>
> > If you think these caveats are the reasons or there is something I am
> > missing, then I can repeat the entire experiments with exactly the same
> > conditions.
>
> Interesting for me test is a comparing hlCover with Cover in your patch, i.e.
> develop a patch which uses hlCover instead of Cover and compare old patch with
> new one.

Re: [pgsql-es-ayuda] AYUDA CON TRIGER - URGENTE

> ERROR: UPDATE no está permitido en una función no-«volatile»

El error te dice que no puedes usar una función volátil.

> CONTEXTO: sentencia SQL: «update imagenfisica set imgfis_origen = $1
> where id = $2 »
> PL/pgSQL function "eliminarepetidos" line 14 at SQL statement
> COPY imagenfisica, línea 1:
> «2450048|N|1738|1933|N19331738000115.TIF|14/05/2008
> 10:15:20|120432|SERVIDOR_4»
>
> alguien tiene idea que quiere decir, y como lo puedo arregla??
>
> aca abajo les dejo el trigger

Lo que dejas aquí no es el trigger. Es el cuerpo de la función, y
encima no ofreces la sentencia
CREATE FUNCTION, que es donde se origina el error.
Es muy probable que hayas creado la función usando algo como
create functio eliminarepetidos.... IMMUTABLE (o STABLE). Debes
crearla como VOLATILE
(o no poner nada, ya que es la opción por defecto).

--
Miguel Rodríguez Penabad
--
TIP 5: ¿Has leído nuestro extenso FAQ?

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

Re: [HACKERS] -head build error report

On Sat, 2008-06-21 at 07:53 -0400, Andrew Dunstan wrote:
>
>
>
> Looks like you do not have the right CVS flags set. You need to use -d
> when you do a cvs update or you won't pick up new directories.
>
> You should really have this set in your .cvsrc file.

Sorry, this is the only project I use dead software for :P (I didn't
even know there was such a thing as a .cvsrc).

Thanks for the tip :)

Joshua D. Drake

>
> cheers
>
> andrew
>


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

[BUGS] bug

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

[BUGS] BUG #4257: about unicode extend

The following bug has been logged online:

Bug reference: 4257
Logged by: arli weng
Email address: program@163.com
PostgreSQL version: 8.3
Operating system: gentoo linux
Description: about unicode extend
Details:

the command (chinese by utf-8):
INSERT INTO "title" VALUES(46307243,46307898,'酋鼠𪕨');

in sqlite text type, no problem..
in postgres report error:

invalid byte sequence for encoding "UNICODE": 0xf0

the 𪕨 char is unicode extend b,
by utf-8 format, the hex code is "f0 aa 95 a8", because unicode extend b,
must start by 0xf0

but postgres cannot support it?

server/database/client encoding has unicode already.

help me pls, because i love postgres..
and sorry my english

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

[GENERAL] function question

Hi LIst;
Is there a way to print all the lines being executed for a function,
like the equivelant of a psql -ef <file> for an sql file ?


Thanks in advance

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

Re: [HACKERS] Not valid dump [8.2.9, 8.3.1]

On Fri, Jun 20, 2008 at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Gaetano Mendola <mendola@gmail.com> writes:
> 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:

This is a bug in your function: it will not work if the search path
doesn't contain the public schema.  You'd be best advised to make it
qualify the reference to t_public explicitly.

Yes, that's the way we are fixing it. Still I have a bitter taste being able to
create a working database instance that doesn't generate a valid dump.

(Of course you realize that referencing any table at all in an
"immutable" function is probably a mortal sin...)

Yes Tom I know, in our case that table is a lookup table, noone update,
delete, insert data in it, so from my point of view it is like I have declared a
static array inside the function declaration.

--
cpp-today.blogspot.com

Re: [HACKERS] -head build error report

Joshua D. Drake wrote:
> Linux jd-laptop 2.6.24-19-generic #1 SMP Wed Jun 4 16:35:01 UTC 2008
> i686 GNU/Linux
>
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v --enable-languages=c,c
> ++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> --enable-mpfr --enable-targets=all --enable-checking=release
> --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
> Thread model: posix
> gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
>
>
>
> de -D_GNU_SOURCE -c -o gistget.o gistget.c
> In file included from gistget.c:21:
> ../../../../src/include/pgstat.h:15:36: error: portability/instr_time.h:
> No such file or directory
> In file included from gistget.c:21:
> ../../../../src/include/pgstat.h:326: error: expected
> specifier-qualifier-list before 'instr_time'
> ../../../../src/include/pgstat.h:566: error: expected
> specifier-qualifier-list before 'instr_time'
> make[4]: *** [gistget.o] Error 1
> make[4]: Leaving directory
> `/home/jd/repos/pgsql/src/backend/access/gist'
> make[3]: *** [gist-recursive] Error 2
> make[3]: Leaving directory `/home/jd/repos/pgsql/src/backend/access'
> make[2]: *** [access-recursive] Error 2
> make[2]: Leaving directory `/home/jd/repos/pgsql/src/backend'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/jd/repos/pgsql/src'
> make: *** [all] Error 2
>
>


Looks like you do not have the right CVS flags set. You need to use -d
when you do a cvs update or you won't pick up new directories.

You should really have this set in your .cvsrc file.

cheers

andrew

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

[pgeu-general] European Agenda ?

Hello,

As i was swimming across the pgeu-general mailing list in search of the
forthcoming PostgreSQL events, i realized that i could be usefull to have a
wiki page listing all these events. I quickly gathered bits of information
and made up this page :

http://wiki.postgresql.eu/wiki/PostgreSQL_EU_Wiki:Current_events

Now i'm sure we can do better. This is just a "quick and naïve" proposal.
Feel free to modify or criticize this page. I know that some might find this
initiative is redundant with :

http://www.postgresql.org/about/eventarchive

Speaking of my own little person, as i don't take airplanes, i'm very little
concerned by events organized outside Europe and i find it useful to have an
european-speciifc event page.

My guess is that having this page on the european wiki, will make things
easier to edit and update.

Any comments ?

--
damien clochard
http://dalibo.org | http://dalibo.com

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

[pgeu-general] Conference and workshops @ Mont-de-Marsan, France, July 1-5

hello everyone,

The LSM (Libre Software Meeting) is an opportunity for all sort of public to
come together around the free software. Over 5 days, conferences and
workshops welcome everyone. This event is organized each year and for the 9th
edition is hosted in the town of Mont de Marsan, in the south of France, from
1 to 5 July 2008.

The PostgreSQLFr Team will organize a conference and 5 workshops. Please note
that the PostgreSQL conefrence and workshop will be in french but some other
conferences will be in English.

you can grab more information here :

http://2008.rmll.info/?lang=en

The complete list of PostgreSQL related events is here :

http://tinyurl.com/3wefnl

Regards,

--
damien clochard
http://dalibo.org | http://dalibo.com

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

[ADMIN] PG 8.0.4 - Does Dump + drop_db + reload reset XID to prevent wraparound?

In a PostgreSQL 8.0.4 environment, does dropping the database and reloading it
completely reset the XID information that causes transaction ID wraparound? (I
am assuming that it does, but wanted to double-check before doing this.)

From what I can tell, I am just about to hit the XID wraparound problem, given
the following results:

SELECT datname, age(datfrozenxid) FROM pg_database;
datname | age
-----------+------------
datadb | 2002912692
template1 | 1034177089
template0 | 1034177089
(3 rows)

I know that a VACUUM FULL will fix this, but on this database a VACUUM FULL
usually takes more than 48 hrs to complete and [more importantly], a VACUUM FULL
usually crashes the PostgreSQL engine. (We _very_ frequently crash with a '
could not rename "d:/pgsql/data/pg_xlog/0000000100000504000000D5" to
"d:/pgsql/data/pg_xlog/0000000100000504000000E8", continuing to try ' error just
with our normal volume of database activity; running any decent-sized VACUUM is
almost always guaranteed to crash at some point with this error or with one of
the "could not fsync" or "could not unlink" errors.)

So ... I'm looking for a viable alternative to a VACUUM FULL to prevent the
impending transaction wraparound. (Note that I _have_ been doing vacuums on all
of the individual tables in this database every week but I don't think this
helps prevent the XID wraparound problem in a PG 8.0.x environment? [By
vacuuming the tables one at a time we've managed to get a 30-40% success rate of
getting through vacuuming all the tables without the database crashing.])

I do understand that this version of PostgreSQL is very old; however, at the
moment I am just looking for an immediate solution to this problem. (The reasons
for it still being at this old version are long and at some point need to be the
subject of another posting. We are looking at moving it to PG 8.3.x since the
"rename" problem appears to finally be fixed; however, we need to wait until
8.3.2 or later because much of the database access is via JDBC.)

Thanks in advance for any insights...

- Bill

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