Re: [BUGS] BUG #8394: SQL command REINDEX doesn't work
On Fri, Aug 23, 2013 at 3:39 PM, Yong Zhang wrote: > Thanks for the prompt response. But that's what I tried and it didn't work. > I tried following command in both pgAdmin III and psql: > > > > REINDEX DATABASE PremierIEX > If that is the name of the database, then it probably is because of the uppercase letters. Try this way: REINDEX DATABASE "PremierIEX" -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] PROBABLE BUG
On Mon, Jul 29, 2013 at 4:11 AM, matty wrote: > Hello, > I have noticed that when I execute this query, the DB (postgresql) is > crashed. > I executed this query without problem. This are the versions i have, i will recommend you to upgrade those that differ from yours and retry (specially geos, i remember we saw a problem with it recently). anyway, this is obviously a bug that should be better reported in the postgis mailing lists, not here. so, if after upgrading those libraries you still have the problem report it to this list: http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users or http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel select version(); version -- PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit (1 row) select postgis_lib_version(); postgis_lib_version - 2.0.3 (1 row) select postgis_proj_version(); postgis_proj_version -- Rel. 4.8.0, 6 March 2012 (1 row) select postgis_geos_version(); postgis_geos_version -- 3.3.8-CAPI-1.7.8 (1 row) -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8248: se presenta una excepcion cuando intento realizar consultas des la aplicacion en netbeasns
On Fri, Jun 21, 2013 at 2:06 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 8248 > Logged by: Jefferson Velasco > Email address: javelasc...@misena.edu.co > PostgreSQL version: 8.4.0 > Operating system: windows > Description: > > Exception [EclipseLink-4002] (Eclipse Persistence Services - > 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.DatabaseException > Internal Exception: org.postgresql.util.PSQLException: ERROR: no están > implementadas las referencias entre bases de datos: > «farmacia.public.usuario» Error Code: 0 Call: SELECT idusuario, clave, > nombreusuario, rol, idpersona FROM Farmacia.public.usuario WHERE > ((nombreusuario = ?) AND (clave = ?)) bind => [2 parameters bound] Query: > ReadAllQuery(referenceClass=Usuario sql="SELECT idusuario, clave, > nombreusuario, rol, idpersona FROM Farmacia.public.usuario WHERE > ((nombreusuario = ?) AND (clave = ?))") > > This is not actually a bug but a well known postgresql limitation, you can't use database references in the from. I answered to the OP, explaining that and redirecting him to pgsql-es-ayuda@ -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Very slow inner join query unacceptable latency
On Tue, May 21, 2013 at 3:54 PM, wrote: > The SARS_ACTS table currently has 37,115,515 rows > > we have indexed: idx_sars_acts_acts_run_id ON SARS_ACTS USING btree > (sars_run_id) > we have pk constraint on the SARS_ACTS_RUN table; sars_acts_run_pkey PRIMARY > KEY (id ) > > serverdb=# explain select count(*) as y0_ from SARS_ACTS this_ inner join > SARS_ACTS_RUN tr1_ on this_.SARS_RUN_ID=tr1_.ID where tr1_.ALGORITHM='SMAT'; This is not a bug, you should write to the pgsql-gene...@postgresql.org or pgsql-performa...@postgresql.org mailing lists. anyway, seems that you need an additional index on SARS_ACTS_RUN.ALGORITHM -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8138: No puedo ver los datos
On Mon, May 6, 2013 at 11:49 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 8138 > Logged by: Jose Guerra > Email address: jgue...@solmovsa.com > PostgreSQL version: 9.2.4 > Operating system: Windows 7 Pro > Description: > > Espero me puedan ayudar, estoy tratando de traer datos de Postgres usando > PostgresSQL Unicode pero no me trae nada > > Esto no es una falla (al menos no es posible saberlo de la poca descripcion que estas dando), ademas que deberías reportar cualquier falla en inglés. Te estoy redirigiendo a pgsql-es-ay...@postgresql.org para que podemos a) hablar en español y b) determinar cual es realmente tu problema. This is not a bug (at least i can infer one from the little description you are giving), also you should report any bug in english. I'm redirecting you to pgsql-es-ay...@postgresql.org so we can a) speak spanish and b) determine what your problem is. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7835: The _ acts like a wildcard when used as '%_%'
On Tue, Jan 29, 2013 at 12:20 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 7835 > Logged by: Elliott Groszek > Email address: elliott.gros...@navy.mil > PostgreSQL version: 9.0.11 > Operating system: Linux > Description: > > Using the _ (underscore) in a wildcard query accesses values with - (dash) > as well. This results in unexpected behaviors when some data values contain > the underscore and some data values contain the dash. > i guess you are using a LIKE expression. And in like both % and _ are wildcards, as documented in: http://www.postgresql.org/docs/9.2/static/functions-matching.html#FUNCTIONS-LIKE And AFAIU, mandated by SQL Standard "An underscore (_) in pattern stands for (matches) any single character; a percent sign (%) matches any sequence of zero or more characters." if you only want to show those that contains an underscore (supressing its wildcard behaviour) you need to use a escape character: col LIKE '%\_%' -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7748: "drop owned by" fails with error message: "unrecognized object class: 1262"
On Tue, Dec 11, 2012 at 2:04 PM, Jeff Janes wrote: > > I am unsure of the goal here. The docs clearly say that only objects > in the current database are affected, so why are we even trying to do > something with tablespaces (or databases), which do not live in any > database? And if we want to change the contract to allow it to climb > out of the current database, why limit it to shared objects rather > than crawling all databases? > ok. you're right, what i suggested before of making something similar on DROP ASSIGNED is actually a violation of the POLA. about your question, i guess the compromise Álvaro was taken here is to affect all objects that could be *seen* from this database you can't climb to other objects in other databases because they can't be seen. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7748: "drop owned by" fails with error message: "unrecognized object class: 1262"
On Sun, Dec 9, 2012 at 11:13 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> >> spam_ea...@gmx.net writes: >> > postgres=# create user testuser with password 'secret'; >> > CREATE ROLE >> > postgres=# create database testdb owner testuser; >> > CREATE DATABASE >> > testdb=> drop owned by testuser; >> > ERROR: unrecognized object class: 1262 >> >> I can reproduce this in all versions back to 8.3. In 8.2, the role's >> ownership of the database is silently ignored, which I think was the >> design intention. I doubt that we want DROP OWNED dropping whole >> databases. At most maybe we should raise a NOTICE? > > I broke it recently: fe3b5eb08 > whatever is the right way to solve this... shouldn't we do something similar in shdepReassignOwned() in which we are still ignoring shared objects? -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgres Partitions not working with hibernate 4.1.6.Final
On Tue, Sep 25, 2012 at 3:12 PM, Freddie Burgess wrote: > > Does anyone know why the previous .jdbc.batcher logic managed the postgres > partitioned inserts without any issues? > Are there any other alternative that will allow us to insert into a Postgres > partition table without making massive code changes? don't know about hibernate or that strange way to insert into partitions. the postgresql's way is to create triggers on parent table to route the inserts into the partitions as described here: http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html > Would upgrading from 4.1.6.Final to Hibernate 4.1.7 in Linux, fix this > partitioning ingest problem? > don't know, but that certainly looks like a hibernate bug, not a postgresql one -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6718: Cannot delete, create or check existence of extension
On Thu, Jul 5, 2012 at 1:56 AM, Craig Ringer wrote: > On 07/05/2012 02:05 AM, gary.ha...@gmail.com wrote: >> >> development=# create extension hstore; >> ERROR: type "hstore" already exists > > First, thanks for the info in the report. > > At a guess, it has the hstore data type in it from before the extension > system exists. You need to follow the upgrade instructions to convert it to > an extension. what about adding a HINT there? something like "you probably need to use CREATE EXTENSION ... FROM unpackaged" -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6680: error para ingresar
On Fri, Jun 8, 2012 at 6:02 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 6680 > Logged by: jeremy palacios bringas > Email address: jeremy_2...@hotmail.com > PostgreSQL version: Unsupported/Unknown > Operating system: datebase server 8.2 > Description: > > trato de ingresar al srvidor y me muestra este msn > el servidor postgresql database server 8.2 con equipo local se inicio y > después se detuvo algunos servicios se detienen automaticamente si no son > usados por ningun servicio o programa > FYI, this seems like a pilot error not a bug so i moved it to the spanish list and asked some additional info to OP -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] version of postgreSQL
On Tue, Jun 5, 2012 at 10:21 AM, luigi pinna wrote: > Hello! > which version of postgreSQL is compatible with Window 7? > > for example 8.2, 8.4 or 9.1 > this question is certainly not a bug and should have been done on one of the users lists listed in http://archives.postgresql.org/ most probably pgsql-general o pgsql-novice. Please direct any new question that doesn't report a bug to one of those lists. Now, about your question: I can't be sure because i haven't used windows in a long time, but the buildfarm shows versions 9.0 and 9.1 passing all tests on windows 7 home premium... http://pgbuildfarm.org/cgi-bin/show_status.pl?member=chough&member=pitta -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6665: problema com Grant
2012/5/25 : > The following bug has been logged on the website: > > Bug reference: 6665 > Logged by: Rammses > Email address: rammses.prat...@gmail.com > PostgreSQL version: 9.1.3 > Operating system: CentOS > Description: > > Temos a seguinte situação: Criamos um novo esquema no projeto, criamos as > tabelas e carregamos as tabelas pai. Executamos os comandos grant porém um > determinado usuario não consegue acessar. Alguem ja passou por isso? > grato pela atenção. > > This is an english list, there is a portuguese one in pgbr-ge...@listas.postgresql.org.br Anyway, can you explain what grant did you execute? what permissions the user had previously? for example, did you grant use of the schema and the table? -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 291 pg_toast_temp schemas?
On Thu, Apr 26, 2012 at 5:48 PM, Tom Lane wrote: > Josh Berkus writes: >> Also, have we discussed maybe hiding these schemas from \dn? > > We've done more than discuss it: > http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=e43fb604d6db229d70d3101aa53348cc16a5473a > > I take it you're using something older than 9.1. > that's a quick reaction :D -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 291 pg_toast_temp schemas?
On Thu, Apr 26, 2012 at 5:35 PM, Josh Berkus wrote: > > Also, have we discussed maybe hiding these schemas from \dn? > +1 from this idea... maybe do them visible only on \dn+ -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Subquery with toplevel reference used to work in pg 8.4
On Fri, Mar 23, 2012 at 11:04 PM, Mark Murawski wrote: > > ERROR: Upper-level PlaceHolderVar found where not expected > This is part of commit c1d9579dd8bf3c921ca6bc2b62c40da6d25372e5 which as stated in the commit log: """ tightened the error checking in this area a bit: if it was ever valid to see an uplevel Var, Aggref, or PlaceHolderVar here, that was a long time ago, so complain instead of ignoring them. """ the query seems useless but valid to me... just removing this check and the assert in find_placeholder_info():placeholder.c seems to make this query behave normally again. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug in postgresql 8.1
On Sun, Mar 18, 2012 at 8:11 AM, Dave Page wrote: > > > On Sunday, March 18, 2012, Jaime Casanova wrote: >> On Sun, Mar 18, 2012 at 12:13 AM, prem tolani >> wrote: >>> Below error occurs only when i restart postgre 8.1 service when >>> applicaion is running. Otherwise it works fine, but while >>> application is running and i restart postgre 8.1 service. Application >>> crashes. Please refer to below email. >>> >> >> postgres 8.1 is not currently supported (since November 2010, >> http://www.postgresql.org/support/versioning), so is likely that if >> something was done in postgres to support win7 it hasn't reach 8.1 > > It hasn't been supported on Windows for *much* longer. > true. i forgot that, support for 8.1 on windows was dropped on 2008 with release of 8.1.11, and it was because of very serious problems. so, not being able to start the database is the less serious of your problems. http://www.postgresql.org/about/news/865 -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Fw: Bug in postgresql 8.1
On Sun, Mar 18, 2012 at 12:13 AM, prem tolani wrote: > Below error occurs only when i restart postgre 8.1 service when applicaion is > running. Otherwise it works fine, but while > application is running and i restart postgre 8.1 service. Application > crashes. Please refer to below email. > postgres 8.1 is not currently supported (since November 2010, http://www.postgresql.org/support/versioning), so is likely that if something was done in postgres to support win7 it hasn't reach 8.1 the best "fix" you can get is to migrate to a newer supported version as soon as possible. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6517: Volatile function erroneously optimized, does not consider change in schema path
On Mon, Mar 5, 2012 at 6:52 AM, wrote: > > set search_path to public; > > CREATE FUNCTION countusers() > RETURNS INT > AS $PROC$ > BEGIN > RETURN count(*) FROM users; > END > $PROC$ LANGUAGE 'plpgsql' VOLATILE; > i think you can workaround your problem using EXECUTE: CREATE FUNCTION countusers() RETURNS INT AS $PROC$ DECLARE counter INT; BEGIN EXECUTE 'SELECT count(*) FROM users' INTO counter; RETURN counter; END $PROC$ LANGUAGE 'plpgsql' VOLATILE; -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6438: I have reinstalled postgresql a couple times and now the postgresql service will not start.
On Tue, Feb 7, 2012 at 7:14 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 6438 > Logged by: James Land > Email address: hoki...@gmail.com > PostgreSQL version: 9.1.2 > Operating system: Windows 7 64bit > Description: > > Note if I change logon to Local System Account from this account it will > start but the database's do not work. > maybe the eventlog shows some error? please look and send if there is any -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6394: Transacciones concurrentes
2012/1/11 : > The following bug has been logged on the website: > This is not a bug. and just for the record i redirected the mail with an explanation (and a brief answer to his problem) to pgsql-es-ayuda where OP can found more help in spanish -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6266: Create temp tables on Slave
On Mon, Oct 24, 2011 at 8:48 AM, Sally wrote: > > The following bug has been logged online: > > Bug reference: 6266 > Logged by: Sally > Email address: sally.na...@tedata.net > PostgreSQL version: 9.1 > Operating system: Centos 5.5 > Description: Create temp tables on Slave > Details: > > We are Using replica (wal streaming replica)to replicate between Master and > slave. > > We need to be able to create temp tables on Slave, > you can't. this isn't a bug but a known limitation and is documented here: http://www.postgresql.org/docs/9.1/static/hot-standby.html#HOT-STANDBY-USERS > Is there any workaround? > How could we create temp database and tables on slave? > not with streaming replication -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6258: Lock Sequence
On Mon, Oct 17, 2011 at 2:43 PM, Tom Lane wrote: > > There really is not any way to generate guaranteed-hole-free sequences > using sequence objects. If you have to have that, I'd suggest locking > the table against other writes and then fetching MAX(id) + 1. It's not > very fast, and it's not at all concurrent, but that's the price of > ensuring no holes. Personally I'd rethink how badly you need that > property. > another option is to create a table to use as a sequence, and lock that table everytime you need a new value... is not concurrent also, but at least faster... unless i'm missing something -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6239: Looking for a technical contact point for PostgreSQL compatibility issue on Windows8
On Mon, Oct 3, 2011 at 8:42 PM, Seiko Ishida wrote: > > The following bug has been logged online: > > Bug reference: 6239 > Logged by: Seiko Ishida > Email address: v-sei...@microsoft.com > PostgreSQL version: 8.2.4 > Operating system: Windows 8 > Description: Looking for a technical contact point for PostgreSQL > compatibility issue on Windows8 > Details: > > Hello, > > I am a Program Manager with the Ecosystem Engineering team at Microsoft. > > I am looking for a technical contact point to notify of compatibility issues > with PostgreSQL. > Could you please connect me to the appropriate > individual for this? > if you think this compatibility issue is a bug of postgresql, this list is just fine otherwise write to pgsql-hack...@postgresql.org... -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Help-PGRES_FATAL_ERROR
On Sun, Aug 7, 2011 at 3:10 PM, John Carriel Gomez wrote: > Please help I can not replicate with Slony > - > PGRES_FATAL_ERROR select "_replicaterminal".storeNode_int(1, 'Nodo > Maestro'); select "_replicaterminal".enableNode_int(1); - ERROR: invalid > input syntax for type timestamp: "Sun Aug 07 14:59:30.073665 2011 ECT" > CONTEXT: SQL statement "insert into "_replicaterminal".sl_confirm > (con_origin, con_received, con_seqno) > select no_id, p_no_id, 0 from > "_replicaterminal".sl_node > where no_id != p_no_id > and no_active" > PL/pgSQL function "enablenode_int" line 32 at SQL statement > what do you have in timezone in postgresql.conf? certainly, the timestamp format looks odd -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6093: timeout
Craig Ringer writes: > -ENOCOFFEE > LOL. this one is the best i have heard this year -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL Soporte 24x7, desarrollo, capacitación y servicios -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Where is pg_create_restore_point funciton in 9.1a2 ?
On Wed, Jun 22, 2011 at 3:28 AM, Emanuel Calvo wrote:
> I'm still finding pg_create_restore_point in 9.1a2 documentation:
> http://www.postgresql.org/docs/9.1/static/functions-admin.html
>
> But I've compiled that version and I didn't found it:
>
> postgres=# \df *create_restore*
> List of functions
> Schema | Name | Result data type | Argument data types | Type
> +--+--+-+--
> (0 rows)
>
the function exists... and it should appear, it does for me
postgres=# \df *create_re*
List of functions
Schema | Name | Result data type | Argument
data types | Type
+-+--+-+
pg_catalog | pg_create_restore_point | text | text
| normal
(1 row)
postgres=# select pg_create_restore_point('jcm');
ERROR: WAL level not sufficient for creating a restore point
HINT: wal_level must be set to "archive" or "hot_standby" at server start.
STATEMENT: select pg_create_restore_point('jcm');
>
> By the way, another issue that I found is when I execute \df. It
> doesn't display anything (I must
> force with * to do that).
i can confirm this
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6042: unlogged table with Streaming Replication
On Fri, May 27, 2011 at 12:26 AM, Tomonari Katsumata wrote: > > > I've checked "unlogged table" and "Streaming Replication". > I'm thinking about using unlogged tables as work-tables on Primary. > > 1) construct Streaming Replication Environment. > Primary and Standby are same server with different database cluster and > port number. > > 2) create unlogged table on Primary. > =# CREATE UNLOGGED TABLE tbl1(i int); > This table is available on primary only. > because streaming replication works shipping WAL records (the records of the transactional log) to the standby but because UNLOGGED tables are not logged to WAL i guess those always will be empty on standby, but the table should appear on the standby, i guess > 4) create unlogged table on Primary again. > =# CREATE UNLOGGED TABLE tbl2(i int); > > when I executed 4), any response is not back to my psql. and I canceled the > query, I got messages bellow. > --- > Cancel request sent > WARNING: canceling wait for synchronous replication due to user request > DETAIL: The transaction has already committed locally, but may not have > been replicated to the standby. > CREATE TABLE > --- > and the table has been created. > > I think It's strange behavior(a canceled table has been created). > actually, you're not cancelling the creation... the table has been created and the wal is being sent to the standby (because the standby is a synchronous standby, it keeps waiting until the standby aknlowdge to have received the wal), so what you are cancelling now is the primary waiting for the standby... btw, i guess we should be defaulting to asynchronous standbys (ie: synchronous_commit=local) -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5967: Db maintainace
On Wed, May 18, 2011 at 12:16 AM, Halli, Savita wrote: > > When we need to rum vacuumdb and reindexdb commands, would like to know how > often we need to perform these ooperation? Is it > once in a week, month or other? > correct answer is: depends on your work load... if you have a recent version of postgres, better you can do is configure autovacuum and let it do most of the job... and by a recent version i mean at least 8.3 (preferable 8.4 or superior) btw, any new question you have please send it to pgsql-gene...@postgresql.org or another one that fits more with the question from the page Hubert show you -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Query Tools
2011/5/17 Eduardo Velasquez M : > > En Pgadmin III el Query Tools no esta funcionando. Se bloquea. Que hay que > hacer para poder habilitarlo. > > Este no es un bug de postgres sino un problema en pgAdmin III, sería preferible que envies la consulta a la lista de correo de soporte de pgAdmin (pgadmin-supp...@postgresql.org) sin embargo esa lista es en inglés (así como esta forma reportar bugs deberías llenarla en íngles)... si se te complica el inglés podrías intentar enviar un reporte a la lista de postgres en español (pgsql-es-ay...@postgresql.org) y podríamos tratar de ayudarte. Siempre que proveas la suficiente información para determinar el problema, lo cual obviamente no has hecho. This is not a postgres' bug but an issue with pgAdmin III, it could be better if you send this inquiry to the pgadmin's support mailing list (pgadmin-supp...@postgresql.org) however that list is an english list (like this form ti report bugs should be filled in english)... if you're not comfortable with english then you could send the report to spanish postgres mailing list (pgsql-es-ay...@postgresql.org) and we will try to help you. But you need to provide enough information to determine what the problem is, which you obviously haven't do it. -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS]
On Sun, Feb 13, 2011 at 11:32 PM, Edwin Giraldo wrote: > when installing postgres a message saying secondary logon is not running > please help > that is a windows service that you need to start. btw, this is not a bug so it shouldn't be reported here. maybe in pgsql-gene...@postgresql.org? besides, a report needs a lot more info, for example postgresql version, operating system, exact message errors, and so on -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5811: Installation error
On Sun, Jan 2, 2011 at 4:54 PM, Carlos wrote: > > The following bug has been logged online: > > Bug reference: 5811 > Logged by: Carlos > Email address: car...@megalogica.com > PostgreSQL version: 9.0.2 > Operating system: Win XP 32 > Description: Installation error > Details: > > When trying to install version 9.0.2 in a Win XP 32 get the error : > > "Unable to write inside TEMP environment variable path" > this seems a permissions issue, are you using an Administrator account or something with enough permissions to install? -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] insert statement going into infinite loop
On Fri, Dec 24, 2010 at 6:57 AM, Trimurthulu Bandaru wrote: > Hi everybody.. > I have table with 11 attributes, 6 of them refers different tables and > having one primary key. > when I am trying to insert row with 121 key value, its going into > infinite loop.. define "infinite loop", the truth is that you're giving almost no information so all we can try now is to guess and cross fingers ;) are you describing that the INSERT never finishes? if so, maybe the table is locked... you can know that by looking in pg_stat_activity view and find your statement in the field current_query and see the field waiting, if is true then the statement is locked waiting for something... or you can see the pg_locks view where relation = 'your_table'::regclass another posibility is that you have a trigger in the table after or before insert and then inside the trigger inserting a new value on the same table forcing a new execution of the trigger making it recursive... > I am thinking its a bug in postgres.. it's too early to blame postgres -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5557: Problema com Bytea
On Tue, Jul 13, 2010 at 4:07 AM, Rafael Almeida wrote: > > The following bug has been logged online: > > Bug reference: 5557 > Logged by: Rafael Almeida > Email address: raf...@rafaeldeveloper.com > PostgreSQL version: 9.0 > Operating system: Windows XP > Description: Problema com Bytea > Details: > > Ae amigos, Bom estive testando a nova versão do postgresql 9.0 detectei um > bug, ou foi modificado a estrutura do campo bitea e não colocaram na > documentação, sou programador C# na versão 8.4 consigo gravar imagens no > campo bytea e recuperar normal. já na versão 9.0 gravo, mais o retorno é > diferente... ou seja... funciona no 8.4 e no 9.0 bug. > Espero que entiendas español, mi portugues ha de ser ofensivo a tus ojos ;) por favor, podrias enviarnos un ejemplo del problema que tienes (en codigo me refiero)? puede ser un ejemplo simplificado con solo el ejemplo basico que funciona en 8.4 y no en 9.0 otra cosa 9.0 esta en version beta y acaba de salir el beta3, podrias probar con ese a ver si aun tienes el error? estas usando npgsql para conectarte? for the list: while this is an english list this is reporting a bug in 9.0 so maybe is fine to manage it here (please, if anyone think it's not tell that) i will try to act as a translator unless someone with better portuguese step up. he's saying that some code for retrieving bytea that works in 8.4 doesn't work in 9.0, so i ask him some code to try... anyone remeber some change in that area or in an area that could affect the npgsql driver? -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Support on Postgres Database Corruption
On Wed, Jun 2, 2010 at 8:38 AM, botak wrote: > Dear sirs, > > Referring to the matter above. > > For your information, we are a government agency and been hosting a > management system since 2006. The system was developed with Postgres Sql and > PHP in Centos Platform. Recently, after a power failure, all the latest data > from system were missing and the system starts to redirect to older data. > However we manage to find the location of the missing data but failed to > rejoin to system as it seems to be corrupted. > > I hope you can solve the problem. > > PostgreSQL 7.4.8 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.4.3 > 20050227 (Red Hat 3.4.3-22) > Hi, Can you please give some more info so someone can help you? 1) where do you "find the location of the missing data"? and how were you trying to rejoint it? 2) how do you determine it is corrupted? 3) it gives you some error messages? which one? 4) How old is the data that you loss? 5) are you aware that you have to have write-cache disabled on your disks in other to assure the data get it to the disk? 6) how frequent are you executing VACUUM? -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] question
On Tue, May 4, 2010 at 11:43 PM, Akul Gupta wrote: > sir, i m facing a problem. > While conneting through pgsql from PHP, it asks for a password. > While i have not given any password at the time of installation. > So, please tell me the solution. > Reply as soon as possible. > I am waiting. > The best you can do is to edit pg_hba.conf and add a line like this: local allall trust connect to pgsql as postgres user and execute ALTER ROLE user_you're_connecting_to_in_app PASSWORD 'yourpassword'; then add to pg_hba.conf a line like this: host dbname username ip_web_server/32 md5 -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Fwd: [BUGS] BUG #5433: pg_dump (8.4.3) copy database failure!
-- Forwarded message -- From: 陳裕耀 Date: 2010/4/22 Subject: Re: [BUGS] BUG #5433: pg_dump (8.4.3) copy database failure! To: Jaime Casanova 於 2010/4/22 下午 12:56, Jaime Casanova 提到: On Wed, Apr 21, 2010 at 11:21 PM, y.y.Chen wrote: pg_dump in A=> pg_dump -h A db > file =>failure pg_dump in B => pg_dump -h A db > file =>success and what was the error? No any message , because of session of pg-dump can not return to command-line ! It is hang up ! But there is a message only when run in Server of data sender : "pg_dump -h localhostVer8.4.3 db | psql -h RemoteHost_Ver8.4.3 db " This messages is " could not receive data from client : connection be reset by remote !" database and user? pg_hba.conf is all ok that Server updated from 8.0->8.1->8.2->8.3->8.4.2 to 8.4.3! -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5433: pg_dump (8.4.3) copy database failure!
On Wed, Apr 21, 2010 at 11:21 PM, y.y.Chen wrote: > > > pg_dump in A=> pg_dump -h A db > file =>failure > pg_dump in B => pg_dump -h A db > file =>success > and what was the error? are you sure pg_hba.conf allow host connections from A to A for that database and user? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bugs that have not been replied-to on list
On Sun, Apr 18, 2010 at 9:03 PM, Robert Haas wrote: [...] > What is frustrating about the current process is that ~5% of the bugs don't > get a response. How are we going to fix that problem? > that's a two side problem, while certainly there are valid bug reports that fall in the cracks, there are bug reports without a lot of info, or with a misguided subject line or that are sent to a wrong list... those we will miss no matter what... for those that are valid bug reports we would need a team of people that categorize and/or respond the bugs as soon as they come... like patch reviewers but they just respond the easy ones, and let difficult ones for more experienced people, and maybe something like "fix bug fest" maybe at the end of commit fests? of course most of this is just a dream, or not? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bugs that have not been replied-to on list
On Sun, Apr 18, 2010 at 3:59 PM, Robert Haas wrote: > On Sun, Apr 18, 2010 at 3:47 PM, Greg Sabino Mullane > wrote: >>> That all sounds pretty reasonable to me, though I would favor using >>> something other than Bugzilla for the tracker. I'm not really sure if >>> there's anything that I'd consider truly good out there, but I've >>> always found Bugzilla pretty terrible. >> >> Bugzilla is the worst form of bug tracking out there, except for >> all the others. > > One of these days, I am going to write a @$#! bug tracker. > after seen the commitfest app, i can swear the bug tracker you write should be cool -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5393: Installer sets superuser password if passwords don't match
On Thu, Apr 8, 2010 at 4:58 PM, Dave Page wrote: > > If this is a real problem for people, perhaps someone should update > the web form to ask for the sub-project and direct the bug reports > accordingly rather than have us continue to bleat at users. > Volunteers? > while of course we can answer some questions there are others that only could be resolved for the sub project team... now, that idea of ask about the sub project seems good to me, actually i have suggested something similar to redirect messages to language specific lists... but seems i send that to an incorrect list :( besides my abilities with web forms are very poor... but if some one is willing to help me a little i can try -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5393: Installer sets superuser password if passwords don't match
On Thu, Apr 8, 2010 at 4:19 PM, Robert Haas wrote: > On Fri, Mar 26, 2010 at 6:16 PM, Joshua Tolley wrote: >> I accidentally rejected this message while moderating -bugs, so I'm >> forwarding >> it to the list to atone for myself. Apologies to all involved... >> >> From: Rens Admiraal >> Date: Fri, 26 Mar 2010 20:00:27 GMT >> To: pgsql-bugs@postgresql.org >> Subject: BUG #5393: Installer sets superuser password if passwords don't >> match >> >> The following bug has been logged online: >> >> Bug reference: 5393 >> Logged by: Rens Admiraal >> Email address: r...@rensnel.nl >> PostgreSQL version: 8.4 >> Operating system: Windows >> Description: Installer sets superuser password if passwords don't >> match >> Details: >> >> I just installed PostgreSQL 8.4 on windows 7 64 bit using the oneclick >> installer. >> >> I didn't read the installation steps as normal :-) So I tried to set a >> username + password in the step where the superuser password is asked. >> >> Offcourse I got the error "Passwords don't match", I read the screen again, >> and thought "A nice, if no users excists, it will be created", and clicked >> next without filling anything. This also didn't work, and I could only get >> it to work using the username I filled in the first password field >> initially... >> >> I would expect the installation not to create a user at all at wrong input! >> So it might be better to check the values in the passwords fields first, and >> create the user if the passwords are equal... > > I don't know if this list is the right place to report bugs in the > one-click installer, or if not where the right place would be. Anyone > else know? > > no, it isn't (extracted from: http://www.postgresql.org/support/submitbug) """ This bug report form should only be used for reporting bugs and problems with the PostgreSQL database. Problems with database connectors such as ODBC and JDBC, graphical administration tools such as pgAdmin or other external projects should not be reported here; please report to those projects directly. For products closely connected with PostgreSQL, there may be an appropriate mailing list available. """ probably, enterprisedb support forums is the way to go: http://forums.enterprisedb.com/forums/list.page -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5388: bortdagos
On Wed, Mar 31, 2010 at 10:46 PM, Robert Haas wrote: > On Thu, Mar 25, 2010 at 11:13 AM, bortdagos wrote: >> >> 1980 anthropogenic google environmental depend trends geoengineering > > Thanks for the report. Will fix. > > no, let it for next version... then we can announce 10.0 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Question about installation in 2003 server
if you prefer spanish (and because of your english is maybe a good idea maybe you want to write to pgsql-es-ay...@postgresql.org ;) On Thu, Mar 25, 2010 at 10:51 AM, ALCALDIA DE INFANTE ALCALDIA DE INFANTE wrote: > Hello, i´m try to install postgresql 8.10 in a server with Windows 2003 > server standart edition. 8.1.0 you mean? 8.10 doesn't exist by the way, that version is *not* supported on windows and has several nasty bugs > > I install XAMPP and postgresql 8.10 but the sistem don´t work. All > components are tested, i can open a database with postgre but in the sistem, > the paga that do it dont work. > how do you install it? what do you mean by: "i can open a database but in the sistem, the paga that do it dont work.". you have any install errors? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5340: Requirement of different syntax on different OS
On Mon, Feb 22, 2010 at 2:51 PM, pradeep wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5340
> Logged by: pradeep
> Email address: patilpradeep...@yahoo.com
> PostgreSQL version: 1.10.1
> Operating system: windows 7
> Description: Requirement of different syntax on different OS
> Details:
>
> If I am using windows 7, I need to pass following query
> "select max(column_name) from table_name"; to get the highest entry in that
> column, but if I am using Windows XP, I need to pass query "select
> max('column_name') from table_name"; for the same operation.
> Why do I need single quote when I am using XP and not when I am
> using windows7 ?
>
ah? i have windows xp and never have need to put those single quotes,
if the name of the column was created with uppercase you could need to
quote "ColumnName" (this is not single quote, though)
can you give a simple test case? i mean, a create table (maybe some
test data) and a select... that works the way you describe on those
OSes
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] add primary key doesn't block?
On Thu, Jan 21, 2010 at 12:45 PM, Tom Lane wrote: > Jaime Casanova writes: >> When we perform a test migration of the data we found some errors on >> the logs, one of them is this one: > >> """ >> mic=# ALTER TABLE tcom_invitacion ADD primary key (id_invitacion); >> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index >> "tcom_invitacion_pkey" for table "tcom_invitacion" >> ERROR: concurrent insert in progress >> """ > > Can you provide a reproducible test case? > trying to do so, gives me an error when moving the affected table from the migration test database to my machine: """ ERROR: invalid byte sequence for encoding "UTF8": 0xed6261 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". CONTEXT: COPY tcom_invitacion, line 543881 """ both servers had client_encoding and server_encoding in UTF8 and if i try this from the real server i get no error, so i guess this was somehow network corruption i failed to say that i make the migration directly via the network: $PG8.4DIR/bin/pg_dump -C -h ip_old_server dbname | $PG8.4DIR/bin/psql -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] add primary key doesn't block?
Hi, I'm testing the migration procedure for a client, we want to migrate from 8.3.6 to 8.4 When we perform a test migration of the data we found some errors on the logs, one of them is this one: """ mic=# ALTER TABLE tcom_invitacion ADD primary key (id_invitacion); NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "tcom_invitacion_pkey" for table "tcom_invitacion" ERROR: concurrent insert in progress """ actually, no indexes were created on this table... and when i tried to add the PK manually after migration i get this same error (not always, it seems this time the index is being created but this time i did it inside a transaction)... doesn't the index creation of the index block the table so, that message should not appear? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5216: pgFouine 1.1 not working correctly, when LC_MESSAGES is "es_ES.UTF-8"
On Fri, Nov 27, 2009 at 2:11 AM, Guillaume Smet wrote: > Henrik, > > On Fri, Nov 27, 2009 at 4:15 AM, Henrik Pestano wrote: >> This information can be in two columns. > > Please note that pgsql-bugs mailing list is for PostgreSQL bugs only. > i think what Henrik was proposing is change postgresql's csv format to store the duration and statements values in different columns. Then, pgFouine will have no problem identifying those values no matter the language. i know i agree with the idea, is very ugly to be writing: " like 'duration: %' instead of simply 'duration >= ' -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] data shown from down to up
On Thu, Nov 19, 2009 at 1:03 PM, Orange wrote: > > Hi it shows like you see bellow > > The stange that once I copy it to other file it shows right > and this is related to postgres... because... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] PROBLEMA AL INSTALAR POSTSGRESQL
On Sun, Sep 27, 2009 at 9:45 PM, Robert Haas wrote: > > (with apologies to anyone on this mailing list who ACTUALLY speaks > Spanish - it must have hurt to read that) > actually it was very good! -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] diferent timezones in the same table?
Hi, One of the tables in a client production system has several timestamp with time zone fields, in one of those fields they store '1900-01-01 00:00:00'::timestamp with time zone where there is no valid value (a legacy from another dbms)... pg = 8.4.1 timezone 'America/Guayaquil' yesterday we found that that field is getting obtained as year 1899 when investigating i find that is beign obtained as timezone GMT+5:14 as shown in this extract of data (look at the data in the other field, is just fine but shows different info about time zone): """ fecha_registro | fecha_registro_retencion +--- 2009-07-09 00:00:00-05 | 1899-12-31 23:46:00-05:14 2009-07-07 00:00:00-05 | 1899-12-31 23:46:00-05:14 2009-07-27 00:00:00-05 | 1899-12-31 23:46:00-05:14 """ i have the data in my test env and i found that this happen when timezone is set to 'America/Guayaquil' but not if set it to 'GMT+5' and only with values in '1900-01-01 00:00:00', even more in the same field all values different from that date are right: """ imrelevsa=# show timezone; TimeZone -- GMT+5 (1 row) imrelevsa=# select '1900-01-01 00:00:00'::timestamp with time zone; timestamptz 1900-01-01 00:00:00-05 (1 row) imrelevsa=# set timezone to 'America/Guayaquil'; SET imrelevsa=# select '1900-01-01 00:00:00'::timestamp with time zone; timestamptz --- 1900-01-01 00:00:00-05:14 (1 row) """ is this intended? why we treat '1900-01-01 00:00:00' different? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5030: Problem on "RETURN QUERY EXECUTE" when a column is dropped from a table
On Wed, Sep 2, 2009 at 12:25 PM, Armando Taffarel Neto wrote: > > SELECT * FROM test_foo(); > ERROR: structure of query does not match function result type > DETAIL: Number of returned columns (1) does not match expected column count > (2). > CONTEXT: PL/pgSQL function "test_foo" line 5 at RETURN QUERY > yeah! that bug was fixed here http://archives.postgresql.org/pgsql-committers/2009-08/msg00068.php but only in the currently in develop 8.5 are we going to backpatch this? while i think we should i know nothing about how feasible that is -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] lost statistics; analyze needs to execute twice
Hi, pgsql 8.3.7 and 8.4.0 when i issue an "immediate shutdown" the statistics on all tables disappear... and when i try to recover them via an analyze; (on all tables on the database) the result is nothing... i have to exexute the analyze commands twice to compute the statistics jd=# select relname, n_live_tup, n_dead_tup from pg_stat_user_tables where relname = 'bpprovee'; relname | n_live_tup | n_dead_tup --++ bpprovee |111 | 0 (1 row) jd=# select version(); version PostgreSQL 8.4.0 on x86_64-unknown-linux-gnu, compiled by GCC gcc (Debian 4.3.2-1.1) 4.3.2, 64-bit (1 row) jd=# \q postg...@casanova1:/usr/local/pgsql/8.4$ bin/pg_ctl -m immediate -D $PWD/data stop waiting for server to shut down done server stopped postg...@casanova1:/usr/local/pgsql/8.4$ bin/pg_ctl -D $PWD/data start server starting postg...@casanova1:/usr/local/pgsql/8.4$ bin/psql psql (8.4.0) Type "help" for help. jd=# select relname, n_live_tup, n_dead_tup from pg_stat_user_tables where relname = 'bpprovee'; relname | n_live_tup | n_dead_tup --++ bpprovee | 0 | 0 (1 row) jd=# analyze; ANALYZE jd=# select relname, n_live_tup, n_dead_tup from pg_stat_user_tables where relname = 'bpprovee'; relname | n_live_tup | n_dead_tup --++ bpprovee | 0 | 0 (1 row) jd=# analyze; ANALYZE jd=# select relname, n_live_tup, n_dead_tup from pg_stat_user_tables where relname = 'bpprovee'; relname | n_live_tup | n_dead_tup --++ bpprovee | 111 | 0 (1 row) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5015: MySQL migration wizard does not start
On Wed, Aug 26, 2009 at 9:55 AM, Ken Smith wrote: > > The following bug has been logged online: > > Bug reference: 5015 > Logged by: Ken Smith > Email address: kensm...@adobe.com > PostgreSQL version: 8.4 > Operating system: Windows > Description: MySQL migration wizard does not start > Details: > > I have downloaded and installed PostgreSQL 8.4 and installed the mysql > migration wizard. MySQL migration wizard is a tool from EnterpriseDB (http://www.enterprisedb.com), you should go ask them... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4999: select 'a' < 'A' is true, but should be false . . .
On Tue, Aug 25, 2009 at 8:38 PM, Brian Ceccarelli wrote: > > If the words are the same words but letters have different case, then the > operator is case-sensitive. > If the words are not the same words, then the operator is case-insensitive > until the operator reaches the character position in both strings where the > letters become different. > this is completely non-sense. can you present a test case that proves what you're claiming? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] When Drop Table or alter Table I need restart service Posgresql - 8.1 ?????
On Fri, Aug 21, 2009 at 2:58 PM, Robert Haas wrote: > > Maybe you are doing this inside a transaction someplace? If so, it > won't be visible to other transactions until you commit. > but then, if he simply restart the service the transaction will rollback -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] When Drop Table or alter Table I need restart service Posgresql - 8.1 ?????
On Fri, Aug 21, 2009 at 9:36 AM, fabiofurlan wrote: > > Hi. > > I do not any idea. > > When i drop table or alter table, i need restart service postgresql 8.1, > because is impossible new connect or > because the changes are not visible. > no, you don't have to. you have a specific problem of this kind? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4993: memory issue with array_agg
On Tue, Aug 18, 2009 at 11:22 AM, Tom Lane wrote: > "Morus Walter" writes: >> when trying to use the array_agg aggregate I ran into a `out of memory' >> issue. > > This looks like a known issue, fixed here: > > http://archives.postgresql.org/pgsql-committers/2009-07/msg00210.php > > It will be in 8.4.1. > > regards, tom lane > if you can compile code then you can download the latest snapshot of 8.4.0 (with the fix) from here http://www.postgresql.org/ftp/snapshot/stable/8.4/ -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] fix: plpgsql: return query and dropped columns problem
On Tue, Jul 28, 2009 at 12:12 PM, Robert Haas wrote: >>> >>> patch attached >>> >> super, thanks >> >> Pavel > > So is this Ready for Committer? > i think so... but being me who added the last bit of code i didn't felt confident to mark it as such... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgresql, ts_headline() adds space when parsing url problem
2009/7/26 Wojciech Walczak : > Hi! > > I found your article over the internet: > http://archives.postgresql.org/pgsql-bugs/2009-01/msg00097.php > I have Postgresql installation version 8.3.5 and I still the problem with > space inserted after "http://": > > Do you know if this bug has been fixed or not? What would be the solution > then? > That was fixed in 8.3.6 (http://www.postgresql.org/docs/8.4/static/release-8-3-6.html) but we are in 8.3.7 now better go to the last... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] fix: plpgsql: return query and dropped columns problem
On Mon, Jul 20, 2009 at 11:34 AM, Jaime
Casanova wrote:
> On Mon, Jul 20, 2009 at 10:09 AM, Alvaro
>>
>> Getting rid of the check on natts was "ungood" ... it needs to compare
>> the number of undropped columns of both tupdescs.
>>
>
> ah! ok, i see... i will mark the patch as "waiting on author" and then
> will try to fix it myself unless pavel wants to do it himself
>
patch attached
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
Index: src/pl/plpgsql/src/pl_exec.c
===
RCS file: /home/postgres/pgrepo/pgsql/src/pl/plpgsql/src/pl_exec.c,v
retrieving revision 1.245
diff -c -r1.245 pl_exec.c
*** src/pl/plpgsql/src/pl_exec.c 18 Jul 2009 19:15:42 - 1.245
--- src/pl/plpgsql/src/pl_exec.c 20 Jul 2009 20:59:38 -
***
*** 2284,2289
--- 2284,2294
{
Portal portal;
uint32 processed = 0;
+ int i;
+ bool dropped_columns = false;
+ Datum *dvalues;
+ bool *nulls;
+ int natts;
if (!estate->retisset)
ereport(ERROR,
***
*** 2308,2318
validate_tupdesc_compat(estate->rettupdesc, portal->tupDesc,
"structure of query does not match function result type");
while (true)
{
MemoryContext old_cxt;
- int i;
SPI_cursor_fetch(portal, true, 50);
if (SPI_processed == 0)
--- 2313,2330
validate_tupdesc_compat(estate->rettupdesc, portal->tupDesc,
"structure of query does not match function result type");
+ natts = estate->rettupdesc->natts;
+
+ if (natts > portal->tupDesc->natts)
+ {
+ dropped_columns = true;
+ dvalues = (Datum *) palloc0(natts * sizeof(Datum));
+ nulls = (bool *) palloc(natts * sizeof(bool));
+ }
while (true)
{
MemoryContext old_cxt;
SPI_cursor_fetch(portal, true, 50);
if (SPI_processed == 0)
***
*** 2323,2335
{
HeapTuple tuple = SPI_tuptable->vals[i];
! tuplestore_puttuple(estate->tuple_store, tuple);
processed++;
}
MemoryContextSwitchTo(old_cxt);
SPI_freetuptable(SPI_tuptable);
}
SPI_freetuptable(SPI_tuptable);
SPI_cursor_close(portal);
--- 2335,2374
{
HeapTuple tuple = SPI_tuptable->vals[i];
! if (!dropped_columns)
! tuplestore_puttuple(estate->tuple_store, tuple);
! else
! {
! int anum;
! int j = 0;
! bool isnull;
!
! for (anum = 0; anum < natts; anum++)
! {
! if (estate->rettupdesc->attrs[anum]->attisdropped)
! nulls[anum] = true;
! else
! {
! dvalues[anum] = SPI_getbinval(tuple, portal->tupDesc,
! ++j, &isnull);
! nulls[anum] = isnull;
! }
! }
! tuple = heap_form_tuple(estate->rettupdesc, dvalues, nulls);
! tuplestore_puttuple(estate->tuple_store, tuple);
! }
processed++;
}
MemoryContextSwitchTo(old_cxt);
SPI_freetuptable(SPI_tuptable);
}
+
+ if (dropped_columns)
+ {
+ pfree(dvalues);
+ pfree(nulls);
+ }
SPI_freetuptable(SPI_tuptable);
SPI_cursor_close(portal);
***
*** 5127,5153
validate_tupdesc_compat(TupleDesc expected, TupleDesc returned, const char *msg)
{
int i;
const char *dropped_column_type = gettext_noop("N/A (dropped column)");
if (!expected || !returned)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("%s", _(msg;
! if (expected->natts != returned->natts)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("%s", _(msg)),
! errdetail("Number of returned columns (%d) does not match "
! "expected column count (%d).",
! returned->natts, expected->natts)));
!
for (i = 0; i < expected->natts; i++)
! if (expected->attrs[i]->atttypid != returned->attrs[i]->atttypid)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("%s", _(msg)),
! errdetail("Returned type %s does not match expected type "
"%s in column \"%s\".",
OidIsValid(returned->attrs[i]->atttypid) ?
format_type_be(returned->attrs[i]->atttypid) :
--- 5166,5197
validate_tupdesc_compat(TupleDesc expected, TupleDesc returned, const char *msg)
{
int i;
+ int j = 0;
const char *dropped_column_type = gettext_noop("N/A (dropped column)");
+ int expected_valid_natts, returned_valid_natts;
if (!expected || !returned)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("%s", _(msg;
! expected_valid_natts = expected->natts;
! returned_valid_natts = returned->natts;
Re: [BUGS] fix: plpgsql: return query and dropped columns problem
On Mon, Jul 20, 2009 at 10:09 AM, Alvaro Herrera wrote: > Tom Lane escribió: >> Jaime Casanova writes: >> > this one applies, compiles and it actually fixes the bug... >> >> And introduces a bunch of new ones. Surely you don't think that version >> of compatible_tupdesc() is good enough. > > Getting rid of the check on natts was "ungood" ... it needs to compare > the number of undropped columns of both tupdescs. > ah! ok, i see... i will mark the patch as "waiting on author" and then will try to fix it myself unless pavel wants to do it himself create table test_tbl (a int, b date, c int); create function trg_ins_test_tbl() returns trigger as $$ begin new.c = 100; return new; end; $$ language plpgsql; create trigger trg_test_tbl before insert on test_tbl for each row execute procedure trg_ins_test_tbl(); insert into test_tbl(a, b) select i, current_date + i from generate_series(7, 9) as i; alter table test_tbl add column z text; alter table test_tbl drop column z; alter table test_tbl add column z text; insert into test_tbl(a, b) select i, current_date + i from generate_series(7, 9) as i; ERROR: returned row structure does not match the structure of the triggering table DETAIL: Returned type text does not match expected type text in column "z". CONTEXT: PL/pgSQL function "trg_ins_test_tbl" during function exit STATEMENT: insert into test_tbl(a, b) select i, current_date + i from generate_series(7, 9) as i; -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] fix: plpgsql: return query and dropped columns problem
On Mon, Jul 20, 2009 at 9:55 AM, Tom Lane wrote: > Jaime Casanova writes: >> this one applies, compiles and it actually fixes the bug... > > And introduces a bunch of new ones. Surely you don't think that version > of compatible_tupdesc() is good enough. > i guess you're talking about my adapted version for backpatching in 8.3, right? i just was trying to move as less code as possible for 8.3... or there is something wrong in pavel's patch (the one that applies to head)? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] fix: plpgsql: return query and dropped columns problem
On Sun, Jul 12, 2009 at 10:28 AM, Pavel Stehule wrote:
> Hello
>
> there is fix for bug Re: [BUGS] BUG #4907: stored procedures and changed
> tables
>
this one applies, compiles and it actually fixes the bug...
it should be backpatched until 8.3... but applies cleanly only until
8.4 (what a surprise), attached is an adapted version for 8.3
the only thing that is bothered me is that the same solution is used
again and again... seems like we can use a function like
make_tuple_from_row (maybe something like make_tuple_from_datum or
eliminate_dropped_cols_from_tuple or something like that) for avoiding
duplicate code... but that's another patch, is worth the trouble?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
Index: src/pl/plpgsql/src/pl_exec.c
===
RCS file: /home/postgres/pgrepo/pgsql/src/pl/plpgsql/src/pl_exec.c,v
retrieving revision 1.202.2.5
diff -c -r1.202.2.5 pl_exec.c
*** src/pl/plpgsql/src/pl_exec.c 2 Apr 2009 01:16:17 - 1.202.2.5
--- src/pl/plpgsql/src/pl_exec.c 20 Jul 2009 06:37:15 -
***
*** 2156,2161
--- 2156,2166
PLpgSQL_stmt_return_query *stmt)
{
Portal portal;
+ int i;
+ bool dropped_columns = false;
+ Datum *dvalues;
+ bool *nulls;
+ int natts;
if (!estate->retisset)
ereport(ERROR,
***
*** 2172,2177
--- 2177,2191
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("structure of query does not match function result type")));
+ natts = estate->rettupdesc->natts;
+
+ if (natts > portal->tupDesc->natts)
+ {
+ dropped_columns = true;
+ dvalues = (Datum *) palloc0(natts * sizeof(Datum));
+ nulls = (bool *) palloc(natts * sizeof(bool));
+ }
+
while (true)
{
MemoryContext old_cxt;
***
*** 2186,2197
{
HeapTuple tuple = SPI_tuptable->vals[i];
! tuplestore_puttuple(estate->tuple_store, tuple);
}
MemoryContextSwitchTo(old_cxt);
SPI_freetuptable(SPI_tuptable);
}
SPI_freetuptable(SPI_tuptable);
SPI_cursor_close(portal);
--- 2200,2238
{
HeapTuple tuple = SPI_tuptable->vals[i];
! if (!dropped_columns)
! tuplestore_puttuple(estate->tuple_store, tuple);
! else
! {
! int anum;
! int j = 0;
! bool isnull;
!
! for (anum = 0; anum < natts; anum++)
! {
! if (estate->rettupdesc->attrs[anum]->attisdropped)
! nulls[anum] = true;
! else
! {
! dvalues[anum] = SPI_getbinval(tuple, portal->tupDesc,
! ++j, &isnull);
! nulls[anum] = isnull;
! }
! }
! tuple = heap_form_tuple(estate->rettupdesc, dvalues, nulls);
! tuplestore_puttuple(estate->tuple_store, tuple);
! }
}
MemoryContextSwitchTo(old_cxt);
SPI_freetuptable(SPI_tuptable);
}
+
+ if (dropped_columns)
+ {
+ pfree(dvalues);
+ pfree(nulls);
+ }
SPI_freetuptable(SPI_tuptable);
SPI_cursor_close(portal);
***
*** 4910,4923
compatible_tupdesc(TupleDesc td1, TupleDesc td2)
{
int i;
!
! if (td1->natts != td2->natts)
! return false;
for (i = 0; i < td1->natts; i++)
{
! if (td1->attrs[i]->atttypid != td2->attrs[i]->atttypid)
! return false;
}
return true;
--- 4951,4963
compatible_tupdesc(TupleDesc td1, TupleDesc td2)
{
int i;
! int j = 0;
for (i = 0; i < td1->natts; i++)
{
! if (!td1->attrs[i]->attisdropped)
! if (td1->attrs[i]->atttypid != td2->attrs[j++]->atttypid)
! return false;
}
return true;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Fwd: [BUGS] WARNING: out of shared memory
cc: the -list this time -- Forwarded message -- From: Jaime Casanova Date: Thu, Jul 16, 2009 at 5:18 PM Subject: Re: [BUGS] WARNING: out of shared memory To: "Juan C. Aragon" it's better for you to always write to the list because there are more people that can help and the most of them are more prepared than me :) On Thu, Jul 16, 2009 at 5:05 PM, Juan C. Aragon wrote: > Yes, this is another server. > > There is 8GB of memory. > > max_connections = 100 > > shared_buffers = 32MB > well, you are plenty of RAM and thats seems a default configuration... you can raise it to something better like 2GB... that doesn't explain the error, though... at least not to me > It looks like this: > > 2009-07-16 16:53:20 WARNING: out of shared memory > 2009-07-16 16:53:20 STATEMENT: INSERT INTO "public"."student_table" ( > student_first_name,student_last_name,student_address,student_city,student_st > ate,student_zip,student_phone,student_email,student_dob,student_status,sycam > pusid,campus_name,student_address2,student_sex,student_mi,student_work_phone > ,student_ssn,datelstmod,syschoolstatusid,systudentid,dlstate,dlnumber,alienn > um,balover10k,balover5k) > 2009-07-16 16:53:20 ERROR: out of shared memory > i can't make an example with this... where's the value clause... what were you inserting? > There is only one table. > great! can you share (if you prefer in private, yes i'm the same that makes the above comment ;) the structure of that single table and if you can the inserts that are executing... what i'm looking for is what is triggering that error and if it's something we can repeat in other environments (say something less evil like linux) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] WARNING: out of shared memory
On Thu, Jul 16, 2009 at 4:41 PM, Juan C. Aragon wrote: > We are working on Windows Server 2003 Enterprise with PostgreSQL 8.4, when > we start populating a table with 130,000 records it start giving “WARNING: > out of shared memory” > > on every record that was inserted. At the end it did not finish, it only > inserted 4,000 records and got the following message: > > > > 2009-07-16 16:54:05 EDT WARNING: worker took too long to start; > cancelled > > 2009-07-16 16:54:05 EDT WARNING: out of shared memory > > 2009-07-16 16:54:05 EDT FATAL: out of shared memory > > but this, is a different thing... how much memory you have in your machine? and how much has been assigned to postgres via shared_buffers? can you show a self contained example of this (eg: the minimun structure of the table and the inserts you need to make the bug happen)? > > Also, we are not able to login to the database with PgAdmin, getting same > error “out of shared memory” > what's the value in max_connections? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] FATAL: could not reattach to shared memory (key=268, addr=01E30000): 487
On Thu, Jul 16, 2009 at 1:50 PM, Juan C. Aragon wrote: > I’m getting this error message continuously in Windows Server 2008 using > PostgreSQL 8.4 release version: > > FATAL: could not reattach to shared memory (key=268, addr=01E3): 487 > there is a patch being tested for a problem that looks a lot like the one you reported here... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7
On Tue, Jun 9, 2009 at 1:00 PM, Kevin Grittner wrote: > > the same paragraph: "The default is to allow scrolling in some cases; "in some cases"... like in "but not all"... ? this doesn't sound like a vow to me. if the user really wants SCROLLing ability he should have been specified that way... i say pay the price for WITH HOLD and SCROLL and don't allow scrolling ability if SCROLL hasn't been specified -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] POSTGRESQL 8.2.3
On Tue, May 12, 2009 at 11:57 AM, Rodrigo Peres Chapelin wrote: > Hi, > > can i install Postgresql 8.2.3 on Red Hat 5 64 bits? > is this a bug of some kind? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4748: hash join and sort-merge join make different results
On Fri, Apr 3, 2009 at 2:10 PM, Alvaro Herrera wrote: > Roman Kononov wrote: > >> Description: hash join and sort-merge join make different results >> Details: >> >> test-std=# create table t(s int,i interval); >> CREATE TABLE >> test-std=# insert into t values (0,'30 days'), (1,'1 month'); >> INSERT 0 2 >> test-std=# select * from t as a, t as b where a.i=b.i; > > Reproducible in 8.2.13 as well .. > and the same in HEAD PS: the analyze not always brings the problems, i had to turn off enable_mergejoin and enable_nestloop -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
On Thu, Mar 5, 2009 at 3:27 PM, Xuân Baldauf wrote: > > > Well, while this behaviour is well-known for PostgreSQL, this is actually an > abuse of syntax. If there are legitimate requirements for rewriting a table, > then there should be explicit syntax for such a feature, like "ALTER TABLE > ... REWRITE". Rewriting a table in case of "ALTER TABLE ... TYPE" is, by the > semantics of that statement, just a side-effect, which may or may not > happen, depending on how optimized the DBMS is. It is bad design to avoid > optimization just because an unnecessary side-effect would be optimized > away. > note that this is my opinion and not represent the PGDG (Postgresql Global Development Group) opinion > now, back to the problem... is not easier to define a column as TEXT > and to put a check to constraint the length? if you wanna change the > constraint that will be almost free > > No. Is it possible to change the column type from VARCHAR(5) to TEXT without > a table-rewrite penalty? > > the idea is to make that change once (and to create new tables just with TEXT) and then you can make ALTER TABLE ... ADD CHECK (length(column) = a_value) as many times as you want without the need for a table rewrite -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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] Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati wrote: > Guillaume Smet ha scritto: >> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut wrote: >>> The question is how you want to implement this in a data type independent >>> fashion. You can't assume that increasing the typmod is a noop for all data >>> types. >> >> Sure. See my previous answer on -hackers (I don't think this >> discussion belong to -bugs) and especially the discussion in the >> archives about Jonas' patch. > > I recently had a similar problem when I added some domains to the > application. ALTER TABLE ... TYPE varchar_dom was leading to a full > table rewrite even though the underlying type definition were exactly > the same (i.e. varchar(64)). I can live with it, but I suppose this fix > might be related to the varlen one. > ALTER TABLE ... TYPE does cause a table rewrite even if new_type = old_type, and that is actually useful... for example when you add a fillfactor to an existing table that fillfactor will not affect the existing data until you rewrite the table and a convenient way is exactly using ALTER TABLE ... TYPE. now, back to the problem... is not easier to define a column as TEXT and to put a check to constraint the length? if you wanna change the constraint that will be almost free -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4693: When I use the order by it gets me an error, but if i use it without order by it's a correct query.
On Wed, Mar 4, 2009 at 2:05 PM, Oscar Bejarano wrote: > > The following bug has been logged online: > > Bug reference: 4693 > Logged by: Oscar Bejarano > Email address: obejara...@msn.com > PostgreSQL version: 8.3.0 > Operating system: Suse 10 > Description: When I use the order by it gets me an error, but if i > use it without order by it's a correct query. > Details: > > ===QUERY= which ORDER BY is causing troubles to you? the one in ther outer query or the one in the inner query? can you provide at least the error message? a little test case would be useful -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4684: lastval in function
On Mon, Mar 2, 2009 at 12:21 PM, Tom Lane wrote: > > Before considering complicating the definition of lastval, I'd vote > for removing it entirely. It's a foot-gun and will never be anything > but. > +1 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgresql
On 12/21/08, dane manship wrote: > hey, sorry for sending this to this email address but i couldnt find another > one. > > but, i have downloaded postgresql tried to install it and it says i need a > password, but i dont have a password. > > is there anyway i can get around this?? > ah? from where do you download it? are you sure it's not asking you to *assign* a password for the postgres database user? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4547: sort columns in \d
On Sun, Nov 23, 2008 at 12:40 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > >> this patch fixes this and makes the output of \d much more usable. > > Calling this a "bug" isn't a good way to start a discussion about it. > specially because this *fix* will lead to confusions about the order of columns in INSERT statements, eventually you will be forced to put column names in every INSERT statement (ie: if you start to work in an enterprise with an already implemented postgres database) -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4413: LEFT JOIN not working as expected
On Tue, Sep 9, 2008 at 3:28 PM, David Jaquay <[EMAIL PROTECTED]> wrote: > > Description:LEFT JOIN not working as expected > Details: > > I'm seeing a problem with a LEFT JOIN. The sql below demonstrates the > issue. > > What I expect to see is no rows in the output, i.e. the LEFT JOIN should > pair the two rows together, and the WHERE clause should decide that the > joined row doesn't match, and should yield no output. > > What happens is that the planner appears to apply the WHERE clause early, > the left table doesn't yield any rows, and the row from the right table is > output by itself. This only appears to happen when both sides of the OR are > present, and the idx_beta_datereceived index is present. Remove any one, > and it works like I expect. > This has been reported and fixed already: http://archives.postgresql.org/pgsql-bugs/2008-06/msg00175.php if you can compile postgres from sources you can apply the fix Tom shows. If not you have to wait for 8.3.4. Is not time for a new minor release? -- regards, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. (593) 87171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4412: Check constraints cannot be added to the table for fields that are mixed case
On Tue, Sep 9, 2008 at 3:11 PM, Kevin <[EMAIL PROTECTED]> wrote: > Description:Check constraints cannot be added to the table for > fields that are mixed case > Details: > > Check constraints cannot be added to the table for fields that are mixed > case. > > Example - field employeeName in table Employees postgres converts all your uppercase in object names to lowercase... if you really want mixed case you must put the name in quotes. Try with: ALTER TABLE "Employees" ADD CONSTRAINT employeenametest CHECK (employeename != 'Kevin') -- regards, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. (593) 87171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Hmm, nodeUnique doesn't really support backwards scan too well
On 8/5/08, Tom Lane <[EMAIL PROTECTED]> wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > I've never seen anyone scan backwards like this at all in practical use. > > > I knew it was possible, but never seen it done. > > > It seems entirely probable nobody else has either. It's a PostgreSQL > > extension, so people arriving from outside don't even know it exists, > > Say again? Both the SCROLL option to DECLARE CURSOR and FETCH PRIOR are > straight out of the SQL92 spec. > i think Simon is talking about DISTINCT ON -- regards, Jaime Casanova Soporte y capacitación de PostgreSQL Guayaquil - Ecuador Cel. (593) 87171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [DOCS] wal_sync_method
On Sat, May 17, 2008 at 1:45 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > [ redirecting to -bugs ] > > "Jaime Casanova" <[EMAIL PROTECTED]> writes: >> On Sat, May 17, 2008 at 11:55 AM, Tom Lane <[EMAIL PROTECTED]> wrote: >>> "Jaime Casanova" <[EMAIL PROTECTED]> writes: >>>> But in my freshly 8.3.1 instalation on win xp, the default is >>>> "fsync"... is a *bug* in the docs :) >>> >>> More like a bug in the code. Does it let you set the value to >>> open_datasync? > >> yes it does... > > Well, that's just bizarre. I found a problem in CVS HEAD that would > lead to a bogus selection of the default for wal_sync_method, but it > doesn't apply to 8.3. I really don't see how 8.3 would fail to use > open_datasync as the default if it's an available value. Did you > build 8.3.1 yourself, and if so how? > nop, default installer downloaded from postgresql.org... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Guayaquil - Ecuador Cel. (593) 087171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4115: PostgreSQL ISO format is not really ISO
On Sat, Apr 19, 2008 at 6:38 AM, Daniel Ruoso <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 4115 > Logged by: Daniel Ruoso > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3.1 > Operating system: Debian GNU/Linux lenny > Description:PostgreSQL ISO format is not really ISO > Details: > > ISO8601[1] defines Date/Time ouput, and is, today, quite accepted, being the > standard used by XML Schema definitions. Which means that they have to be in > that format to be accepted by a XML validator. > > The basic difference between PostgreSQL format and the ISO format is the > absence of a "T" between the date and the time. > > [1] http://en.wikipedia.org/wiki/ISO_8601 > This says that a space between date and time is acceptable, although not considered a single field. http://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations """ Unlike the previous examples, "2007-04-05 14:30" is considered two separate, but acceptable, representations—one for date and the other for time. It is then left to the reader to interpret the two separate representations as meaning a single time point based on the context. """ -- regards, Jaime Casanova Soporte de PostgreSQL Guayaquil - Ecuador Cel. 087171157 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] HELP URGENTE
On 9/8/07, LIZETH ANGHELA SIRPA CACERES <[EMAIL PROTECTED]> wrote: > Escribo para comunicarle que estoy realizando mi tesis. > > soy egresada de la carrera de Informatica de la Universidad Mayor de San > Andres de LA PAZ-BOLIVIA, me encuentro realizando mi tesis, estoy trabajando > en una idea para complementar la seguridad en Postgres, y me entere que > usedes trabajan con este gestor y quisiera hacerles algunas consultas > especificamente hablando de procedimientos almacenados. Spanish version of the answer: Hola, Esta es una lista en ingles y especificamente para informar de bugs (fallas) de postgresql. Si deseas ayuda con tu tesis y por la naturaleza del tema podrias escribir en *ingles* a [EMAIL PROTECTED] o [EMAIL PROTECTED] sino sabes ingles puedes escribir en español a [EMAIL PROTECTED] English version of the answer: Hi, This is an english list and specifically for bugs reporting. If you want help with your work and because of the nature of it yo can write in english to [EMAIL PROTECTED] or to [EMAIL PROTECTED] if you don't know english you can write in spanish to [EMAIL PROTECTED] -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Fwd: [BUGS] BUG #3421: Failed to create temporary batch file
-- Forwarded message -- From: Fadi Thabtah <[EMAIL PROTECTED]> Date: Sun, 1 Jul 2007 12:56:52 +0100 Subject: RE: [BUGS] BUG #3421: Failed to create temporary batch file To: Jaime Casanova <[EMAIL PROTECTED]> yes I do. Fadi From: Jaime Casanova [mailto:[EMAIL PROTECTED] Sent: Sun 7/1/2007 5:40 AM To: Fadi Thabtah Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #3421: Failed to create temporary batch file On 6/30/07, Fadi Thabtah <[EMAIL PROTECTED]> wrote: The following bug has been logged online: Bug reference: 3421 Logged by: Fadi Thabtah Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows Description:Failed to create temporary batch file Details: I was unable to install Postgres because of the following message "Failed to create temporary batch file", which interrupts the installation. do you have write permissions on the directory you are installing at? -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability. -- Atentamente, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #3421: Failed to create temporary batch file
On 6/30/07, Fadi Thabtah <[EMAIL PROTECTED]> wrote: The following bug has been logged online: Bug reference: 3421 Logged by: Fadi Thabtah Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Windows Description:Failed to create temporary batch file Details: I was unable to install Postgres because of the following message "Failed to create temporary batch file", which interrupts the installation. do you have write permissions on the directory you are installing at? -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] No error when FROM is missing in subquery
On 12/18/06, Thomas H. <[EMAIL PROTECTED]> wrote: >> oups. just thumbled over this as well when i forgot a FROM in a WHERE ... >> IN >> () and damaged quite some data. the bad query went like this: >> >> SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id WHERE >> mov_name like '%, %' LIMIT 2) >> >> the subselect is missing a FROM . in that case, pgsql seemed to >> also >> ignore the LIMIT 2 and returned 3706 records out of ~13... > > and the UPDATE was? that was done by the application with the returned recordset. > also the limit applies only to the subselect, it has nothing to do > with the upper query so the upper query can return more than number of > rows specified in the subselect... IF the subquery would only have returned 2 ids, then there would be at most like +/-10 records affected. each mov_id can hold one or more (usuals up to 5) names. but here, the subquery seemed to return ~3700 distinct mov_ids, thus around 37000 names where damaged by the following programmatical updates instead of only a hands full... have you tested the query in psql? what results do you get? -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] No error when FROM is missing in subquery
On 12/18/06, Thomas H. <[EMAIL PROTECTED]> wrote: >> > Is it a bug? If no, maybe to produce warning in such cases? oups. just thumbled over this as well when i forgot a FROM in a WHERE ... IN () and damaged quite some data. the bad query went like this: SELECT * FROM movies.names WHERE mov_id IN (SELECT DISTINCT mov_id WHERE mov_name like '%, %' LIMIT 2) the subselect is missing a FROM . in that case, pgsql seemed to also ignore the LIMIT 2 and returned 3706 records out of ~13... and the UPDATE was? also the limit applies only to the subselect, it has nothing to do with the upper query so the upper query can return more than number of rows specified in the subselect... no clue which ones :-/ LIMIT is often meaningfull only in conjuction with ORDER BY -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] No error when FROM is missing in subquery
On 12/19/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote: > Following query is considered as correct, no "missing from" error has > been reported (so, entire table will be updated and "on update" > triggers will be fired for every row): > > update item set obj_id = obj_id > where obj_id in (select obj_id where item_point is null order by > obj_modified limit 10) > > Is it a bug? If no, maybe to produce warning in such cases? On 12/18/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote: ok, sorry, I've realized that it's yet another example of "outer reference", Tom will say "read any SQL book" again :-) http://archives.postgresql.org/pgsql-bugs/2006-12/msg00115.php not really... AFAIK, the FROM clause is mandatory per SQL... older releases of postgres fill the missing from clause if it was easy to determine, in recent releases it's mandatory unless you specify the opposite in postgresql.conf with the add_missing_from parameter -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2681: duplicate key violates unique constraint
On 10/6/06, Jean Tourrilhes <[EMAIL PROTECTED]> wrote: The following bug has been logged online: Bug reference: 2681 Logged by: Jean Tourrilhes Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: Linux - Debian 3.1 (stable) Description:duplicate key violates unique constraint Details: the first thing you have to do is to upgrade at least to 7.4.13 (the last release in that branch) and try again. Maybe the bug was already fixed. -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2211: select (1::float-1::float)*(-1) = -0 ??
On 1/25/06, Tiago D. J. <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 2211 > Logged by: Tiago D. J. > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 > Operating system: Slackware 10.2 > Description:select (1::float-1::float)*(-1) = -0 ?? > Details: > > Hi people, > I think that anything * 0, or 0*anything should be zero. > But run this query : > select (1::float-1::float)*(-1) > > it returns -0 > > Sorry, my english is so poor, > I hope that i'm helping you with this information. > > Tiago > pruebas=# select version(); version -- PostgreSQL 8.1.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special) (1 fila) pruebas=# select (1::float-1::float)*(-1); ?column? -- 0 (1 fila) This is good for me... maybe a bug already fixed? -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2195: log_min_messages crash server when in DEBUG3 to 5
The following bug has been logged online: Bug reference: 2195 Logged by: Jaime Casanova Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.1 Operating system: Windows XP Description:log_min_messages crash server when in DEBUG3 to 5 Details: Hi, in my machine (win xp) i was trying to start psql (8.1.1) with log_min_messages to debug5 (just to see the messages :) but even the service start i cannot use psql nor pgadmin i receive an error of server closed the connection unexpectedly postgres=# select version(); version -- PostgreSQL 8.1.1 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special) (1 fila) Sorry, my postgres is in spanish but maybe you can recognize the message... ;) C:\Archivos de programa\PostgreSQL\8.1\bin>psql -U postgres pruebas psql: el servidor ha cerrado la conexión inesperadamente, probablemente porque terminó de manera anormal antes o durante el procesamiento de la petición. is this expected on windows platforms? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2176: Pgadmin III not honoring DATESTYLE
On 1/17/06, Francisco Leovey <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 2176 > Logged by: Francisco Leovey > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.2 > Operating system: Linux > Description:Pgadmin III not honoring DATESTYLE > Details: > > By default in postgresql.conf the DATESTYLE is set to "SQL,European" and it > works OK except for Pgadmin III. > When you ask for "view data" in Pgadmin III a date field shows -mm-dd > instead of dd/mm/ > Please tell me how to fix this > Thank you > Then, this is a pgAdmin bug and you have to report it to the pgAdmin team... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2185: function compilation error with "Create [TEMP] table?
On 1/19/06, marc mamin <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 2185 > Logged by: marc mamin > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 > Operating system: DB Server: Linux Client: windows XP > Description:function compilation error with "Create [TEMP] table? > Details: > > within a function, when I: > - use create temp table , > - do anyting with this table > - drop that table, > > The first call to that function works, but further calls fail. Rebuilding > the function before each call fix the issue. > I guess that the function is not yet compiled at the first call, and that > further calls use a compiled version > > Cheers, Marc > > Here the steps to repeat the bug: > - > > CREATE OR REPLACE FUNCTION bugtest() > RETURNS int AS > $BODY$ > > > BEGIN > > > create temp table bugt(i int); > insert into bugt values(1); > drop table bugt; > > > RETURN 0; > > > END; > $BODY$ > LANGUAGE 'plpgsql' VOLATILE; > > > select bugtest(); > -->0 > select bugtest(); > -->ERROR: relation with OID 52284 does not exist > -->CONTEXT: SQL statement "insert into bugt values(1)" > -->PL/pgSQL function "bugtest" line 9 at SQL statement > that is a known issue, do it this way CREATE OR REPLACE FUNCTION bugtest() RETURNS int AS $BODY$ BEGIN execute 'create temp table bugt(i int)'; execute 'insert into bugt values(1)'; execute 'drop table bugt'; RETURN 0; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2169: excelente
On 1/13/06, Luis Felipe <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 2169 > Logged by: Luis Felipe > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.3 > Operating system: windows Xp > Description:excelente > Details: > > Good trades I go to you since I am fiek usuary of the best motor of free BD > Postgres.En this occasion I am working version 8.0.3 for Windows and need to > execute flat archives in estructura.Como I can realizar.Gracias pos its > collaboration or if..un has information agradeceria hug thanks > Sorry there is no spanglish list... please, post in english or in spanish in [EMAIL PROTECTED] (i recommend you do that) -- Atentamente, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2166: attempted to update invisible tuple
> > I think EvalPlanQual is deciding that updated tuples are valid in > some cases where it shouldn't. Unfortunately, if that's correct it > means that all the branches are broken since last August :-( > >regards, tom lane > i reproduced it in 8.1.1, so i guess you are right in tell that old branches are broken... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2144: Domain NOT NULL constraints ignored in rules
On 1/7/06, John Supplee <[EMAIL PROTECTED]> wrote: > Tom Lane wrote: > > > OK, got it. Patch for 8.1 is attached if you need it. > > Thanks for the test case. > > Wow, thanks for the quick work. But since I can solve the problem with NOT > NULL constraints directly on the column I will wait for the next release to > test it (I don't have the source on my machine). > > BTW, I also observed the same behavior in 8.0.5 as well. > > > John Supplee > of course. Tom backpatch all branches until 7.3... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2152: psql crash reproducible
On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Andreas Kretschmer" <[EMAIL PROTECTED]> writes:
> > test=# select x from (select extract(dow from ('2006/01/01'::date +
> > (generate_series(0,10)||'days')::interval)::date)) x;
> > server closed the connection unexpectedly
>
> Works for me as of 8.1 branch tip, so the fix is in either 8.1.1 or
> 8.1.2.
>
>regards, tom lane
>
must be in 8.1.2 because i'm saying the same error in 8.1.1
--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [BUGS] autovacuum process (PID ...) was terminated by signal 11
On 1/4/06, Michael Fuhr <[EMAIL PROTECTED]> wrote: > On Wed, Jan 04, 2006 at 12:20:28PM -0500, Jaime Casanova wrote: > > On 1/4/06, Brian Hirt <[EMAIL PROTECTED]> wrote: > > > that's strange, because I'm running 8.1.1. > > > > what Tom is saying is that a patch was applied after 8.1.1 was > > launched... > > Is that what Tom is saying? The commit message he posted had a > date of 2005-11-28; 8.1.1 wasn't tagged until 2005-12-08. > > -- > Michael Fuhr > sorry... you are right... my memory is not as good as some years ago... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] autovacuum process (PID ...) was terminated by signal 11
On 1/4/06, Brian Hirt <[EMAIL PROTECTED]> wrote: > that's strange, because I'm running 8.1.1. > what Tom is saying is that a patch was applied after 8.1.1 was launched... it will be fixed in 8.1.2 and if you are installing from sources you can apply yourself the patch to your tree source recompile and you will have your problem solved now... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2143: Indexes incorrectly created from database dump
On 1/4/06, Robert Osowiecki <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 2143 > Logged by: Robert Osowiecki > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.1 > Operating system: Linux 2.6.14-gentoo-r5 #2 SMP Thu Dec 22 11:58:01 CET > 2005 i686 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux > Description:Indexes incorrectly created from database dump > Details: > > I've got this indexes on my table: >primary key >"unique_code_i" UNIQUE, btree (ar_code, ... 6 int fields) >"pattern_i" btree (ar_code varchar_pattern_ops) > > Immediately after restoring from SQL dump with pg_sql, unique_code_i index > is buggy. When I read: > > select * from my_table where ar_code like 'FOO' > > postgres uses pattern_i and returns all requested rows. > > BUT when on "where ar_code = 'FOO'" unique_code_i index is used and query > returns NO ROWS! > > The bug dissapears after REINDEX and does not apper when doing data-only > restore on empty database structure. > > Please, help. I'll gladly provide any additional information as sonn as I > know where to look. > > Robert > > PS. Spotting that kind of bug on production database (as it was i my case) > can really spoil a day :) > Last year come up an issue with similar behaviour (maybe the same problem)... http://archives.postgresql.org/pgsql-general/2005-12/msg00740.php IRC, there was a patch made for this... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2139: Problem when calling functions without any argument
On 1/3/06, Jacques Gollion <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 2139 > Logged by: Jacques Gollion > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.1 > Operating system: Windows 2000 > Description:Problem when calling functions without any argument > Details: > > have have written some functions without any argument. When my powerbuilder > V9 application calls these functions, the behaviour is different : > > *Using ODBC driver, it works well > *Using JDBC driver (I tried several versions), I get the error message > "ERROR : Syntax error at or near $1. If I add a unused argument to the > function; it works. > If I call in JDBC the same function for Oracle or Sybase, it works. > If I call other PostGreSQL functions with arguments, it works. > > Where am I wrong ? > > Thanks in advance for your help. > and... where is the function? how is defined? how do you use it? code, please wiyhout that you can't expect any help... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
