Re: [GENERAL] pg_restore misuse or bug?

Assuming you have a user called "test", this will create a database that suffers from this problem. create database mvtest; \c mvtest create table main_table (id serial not null, something varchar(20), primary key (id)); create table child_table (id serial not null, parent_id int not null,

Re: [GENERAL] pg_restore misuse or bug?

This is on version 9.5, 9.6 and 10beta2. I could probably make a test-case over the weekend if I'm at home. On 21 July 2017 at 17:03, Tom Lane wrote: > Jordan Gigov writes: >> When running pg_restore as the superuser it gives the following error >>

Re: [GENERAL] pg_restore misuse or bug?

Jordan Gigov writes: > When running pg_restore as the superuser it gives the following error > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 3253; 0 320628 > MATERIALIZED VIEW DATA combined_query_data web_user >

[GENERAL] pg_restore misuse or bug?

So we have this database dump created using "pg_dump -Fc ourdb > file.dump" that has a Materialized View that gets refreshed under certain conditions by our Java web-app. When running pg_restore as the superuser it gives the following error pg_restore: [archiver (db)] Error while PROCESSING TOC:

Re: [GENERAL] (Might be a bug) locale issue while upgrading data directory from PostgreSQL 8.4 to 9.5

The setups were downloaded from postgresql site only. On Jul 7, 2017 7:12 PM, "Adrian Klaver" wrote: On 07/06/2017 11:13 PM, Mayank Agrawal wrote: > No, windows has not been upgraded (Windows 7). Moreover, I think it is not > related to windows version, because I

Re: [GENERAL] (Might be a bug) locale issue while upgrading data directory from PostgreSQL 8.4 to 9.5

On 07/06/2017 11:13 PM, Mayank Agrawal wrote: No, windows has not been upgraded (Windows 7). Moreover, I think it is not related to windows version, because I tried the scenarios from scratch on a same machine and on a some windows version. While working on this issue I notices something.

Re: [GENERAL] (Might be a bug) locale issue while upgrading data directory from PostgreSQL 8.4 to 9.5

No, windows has not been upgraded (Windows 7). Moreover, I think it is not related to windows version, because I tried the scenarios from scratch on a same machine and on a some windows version. While working on this issue I notices something. Details are as follows: On Windows7, I installed the

Re: [GENERAL] (Might be a bug) locale issue while upgrading data directory from PostgreSQL 8.4 to 9.5

On 07/04/2017 10:23 PM, Mayank Agrawal wrote: Hello, I am upgrading PostgreSQL 8.4 to 9.5 on Windows. There is some issue related to locale. Details are as follows: The steps that I am following are: 1. Install PostgreSQL 9.5 (8.4 is already installed). 2. Migrate data from 8.4's data dir

[GENERAL] (Might be a bug) locale issue while upgrading data directory from PostgreSQL 8.4 to 9.5

Hello, I am upgrading PostgreSQL 8.4 to 9.5 on Windows. There is some issue related to locale. Details are as follows: The steps that I am following are: 1. Install PostgreSQL 9.5 (8.4 is already installed). 2. Migrate data from 8.4's data dir to 9.5's data dir using pg_upgrade utility. 3.

[GENERAL] [SQL] Q: documentation bug ?

Hello all, the online documentation for REINDEX http://www.postgresql.org/docs/9.5/static/sql-reindex.html talks about VERBOSE Synopsis REINDEX [ ( { VERBOSE } [, ...] ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } name [...] VERBOSE

Re: [GENERAL] [SQL] Q: documentation bug ?

On Thu, Feb 04, 2016 at 12:00:45PM +0100, Vik Fearing wrote: >> REINDEX [ ( { VERBOSE } [, ...] ) ] { INDEX | TABLE | SCHEMA | DATABASE >> | SYSTEM } name ... >> Does this constitute a bug in the documentation or in the Debian version of >> PG ? > > Neither. It's a little bit obscure

Re: [GENERAL] [SQL] Q: documentation bug ?

On 04-02-2016 08:53, Karsten Hilbert wrote: > Hello all, > > the online documentation for REINDEX > > http://www.postgresql.org/docs/9.5/static/sql-reindex.html > > talks about VERBOSE > > Synopsis > > REINDEX [ ( { VERBOSE } [, ...] ) ] { INDEX | TABLE | SCHEMA | DATABASE

Re: [GENERAL] [SQL] Q: documentation bug ?

Karsten Hilbert writes: > On Thu, Feb 04, 2016 at 12:00:45PM +0100, Vik Fearing wrote: >>> REINDEX [ ( { VERBOSE } [, ...] ) ] { INDEX | TABLE | SCHEMA | DATABASE | >>> SYSTEM } name >>> Does this constitute a bug in the documentation or in the Debian version of >>> PG

[GENERAL] PSA: linux kernel bug in TRIM support corrupts data with md raid levels 0 and 10

http://www.spinics.net/lists/raid/msg49452.html (via slashdot) merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Row count estimation bug in BETWEEN?

Tom Lane-2 wrote The assumption is that the histogram represents a continuous distribution of values in which no one value occurs often enough to be interesting (if it did, it would be in the MCV list...). Therefore it does not matter much whether any specific histogram entry is exactly =.

Re: [GENERAL] Row count estimation bug in BETWEEN?

My simple test (using MCVs) is below ... I've posted wrong second query in the test, should have been: EXPLAIN SELECT * FROM t2 WHERE n = 0 AND n = 2 -- rows=12 - WBR, Yaroslav Schekin. -- View this message in context:

Re: [GENERAL] Row count estimation bug in BETWEEN?

Yaroslav ladayaros...@yandex.ru writes: Tom Lane-2 wrote PG doesn't try to estimate inequalities exactly, because it usually doesn't make enough of a difference to matter. Currently we don't even bother to distinguish say from = for estimation purposes, though certainly we would need to in

Re: [GENERAL] Row count estimation bug in BETWEEN?

=?koi8-r?B?/cXLyc4g8dLP08zB1w==?= ladayaros...@yandex.ru writes: I've noticed strange row count estimations in BETWEEN predicate: EXPLAIN SELECT * FROM t1 WHERE f1 = 42; -- Bitmap Heap Scan on t1 (cost=203.07..28792.94 rows=10662 width=24) skipped EXPLAIN SELECT * FROM t1

[GENERAL] Row count estimation bug in BETWEEN?

Hi. I've noticed strange row count estimations in BETWEEN predicate: -- -- I'm using this: SELECT version(); -- PostgreSQL 9.4.1, compiled by Visual C++ build 1800, 32-bit -- Prepare table: CREATE TABLE t1 ( id bigserial NOT NULL, f0 bigint NOT NULL, f1 bigint NOT NULL, CONSTRAINT t1_pkey

Re: [GENERAL] Row count estimation bug in BETWEEN?

Tom Lane-2 wrote PG doesn't try to estimate inequalities exactly, because it usually doesn't make enough of a difference to matter. Currently we don't even bother to distinguish say from = for estimation purposes, though certainly we would need to in order to deal with zero-width ranges

Re: [GENERAL] Sequences not created, bug in pg_dump?

On 03/20/2015 10:21 AM, Leonardo M. Ramé wrote: El 19/03/15 a las 14:13, Adrian Klaver escibió: On 03/19/2015 10:02 AM, Leonardo M. Ramé wrote: El 19/03/15 a las 13:09, Adrian Klaver escibió: On 03/19/2015 08:43 AM, Leonardo M. Ramé wrote: Hi, I'm creating a database dump excluding one

Re: [GENERAL] Sequences not created, bug in pg_dump?

El 19/03/15 a las 14:13, Adrian Klaver escibió: On 03/19/2015 10:02 AM, Leonardo M. Ramé wrote: El 19/03/15 a las 13:09, Adrian Klaver escibió: On 03/19/2015 08:43 AM, Leonardo M. Ramé wrote: Hi, I'm creating a database dump excluding one table and found only the sequences created

Re: [GENERAL] Sequences not created, bug in pg_dump?

On 03/19/2015 10:02 AM, Leonardo M. Ramé wrote: El 19/03/15 a las 13:09, Adrian Klaver escibió: On 03/19/2015 08:43 AM, Leonardo M. Ramé wrote: Hi, I'm creating a database dump excluding one table and found only the sequences created implicitly (using serial type) are created when I restore

Re: [GENERAL] Sequences not created, bug in pg_dump?

El 19/03/15 a las 13:09, Adrian Klaver escibió: On 03/19/2015 08:43 AM, Leonardo M. Ramé wrote: Hi, I'm creating a database dump excluding one table and found only the sequences created implicitly (using serial type) are created when I restore the dump. The command I use is: pg_dump -T

Re: [GENERAL] Sequences not created, bug in pg_dump?

On 03/19/2015 08:43 AM, Leonardo M. Ramé wrote: Hi, I'm creating a database dump excluding one table and found only the sequences created implicitly (using serial type) are created when I restore the dump. The command I use is: pg_dump -T table_to_be_excluded mydb I understand all related

[GENERAL] Sequences not created, bug in pg_dump?

Hi, I'm creating a database dump excluding one table and found only the sequences created implicitly (using serial type) are created when I restore the dump. The command I use is: pg_dump -T table_to_be_excluded mydb I understand all related objects to the table to be excluded are not

[GENERAL] Re: There is bug in PCS 0.9.26: configure pacemaker resource agent for PG stream replication

Michael Paquier wrote On Fri, Mar 7, 2014 at 3:32 PM, leo lt; dazhoufei@ gt; wrote: I just complete my HA configuration on Redhat 6.4 enterprise: Clusterware: Pacemaker 1.1.8 ( CMAN .0.12.1, corosync 1.4.1 ) Resource manager: PCS 0.9.26 PostgreSQL 9.3.3.1

Re: [GENERAL] Is this a bug in ECPG?

2013-09-06 09:57 keltezéssel, Boszormenyi Zoltan írta: 2013-09-06 02:57 keltezéssel, Wang, Jing írta: Hi, ECPG don't support the following scenario: char cur_name = cur1; EXEC SQL DECLARE :cur_name CURSOR FOR ... EXEC SQL OPEN :cur_name; EXEC SQL FETCH cur1 INTO... ... EXEC SQL CLOSE

Re: [GENERAL] Is this a bug in ECPG?

2013-09-06 02:57 keltezéssel, Wang, Jing írta: Hi, ECPG don't support the following scenario: char cur_name = cur1; EXEC SQL DECLARE :cur_name CURSOR FOR ... EXEC SQL OPEN :cur_name; EXEC SQL FETCH cur1 INTO... ... EXEC SQL CLOSE :cur_name; An compile error will occur for above codes

[GENERAL] Is this a bug in ECPG?

Hi, ECPG don't support the following scenario: char cur_name = cur1; EXEC SQL DECLARE :cur_name CURSOR FOR ... EXEC SQL OPEN :cur_name; EXEC SQL FETCH cur1 INTO... ... EXEC SQL CLOSE :cur_name; An compile error will occur for above codes because ECPG can't find the cur1.

[GENERAL] JDBC XA resource bug?

There is a view named pg_prepared_xacts which contains list of prepared transactions in all databases of current instance. PGXAConnection uses following query to retrive prepared transactions: SELECT gid FROM pg_prepared_xacts. Shouldn't it be the following: SELECT gid FROM pg_prepared_xacts

[GENERAL] Fw: Re: [BUGS] BUG #6099: Does pgcluster support hibernate?

2011-07-11 赵伟宇 北京英泰伟业通信技术开发有限公司 运行维护部 地址：北京市宣武区新居东里4号楼鼎元国际中心 (100055) Tel：010-63263322-8676Mobile：18701380311 Fax：010-63285517 E-mail：zha...@iwgroup.com.cn 本邮件可能含有机密内容，非指定收件人请勿打开、复印本邮件或依赖本邮件的内容而采取任何行动。若误收到本邮件，请立即通知发件人并删除本邮件及其附件。 This message may contain privileged and confidential

Re: [GENERAL] Fw: Re: [BUGS] BUG #6099: Does pgcluster support hibernate?

On 11/07/2011 12:54 PM, 赵伟宇 wrote: 2011-07-1 Your message was empty except for a signature, this date, and forwarded message content. You seem to have forwarded a question you submitted using the bug report from the pgsql-bugs list to pgsql-general. Was that intentional? As I asked in my

[GENERAL] missing chunk number (Bug 5507)

I found this link: http://postgresql.1045698.n5.nabble.com/BUG-5507-missing-chunk-number-0-for-toast-value-X-in-pg-toast-X-td2126674.html And am also experiencing the same issue... More anecdotal evidence that this is a bug: We recently(couple days ago) completely recreated the DB, and

Re: [GENERAL] Is there a bug in FOR i IN 1..10 LOOP (8.4.4)?

What makes you think there is a bug? What does this function return for you? It always helps us to see everything you have seen. Without taking the time to try it on my system, I'd recommend explictly converting your index to text: num_var := num_var || ',' || i::text; RobR -- Sent via

Re: [GENERAL] Is there a bug in FOR i IN 1..10 LOOP (8.4.4)?

Woops, figured it out. Just needed to declare the num_var := ''; On Sep 11, 10:45 pm, Nick nboutel...@gmail.com wrote: CREATE FUNCTION test() RETURNS text     LANGUAGE plpgsql     AS $$DECLARE   num_var TEXT; BEGIN   FOR i IN 1..10 LOOP     num_var := num_var || ',' || i;   END LOOP;  

[GENERAL] Is there a bug in FOR i IN 1..10 LOOP (8.4.4)?

CREATE FUNCTION test() RETURNS text LANGUAGE plpgsql AS $$DECLARE num_var TEXT; BEGIN FOR i IN 1..10 LOOP num_var := num_var || ',' || i; END LOOP; RETURN num_var; END;$$; SELECT test(); returns NULL -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To

[GENERAL] psql exit code, bug ?

http://gj.pastebin.com/f119e67bc Looks like psql loves to report on errors, only when -c is used, otherwise return code is always 0... I tested 8.3 and cvs-head, both have the same issue. Is that the 'by design' (bug/feature) ? -- GJ -- Sent via pgsql-general mailing list

Re: [GENERAL] psql exit code, bug ?

=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes: Looks like psql loves to report on errors, only when -c is used, otherwise return code is always 0... The documentation seems perfectly clear on this point: psql returns 0 to the shell if it finished normally, 1 if a fatal error of

Re: [GENERAL] psql exit code, bug ?

2009/9/16 Tom Lane t...@sss.pgh.pa.us: =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= gryz...@gmail.com writes: Looks like psql loves to report on errors, only when -c is used, otherwise return code is always 0... The documentation seems perfectly clear on this point: psql returns 0 to the shell if

[GENERAL] Is this a bug or a feature? Column visibility in subquery from outer query

postgres=# create table public.ps_test_x (x1 oid, x2 oid, x3 oid); CREATE TABLE postgres=# create table public.ps_test_y (y1 oid, y2 oid, y3 oid); CREATE TABLE postgres=# explain select * from public.ps_test_x where x1 in (select x1 from public.ps_test_y); QUERY PLAN

Re: [GENERAL] Is this a bug or a feature? Column visibility in subquery from outer query

Paolo Saul paolo.s...@telogis.com writes: I just want to point out that the sub-query is using a column from the outer query (eg. x1) without an alias from the table in the outer query. This behavior is required by the SQL standard. It's called an outer reference.

Re: [GENERAL] Is this a bug or a feature? Column visibility in subquery from outer query

Thank you for clearing that up. Regards, Paolo Saul This behavior is required by the SQL standard. It's called an outer reference. regards, tom lane

[GENERAL] postgres silent install bug?

Hello everyone, I am trying to run a silent install of Postgres 8.3 using the following command line: MSIEXEC /i postgresql-8.3-int.msi /qb /log c:\mydir\logfile.txt ADDLOCAL=server,nls,psql,pgadmin,includefiles,libfiles,binfiles INTERNALLAUNCH=1 DOSERVICE=1 CREATESERVICEUSER=0 DOINITDB=1

Re: [GENERAL] is it a bug in rule system?

It's not a bug, just your misunderstanding of how rules work. Rules rewrite queries. What happen in your case is because of the condition your query will be split into two: once with your INSERT with a NOT EXISTS (subquery) and once as an UPDATE with the condition EXISTS (subquery). So the

Re: [GENERAL] is it a bug in rule system?

laser wrote: It's not a bug, just your misunderstanding of how rules work. Rules rewrite queries. What happen in your case is because of the condition your query will be split into two: once with your INSERT with a NOT EXISTS (subquery) and once as an UPDATE with the condition EXISTS

[GENERAL] is it a bug in rule system?

hi all, see query below: create table ruleTest(id integer, name text); create or replace rule ruleTest_insert_rule AS on insert to ruleTest where exists(select 1 from ruleTest where ruleTest.name = NEW.name) do instead (update ruleTest set id = id+1 where ruleTest.name = NEW.name); create

Re: [GENERAL] is it a bug in rule system?

am Wed, dem 28.05.2008, um 15:56:22 +0800 mailte laser folgendes: hi all, see query below: create table ruleTest(id integer, name text); create or replace rule ruleTest_insert_rule AS on insert to ruleTest where exists(select 1 from ruleTest where ruleTest.name = NEW.name) do instead

Re: [GENERAL] is it a bug in rule system?

On Wed, May 28, 2008 at 04:59:33PM +0800, laser wrote: Yes, use a TRIGGER instead a RULE for such tasks. thanks, good to know it's a bug and we'll try TRIGGER approach. It's not a bug, just your misunderstanding of how rules work. Rules rewrite queries. What happen in your case is because of

Re: [GENERAL] is it a bug in rule system?

A. Kretschmer wrote: am Wed, dem 28.05.2008, um 15:56:22 +0800 mailte laser folgendes: hi all, see query below: create table ruleTest(id integer, name text); create or replace rule ruleTest_insert_rule AS on insert to ruleTest where exists(select 1 from ruleTest where ruleTest.name =

Re: [GENERAL] Is this a bug? (changing sequences in default value)

En un mensaje anterior, Merlin Moncure escribió: [...] Am I doing something wrong? yes and no when you created the table initially you probably made it a 'serial' column which set up the ownership that prevents the drop operation. that ownership did not go away when you altered the

Re: [GENERAL] Is this a bug? (changing sequences in default value)

On Tue, May 13, 2008 at 8:50 AM, Fernando Schapachnik [EMAIL PROTECTED] wrote: ALTER SEQUENCE name [ INCREMENT [ BY ] increment ] [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ] [ RESTART [ WITH ] start ] [ CACHE cache ] [ [ NO ] CYCLE ] oop, you

Re: [GENERAL] Is this a bug? (changing sequences in default value)

En un mensaje anterior, Merlin Moncure escribió: On Tue, May 13, 2008 at 8:50 AM, Fernando Schapachnik [EMAIL PROTECTED] wrote: ALTER SEQUENCE name [ INCREMENT [ BY ] increment ] [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ] [ RESTART [ WITH ]

[GENERAL] Is this a bug? (changing sequences in default value)

Pg 8.1.11, I try to change sequences as default value of a table, then remove old sequence: # \d table1 Table table1 Column | Type | Modifiers +-+--- id |

Re: [GENERAL] Is this a bug? (changing sequences in default value)

On Thu, May 8, 2008 at 7:52 AM, Fernando Schapachnik [EMAIL PROTECTED] wrote: Pg 8.1.11, I try to change sequences as default value of a table, then remove old sequence: # \d table1 Table table1 Column | Type | Modifiers

Re: [GENERAL] Is this a bug? (changing sequences in default value)

En un mensaje anterior, Merlin Moncure escribió: On Thu, May 8, 2008 at 7:52 AM, Fernando Schapachnik [EMAIL PROTECTED] wrote: Pg 8.1.11, I try to change sequences as default value of a table, then remove old sequence: # \d table1 Table table1 Column |

Re: [GENERAL] Is this a bug? (changing sequences in default value)

On Fri, May 9, 2008 at 8:55 AM, Fernando Schapachnik [EMAIL PROTECTED] wrote: En un mensaje anterior, Merlin Moncure escribió: On Thu, May 8, 2008 at 7:52 AM, Fernando Schapachnik [EMAIL PROTECTED] wrote: Pg 8.1.11, I try to change sequences as default value of a table, then remove old

Re: [GENERAL] --enable-thread-safety bug

Craig Ringer wrote: Steve Clark wrote: I guess the real question is why we are running out of memory when this option is enabled. Since my app doesn't use threads that points to a memory leak in the ecpg library when enable thread safety is turned on. It might be worth building ecpg with

Re: [GENERAL] --enable-thread-safety bug

Steve Clark [EMAIL PROTECTED] writes: I could do that - but in my situation I am not using threads so I really don't need --enable-thread-safety turned on. The freebsd ports maintainer for postgresql decided everybody should have it whether they needed it or not. I simply deleted the option

Re: [GENERAL] --enable-thread-safety bug

On Sat, Mar 22, 2008 at 04:58:28PM -0400, Steve Clark wrote: Not exactly sure what you are asking about - descriptors and auto allocating. So I guess you don't use either feature. :-) The program processes about 80 packets a day, which can update several tables. It runs continously

Re: [GENERAL] --enable-thread-safety bug

Michael Meskes wrote: On Sat, Mar 22, 2008 at 04:58:28PM -0400, Steve Clark wrote: Not exactly sure what you are asking about - descriptors and auto allocating. So I guess you don't use either feature. :-) The program processes about 80 packets a day, which can update several

Re: [GENERAL] --enable-thread-safety bug

Tom Lane wrote: Steve Clark [EMAIL PROTECTED] writes: The return from malloc should be checked to make sure it succeeds - right??? Probably, but what do you expect the code to do if it doesn't succeed? This function seems not to have any defined error-return convention.

Re: [GENERAL] --enable-thread-safety bug

On Sat, Mar 22, 2008 at 11:28:24AM -0400, Steve Clark wrote: Retry - the malloc - maybe there is a memory leak when --enable-thread-saftey is enabled, send an out of memory message to the postgres log, abort the transaction - I don't know I am not a postgres developer so I don't know all

Re: [GENERAL] --enable-thread-safety bug

Martijn van Oosterhout [EMAIL PROTECTED] writes: Note this is your in application, not the server. Only your program died. Ofcourse the transaction got aborted, since the client (you) disconnected. There is no way for this to write to the server log, since it may be one another machine...

Re: [GENERAL] --enable-thread-safety bug

Tom Lane wrote: Martijn van Oosterhout [EMAIL PROTECTED] writes: Note this is your in application, not the server. Only your program died. Ofcourse the transaction got aborted, since the client (you) disconnected. There is no way for this to write to the server log, since it may be one another

Re: [GENERAL] --enable-thread-safety bug

Martijn van Oosterhout wrote: On Sat, Mar 22, 2008 at 11:28:24AM -0400, Steve Clark wrote: Retry - the malloc - maybe there is a memory leak when --enable-thread-saftey is enabled, send an out of memory message to the postgres log, abort the transaction - I don't know I am not a postgres

Re: [GENERAL] --enable-thread-safety bug

On Sat, Mar 22, 2008 at 12:42:51PM -0400, Tom Lane wrote: Do you create and destroy a lot of threads since it seems this memory won't be freed? The OP's program isn't threaded at all, since he was apparently running with a non-threaded ecpg/libpq before. This means that the proposal of

Re: [GENERAL] --enable-thread-safety bug

On Sat, Mar 22, 2008 at 12:51:30PM -0400, Steve Clark wrote: My program had no threads - as I pointed out if I change the default Makefile in the FreeBSD ports system to not enable thread safety my programs runs just fine for days on end. It appears to me without any kind of close

Re: [GENERAL] --enable-thread-safety bug

Michael Meskes wrote: On Sat, Mar 22, 2008 at 12:51:30PM -0400, Steve Clark wrote: My program had no threads - as I pointed out if I change the default Makefile in the FreeBSD ports system to not enable thread safety my programs runs just fine for days on end. It appears to me without any

Re: [GENERAL] --enable-thread-safety bug

Steve Clark wrote: Michael Meskes wrote: On Sat, Mar 22, 2008 at 12:51:30PM -0400, Steve Clark wrote: My program had no threads - as I pointed out if I change the default Makefile in the FreeBSD ports system to not enable thread safety my programs runs just fine for days on end. It

Re: [GENERAL] --enable-thread-safety bug

Steve Clark wrote: I guess the real question is why we are running out of memory when this option is enabled. Since my app doesn't use threads that points to a memory leak in the ecpg library when enable thread safety is turned on. It might be worth building ecpg with debug symbols then

[GENERAL] --enable-thread-safety bug

Hello List, I am running 8.3.1 on FreeBSD 6.2 patch-7. The ports for Freebsd turn on --enable-thread-safety during configure of pg. When running my app after some time I have been getting a core dump - sig 11. #0 0x28333b96 in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x28333b96 in

Re: [GENERAL] --enable-thread-safety bug

Steve Clark [EMAIL PROTECTED] writes: The return from malloc should be checked to make sure it succeeds - right??? Probably, but what do you expect the code to do if it doesn't succeed? This function seems not to have any defined error-return convention. regards, tom

[GENERAL] possible psql \d bug in 8.3 beta2

Is seems that \d is missing the following entry when I set search_path to display two schemas: List of relations Schema |Name | Type | Owner -+-+---+-- project | managers| table | teaminst instrumentation= select version();

Re: [GENERAL] possible psql \d bug in 8.3 beta2

Richard Broersma Jr [EMAIL PROTECTED] writes: Is seems that \d is missing the following entry when I set search_path to display two schemas: List of relations Schema |Name | Type | Owner -+-+---+-- project | managers| table |

Re: [GENERAL] possible psql \d bug in 8.3 beta2

--- On Sun, 12/23/07, Tom Lane [EMAIL PROTECTED] wrote: -+-+---+-- project | managers| table | teaminst It's hidden by the managers table in the earlier history schema. \d without any particular schema specification will only show tables that could

[GENERAL] Is this a bug? Insert float into int column inserts rounded value instead of error.

List, One of the reasons why I use postgres is because you can insert data and it will work or give you an error instead of converting, truncating, etc... well I found a place where postgres makes an erroneous assumption and I'm not sure this is by design. When inserting a float such as

Re: [GENERAL] Is this a bug? Insert float into int column inserts rounded value instead of error.

Matthew Schumacher [EMAIL PROTECTED] writes: template1=# create table test (number int); CREATE TABLE template1=# insert into test (number) values (4.123123123); INSERT 0 1 Perhaps you'd be happier doing it like this: regression=# insert into test (number) values ('4.123123123'); ERROR:

Re: [GENERAL] Is this a bug? Insert float into int column inserts rounded value instead of error.

On Mon, Aug 27, 2007 at 12:48:34PM -0800, Matthew Schumacher wrote: When inserting a float such as 4.12322345 into a int column postgres inserts 4 instead of returning an error telling you that your value won't fit. I would much rather have the error and check for it since I can be sure I'll

Re: [GENERAL] Is this a bug?

Harry Jackson wrote: The following sql statement fails because the column user_id does not exist in the users table. =# select user_id from users WHERE username = 'blah'; ERROR: column user_id does not exist LINE 1: select user_id from users WHERE username = 'blah..

[GENERAL] Is this a bug?

The following sql statement fails because the column user_id does not exist in the users table. =# select user_id from users WHERE username = 'blah'; ERROR: column user_id does not exist LINE 1: select user_id from users WHERE username = 'blah.. ^ The following shows a

Re: [GENERAL] Is this a bug?

Harry Jackson [EMAIL PROTECTED] writes: If I made a mistake and changed the id column to user_id then from some the statement executes. =# delete from map_users_roles where user_id = (select user_id from users WHERE username = 'blah'); This is a standard outer reference construction, ie,

[GENERAL] Bug o not bug in subqueries

I have one table. create table u ( id integer, __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ ---(end of

Re: [GENERAL] Is this a bug? Sequences and rules

Chris Travers wrote: Hi; I noticed that rules were not behaving properly. I created a test case, and it looks like the sequence is getting double-incrimented. Is this the way this is supposed to work? I know triggers would be better for something like this but I find these results...

Re: [GENERAL] Is this a bug? Sequences and rules

am Tue, dem 10.04.2007, um 22:49:27 -0700 mailte Chris Travers folgendes: Hi; I noticed that rules were not behaving properly. I created a test case, and it looks like the sequence is getting double-incrimented. Is this the way this is supposed to work? I know triggers would be

[GENERAL] Is this a bug? Sequences and rules

Hi; I noticed that rules were not behaving properly. I created a test case, and it looks like the sequence is getting double-incrimented. Is this the way this is supposed to work? I know triggers would be better for something like this but I find these results... surprising Version

Re: [GENERAL] Possible outer join bug with coalesce in 8.2

John McCawley [EMAIL PROTECTED] writes: My development machine is PostgreSQL 8.1.5, and my production machine is PostgreSQL 8.2. Until now I haven't run into any differences in behavior. I have a query with a relatively wacky join, and while it was working on my development machine, it

[GENERAL] Possible outer join bug with coalesce in 8.2

My development machine is PostgreSQL 8.1.5, and my production machine is PostgreSQL 8.2. Until now I haven't run into any differences in behavior. I have a query with a relatively wacky join, and while it was working on my development machine, it wouldn't work on the production machine. The

Re: [GENERAL] Possible outer join bug with coalesce in 8.2

John McCawley [EMAIL PROTECTED] writes: What exactly is going on here? EXPLAIN might shed some light. However, if you think this is a bug then you need to provide a self-contained test case. regards, tom lane ---(end of

[GENERAL] pg_dump design problem (bug??)

Postgresql 8.1.3 Hi, I'm wondering if there's a problem with pg_dump --create, or if I'm just missing something. It does not seem to restore things like: ALTER DATABASE foo SET DateStyle TO European; Shouldn't the database that is re-created be like the database that is being dumped? For our

[GENERAL] Insert/select union bug

create table temp(a timestamptz); insert into temp(a) select NULL; /* this passes */ insert into temp(a) select NULL union select NULL; /* fails: ERROR: column a is of type timestamp with time zone but expression is of type text */ I need to insert hundreds of thousands of rows, and insert

Re: [GENERAL] Insert/select union bug

On Wed, Sep 27, 2006 at 12:14:44PM +0300, Peter wrote: create table temp(a timestamptz); insert into temp(a) select NULL; /* this passes */ insert into temp(a) select NULL union select NULL; /* fails: ERROR: column a is of type timestamp with time zone but expression is of type text */

Re: [GENERAL] Insert/select union bug

Martijn van Oosterhout wrote: On Wed, Sep 27, 2006 at 12:14:44PM +0300, Peter wrote: create table temp(a timestamptz); insert into temp(a) select NULL; /* this passes */ insert into temp(a) select NULL union select NULL; /* fails: ERROR: column "a" is of type timestamp with time

Re: [GENERAL] Insert/select union bug

On Wed, Sep 27, 2006 at 01:05:56PM +0300, Peter wrote: Typecast eliminates the issue, you're right on that as well. However, my problem is that those statements are dynamically generated on various tables/columns, so typecasting would mean extracting target field type and translating

Re: [GENERAL] Insert/select union bug

Typecast eliminates the issue, you're right on that as well. However, my problem is that those statements are dynamically generated on various tables/columns, so typecasting would mean extracting target field type and translating fieldtype code into SQL typename. Rather messy.

Re: [GENERAL] Insert/select union bug

On Sep 27, 2006, at 20:39 , Peter wrote: Using COPY avoids this issue ofcourse, because there's a direct link to the table. Similarly, as of 8.2 it will be possible to do: INSERT INTO table (blah) VALUES (x,y,a),(f,d,g),(s,f,g), etc... Which will also avoid the issue. COPY wont work... my

Re: [GENERAL] Insert/select union bug

On Wed, Sep 27, 2006 at 02:39:13PM +0300, Peter wrote: COPY wont work... my list of columns for insert is also dynamically built and will never cover all fields in table. You don't have to include all columns for copy, just the fields you copy into, the rest should get the default. COPY table

Re: [GENERAL] pg_dump design problem (bug??)

So, what about it? I periodically encounter with the same problem. People (e.g. me :-) but not only) expect that when they use pg_dump to backup some database (either schema only or both schema and data), all database properties will be dumped and, then, restored. People think that this thing

Re: [GENERAL] pg_dump design problem (bug??)

On 06/27/2006 09:29:36 AM, Nikolay Samokhvalov wrote: So, what about it? I periodically encounter with the same problem. People (e.g. me :-) but not only) expect that when they use pg_dump to backup some database (either schema only or both schema and data), all database properties will be

Re: [GENERAL] pg_dump design problem (bug??)

On Tuesday 27 June 2006 11:10, Karl O. Pinc wrote: On 06/27/2006 09:29:36 AM, Nikolay Samokhvalov wrote: So, what about it? I periodically encounter with the same problem. People (e.g. me :-) but not only) expect that when they use pg_dump to backup some database (either schema only or

  1   2   3   >