Re: [BUGS] BUG #6270: Invalid string comparison if the string contains '+' or '-' sign.
Evgeniy Galkin unik...@gmail.com writes: I'm trying to compare two strings which are starting with '+' and '-' signs. And there is some strange behaviour. This is fairly standard if you're using a non-C locale. Try creating a fresh database with LC_COLLATE and LC_CTYPE set to 'C'. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6268: multiple update with on cascade
Roman Lytovchenko roman.lytovche...@gmail.com writes: Description:multiple update with on cascade Yeah, this is a bug all right, see my analysis at http://archives.postgresql.org/pgsql-hackers/2011-10/msg01361.php As a stopgap workaround, you could manually rename the triggers generated by the FK constraint so that they execute in the opposite order. Try a command like this to see the triggers on t2: regression=# select tgname, tgfoid::regproc from pg_trigger where tgrelid = 't2'::regclass order by 1; tgname |tgfoid +--- RI_ConstraintTrigger_53586 | RI_FKey_check_ins RI_ConstraintTrigger_53587 | RI_FKey_check_upd RI_ConstraintTrigger_53588 | RI_FKey_cascade_del RI_ConstraintTrigger_53589 | RI_FKey_cascade_upd (4 rows) (The numbers at the ends of the names will almost certainly be different for you.) You need to adjust the names so that the RI_FKey_check_upd trigger sorts after the one that calls RI_FKey_cascade_upd. For example, on my copy of your test case, update pg_trigger set tgname = 'RI_ConstraintTrigger_x53587' where tgname = 'RI_ConstraintTrigger_53587' and tgrelid = 't2'::regclass; followed by starting a fresh database session fixes it. (You'll need to be superuser to mess with the system catalogs directly like that.) Keep in mind that until we fix this in the source code, any freshly-created self-referential FK constraint is vulnerable to the same problem; in particular the problem would come back if you did a dump and reload. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] auto_explain causes cluster crash if pg_ctl reload is used (not pg_ctl restart)
bricklen brick...@gmail.com writes: The steps to reproduce are pretty simple. Set the following in the postgresql.conf file: shared_preload_libraries = 'pg_stat_statements,auto_explain' custom_variable_classes = 'auto_explain' auto_explain.log_min_duration = '10s' auto_explain.log_analyze = true auto_explain.log_buffers = true As the postgres user, issue pg_ctl reload pg_ctl status will now show that there is no running postmaster. This looks like the same thing as bug #6097, which is fixed in 9.0.5. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6267: Wrong results in pg_database_size
Maxim Boguk maxim.bo...@gmail.com writes: No other tablespaces exists as can be seen in output of: SELECT oid,spcname,spclocation,pg_size_pretty(pg_tablespace_size(spcname)) from pg_tablespace; oid | spcname | spclocation | pg_size_pretty ---++---+ 1663 | pg_default | | 21 MB 1664 | pg_global | | 1092 kB 16443 | main | /db/base/main | 124 GB However I seem to have found reason for such strange behavior. That is a duplicating link in pg_tblspc: postgres@db:~$ ls -la /var/lib/postgresql/9.0/main/pg_tblspc/ total 8 drwx-- 2 postgres postgres 4096 Jun 3 04:08 . drwx-- 12 postgres postgres 4096 Sep 28 17:08 .. lrwxrwxrwx 1 postgres postgres 13 Jun 6 14:39 16384 - /db/base/main lrwxrwxrwx 1 postgres postgres 13 Jun 3 04:08 16443 - /db/base/main I have no idea how could this happen. No crashes/power-offs and so on happens on that database for more then year. That is bizarre. DROP TABLESPACE should certainly have removed the symlink, so creating and dropping wouldn't explain this. The other really interesting thing here is that the second symlink, which must have been created later to judge by its OID, has an earlier filesystem timestamp. AFAIK, the timestamps on symlinks never change after creation. What I am suspicious of is that the 16384 symlink got restored by some filesystem-level backup/restore action. FWIW, 16384 is the first possible user-assigned OID, so assuming that that was real at all, the CREATE TABLESPACE for it would've had to be the very first user action in this cluster. What I surmise is that you created a tablespace (with OID 16384), and some time later you thought better of that and dropped and recreated it (now with OID 16443, so this wasn't all that long after initdb either), and then about three days after that, something took it upon itself to re-create the 16384 symlink. The only part of Postgres that could conceivably recreate a previously existing symlink is WAL replay, but if you've not had any database crashes then a theory involving WAL replay seems to be foreclosed. Anyway it's hard to believe that a crash would replay events as old as three days. Can the second (16384 - /db/base/main) link be safely deleted? If there's no matching entry in pg_tablespace then it should be junk. But you might want to check for pg_class entries with reltablespace = 16384 before pulling the trigger. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6264: Superuser does not have inherent Replication permission
Keith Fiske ke...@omniti.com writes: The documentation says replication is inherent to a superuser. What it actually says is that superusers get the replication privilege by default --- but you can create a superuser without that. If you see a place that says something different, please point it out specifically so we can improve it. After testing several times, I can assure you it is not. Please show your test case. It looks to me like it works as expected: regression=# create user foo superuser; CREATE ROLE regression=# create user foo2 superuser noreplication; CREATE ROLE regression=# select rolname,rolsuper,rolreplication from pg_authid ; rolname | rolsuper | rolreplication --+--+ postgres | t| t foo | t| t foo2 | t| f (3 rows) If you create a user as a NONsuperuser, then later ALTER them to be one, they will NOT have the replication permission and cannot be used as a replication user until you explicitly grant that permission. That doesn't sound to me like a bug. These flags are independent, we just provide a certain default at role creation time. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 'pg_ctl restart' confused about pathname to postgresql.conf
Josh Kupershmidt schmi...@gmail.com writes: You can run the test case stand-alone, though it's probably easier to see what's going on if you just copy-paste into your terminal: at the end you should wind up with your current directory /tmp/foo/. You should see that the last command, pg_ctl -D $DATADIR restart failed to start the server back up, complaining: postgres cannot access the server configuration file /tmp/foo/baz/postgresql.conf: No such file or directory even though $DATADIR is clearly set to /tmp/foo/bar/baz/ (N.B. directory bar has gone missing in the above error message). A pg_ctl -D $DATADIR start should work at this point, though. This seems like some bug in normalizing the absolute path to postgresql.conf. I think the reason it has a problem is that this is what's left in postmaster.opts: /home/tgl/pgsql/bin/postgres -D baz (which is an accurate representation of the command line from startup) and that -D switch gets fed to the postmaster as-is during restart. By and large, I would not recommend using a relative pathname to start the postmaster, unless you plan to start it from the same working directory every time. We could possibly avoid this by having pg_ctl try to absolute-ify the -D setting during postmaster start, but I'm not convinced it's worth the trouble, or even that it's appropriate for pg_ctl to editorialize on the user's choice of absolute vs relative path. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6262: while installing postgis in make install leavingdirectory
Maruthi Kiran mnandi...@avineonindia.com writes: make[1]: Entering directory `/usr/postgis-1.5.3/postgis' Makefile.pgxs:17: warning: overriding recipe for target `install' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:92: warning: ignoring old recipe for target `install' Makefile.pgxs:63: warning: overriding recipe for target `installdirs' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:140: warning: ignoring old recipe for target `installdirs' Makefile.pgxs:82: warning: overriding recipe for target `uninstall' /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk:164: warning: ignoring old recipe for target `uninstall' make[1]: Nothing to be done for `all'. You probably need to report that to the postgis folk, not here. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
Valentine Gogichashvili val...@gmail.com writes: And, ernestly, if it were useless to have SELECT without INTO in plpgsql, there also would be no PERFORM command in plpgsql... Precisely. Pavel's claim is nonsense. The only real question is how useful is it to call it PERFORM instead of SELECT. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6263: \l causes core dump with large database
Robert Messer bob.mes...@l-3com.com writes: postgres=# \l *** glibc detected *** /opt/PostgreSQL/9.1/bin/psql.bin: realloc(): invalid next size: 0x19510a20 *** Well, this is interesting, but you're going to need to provide enough information to let someone else duplicate it. large database means little, and it certainly doesn't explain why you're seeing it when nobody else has reported any such thing. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6263: \l causes core dump with large database
bob.mes...@l-3com.com writes: 2) If I replace the libedit.so with the version in this rpm: libedit-2.11-2.20080712cvs.el5.x86_64.rpm, the command works. 3) if I edit the psql script to use the libreadline.so that is installed on the system (it's looking in the wrong place), the command works. In that case you're dealing with a libedit bug. libedit has a lot of known problems, especially if you're trying to use an old version as it sounds like you might be. There's not a lot we can do about that. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6263: \l causes core dump with large database
bob.mes...@l-3com.com writes: I am talking about the one that is installed in the PostgreSQL/lib folder, not the one from the operating system. Well, you need to be complaining to whoever provided that build of Postgres, which is not the upstream project ... and it is definitely not me personally, so replying only to me isn't going to get you anywhere. Please keep the list cc'd when replying. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
Pavel Stehule pavel.steh...@gmail.com writes: I didn't design a PERFORM statement. There is two views - somebody from sybase's family know so SELECT without into is forwarded to client. This functionality is missing on Oracle's family. Is true so PERFORM statement is strange, but maybe it's open door for sybase's functionality that was not implemented ever. I cannot imagine that we'd ever make SELECT inside a plpgsql function act like that. Functions have no business directly transmitting information to the client; if they tried, they'd most likely just break the FE/BE protocol. There might be use for such a thing in a hypothetical real stored procedure language where the code is executing in a context entirely different from what Postgres functions run in ... but that language would be something different from plpgsql. I grant the argument that people coming from Sybase-ish DBs might be confused by this; but the current arrangement is also confusing lots of people, so I don't think that argument has all that much weight. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] incompatible pointer type
Robert Young yay...@gmail.com writes: As I tested, if you explicit appoint a union tag, the OpenBSD m4 and GNU m4 work identically. And This explicit definition just corresponding to the forward-declaration. As mentioned in http://www.gnu.org/s/bison/manual/html_node/Union-Decl.html This feature is a POSIX extension. I don't know what impact to other platform. So I suppose this should be the appropriate patch to solve this problem I don't think we're going to worry too much about making plpgsql cope with an m4 that's too old to support autoconf, which I gather is the case from the bison bug report thread I mentioned before. If you're going to be changing the source code or working from a git pull, you need to have reasonably non-broken tools. We do provide pre-made bison output in release tarballs, if you don't want to take the responsibility of having a non-buggy bison available. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
Merlin Moncure mmonc...@gmail.com writes: The point being, how do I convert any query to a non WITH variant so it can be PERFORM'd? Anyways, I always thought having to do perform at all was pretty weak sauce -- not sure why it's required. Possibly it was an Oracle compatibility thing ... anyone know PL/SQL well enough to say how this works there? I suppose you could argue that selecting a value and implicitly throwing it away is confusing to novices, but on the other hand I've seen a whole lot of novices confused by the need to write PERFORM instead of SELECT. I think it wouldn't be an unreasonable thing to just interpret a SELECT with no INTO clause as being a PERFORM (ie execute and discard results). Then we'd not have to do anything magic for commands starting with WITH. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Can't use WITH in a PERFORM query in PL/pgSQL?
I wrote: Merlin Moncure mmonc...@gmail.com writes: The point being, how do I convert any query to a non WITH variant so it can be PERFORM'd? Anyways, I always thought having to do perform at all was pretty weak sauce -- not sure why it's required. Possibly it was an Oracle compatibility thing ... anyone know PL/SQL well enough to say how this works there? After writing that, I remembered I had an old PL/SQL manual sitting about, so I took a look. So far as I can see, there is no PERFORM statement in PL/SQL, and no SELECT-without-INTO either; that is, the functionality of executing a SELECT and discarding the result simply isn't there. So at this point it looks like we made up PERFORM out of whole cloth, and we could just as easily choose to do it another way. Jan, do you remember anything about the reasoning for PERFORM? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] char(0)
Susanne Ebrecht susa...@2ndquadrant.com writes: On 17.10.2011 16:41, Andreas Pflug wrote: This is a little bit annoying on migration topics. While not move on to a cleaner approach during the migration and use a boolean not null? Sounds much too straight forward, not mysql-ish artistic enough... Depends if you want / are able to touch the application source code or not. If you're expecting to move a mysql application to postgres with zero source code changes, you're living in a fantasy world anyway ... but this difference is hardly likely to be your worst problem. AFAICT the SQL standard is perfectly clear on this. *Values* of type varchar can be of zero length, but that does not mean that you can *declare* a column to be varchar(0), and that NOTE says specifically that you can't. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] incompatible pointer type
Robert Young yay...@gmail.com writes:
Platform:
OpenBSD 4.9 GENERIC.MP#819 amd64 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
Hmm, what version of bison are you using? Because the ones I've dealt
with emit
typedef union YYSTYPE {
...
} YYSTYPE;
which makes the code correct as-is. Your proposed patch seems to me
to be making more assumptions about what bison will emit (specifically,
about the ordering of various code blocks) than what we're doing now.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] incompatible pointer type
Robert Young yay...@gmail.com writes: On Tue, Oct 18, 2011 at 18:22, Tom Lane t...@sss.pgh.pa.us wrote: Hmm, what version of bison are you using? # /usr/bin/bison -V bison (GNU Bison) 2.3 Written by Robert Corbett and Richard Stallman. Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # From: http://ftp.openbsd.org/pub/OpenBSD/4.9/packages/amd64/bison-2.3.tgz Interesting. I've got bison 2.3 on my Mac laptop, and it does what I expect (ie, it emits typedef union YYSTYPE ...). So do the oldest and newest bison versions I have handy (1.875 and 2.4.3), and both of their manuals specify that this is the expected behavior -- see http://www.gnu.org/s/bison/manual/html_node/Union-Decl.html about halfway down the page. A little bit of googling suggests that this is a bug or incompatibility with openbsd's m4 (a tool that bison relies on): http://comments.gmane.org/gmane.comp.parsers.bison.bugs/2708 That thread petered out without any clear resolution, but maybe you should check for m4 updates, or try installing GNU m4. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] incompatible pointer type
I wrote: A little bit of googling suggests that this is a bug or incompatibility with openbsd's m4 (a tool that bison relies on): http://comments.gmane.org/gmane.comp.parsers.bison.bugs/2708 Scratch that: closer reading of the page says that the complainant was not using some openbsd-specific copy of m4, but GNU m4 1.4.4, and that the problem is not reproducible with newer versions of m4. So what it seems to boil down to is get a newer m4. Especially if you've got 1.4.4. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] incompatible pointer type
Robert Young yay...@gmail.com writes: I've update my m4 to version 1.4.13 from: http://ftp.openbsd.org/pub/OpenBSD/4.9/packages/amd64/m4-1.4.13.tgz the problem solved perfectly! Just for the archives' sake, can you confirm which m4 version you had before? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6258: Lock Sequence
Laerson Keler laerson.ke...@lkmc.com.br writes: Dear Srs, good morning, I did the automatic update postgresql 8.4.9 and a function stopped working, I used the option select for update in a sequence and is now giving the following error can not lock rows in sequence ..., how can I enable the blocking of the sequence? Why did you do that, that is what were you trying to accomplish? It never did block nextval() on the sequence, for example. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6258: Lock Sequence
Laerson keler laerson.ke...@lkmc.com.br writes:
2011/10/17 Tom Lane t...@sss.pgh.pa.us
Laerson Keler laerson.ke...@lkmc.com.br writes:
Why did you do that, that is what were you trying to accomplish? It
never did block nextval() on the sequence, for example.
Tom Lane, good afternoon, I block the sequence not to miss the sequel, for
it not to be skipped if the insert to fail. My logic involves two triggers,
one before and one after. I give the first one in last_value select for
update in the sequence and insert after I run a select next_val ('sequence')
to place in the next issue, so the sequence in my table is no failure.
Well, that's a cute idea, but the fact is that it was always quite
unsafe because it had no interlock against nextval(). Moreover, you
still did not have a guarantee of no holes in the assigned ID values,
because the transaction could still fail after the AFTER trigger runs.
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.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6259: Collation Error with Citext fields
Stan S ssanti...@adinfocenter.com writes: shard_1=# CREATE TABLE users (nickname CITEXT PRIMARY KEY,pass TEXT NOT NULL); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index users_pkey for table users shard_1=# INSERT INTO users VALUES ( 'larry', 'aaa' ); INSERT 0 1 shard_1=# INSERT INTO users VALUES ( 'Tom', 'bbb' ); ERROR: could not determine which collation to use for string comparison HINT: Use the COLLATE clause to set the collation explicitly. Hmm, I can't replicate this here ... shard_1=# CREATE TABLE users (nickname CITEXT COLLATE C PRIMARY KEY,pass TEXT NOT NULL); ERROR: collations are not supported by type citext This suggests strongly that you're using a 9.0-or-earlier citext installation that you've not upgraded to 9.1. If that's the right guess, you need to do CREATE EXTENSION citext FROM unpackaged to fix it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6238: ECPG converts long long to long on Windows
Magnus Hagander mag...@hagander.net writes: Does ecpg have a different requirement from everything else, or are we just doing it differently in different places for no special reason? I believe that in ecpg, the requirement is support the data types defined by the C compiler, that is we should support long long with whatever width it actually has on the platform. Just about everyplace else in PG, we want an integer of a known number of bits, and whether that's long or long long is incidental. So it's not surprising to me that this case got overlooked in the win64 patches. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql's \copy incompatible with :variables
Bruce Momjian br...@momjian.us writes: Josh Berkus wrote: Note that psql variables work perfectly fine with COPY. It's just \copy which seems to be misbehaving. The problem is that none of the backslash commands interpret variables: Nonsense. regression=# \set foo bar regression=# \d foo Did not find any relation named foo. regression=# \d :foo Did not find any relation named bar. \copy is different because it uses OT_WHOLE_LINE mode to read the argument, and that doesn't expand :variable references. I'd be a bit leery of changing that. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] memory leak in postgresql
Pavel Stehule pavel.steh...@gmail.com writes: I found a following issue (tested on PostgreSQL 9.2) CREATE OR REPLACE FUNCTION public.setfield(a anyelement, text, text) RETURNS anyelement LANGUAGE plpgsql AS $function$ begin create temp table aux as select $1.*; execute 'update aux set ' || quote_ident($2) || ' = ' || quote_literal($3); select into $1 * from aux; drop table aux; return $1; end; $function$ create type mypoint as (a int, b int); create table omega(p mypoint); insert into omega select mypoint '(10,20)' from generate_series(1,10); update omega set p = setfield(p, 'a', '20'); WARNING: out of shared memory CONTEXT: SQL statement create temp table aux as select $1.* PL/pgSQL function setfield line 3 at SQL statement ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction. CONTEXT: SQL statement create temp table aux as select $1.* PL/pgSQL function setfield line 3 at SQL statement This is not a memory leak, this is a your transaction is holding too many locks problem (namely, one lock for each transient table). Please follow the advice given in the error message. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6240: About - postgreswdinit.sql
Chethan HB chethanbasava...@gmail.com writes: Jan 1 02:05:10.531239 warn CLA-0 postgres[9919]: [2-1] ERROR: could not create file base/16384/11500: File exists [This error is from postgres server] Jan 1 02:05:10.531317 warn CLA-0 postgres[9919]: [2-2] STATEMENT: create database postgreswd; This is extremely strange on several levels. Are you sure you are using an unmodified Postgres 9.0.4 server? In my copy of 9.0, there would never be a file with a relfilenode number as small as 11500, not to mention that CREATE DATABASE should certainly not be targeting a nonempty subdirectory of $PGDATA/base to create a new database in. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6226: Broken foreign key stored on database (parent deleted with children still readable, BUG#6225 Update)
Daniel Cristian Cruz danielcrist...@gmail.com writes: 2011/10/5 Alvaro Herrera alvhe...@commandprompt.com Well, some people say it's a bug, others say it's not; and even if it is, changing it means backwards incompatible behavior, so *if* it is patched, it will only change the behavior on a future release, not whatever you're using. Well, I'll try to explain better, because it could be a bug, since after deleting and cascading, a deleted row is still visible and has a foreign key constraint violated with no error message. This schema arrangement is circular. Consider what happens: 1. You issue a DELETE for the event row with id_event = 1. 2. This fires (as AFTER triggers) commands to do these things: a. DELETE FROM repetition_conf WHERE id_event = 1. b. UPDATE repetition SET id_event = NULL WHERE id_event = 1. (This one does nothing since there is no such row in repetition.) I don't recall whether we have any particular guarantees about the order these two things get done in, but in this example it doesn't matter. 3. The DELETE on repetition_conf deletes the lone repetition_conf row, and then fires an AFTER trigger to do DELETE FROM repetition WHERE id_repetition_conf = 1. 4. That DELETE finds it should delete the lone repetition row ... but wait! *Before* it can delete that row, it must fire the BEFORE DELETE trigger. 5. The trigger function issues DELETE FROM event WHERE id_event = 2. 6. This fires (as AFTER triggers) commands to do these things: a. DELETE FROM repetition_conf WHERE id_event = 2. (This does nothing.) b. UPDATE repetition SET id_event = NULL WHERE id_event = 2. (This one finds and updates the lone repetition row.) 7. Now we exit the trigger function and are back at the step-3 DELETE command. It was supposed to delete the repetition row. But by now, that row has already been updated, and under Postgres' visibility rules that means the previously-started delete can't delete it. If it did delete it, it might be deleting data other than what you intended, since the row is now different from what it was when it was selected for deletion. In my view, this whole thing is just an example of the hazards of defining BEFORE triggers that can change the state of the target row. That's best avoided, because there simply isn't any good semantics for it. But generally the rule in Postgres is first action past the post wins, and in this case it's the UPDATE SET NULL that gets done first. The rough rule of thumb is that BEFORE triggers are good for adjusting the contents of the row that's about to be stored, while AFTER triggers are what to use to propagate changes elsewhere. I'm not sure that changing the BEFORE trigger to AFTER would make all your problems go away, but it'd be worth a try. Another point worth making here is that in Postgres, triggers run at a lower level than foreign key constraints (since FKs are implemented using triggers). It *is possible* to cause an FK constraint to be violated, if you install a trigger that interferes with the operation of the FK action, which is what's happening here. We don't consider that a bug but a feature. The only way to prevent it would be to not fire triggers for updates caused by FK actions, which would be a cure worse than the disease. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6233: pg_dump hangs with Access Violation C0000005
Pavel Holec ho...@email.cz writes: In the meantime I tried debug in msvc2005 (Win7/32) and free(funcsig); in pg_dump.c line 7510 cause _ASSERTE(_CrtIsValidHeapPointer(pUserData)); in dbgheap.c line 1252 * If this ASSERT fails, a bad pointer has been passed in. It may be * totally bogus, or it may have been allocated from another heap. * The pointer MUST come from the 'local' heap. If I comment free(funcsig); and next one free(funcsig_tag); pg_dump works fine. Hmm. I can see how that would happen if you're using one of the Windows environments wherein malloc's done inside libpq have to be free'd inside libpq. (The PQExpBuffer support code is in libpq...) However, the flaw in that explanation is that it would basically mean pg_dump doesn't work at all on Windows, at least not if you have any user-defined functions, and probably some other cases too because there seem to be multiple instances of the dubious coding. It's a bit hard to believe that nobody's noticed that before. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6233: pg_dump hangs with Access Violation C0000005
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Tom Lane's message of mar oct 04 22:04:29 -0300 2011: Hmm. I can see how that would happen if you're using one of the Windows environments wherein malloc's done inside libpq have to be free'd inside libpq. (The PQExpBuffer support code is in libpq...) Isn't this the kind of thing that you have to enable explicitly? I'm looking at our docs for PQfreemem: Frees memory allocated by libpq, particularly PQescapeByteaConn, PQescapeBytea, PQunescapeBytea, and PQnotifies. It is particularly important that this function, rather than free(), be used on Microsoft Windows. This is because allocating memory in a DLL and releasing it in the application works only if multithreaded/single-threaded, release/debug, and static/dynamic flags are the same for the DLL and the application. On non-Microsoft Windows platforms, this function is the same as the standard library function free(). I have no idea how accurate or complete that third sentence is; but perhaps the OP is trying to use a libpq.dll that was built separately from his pg_dump executable? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bug in dependency - there is possibility to break a system catalog
Pavel Stehule pavel.steh...@gmail.com writes: [ we forgot to record dependencies on function default expressions ] Fixed, thanks for the report. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Typo in nbtsort.c
Peter Geoghegan pe...@2ndquadrant.com writes: I noticed this typo in a comment in the file nbtsort.c: /* * We need to log index creation in WAL iff WAL archiving/streaming is * enabled UNLESS the index isn't WAL-logged anyway. */ I suggest an s/iff/if/ This is not a typo, it's the standard contraction for if and only if. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6236: Query execution bug
Boris Matkov bor...@devart.com writes: INSERT INTO btest0 (id, name) VALUES ((SELECT DISTINCT id FROM btest0 WHERE name = $1 LIMIT 1), $1) - was executed successfully INSERT INTO btest0 (name,id) VALUES ($1, (SELECT DISTINCT id FROM btest0 WHERE name = $1 LIMIT 1)) - I got error: --- inconsistent types deduced for parameter $1 --- Script for the btest0 table creating: CREATE TABLE btest0 ( id integer NOT NULL, name character varying(50) NOT NULL, value double precision, CONSTRAINT pk_btest0 PRIMARY KEY (id) ) It may be annoying, but it's not a bug. The equality test uses the text = text operator, so if that's seen first then the parameter gets resolved as text. You'd be better off to declare the type of the parameter instead of assuming that it will always be resolved the way you want ... but if you can't be bothered to do that, using text instead of varchar as the column type would avoid most of the cases where you'll see something like this. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6235: Delete fails with ON DELETE rule on inherited table
Evan Martin postgre...@realityexists.net writes: Defined a RULE that deletes from a child table whenever a parent table row is deleted. If the parent (referencing) table INHERITS from another table this rule doesn't work as intended, whether you delete from the base or derived table. If you delete from the base table then the DELETE succeeds (the row is deleted), but the referenced row is not deleted. This might make sense to someone who knows how inheritance is implemented, but it wasn't immediately obvious to me. It would be nice if this worked, but if it doesn't, I think the documentation should warn users about this trap. The reason this doesn't happpen is that inheritance expansion is done after rule expansion. While you could argue that rules on child tables should be considered too, it's not very clear to me that that would be well defined, and it's unlikely we'd make such a non-backwards-compatible change in rule behavior anyway. Personally I'd suggest using a trigger not a rule here, as it's not going to be subject to this problem and is generally the preferred way anyhow. The more serious problem is that if you try to delete from the derived table the delete fails with an error: ERROR: update or delete on table referenced violates foreign key constraint fk_derived_referenced on table derived DETAIL: Key (id)=(2) is still referenced from table derived. The reason for that is that the DO ALSO action occurs before the main action, so you're trying to delete a referenced row that is in fact still referenced. One solution would be to declare the foreign key constraint as DEFERRABLE INITIALLY DEFERRED. (The same would be the case for a trigger, unless you made it an AFTER trigger.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] no relation entry for relid 1
Peter Geoghegan pe...@2ndquadrant.com writes: I've built Postgres from master, and found that the following fairly simple query breaks: select count(*) from ( select schemaname frompg_stat_user_tables order by1 ) sub group by schemaname This produces the internal error message no relation entry for relid 1. Why is that? Looks like I broke it here: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57 Fixed, thanks for the report! regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] no relation entry for relid 1
Peter Geoghegan pe...@2ndquadrant.com writes: On 29 September 2011 23:15, Tom Lane t...@sss.pgh.pa.us wrote: Looks like I broke it here: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1cb108efb0e60d87e4adec38e7636b6e8efbeb57 Hmm. Although it was obvious to me that this was an internal error, I have to wonder what a novice would have made of it. Specifically, I wonder if there should be an INTERNAL_ERROR severity level, to explicitly advertise that you're not supposed to see this, and to help log analysis tools (including grep) bring these sorts of things to the DBA's attention, as they are surely much more severe than most errors seen in practice. Well, the SQLSTATE for this sort of thing is already ERRCODE_INTERNAL_ERROR. As to whether it's more severe than other errors, I'm not convinced. It didn't crash, nor corrupt your data. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Problems with ENUM type manipulation in 9.1
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011: ALTER TYPE ... ADD VALUE does not work inside transaction blocks, period, whether they are executed as a multi-command string or one query at a time. Try it: The reason it is not allowed is because it breaks stuff (I cannot remember what). Inconvenient, yes. Broken, perhaps. But it's working as designed. If you're interested, you could examine the old threads that led to this behavior and see if it can be improved. But just removing the check won't do. The comment beside the code says what it breaks: case T_AlterEnumStmt:/* ALTER TYPE (enum) */ /* * We disallow this in transaction blocks, because we can't cope * with enum OID values getting into indexes and then having their * defining pg_enum entries go away. */ PreventTransactionChain(isTopLevel, ALTER TYPE ... ADD); AlterEnum((AlterEnumStmt *) parsetree); break; As Merlin says, this is not a bug. It's a design compromise that we made after quite some careful consideration, and we're unlikely to reconsider it unless someone thinks of an actually better solution. You might care to review the WIP: extensible enums thread in pgsql-hackers during October 2010 to see the issues and alternatives that were considered. BTW, I imagine that the reason that manually adding rows to pg_enum no longer works with any reliability at all is that the manual procedure isn't cognizant of the new rules about even vs odd OIDs in pg_enum. Not that it really worked before --- once the OID counter wrapped around, you'd be pretty well screwed. As Alvaro says, manual alterations of the system catalogs never have been supported, meaning that we will never offer a guarantee that something that (more or less) worked in a previous release will still work in newer ones. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Problems with ENUM type manipulation in 9.1
Josh Kupershmidt schmi...@gmail.com writes: Excerpts from depstein's message of mié sep 28 07:21:17 -0300 2011: Anyway, the procedure that we used (based on http://en.dklab.ru/lib/dklab_postgresql_enum/) does the necessary checks before removing enum values. Not exactly; that code is rife with race conditions. For instance, how does the Check data references loop ensure that previously-checked tables don't get a new row containing the forbidden enum_elem before the function is finished? It's worse than that: even if you have in fact deleted all occurrences of a specific enum OID from the tables, that OID might still be lurking in a btree index on an enum column. If you delete the pg_enum entry, and the OID is odd (meaning that the pg_enum entry must be consulted to find out how to sort it), you just broke that index. You might think you could get out of that by VACUUM'ing to ensure that dead index entries get cleaned out, but that is not good enough. The problem OID could have gotten copied into a btree page boundary value or non-leaf-page entry. If that happens, the OID will most likely never disappear from the index, short of a REINDEX; and this is also the worst case for index corruption, since we must be able to compare other OID values to the non-leaf-page entry to figure out which leaf page to descend to in searches. In short, the reason why this type of code hasn't been adopted into core is that it doesn't work. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6232: hstore operator ? no longer uses indexes
Pierre Ducroquet p.p...@pinaraf.info writes: [ the hstore ? text operator no longer matches an hstore GIST index ] Hmm ... this doesn't seem to be specific to either hstore or GIST; it's a collation problem. The index is marked as having no collation, which is reasonable since hstore is a collation-less type. However, the ? OpExpr gets marked as having default collation because it has one collatable input, namely the text constant. And then, match_clause_to_indexcol decides the clause doesn't match the index. Not sure what to do about this. Is it okay to suppose that collation can be ignored when matching to a collation-less index? If not, what's the correct rule? I don't like the idea of concluding that hstore has to be forcibly assigned a collation just because it has some operators that accept text ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6232: hstore operator ? no longer uses indexes
Greg Stark st...@mit.edu writes: On Thu, Sep 29, 2011 at 4:22 AM, Peter Eisentraut pete...@gmx.net wrote: Not sure what to do about this. Â Is it okay to suppose that collation can be ignored when matching to a collation-less index? That sounds correct on first reading. Doesn't this depend on the semantics of the ? operator? Well, yeah. But if the operator requires a particular collation, what's it doing in an operator class for a collation-less indexed datatype? I think the operator could actually depend on its input collation with respect to some part of the processing it does on its collatable right-hand input. But if the left-hand column (the indexed column) is of a non-collatable type, it's hard to see how the operator could depend on the index having a collation. Also, I've now tested a patch along these lines and it passes core and contrib regression tests, so there's not anything too obviously broken about the idea. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6229: Postgresql crashes after: LOG: statistics buffer is full
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Max Kunz's message of mar sep 27 13:50:57 -0300 2011: i have detected a problem after postgres logs statistics buffer is full: The database achieves farther on connections from the clients but no one could process a statement and neither of the connection was closed. It was also not possible to shutdown postgresql regularly. The 8.1 branch is no longer supported. You need to upgrade, at least to 8.2; but since that's going to lose support just past December 2011, you should look into something more recent than that too. FWIW, I suspect the problem is at a much deeper level and statistics buffer is full is just a minor symptom. If the stats buffer process is stuck, that should really have no effect on the system other than failure to deliver statistics updates. Probably the reason why it's reporting this is that the stats collector process is stuck, and perhaps the underlying reason for that is also affecting regular backends. But there's not nearly enough info here to diagnose the true cause. In any case I agree with Alvaro that 8.1.3 is horribly obsolete, and you should at least update to the end of the 8.1 release branch if you can't easily migrate to a supported branch. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6227: No arguments for COPY OIDS and HEADER
Itagaki Takahiro itagaki.takah...@gmail.com writes: Our documentation says OIDS and HEADER options in COPY command take [ boolean ] arguments, but actually they don't accept any arguments. We can only set them to TRUE by specifying their names. Um, these examples all work fine for me in HEAD: regression=# copy tenk1 to '/dev/null' with (oids); COPY 1 regression=# copy tenk1 to '/dev/null' with (oids true); COPY 1 regression=# copy tenk1 to '/dev/null' with (oids false); COPY 1 regression=# copy tenk1 to '/dev/null' with (format csv, header); COPY 1 regression=# copy tenk1 to '/dev/null' with (format csv, header true); COPY 1 regression=# copy tenk1 to '/dev/null' with (format csv, header false); COPY 1 Also, regression=# copy tenk1 to '/dev/null' with (oids fals); ERROR: oids requires a Boolean value so it is checking the argument. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6230: strange changes in behavior of string functions
Dmitry Ryabov dmitry-rya...@mail.ru writes:
In the version 9.1 I was surprised to find that the function upper now is
not working as before. For example:
select upper ('SISTEM AYGıTLARı') = 'SISTEM AYGITLARI'
in postgresql 9.0 returns true, but in postgresql 9.1 - false.
It sounds like you didn't use the same locale settings when creating
your 9.1 database. Check LC_CTYPE and LC_COLLATE settings.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6213: COPY does not work as expected in a plpgsql function
Robert Haas robertmh...@gmail.com writes: It would actually be nice if worked even without that, but I'm not sure what would be involved in making that happen. I've been too busy to look at this in detail, but I imagine the issue is failure to pass parameters down from the ProcessUtility call to COPY into the parsing/execution of the sub-SELECT. It might be relatively straightforward to fix, or then again it might not. The parsing end of it could quite likely be harder than the execution end. We've surmounted similar issues in places like EXPLAIN, though. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6218: TRAP: FailedAssertion( !(owner-nsnapshots == 0), File: resowner.c, Line: 365)
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: Maybe, but I'd still like to see a test case, because I can't reproduce any such problem by preparing ROLLBACK in an aborted transaction. reading GetTransactionSnapshot, it seems that the problem happens only with IsolationUsesXactSnapshot() true. Hmm. I'm inclined to think that this demonstrates a bug in snapshot management, not so much in plancache. We have plancache doing PushActiveSnapshot(GetTransactionSnapshot()); and then later PopActiveSnapshot(); and at this point surely it is not plancache's fault if there is any remaining refcount for the snapshot. There is, though, because GetTransactionSnapshot saved a refcount in TopTransactionResourceOwner. I think it's snapmgr.c's responsibility to make sure that that's cleaned up, and it's not doing so. The place where that refcount normally gets dropped is AtEarlyCommit_Snapshot, but that isn't going to be called at all in aborted-transaction cleanup. Worse, if we just transposed it over to be called in a place in AbortTransaction comparable to where it's called during commit, that still wouldn't fix the problem, because when the ROLLBACK happens, we've already aborted the transaction. I think that AtEarlyCommit_Snapshot is misdesigned, and that far from being done early in commit/abort, it needs to be done late, like somewhere not very long before the ResourceOwnerDelete(TopTransactionResourceOwner) calls. There is no very good reason to think that someone might not ask for a snapshot during commit processing. Alvaro, do you happen to remember why this got designed as an early transaction shutdown action, rather than delaying it as long as possible? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6222: Segmentation fault on unlogged table
Robert Haas robertmh...@gmail.com writes: I was just wondering about that. Â It seems like it could very well be the same issue, but I have not tested it yet. OK, I tested it. On my system, that patch appears to fix this problem. Yeah, I was just going to suggest that that might be related, but I see you beat me to the deduction. Will commit it (with more than zero comments) in a moment. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bug in plancache.c
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: GetCachedPlan can pass the 'qlist' to the planner twice. if i understand the code correctly, it's unsafe because the planner is destructive wrt the input tree. for my application, it often causes a crash in executor. Good catch, thanks! (But a fix like this really requires a comment IMO.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6218: TRAP: FailedAssertion( !(owner-nsnapshots == 0), File: resowner.c, Line: 365)
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Tom Lane's message of lun sep 26 13:26:37 -0300 2011: The place where that refcount normally gets dropped is AtEarlyCommit_Snapshot, but that isn't going to be called at all in aborted-transaction cleanup. Worse, if we just transposed it over to be called in a place in AbortTransaction comparable to where it's called during commit, that still wouldn't fix the problem, because when the ROLLBACK happens, we've already aborted the transaction. ... ouch. Shall I work on a fix? I expect you are plenty busy with commitfest stuff, but please let me know otherwise. I have what-I-think-is-the-fix pretty clear in my own mind, so let me give it a try. If it doesn't work I'll bounce it back to you. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg 9.1.1 - ERROR: could not find pathkey item to sort
bricklen brick...@gmail.com writes: Is this a bug, Yes. Thanks for the test case, will look. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg 9.1.1 - ERROR: could not find pathkey item to sort
I wrote: bricklen brick...@gmail.com writes: Is this a bug, Yes. Thanks for the test case, will look. Fixed, patch is at http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=1679e9feddc94bd7372a6829db92868e55ef7177 regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6218: TRAP: FailedAssertion( !(owner-nsnapshots == 0), File: resowner.c, Line: 365)
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: There isn't terribly much we can do with this report unless you can provide a complete test case to reproduce it. after some investigation, i think it is triggered by protocol-level prepare of ROLLBACK in an aborted transaction. does the following patch make sense? Maybe, but I'd still like to see a test case, because I can't reproduce any such problem by preparing ROLLBACK in an aborted transaction. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6216: Calling PQconnectdbParams from C++ with a char**
Craig Ringer ring...@ringerc.id.au writes: On 21/09/2011 4:25 PM, Lionel Elie Mamane wrote: I added my initial patch, and as far as I understand, I have to send the revised patch to the list before I can register it at the commitfest. So here is my revised patch, that uses const char *const * like elsewhere in the same file instead of char const* const*. Yep, I'm happy with that. It does what it says and no more. I went ahead and committed this, since there seems no very good reason to make it wait for the next commitfest. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Timezone issues with Postrres
Magnus Hagander mag...@hagander.net writes: On Thu, Sep 22, 2011 at 07:42, Tom Lane t...@sss.pgh.pa.us wrote: I think we ought to map Central America Standard Time to plain CST6. Magnus, AFAICT from the commit logs, that lookup table was your work to begin with --- do you remember anything about the reasoning for the Central America entries? Hmm. not entirely. I know the initial round was basically all just guesses. Then at some point we added tools/win32tzlist.pl. But IIRC the actual timezones picked were more or less still guestimates. So I think it's just a mistake in that, and should be changed. OK, done. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6205: ERROR: temporary tables cannot specify a schema name
Robert Haas robertmh...@gmail.com writes: On Sun, Sep 18, 2011 at 5:10 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Sep 15, 2011 at 12:05 AM, Tom Lane t...@sss.pgh.pa.us wrote: In that case I'm betting Robert broke it somewhere in the unlogged-table changes. Yeah, looks like it. Â Will investigate. I committed a localized fix for this. Basically, it now double-checks that the schema name isn't the one that would have been forced by the temp-ness, and doesn't throw an error if they match. Keeping in mind that this worked before ... did you take the approach of seeing exactly why it worked before, and why your changes broke it? The patch you committed looked like it was introducing the functionality from scratch, which should not have been the case. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6218: TRAP: FailedAssertion(!(owner-nsnapshots == 0), File: resowner.c, Line: 365)
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp writes: 9.2devel (2562dcea811eb642e1c5442e1ede9fe268278157) ERROR: could not serialize access due to concurrent update STATEMENT: UPDATE file SET atime = current_timestamp WHERE fileid = $1 TRAP: FailedAssertion(!(owner-nsnapshots == 0), File: resowner.c, Line: 365) LOG: server process (PID 16832) was terminated by signal 6: Abort trap There isn't terribly much we can do with this report unless you can provide a complete test case to reproduce it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Timezone issues with Postrres
Euler Taveira de Oliveira eu...@timbira.com writes: On 21-09-2011 13:38, Robert Haas wrote: The rules for interpreting time zone specifications are arcane enough to make me suspect that this isn't a bug even though it seems rather odd, but in any case it would be useful to know how many hours PostgreSQL's timestamp is behind (or ahead of) UTC and similarly for the operating system. I think the OP is talking about one of these timezones: It's a bit premature to speculate without knowing his exact timezone setting, but there seem at least three possibilities: 1. The system clock is, in fact, set wrong, so that the OS is delivering the wrong UTC time to Postgres. This being on a Windows platform, I wouldn't write that off. It would be a good idea to do SET TIMEZONE = UTC; and then see if now() reports the correct UTC time. 2. The timezone setting he's using is inappropriate for the jurisdiction he's in, so that Postgres is following the wrong DST rule. Not knowing either his actual setting or his precise jurisdiction, this is hard to guess about. 3. The zone data that Postgres has is obsolete for his zone. This seems entirely possible, although a look at the git logs doesn't reveal any changes in Central American zone rules since 9.0.1 was released. (I see a change in Mexican rules listed for tzdata release 2010j in May 2010, but that was in 9.0 beta2 and later.) A relevant question here is whether his jurisdiction has observed DST in recent years and then changed their laws. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Broken selectivity with special inet operators
Josh Berkus j...@agliodbs.com writes: Summary: special inet operators ( = = ) are up to 100X off in estimating rowcounts A look in pg_operator will show you that these operators have no associated selectivity estimators at all. It's not so much broken as unimplemented. regression=# select oid::regoperator,oprcode,oprrest,oprjoin from pg_operator where (oprleft = 869 or oprright = 869) and oprresult = 16; oid |oprcode| oprrest | oprjoin +---+-+- =(inet,inet) | network_eq| eqsel | eqjoinsel (inet,inet) | network_ne| neqsel | neqjoinsel (inet,inet) | network_lt| scalarltsel | scalarltjoinsel =(inet,inet) | network_le| scalarltsel | scalarltjoinsel (inet,inet) | network_gt| scalargtsel | scalargtjoinsel =(inet,inet) | network_ge| scalargtsel | scalargtjoinsel (inet,inet) | network_sub | - | - =(inet,inet) | network_subeq | - | - (inet,inet) | network_sup | - | - =(inet,inet) | network_supeq | - | - (10 rows) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Broken selectivity with special inet operators
Josh Berkus j...@agliodbs.com writes: On 9/21/11 1:56 PM, Tom Lane wrote: A look in pg_operator will show you that these operators have no associated selectivity estimators at all. It's not so much broken as unimplemented. Oh! I was assuming that the special case code kicked in regardless. So we implemented the rewrite to and for the actual execution, but not for cost estimates? If you mean the indexscan optimization, we do know how to estimate the cost of the indexscans, because that depends mostly on the behavior of the added or condition(s). This does not imply knowing how to estimate the behavior of = itself. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Broken selectivity with special inet operators
Josh Berkus j...@agliodbs.com writes: If you mean the indexscan optimization, we do know how to estimate the cost of the indexscans, because that depends mostly on the behavior of the added or condition(s). This does not imply knowing how to estimate the behavior of = itself. If we can estimate the cost of the indexscan, why can't we estimate the rowcount? Because the estimated rowcount is derived long before we consider whether to use an indexscan at all, and indeed must be computable whether the table has any related index or not. The special-indexscan-qual code is *not* a substitute for providing a selectivity estimator. It's possible that we could build simple estimators for these operators that just turn the problem into a range estimation and then pass it off to somewhere else, but nobody has tried. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Timezone issues with Postrres
pratikchirania pratik.chira...@hp.com writes: 1. I am in Costa Rica, using Windows Server 2008 R2/Windows 2003 with PostgreSQL 8.3/9.0 2. System Date/Time Settings shows CST/Central America with UTC-6 as extra display 4. There is NO DST for CST (Central America) a.k.a America/Costa_Rica to the PostgreSQL database through the pg_timezone_names view Well, if you want no-DST behavior, this is wrong: show timezone CST6CDT That timezone specifies daylight savings behavior (CDT). As it happens, it's going to follow the USA rules for when to switch, but any switch would be wrong for Costa Rica. You need the America/Costa_Rica setting. Now having said that, it appears that the reason you got CST6CDT by default is that we map the Windows Central America Standard Time and Central America Daylight Time registry strings to that. This seems clearly wrong. A look at the tzdata northamerica file shows that noplace in Central America other than Mexico has observed DST with any regularity, and certainly none of them could be said to follow USA DST rules. Mexico is a separate case, because there are separate Central Standard Time (Mexico) and Central Daylight Time (Mexico) entries, which we map to America/Mexico_City, which seems proper. I think we ought to map Central America Standard Time to plain CST6. (Or we could map to one of America/Costa_Rica, America/Guatemala, America/El_Salvador, etc, but that seems more likely to offend people in the other countries than provide any additional precision.) I am not sure what we ought to do with Central America Daylight Time, but on the evidence here I wonder whether that setting exists in the wild at all. Magnus, AFAICT from the commit logs, that lookup table was your work to begin with --- do you remember anything about the reasoning for the Central America entries? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6217: to_char() gives incorrect output for very small float values
Chris Gernon kabi...@gmail.com writes: CREATE TABLE t ( id serial, f double precision, CONSTRAINT t_pk PRIMARY KEY (id) ); INSERT INTO t (f) VALUES (0.000563219288); SELECT to_char(f, 'FM90.99') FROM t WHERE id = 1; Expected Output: 0.000563219288 Actual Output: 0. My immediate reaction to that is that float8 values don't have 57 digits of precision. If you are expecting that format string to do something useful you should be applying it to a numeric column not a double precision one. It's possible that we can kluge things to make this particular case work like you are expecting, but there are always going to be similar-looking cases that can't work because the precision just isn't there. (In a quick look at the code, the reason you just get 0. is that it's rounding off after 15 digits to ensure it doesn't print garbage. Maybe it could be a bit smarter for cases where the value is very much smaller than 1, but it wouldn't be a simple change.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6217: to_char() gives incorrect output for very small float values
Kevin Grittner kevin.gritt...@wicourts.gov writes: Christopher Gernon kabi...@gmail.com wrote: to_char() should be able to convert 5.6e-32 to text just as easily as it can convert 5.6e-3. For some reason, it doesn't. Oh, I see your point now, and I agree with you. We should probably at least put this on the TODO list, I think. Any objections? If we're gonna fix it, we should just fix it, I think. I was considering taking a stab at it, but if someone else would like to, that's fine too. One other thing I notice in the same area is that the handling of NaNs and infinities seems a bit incomplete. There's an explicit special case for them in the -format code path, but not otherwise, and I think that the results you get for other formats will vary depending on what the local implementation of snprintf does. What *should* the output be, if the input is NaN or Inf? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6217: to_char() gives incorrect output for very small float values
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: If we're gonna fix it, we should just fix it, I think. I was considering taking a stab at it, but if someone else would like to, that's fine too. I wouldn't mind doing it, but not until after the CF wraps. On the other hand, isn't this is one of those compatibility functions? Perhaps it would best be done by someone who has familiarity with, and access to, a database with which we're trying to be compatible. Chris already stated that the case gives the answer he expects in several other DBs, so I don't seem much need for further compatibility checking on the don't round off prematurely angle. However, it would be interesting to know what Oracle etc do with NaN and Infinity, assuming they even support such numbers. Currently what our code does for the format-with- case is to output # in all digit positions. It would be plausible for that to happen in the non- cases too, but whether that's actually what happens in other systems is something I don't know. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6217: to_char() gives incorrect output for very small float values
Greg Stark st...@mit.edu writes:
On Tue, Sep 20, 2011 at 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, it would
be interesting to know what Oracle etc do with NaN and Infinity,
assuming they even support such numbers.
Note that it looks like NUMBER cannot store either Infinity or NaN.
They can only occur in BINARY_FLOAT and BINARY_DOUBLE. From the docs:
If a BINARY_FLOAT or BINARY_DOUBLE value is converted to CHAR or NCHAR, and
the input is either infinity or NaN (not a number), then Oracle always
returns the pound signs to replace the value.
And testing shows:
SQL select to_char(cast('NAN' as binary_float), 'FM.') from dual;
TO_CHAR(CA
--
##
Hmm, interesting. They replace the whole field with '#', not just the
digit positions? Because that's not what is happening in our code at
the moment, for the one case where we consider this at all:
regression=# select to_char('nan'::float8, '.');
to_char
.
(1 row)
The path seems rather broken in some other ways as well:
regression=# select to_char('43.5'::float8, '.');
to_char
-
4.3500e+01
(1 row)
Since I did not say FM, why is it suppressing leading spaces here?
I'm starting to think that that code needs a wholesale rewrite
(not but what that's true of just about every part of formatting.c).
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6216: Calling PQconnectdbParams from C++ with a char**
Craig Ringer ring...@ringerc.id.au writes: As for wording: my *personal* preference is const char * const but I don't know what the opinions of those who work with the code day-to-day are. +1. Isn't the other ordering deprecated by recent C standards? (Or maybe I'm just thinking of where you're supposed to put static, but in any case char const * looks pretty weird to me.) Also, the existing usages in libpq-fe.h look like that, and there's no good reason for these to be randomly different. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6214: can't change Column COLLATE
yulin liu e9320...@gmail.com writes: can't change Column COLLATE pg_catalog.default to pg_catalog.zh_TW.euctw Use ALTER TABLE ... ALTER COLUMN ... TYPE ... COLLATE ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6214: can't change Column COLLATE
=?Big5?B?pHCoqA==?= e9320...@gmail.com writes: Use ALTER TABLE item ALTER COLUMN title TYPE character varying(2000) COLLATE pg_catalog.zh_TW.euctw; but, SQL state: 42704 UTF8 pg_catalog.zh_TW.euctw not found I hope that's not the exact phrasing of the error message ... but what it's probably trying to tell you is that you can't use an EUC_TW based locale in a database with UTF8 encoding. Try zh_TW.utf8. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6212: PREPARE(pseudotype) should be blocked off
Caleb Welton caleb.wel...@emc.com writes: statements such as: PREPARE p1(anyelement) AS SELECT quote_literal($1); PREPARE p2(internal) AS SELECT int2recv($1); Should not be allowed. Hmm. It would require an extra catalog lookup per parameter to enforce that. Not sure that it's worth it just to prevent peculiar errors. Can you point to any worse consequences? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6212: PREPARE(pseudotype) should be blocked off
caleb.wel...@emc.com writes: On Sep 16, 2011, at 11:11 AM, Tom Lane wrote: Hmm. It would require an extra catalog lookup per parameter to enforce that. Not sure that it's worth it just to prevent peculiar errors. Can you point to any worse consequences? I haven't found any more severe issues and I'll agree its not a high priority item. But the fix is simple enough that I don't see a reason to ignore it either. The easiest fix would be, as you say, adding one extra syscache lookup: If it were just PREPARE I'd have done it without quibbling; that isn't something I regard as a critical performance path. But if we're trying to lock this out then we logically have to enforce the same restriction in exec_parse_message, and that *is* a performance-critical path. Plus it has no existing catalog lookup that might be kluged to pass back the extra information. Maybe we should do it anyway, but I'd really like to see a more significant reason. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5800: corrupted error messages (encoding problem ?)
Craig Ringer ring...@ringerc.id.au writes: On 09/17/2011 05:10 AM, Carlo Curatolo wrote: Just tried with PG 9.1...same problem... Yep. There appears to be no interest in fixing this bug. All the alternatives I proposed were rejected, and there doesn't seem to be any concern about the issue. The problem is to find a cure that's not worse than the disease. I'm not exactly convinced that forcing all log messages into a common encoding is a better behavior than allowing backends to log in their native database encoding. If you do want a common encoding, there's a very easy way to get it, ie, standardize on one encoding for all your databases. People who aren't doing that already probably have good reasons why they want to stay with the encoding choices they've made; forcing their logs into some other encoding isn't necessarily going to improve their lives. ... The only valid fixes are to log them to different files (with some way to identify which encoding is used) I don't recall having heard any serious discussion of such a design, but perhaps doing that would satisfy some use-cases. One idea that comes to mind is to provide a %-escape for log_filename that expands to the name of the database encoding (or more likely, some suitable abbrevation). The logging collector protocol would have to be expanded to include that information, but that seems do-able. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Dropped index on table preventing rule creation
Robert Haas robertmh...@gmail.com writes: I spent some more time looking at this tonight. I am wondering if perhaps we should just get rid of relhasindex. -1, there is absolutely no reason to believe that's a good idea. ... I think we could fix Thom's complaint by changing DefineQueryRewrite() to call RelationGetIndexList() rather than blindly believing relhasindex, which would be maybe a five line code-change. We'd probably also want to change SetRelationRuleStatus() to clear relhasindex, which would be one more line of code. Yeah, that's about what it would take, but what I'm asking is why bother. The *only* case that we support here is turning a just-created, not-fooled-with table into a view, and I don't feel a need to promise that we will handle other cases (which are inevitably going to be poorly tested). See for example the adjacent relhassubclass test, which has got exactly the same issue. One related thing that seems worth doing is ripping out relhaspkey, Having a hard time getting excited about that either ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] segfault using pg_options_to_table(), v9.0.4
Frank van Vugt ftm.van.v...@foxi.nl writes: postgres=# select pg_options_to_table(ARRAY['article']); --3262-2011-09-13 14:28:18 CESTLOG: server process (PID 7427) was terminated by signal 11: Segmentation fault Looks like deflist_to_tuplestore fails to handle the case where an option has no value. Will fix, thanks. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Dropped index on table preventing rule creation
Robert Haas robertmh...@gmail.com writes: On Sep 10, 2011, at 11:26 PM, Tom Lane t...@sss.pgh.pa.us wrote: (IOW, rather than fix this I'd prefer to rip out the code altogether. But maybe we should wait a couple more years for that.) IIRC, it's not dead code. I think you can still generate such a dump if you use CREATE OR REPLACE VIEW to manufacture a pair of mutually recursive views. Oh, yeah, I'd forgotten about that. In general that's pg_dump's strategy for breaking a circular dependency loop that involves a view. Now we should probably disallow that, but we currently don't. Losing that particular case isn't problematic, but I'm not sure that that's the only possible circularity involving a view. One idea that comes to mind is create table foo (list-of-columns); create function foofunc () returns setof foo as ...; create rule as select * from foofunc(); This only saves somebody from citing the list of column types twice, so maybe we could blow off this case too; but who's to say there are not more-useful cases that would create circularities? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Dropped index on table preventing rule creation
Thom Brown t...@linux.com writes: I don't use rules, but in a bit of experimentation on Git master, I discovered the following behaviour: CREATE TABLE test1 (id serial primary key, things text); CREATE TABLE test2 (id serial primary key, things text); ALTER TABLE test1 DROP CONSTRAINT test1_pkey; ALTER TABLE test2 DROP CONSTRAINT test2_pkey; CREATE RULE _RETURN AS ON SELECT TO test1 DO INSTEAD select * from test2; This produces the error message: could not convert table test1 to a view because it has indexes IIRC, this is because the check is just checking relhasindex. You should be able to recover and create the rule if you VACUUM the table. We could no doubt add more code to make that more transparent, but I don't see the point. The entire exercise of converting a table to a view is only meant to support loading of pg_dump output from versions that are probably ten years obsolete at this point. We don't even document that you can do the above, do we? (IOW, rather than fix this I'd prefer to rip out the code altogether. But maybe we should wait a couple more years for that.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6200: standby bad memory allocations on SELECT
Daniel Farina dan...@heroku.com writes: A huge thanks to Conrad Irwin of Rapportive for furnishing virtually all the details of this bug report. This isn't really enough information to reproduce the problem ... The occurrence rate is somewhere in the one per tens-of-millions of queries. ... and that statement is going to discourage anyone from even trying, since with such a low occurrence rate it's going to be impossible to be sure whether the setup to reproduce the problem is correct. So if you'd like this to be fixed, you're either going to need to show us exactly how to reproduce it, or investigate it yourself. The way that I'd personally proceed to investigate it would probably be to change the invalid memory alloc request size size errors (in src/backend/utils/mmgr/mcxt.c; there are about four occurrences) from ERROR to PANIC so that they'll provoke a core dump, and then use gdb to get a stack trace, which would provide at least a little more information about what happened. However, if you are only able to reproduce it in a production server, you might not like that approach. Perhaps you can set up an extra standby that's only there for testing, so you don't mind if it crashes? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql doesn't reuse -p after backend fail
hubert depesz lubaczewski dep...@depesz.com writes: On Mon, Sep 05, 2011 at 02:27:23PM -0400, Tom Lane wrote: It's not just the port, it's all the connection parameters --- do_connect relies on the PGconn object to remember those, and in this case there no longer is a PGconn object. We could have psql keep that information separately, but I'm not sure it's really worth the trouble. well, I think it's definitely worth the trouble. [ shrug.. ] So submit a patch. Personally I don't think the case comes up often enough to be worth the trouble, and I'd much rather spend development time on preventing the server from crashing in the first place. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6199: Can't install datatype hstore
Hadmut had...@danisch.de writes: I'd like to run a database application which requires datatype hstore. But when trying something like psql -f /usr/share/postgresql/9.1/extension/hstore--1.0.sql That is not how you install extensions anymore. Use CREATE EXTENSION. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] psql doesn't reuse -p after backend fail
hubert depesz lubaczewski dep...@depesz.com writes: ran psql with specyfying port: psql -p 4329 -U postgres -d some_database then I run query which breaks backend: =# select * from categories limit 1; The connection to the server was lost. Attempting reset: Failed. ! When I'll try to re-issue \c some_database now, I got: ! \c some_database could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket /tmp/.s.PGSQL.5432? ! It's not just the port, it's all the connection parameters --- do_connect relies on the PGconn object to remember those, and in this case there no longer is a PGconn object. We could have psql keep that information separately, but I'm not sure it's really worth the trouble. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6198: init-po fails for plperl due to invalid xsubpp path (contains ExtUtils)
Alex Hunsaker bada...@gmail.com writes: On Sun, Sep 4, 2011 at 16:57, Tomas Vondra t...@fuzzy.cz wrote: Aha! When I run configure like this $ ./configure --with-perl --enable-nls=cs Whoa, I totally missed that it was without --with-perl. :-) then it works, so obviously the --with-perl option is required. Shouldn't this behave a bit differently, e.g. not allowing enable-nls without with-perl? Allowing that and getting not-fully-working tree is not a good thing I guess ... Hrm, I don't know much about the nls stuff... but it seems like a reasonable request to me. Uh, no, because init-po is not needed by mere users of existing translations. Nor does somebody who wants --enable-nls necessarily care about building plperl. The failure here is not about combining NLS with --without-perl, it's about trying to do anything at all with plperl with --without-perl. I'd say the fix is to make plperl's makefile defend itself against somebody cd'ing to that directory and trying to use the makefile without having configured correctly. Another question worth asking is why is the rule being run at all? Do we need to have built SPI.c in order to do init-po for plperl? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6192: Incorrect result from operator overlaps
Incorrect result from operator overlaps wolfm...@o2.pl writes:
SELECT ('2011-08-31'::date,'2011-08-31'::date) overlaps
('2011-08-1'::date,'2011-08-31'::date);
Returns false, should return true.
This is correct per SQL standard. The spec is written such that an
interval is considered half-open, ie ['2011-08-01', '2011-08-31').
So that does not overlap the point '2011-08-31'.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6186: out of memory while analyze
Lampa lamp...@gmail.com writes: default_statistics_target = 8000# range 1-1 Problem seems to be in default_statistics_target values from approx 6300. Up to 6300 analyze works but on another machine (64bit) works 1 without problems on same but larger table (more data) Well, there's a reason why the default value of that parameter is 100 and not 1 ;-). The larger it is, the more memory space it's going to take to do an ANALYZE. I don't see any bug here, you're just trying to do more than you can do in a 32-bit machine. I guess we could improve the documentation of default_statistics_target to point out that it costs not only more time but more memory in ANALYZE. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6186: out of memory while analyze
Lampa lamp...@gmail.com writes: Trying analyze table (ANALYZE TABLE table or VACUUM ANALYZE table) with 3051316 rows (displayed size 2521MB in \dt+) What have you got maintenance_work_mem set to? shared_buffers might also be interesting. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] the '::' cast doesn't work in the FROM clause
Kevin Grittner kevin.gritt...@wicourts.gov writes: Merlin Moncure mmonc...@gmail.com wrote: yeah, that's the correct way, but why does this work? select val from random() as val; If you look at the PostgreSQL reference docs for the SELECT statement, a from_item can be a SELECT statement in parentheses or a function call (among other things). It cannot be an arbitrary expression containing operators (like ::). Right. We also accept things that look syntactically like function calls, so as to avoid debates with newbies about whether, say, COALESCE(...) is a function or not. CAST() falls into that category, while :: doesn't. There is actually a practical reason for this policy beyond the question of whether CAST is a function call or not: the structure name(...) has a well-defined syntactic extent, so there are no issues of operator precedence to worry about when it's embedded in a larger construct. IIRC, we ran into exactly that problem with the CREATE INDEX syntax, which is why an expression index column has to be parenthesized unless it looks like a function call. So IMO there is no syntax bug here. There is a dump/reload bug though :-( ... if you were to do create view vv as select val from CAST(random() as integer) as val; you will find that the system prints it out with the :: syntax, which won't work. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6181: concat_ws() incompatibility with MySQL
Itagaki Takahiro itagaki.takah...@gmail.com writes:
For query concat_ws('/', NULL, 'X'),
PostgreSQL 9.1 returns '/X', but MySQL returns 'X'.
I think postgres should return 'X' because of compatibility.
Another reason is that both of the two queries below return 'X'.
- concat_ws('/', 'X', NULL)
- array_to_string(ARRAY[NULL, 'X'], '/')
Yeah, I think you're right. Fortunately it's not too late to change
this without introducing backwards-compatibility issues of our own.
Will fix.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6182: /etc/init.d/postgresql-8.4 is incomplete for chkconfig
Steven Williams stwilli...@novell.com writes: Description:/etc/init.d/postgresql-8.4 is incomplete for chkconfig This file is not distributed by us. You probably need to contact the SUSE packager of postgresql. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6183: FATAL: canceling authentication due to timeout
Thorvald Natvig thorv...@medallia.com writes: We get a lot of FATAL: canceling authentication due to timeout in the log, with accompanying closed connections to clients. Well, the only known cause of that (other than genuine timeout conditions) is in fact fixed in 9.1rc1. You have not provided any information that would permit anyone to look for another cause. There does indeed seem to be a correlation between doing vacuum and seeing this error. Are you doing VACUUM FULLs on pg_authid (and if so, why)? If you are, is it possible that those are queuing up behind other queries that access pg_authid, and for some reason aren't releasing their locks promptly? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pgbench -T isn't a hard cutoff.
mark dvlh...@gmail.com writes: Expected behavior would be -T would mean a hard cut off. Why would you expect that? What I'd expect is that each transaction would be run to completion, which would mean that -T cannot possibly be exact. Even if it were, what's your notion of exact? Clock resolutions are different on different platforms. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libber library not found on RC1
alexondi alexo...@rambler.ru writes: I update server to RC1 version and after call pg_ctl to start I get this error opt/PostgreSQL/9.1/bin/pg_ctl: error while loading shared libraries: liblber-2.3.so.0: cannot open shared object file: No such file or directory But I have 2.4 version of this library. And I see in ldd pg_ctl that this library was added in RC or why I can't start server without ldap auth? How did you install RC1? The only obvious explanation for this error is that you are trying to use somebody else's executables that were built for a different environment than you have (specifically, wanting different revision numbers of some shared libraries). If so, you may need to build the software locally to get something that will work for you. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6176: pg_dump dumps pg_catalog tables
Chander Ganesan chan...@otg-nc.com writes: Normally, the pg_dump command ignored the pg_catalog tables when performing a dump. However, when provided the '--table' argument it fails to ignore the pg_catalog table. For example, suppose I had tables p1-p10 that I wanted to dump, I could use the following command: pg_dump test_db --table 'p*' This command would dump the requested tables, but it would also dump all the tables (in all schemas) that start with 'p*' . Generally speaking, there are no excluded schemas when using the pg_dump command with the '--table' argument. It is my belief that the pg_catalog tables should almost always be ignored (lest restores fail miserably). This proposal seems overly simplistic to me: if we did this, it would be impossible to use pg_dump to dump a catalog's contents at all. (I don't care whether the resulting script is restorable; sometimes you just need to see what's actually in pg_class.) I wonder whether it would be helpful to provide a default setting for --exclude-schema that lists pg_catalog, information_schema, etc. If we approached it that way, it'd be possible to override the default at need. However, I'm not sure how that switch interacts with wildcard --table specs ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6171: Sockets Issue
Robert Hopek rho...@getnetworks.com writes: Why do you have the configuration option to change the pgsql socket (which we need to do for our jailed shell environment), but not have psql check the postgresql.conf file for the enablement of that location change so that psql would look there automatically? How would that work? psql does not know where the server configuration file is, and would typically not have adequate permissions to read it anyway. If you must use a socket location other than /tmp, the most comfortable way to deal with it is to build custom executables with the correct locations as their wired-in defaults. This is not really much different from the situation for a custom port number... It seems very counter-productive. A common reason for using a nondefault connection location is to not *want* the postmaster to be reached by default-using clients. The configuration file option does have use-cases, just not yours. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6172: DROP EXTENSION error without CASCADE
Dimitri Fontaine dimi...@2ndquadrant.fr writes: ... My fix is to have deleteDependencyRecordsFor use true for skipExtensionDeps. On further reflection, there's some merit in that fix too. The question is what do we think should happen if the pre-existing shell operator belongs to another extension. It seems like the reasonable alternatives are (1) delete those pg_depend entries and allow the current extension to take ownership. (2) throw an error. What you suggest above would result in (2), whereas what I was thinking of would result in (1). The case where this would actually happen is where extension A creates some operator, and mentions some other operator as its commutator or negator, but never gets around to defining the other operator. Then extension B comes along and tries to fill in the other operator definition. Do we want to let that happen, or do we want to throw an error on the grounds that this sort of interconnection of two extensions was almost certainly not intended? (Note that I rather doubt that dropping either extension alone, afterwards, would clean up nicely, since we have no code that would remove the oprcom/oprnegate linkage.) A completely different line of thought is that maybe extension membership records shouldn't be created at all for a shell operator, on the grounds that it's not a real object but only a placeholder until it's filled in. One somewhat analogous situation is where we create a shell type and then fill it in later. That code uses skipExtensionDeps = true and so will end up throwing an error if the pre-existing membership is for another extension. However, it's pretty hard to imagine a useful situation where an extension would create a shell type and not fill it in, so I'm not sure that this is a close analogy. On the whole I'm starting to think that throwing an error is the best thing. We could always relax that later, but going the other way might be problematic. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6165: documentation bug in plpgsql-declarations.html and plpgsql-statements.html (or plpgsql parser bug)
Robert Haas robertmh...@gmail.com writes: On Wed, Aug 17, 2011 at 1:21 AM, raf r...@raf.org wrote: so, there is either a plpgsql parser bug that treats the sql equality operator as the plpgsql assignment operator, or = is an undocumented alternative to the documented plpgsql assignment operator (:=). I think it's the latter. It's definitely intentional, not a bug, so far as the source code is concerned: assign_operator : '=' | COLON_EQUALS ; I have a vague recollection that we might have left that undocumented on purpose, but I'm not actually sure why we support it in the first place. I think it's legacy at this point. We have discussed before whether to document it, and IIRC the general feeling was if we do document it, we'll never be able to get rid of it. Whether we could get rid of it now (instead of documenting it) was not seriously discussed. I've seen at least a few people saying that they do rely on it ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Segfault with before triggers and after triggers with a WHEN clause.
Yoran Heling i...@yorhel.nl writes: After upgrading to PostgreSQL 9.0.4 (don't remember exactly where I came from, but I believe it was an earlier 9.0.x), postgresql began to segault on certain queries. I have managed to isolate the problem and can reproduce the crash on a newly created and empty database with the following queries: Thanks, nice example! I traced through this and found that: 1. ExecBRUpdateTriggers returns the tuple-modified-by-the-before-trigger in the estate-es_trig_tuple_slot slot. 2. ExecUpdate does ExecMaterializeSlot() on that slot. Now the slot has a privately allocated copy of the tuple. (This is necessary since we'll scribble on the tuple's header fields during heap_update.) 3. During ExecARUpdateTriggers, TriggerEnabled needs to put the new tuple into a slot for execution of the WHEN condition. It thinks it can use the estate-es_trig_tuple_slot slot for this, but it's passing the same tuple *already* stored in that slot to ExecStoreTuple. ExecStoreTuple sees it's clearing a slot with shouldFree = true, so it pfree's the tuple, and then stores a dangling pointer back into the slot. Ooops. TriggerEnabled's apparently-similar use of estate-es_trig_oldtup_slot is perfectly safe because that slot is actually dedicated for the use of this function. The safest fix for this bug would be to make another dedicated slot for the new tuple too. That will require adding a field to EState, which is a bit risky in released branches, but I think we can get away with it if we add the field at the end of the struct. We did the same in a post-release 8.1 patch (in fact, that was adding es_trig_tuple_slot itself) and did not get complaints. The only alternative I can see that doesn't add another field to EState is to hack the TriggerEnabled code so that it checks if the tuple is already stored in the slot and skips ExecStoreTuple if so. That seems like a modularity violation, though: it'd require more knowledge about the detailed behavior of slots than I think this function ought to have. And it's still fairly fragile, in that es_trig_tuple_slot is mainly meant for the use of the layer of functions that are calling TriggerEnabled --- it's not hard to foresee other bugs if we rearrange the timing of the existing ExecStoreTuple calls in ExecBRUpdateTriggers and friends. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6172: DROP EXTENSION error without CASCADE
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Dimitri Fontaine dimi...@2ndquadrant.fr writes: Also, \dx+ cube will not show all the operators and functions. Some dependency information is indeed missing in pg_depend. Will look at why tomorrow, day's over here. I'm betting it's got something to do with http://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=eb15f26d577a11319b9429fb84f752a0135918db regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6166: configure from source fails with 'This platform is not thread-safe.' but was actually /tmp perms
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(The error message seems to be suffering from a bad case of copy-and-
paste-itis, too.)
Actually, it is accurate. The code is:
#ifdef WIN32
h1 = CreateFile(TEMP_FILENAME_1, GENERIC_WRITE, 0, NULL,
OPEN_ALWAYS, 0, NULL);
h2 = CreateFile(TEMP_FILENAME_1, GENERIC_WRITE, 0, NULL,
CREATE_NEW, 0, NULL);
if (h1 == INVALID_HANDLE_VALUE || GetLastError() !=
ERROR_FILE_EXISTS)
#else
if (open(TEMP_FILENAME_1, O_RDWR | O_CREAT, 0600) 0 ||
open(TEMP_FILENAME_1, O_RDWR | O_CREAT | O_EXCL, 0600) = 0)
#endif
{
fprintf(stderr, Could not create file in current directory
or\n);
fprintf(stderr, could not generate failure for create file in
current directory **\nexiting\n);
exit(1);
}
This code generates an errno == EEXIST in one thread, while another
thread generates errno == ENOENT, and this is how we test for errno
being thread-safe. If you have a cleaner way to do this, please let me
know. mkdir()?
The problem with that is you're trying to make one error message serve
for two extremely different failure conditions. I think this should be
coded more like
if (open(TEMP_FILENAME_1, O_RDWR | O_CREAT, 0600) 0)
{
report suitable failure message;
exit(1);
}
if (open(TEMP_FILENAME_1, O_RDWR | O_CREAT | O_EXCL, 0600) = 0)
{
report suitable failure message;
exit(1);
}
You would probably find that the messages could be a lot more clear and
specific if they were done like that. Also, a file-related error
message that doesn't provide the filename nor strerror(errno) is pretty
much wrong on its face, in my book.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6168: db_link may generate additional unformatted log entries in stderr
Marc Mamin m...@intershop.de writes: I've stumbled on a few entries in my stderr log where the line prefix where missing. e.g.: 2011-08-08 13:12:16 CEST|4e3fc490.17bc|6076|foo|DETAIL: Returned type character ... 2011-08-08 13:12:16 CEST|4e3fc490.17bc|6076|foo|CONTEXT: PL/pgSQL function bm_ ... 2011-08-08 13:12:16 CEST|4e3fc490.17bc|6076|foo|STATEMENT: Select coalesce(colu ... = NOTICE: table sessions_summary_raw_20110815 does not exist, skipping = NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index pk_sessions_s ... = NOTICE: table sessions_site_summary_raw_20110815 does not exist, skipping NOTICE entries should moreover not be logged ! Those entries are coming from db_link. I guess your test case is looping back to the same Postgres instance? What I see here is that the target backend (the one connected to by dblink) logs the warning as expected, and then the dblink one also prints the warning to stderr. This is because dblink does not override either PQsetNoticeReceiver or PQsetNoticeProcessor, so libpq provides its default behavior of printing warnings/notices on stderr. It'd probably make sense for dblink to supply a notice receiver that converts the result into an ereport() call, much as it does for actual error results (in fact it could likely use dblink_res_error for that). But frankly this is an enhancement request, not a bug. The entire point of the stderr logging mechanism is to capture random printouts to stderr that might happen in code called by the backend, and it's doing exactly what it's supposed to. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6167: pg_dump fails on table lock
Jesper Engman jes...@engman.net writes: I wonder if there is a small time span between when pg_dump starts and when all locks have been acquired that may be the problem (if a table is dropped during that time span). Is there such a small time of vulnerability? Certainly. pg_dump has to read pg_class to get the names of the tables, and then try to lock each one. If you drop a table during that window, the lock command will fail. The window is actually a bit longer than necessary in existing releases, because pg_dump was doing some other stuff before it got around to acquiring the locks. I fixed that recently http://git.postgresql.org/gitweb/?p=postgresql.gita=commitdiffh=68d977a73 but that patch hasn't made it to any released versions yet. In any case there's still a nonzero window. Excluding tables from the dump is not an option - that will be an incomplete backup. Um ... if you know it's a transient table, why do you care about backing it up? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6166: configure from source fails with 'This platform is not thread-safe.' but was actually /tmp perms
Alex Soto aps...@gmail.com writes: I was trying to build the 9.0.4 source tarball as the postgres user on a test machine. The configure step failed with the error: This platform is not thread-safe. Check the file 'config.log' or compile and run src/test/thread/thread_test for the exact reason. Use --disable-thread-safety to disable thread safety. As I started looking through the log file I noticed that it failed to write to the /tmp directory. Other configure steps had written to /var/tmp, but this step tried to write to /tmp for some reason. I fixed by correcting the permissions on the /tmp dir, but I thought the error message was a little misleading, so I thought I'd report the problem. Hmm ... I can't find any explicit reference to either /tmp or /var/tmp in our configure script. It seems like this must be an artifact of your compiler, or some other tool you're using. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6166: configure from source fails with 'This platform is not thread-safe.' but was actually /tmp perms
Alex Soto aps...@gmail.com writes: Here's the section in the config.log in case it makes a difference configure:28808: ./conftest Could not create file in /tmp or Could not generate failure for create file in /tmp ** exiting configure:28812: $? = 1 configure: program exited with status 1 [ greps... ] Oh, that error is coming from src/test/thread/thread_test.c. I wonder why we have that trying to write to /tmp at all, when all the other transient junk generated by configure is in the current directory. Bruce, do you have a good reason for doing it that way? (The error message seems to be suffering from a bad case of copy-and- paste-itis, too.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] ISBN: dump from 64bits and restore on 32 bits fail, Datum?
Daniel Cristian Cruz danielcrist...@gmail.com writes: I'm in a project where there is one development server with 32bits architecture and all the others are 64 bits. The server where I generate the base models (in sense of version) is a 64 bit. Dump and restore from this machine to all others 64bits development servers works well. When I try to restore it in the 32 bits server, it returns the following errors: [pg9@server ~]$ createdb isbn -T template0 [pg9@server ~]$ pg_restore -d isbn /tmp/isbn.backup *ERROR: internal size 8 is invalid for passed-by-value type* This isn't a bug ... you need to load the appropriate version of contrib/isn for that server. Admittedly, pg_dump doesn't make that terribly easy (it will work a lot better in 9.1 with the extensions infrastructure). In existing releases the best advice is to load the .sql file for the contrib module, then source the dump, ignoring the object-already-exists errors you get for the module's objects. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
