[HACKERS] FailedAssertion() in 8.2beta1
Hello -hackers,
I've found a bug with 8.2beta1:
1) Log message:
LOG: duration: 9.144 ms bind unnamed: UPDATE table_list SET description
= $1 WHERE id = cas_get_table_id ( $2,$3 )
DETAIL: parameters: $1 = '\tag{image SRC=/vizier/new2.gif}3rd release of
DENIS (2005Sep)', $2 = 'cas_data_sega', $3 = 'b_denis_denis5'
TRAP: FailedAssertion(!(n list-length), File: list.c, Line: 392)
LOG: server process (PID 26633) was terminated by signal 6
LOG: terminating any other active server processes
-
2) gdb bt:
Program received signal SIGABRT, Aborted.
0xb7e62027 in raise () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7e62027 in raise () from /lib/tls/libc.so.6
#1 0xb7e63747 in abort () from /lib/tls/libc.so.6
#2 0x082bcfd7 in ExceptionalCondition (
conditionName=0x837be2c !(n list-length),
errorType=0x837bb07 FailedAssertion, fileName=0x837bb00 list.c,
lineNumber=392) at assert.c:51
#3 0x081a27de in list_nth_cell (list=0x84d2410, n=5) at list.c:392
#4 0x081a287d in list_nth (list=0x84d2410, n=5) at list.c:413
#5 0x08185324 in ExecOpenScanRelation (estate=0x84f1a34, scanrelid=6)
at execUtils.c:823
#6 0x0818d8a0 in ExecInitIndexScan (node=0x84f0358, estate=0x84f1a34,
eflags=2) at nodeIndexscan.c:508
#7 0x0817b7fb in ExecInitNode (node=0x84f0358, estate=0x84f1a34, eflags=2)
at execProcnode.c:169
#8 0x0818758c in ExecInitAppend (node=0x84f06b0, estate=0x84f1a34,
eflags=2)
at nodeAppend.c:215
#9 0x0817b78b in ExecInitNode (node=0x84f06b0, estate=0x84f1a34, eflags=2)
at execProcnode.c:146
#10 0x0819040d in ExecInitNestLoop (node=0x84f0974, estate=0x84f1a34,
eflags=0)
at nodeNestloop.c:323
#11 0x0817b8bf in ExecInitNode (node=0x84f0974, estate=0x84f1a34, eflags=0)
at execProcnode.c:207
#12 0x08178fa6 in InitPlan (queryDesc=0x84db76c, eflags=0) at execMain.c:628
---Type return to continue, or q return to quit---
#13 0x081787bd in ExecutorStart (queryDesc=0x84db76c, eflags=0)
at execMain.c:171
#14 0x08229cdf in ProcessQuery (parsetree=0x84d1e74, plan=0x84f0974,
params=0x84c0d4c, dest=0x83bfc10, completionTag=0xbfedbed0 )
at pquery.c:152
#15 0x0822b10e in PortalRunMulti (portal=0x849cea4, dest=0x83bfc10,
altdest=0x83bfc10, completionTag=0xbfedbed0 ) at pquery.c:1145
#16 0x0822a874 in PortalRun (portal=0x849cea4, count=1, dest=0x847a260,
altdest=0x847a260, completionTag=0xbfedbed0 ) at pquery.c:700
#17 0x08226f1d in exec_execute_message (portal_name=0x847a154 ,
max_rows=1)
at postgres.c:1775
#18 0x08229316 in PostgresMain (argc=4, argv=0x8426114,
username=0x8426020 sega) at postgres.c:3452
#19 0x081f7608 in BackendRun (port=0x8439268) at postmaster.c:2848
#20 0x081f6c34 in BackendStartup (port=0x8439268) at postmaster.c:2485
#21 0x081f4cab in ServerLoop () at postmaster.c:1198
#22 0x081f46c2 in PostmasterMain (argc=1, argv=0x840cff0) at
#postmaster.c:950
#23 0x081a1a7c in main (argc=1, argv=0x840cff0) at main.c:187
---
3) gdb bt full
(gdb) bt full
#0 0xb7e62027 in raise () from /lib/tls/libc.so.6
No symbol table info available.
#1 0xb7e63747 in abort () from /lib/tls/libc.so.6
No symbol table info available.
#2 0x082bcfd7 in ExceptionalCondition (
conditionName=0x837be2c !(n list-length),
errorType=0x837bb07 FailedAssertion, fileName=0x837bb00 list.c,
lineNumber=392) at assert.c:51
No locals.
#3 0x081a27de in list_nth_cell (list=0x84d2410, n=5) at list.c:392
match = (ListCell *) 0x84f3e2c
#4 0x081a287d in list_nth (list=0x84d2410, n=5) at list.c:413
No locals.
#5 0x08185324 in ExecOpenScanRelation (estate=0x84f1a34, scanrelid=6)
at execUtils.c:823
rtentry = (RangeTblEntry *) 0x84f3e2c
reloid = 139411100
lockmode = 1
resultRelInfos = (ResultRelInfo *) 0x84f1ac0
i = 1
#6 0x0818d8a0 in ExecInitIndexScan (node=0x84f0358, estate=0x84f1a34,
eflags=2) at nodeIndexscan.c:508
indexstate = (IndexScanState *) 0x84f3e2c
---Type return to continue, or q return to quit---
currentRelation = 0x2
relistarget = 0 '\0'
#7 0x0817b7fb in ExecInitNode (node=0x84f0358, estate=0x84f1a34, eflags=2)
at execProcnode.c:169
result = (PlanState *) 0x84f1a34
subps = (List *) 0x0
l = (ListCell *) 0x1
#8 0x0818758c in ExecInitAppend (node=0x84f06b0, estate=0x84f1a34, eflags=2)
at nodeAppend.c:215
appendstate = (AppendState *) 0x84f3d8c
appendplanstates = (PlanState **) 0x84f3e18
nplans = 2
i = 0
initNode = (Plan *) 0x84f0358
#9 0x0817b78b in ExecInitNode (node=0x84f06b0, estate=0x84f1a34, eflags=2)
at execProcnode.c:146
result = (PlanState *) 0x84f2a44
subps = (List *) 0x0
l = (ListCell *) 0x0
#10 0x0819040d in ExecInitNestLoop (node=0x84f0974, estate=0x84f1a34, eflags=0)
at nodeNestloop.c:323
nlstate = (NestLoopState *) 0x84f279c
#11 0x0817b8bf in ExecInitNode
Re: [HACKERS] array_accum aggregate
Tom Lane wrote: Stephen Frost [EMAIL PROTECTED] writes: * Tom Lane ([EMAIL PROTECTED]) wrote: It looks like it should work to have just one polymorphic aggregate definition, eg, array_accum(anyelement) returns anyarray. I was hoping to do that, but since it's an aggregate the ffunc format is pre-defined to require accepting the 'internal state' and nothing else, and to return 'anyelement' or 'anyarray' one of the inputs must be an 'anyelement' or 'anyarray', aiui. Hmm ... I hadn't been thinking about what the state type would need to be, but certainly bytea is a lie given what you're really doing. We've run into this same problem in contrib/intagg: sometimes you'd like to use a state data structure that isn't any regular SQL datatype, and in particular isn't just a single blob of memory. That's a problem from nodeAgg's point of view because it expects to be responsible for copying the state value from one context to another. Don't have an immediate idea for a solution ... I used an int8 as state type for an implementation of a kind of array_accum_unique aggregate. I know that it's a ugly hack, but it has been running on a production machine for months now, without a problem... The memory is alloc'd from the aggcontext, btw. Note that I only use this aggregate in one particular query - so there might be problems with my approach that just don't manifest in my particular situation. For example, the aggregate is used only on a table that is never updated, and it is only used in select queries. So there might be problems if the executor decides that it has to restart a query... greetings, Florian Pflug ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] FailedAssertion() in 8.2beta1
Sergey E. Koposov [EMAIL PROTECTED] writes: I've found a bug with 8.2beta1: Can you put together a self-contained test case for this? The planner is evidently generating an incorrect plan from that messy view, but trying to reverse-engineer the complete scenario from what you've told us looks painful. (No, I don't think the log setting is related.) regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] FailedAssertion() in 8.2beta1
On Sat, 7 Oct 2006, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
I'll try, but it will be quite hard.
is evidently generating an incorrect plan from that messy view, but
trying to reverse-engineer the complete scenario from what you've told
us looks painful. (No, I don't think the log setting is related.)
At least the plan for the problematic query looks like this
cas=# explain UPDATE table_list SET description = 'tag{image
SRC=/vizier/new2.gif}3rd release of DENIS (2005Sep)' WHERE id =
cas_get_table_id ('cas_data_sega','b_denis_denis5' );
QUERY PLAN
Nested Loop (cost=0.01..17.11 rows=2 width=82)
- Index Scan using table_user_list_pkey on table_user_list
(cost=0.00..8.02 rows=1 width=10)
Index Cond: (cas_get_table_id('cas_data_sega'::character varying,
'b_denis_denis5'::character varying) = id)
- Append (cost=0.00..9.07 rows=2 width=76)
- Index Scan using table_user_list_pkey on table_user_list
(cost=0.00..8.02 rows=1 width=76)
Index Cond: (id = cas_get_table_id('cas_data_sega'::character
varying, 'b_denis_denis5'::character varying))
- Seq Scan on table_list (cost=0.00..1.04 rows=1 width=51)
Filter: (id = cas_get_table_id('cas_data_sega'::character
varying, 'b_denis_denis5'::character varying))
(8 rows)
As I see from it, it generates two seq. scans for one table (table_user_list)
Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Regards,
Sergey
***
Sergey E. Koposov
Max Planck Institute for Astronomy/Sternberg Astronomical Institute
Tel: +49-6221-528-349
Web: http://lnfm1.sai.msu.ru/~math
E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] FailedAssertion() in 8.2beta1
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
cas=# explain UPDATE table_list SET description = 'tag{image
SRC=/vizier/new2.gif}3rd release of DENIS (2005Sep)' WHERE id =
cas_get_table_id ('cas_data_sega','b_denis_denis5' );
QUERY PLAN
Nested Loop (cost=0.01..17.11 rows=2 width=82)
- Index Scan using table_user_list_pkey on table_user_list
(cost=0.00..8.02 rows=1 width=10)
Index Cond: (cas_get_table_id('cas_data_sega'::character varying,
'b_denis_denis5'::character varying) = id)
- Append (cost=0.00..9.07 rows=2 width=76)
- Index Scan using table_user_list_pkey on table_user_list
(cost=0.00..8.02 rows=1 width=76)
Index Cond: (id = cas_get_table_id('cas_data_sega'::character
varying, 'b_denis_denis5'::character varying))
- Seq Scan on table_list (cost=0.00..1.04 rows=1 width=51)
Filter: (id = cas_get_table_id('cas_data_sega'::character
varying, 'b_denis_denis5'::character varying))
(8 rows)
As I see from it, it generates two seq. scans for one table (table_user_list)
I meant index scans.
By the way, I sent again the full info about the used tables .
cas=# \d cas_metadata_sega.table_user_list
Table cas_metadata_sega.table_user_list
Column| Type|Modifiers
-+---+-
id | integer | not null default
nextval('table_list_id_seq'::regclass)
catalog_id | bigint|
name| character varying | not null
info| character varying |
description | character varying |
Indexes:
table_user_list_pkey PRIMARY KEY, btree (id)
table_user_list_catalog_id_key UNIQUE, btree (catalog_id, name)
Foreign-key constraints:
table_user_list_catalog_id_fkey FOREIGN KEY (catalog_id) REFERENCES
catalog_user_list(id) ON UPDATE CASCADE ON DELETE CASCADE
cas=# \d cas_metadata_sega.table_list
View cas_metadata_sega.table_list
Column| Type| Modifiers
-+---+---
id | integer |
catalog_id | bigint|
name| character varying |
info| character varying |
description | character varying |
View definition:
SELECT table_user_list.id, table_user_list.catalog_id, table_user_list.name,
table_user_list.info, table_user_list.description
FROM table_user_list
UNION ALL
SELECT table_list.id, table_list.catalog_id, table_list.name, table_list.info,
table_list.description
FROM cas_metadata.table_list;
Rules:
rule_delete_table AS
ON DELETE TO table_list DO INSTEAD DELETE FROM table_user_list
rule_insert_table AS
ON INSERT TO table_list DO INSTEAD INSERT INTO table_user_list
(catalog_id, name, info, description) SELECT new.catalog_id, new.name,
new.info, new.description
rule_update_table AS
ON UPDATE TO table_list DO INSTEAD UPDATE table_user_list SET catalog_id =
new.catalog_id, name = new.name, info = new.info, description = new.description
WHERE table_user_list.id = new.id
cas=# \d cas_metadata.table_list
Table cas_metadata.table_list
Column| Type|Modifiers
-+---+-
id | integer | not null default
nextval('table_list_id_seq'::regclass)
catalog_id | bigint|
name| character varying | not null
info| character varying |
description | character varying |
Indexes:
table_list_pkey PRIMARY KEY, btree (id)
table_list_catalog_id_key UNIQUE, btree (catalog_id, name)
table_list_catalog_id_idx btree (catalog_id)
table_list_name_idx btree (name)
Foreign-key constraints:
table_list_catalog_id_fkey FOREIGN KEY (catalog_id) REFERENCES
cas_metadata.catalog_list(id) ON UPDATE CASCADE ON DELETE CASCADE
Regards,
Sergey
***
Sergey E. Koposov
Max Planck Institute for Astronomy/Sternberg Astronomical Institute
Tel: +49-6221-528-349
Web: http://lnfm1.sai.msu.ru/~math
E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] FailedAssertion() in 8.2beta1
Sergey E. Koposov [EMAIL PROTECTED] writes: Will it be enough to provide the testcase for just that 'expain UPDATE' ? Whatever makes it crash ;-) My guess is that there's some rewriter interaction involved, which means that the rule itself is part of the problem --- you'll likely not be able to duplicate it without a similar rule. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Checking max_stack_depth automatically
I have just realized that getrlimit(RLIMIT_STACK) is a pretty widely available syscall --- it's specified by the Single Unix Spec and the man pages claim it works on all the platforms I have handy to check. I propose that we make use of this call where available to prevent people from setting max_stack_depth larger than, say, the current stack rlimit less half a megabyte. This will prevent pilot error such as here: http://archives.postgresql.org/pgsql-bugs/2006-10/msg00053.php It'd be even nicer to not have a max_stack_depth GUC at all, but it's probably untenable to assume that getrlimit is available on every platform. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] FailedAssertion() in 8.2beta1
On Sat, 7 Oct 2006, Tom Lane wrote:
Sergey E. Koposov [EMAIL PROTECTED] writes:
Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
So, the database schema with little data and a few functions is here
http://lnfm1.sai.msu.ru/~math/public_misc/cas.dump
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql)
(it's possible to rewrite it in C with libpq, but I cannot do that very
easily).
Regards,
Sergey
***
Sergey E. Koposov
Max Planck Institute for Astronomy/Sternberg Astronomical Institute
Tel: +49-6221-528-349
Web: http://lnfm1.sai.msu.ru/~math
E-mail: [EMAIL PROTECTED]import java.sql.*;
public class xx
{
public static void main(String args[]) throws Exception
{
Class.forName(org.postgresql.Driver);
Connection conn =
DriverManager.getConnection(jdbc:postgresql://localhost:5432/cas,math,);
//Thread.sleep(1);
conn.setAutoCommit(false);
Statement stmt = conn.createStatement();
stmt.execute(set search_path to cas_metadata_sega, cas_metadata);
String query=UPDATE table_list SET description = ? WHERE +
id = cas_get_table_id ( ?,? );
String desc=\\tag{image SRC=\/vizier/new2.gif\}3rd release of DENIS
(2005Sep);
PreparedStatement pstmt = conn.prepareStatement(query);
String catalog=cas_data_sega;
String table=b_denis_denis5;
pstmt.setString(1,desc);
pstmt.setString(2,catalog);
pstmt.setString(3,table);
pstmt.executeUpdate();
pstmt.close();
conn.rollback();
}
}
---(end of broadcast)---
TIP 6: explain analyze is your friend
[HACKERS] libreadline only used with psql?
I've grepped through the source code, and the only thing I can find that uses readline (or libedit) is psql. Is that correct? If that's the case, how hard would it be to link only psql with readline (or libedit)? Currently, if you ./configure with readline support, -lreadine (or - ledit) is added to the used-by-everything LIBS variable. Can we create a PSQL_LIBS variable and have ./configure populate that with libraries that will only be needed by psql? That way, ./configure can put -lreadline there and keep it out of LIBS so all the other binaries (postmaster, pg_ctl, pg_dump, pg_restore, etc) won't require it. This request would be accompanied by a patch, but I wanted to ask about the feasibility of a PSQL_LIBS variable before going down that road. Thanks! - Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] FailedAssertion() in 8.2beta1
On Sat, 7 Oct 2006, Sergey E. Koposov wrote: And the java program crashing the backend is attached. (it is generally one prepared statement , which i didn't succeded to crash from psql) (it's possible to rewrite it in C with libpq, but I cannot do that very easily). As I did before, I send the strace ouput showing what jdbc is sending to the backend. send(5, \0\0\0E\0\3\0\0user\0math\0database\0xx\0client_encoding\0UNICODE\0DateStyle\0ISO\0\0, 69, 0) = 69 send(5, P\0\0\0\20S_1\0BEGIN\0\0\0B\0\0\0\17\0S_1\0\0\0\0\0\0\0E\0\0\0\t\0\0\0\0\0P\0\0\0:\0set search_path to cas_metadata_sega, cas_metadata\0\0\0B\0\0\0\f\0\0\0\0\0\0\0\0D\0\0\0\6P\0E\0\0\0\t\0\0\0\0\0S\0\0\0\4, 137, 0) = 137 send(5, P\0\0\0a\0UPDATE table_list SET description = $1 WHERE id = cas_get_table_id ( $2,$3 )[EMAIL PROTECTED] SRC=\/vizier/new2.gif\}3rd release of DENIS (2005Sep)\0\0\0\rcas_data_sega\0\0\0\16b_denis_denis5\0\0D\0\0\0\6P\0E\0\0\0\t\0\0\0\0\1S\0\0\0\4, 242, 0) = 242 Regards, Sergey *** Sergey E. Koposov Max Planck Institute for Astronomy/Sternberg Astronomical Institute Tel: +49-6221-528-349 Web: http://lnfm1.sai.msu.ru/~math E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Select for update with outer join broken?
Tom, OK, figured out what happened. I submitted the desired change, *coincidentally* right before the error message got broken. As a result, I mistakenly believed that the behaviour had been fixed by someone else before I could get to a patch. Since I was travelling at the time (OSCON) I didn't check to see that there actually had been a patch. OOops. I will have to find standards documentation on this grey area and hopefully submit something for 8.3. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] FailedAssertion() in 8.2beta1
Tom Lane [EMAIL PROTECTED] writes: Sergey E. Koposov [EMAIL PROTECTED] writes: I've found a bug with 8.2beta1: Can you put together a self-contained test case for this? The planner is evidently generating an incorrect plan from that messy view, but trying to reverse-engineer the complete scenario from what you've told us looks painful. (No, I don't think the log setting is related.) Would a core dump file (and his binary) be useful? Earlier I was going to suggest he execute these commands from gdb: f 5 p *rtentry p *estate But I fear even that won't be enough to actually track down where the state got corrupted. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] FailedAssertion() in 8.2beta1
Sergey E. Koposov [EMAIL PROTECTED] writes: As I did before, I send the strace ouput showing what jdbc is sending to the backend. Thanks. I've been able to reproduce it now, and I think the plan is actually OK, but for some reason the wrong rtable list is getting sent along to the executor. Looking ... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] libreadline only used with psql?
Chris Campbell wrote: If that's the case, how hard would it be to link only psql with readline (or libedit)? This is already addressed, more or less, in 8.2. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 translation status?
Josh Berkus wrote: I'd really like to get the Japanese translations merged with the main distribution. I've asked JPUG about this, and haven't been able to get an answer on whether this is reasonable for 8.2. Do you have any idea? I don't know what format they have or why they have never contributed their stuff, but they're certainly welcome. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] FailedAssertion() in 8.2beta1
Sergey E. Koposov [EMAIL PROTECTED] writes: And the java program crashing the backend is attached. (it is generally one prepared statement , which i didn't succeded to crash from psql) Right, because the bug was in exec_bind_message, which you can't invoke from psql :-(. Fixed, but we really need to think harder about having a test suite that makes use of the Parse/Bind/Execute protocol path... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Checking max_stack_depth automatically
I wrote: I have just realized that getrlimit(RLIMIT_STACK) is a pretty widely available syscall --- it's specified by the Single Unix Spec and the man pages claim it works on all the platforms I have handy to check. I propose that we make use of this call where available to prevent people from setting max_stack_depth larger than, say, the current stack rlimit less half a megabyte. I've committed changes along this line, and am now wondering whether there isn't some equivalent to getrlimit(RLIMIT_STACK) on Windows (I somehow doubt that the syscall exists as such ;-)). If someone can provide a patch to postgres.c's new get_stack_depth_rlimit() function, please do. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] libreadline only used with psql?
Peter Eisentraut [EMAIL PROTECTED] writes: Chris Campbell wrote: If that's the case, how hard would it be to link only psql with readline (or libedit)? This is already addressed, more or less, in 8.2. We've suppressed libreadline in the backend, but not in any of the other client programs (eg, pg_dump still has it). Not sure whether Chris really cares about those. In any case, I think it's inappropriate for configure to know exactly which programs need which libraries. It'd probably be more maintainable in the long run to propagate src/backend/Makefile's technique into the other Makefiles: # The backend doesn't need everything that's in LIBS, however LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses, $(LIBS)) with suitable adjustment of the filter list for each program. (But possibly -lreadline -ledit -ltermcap -lncurses -lcurses should be factored out as a READLINE_LIBS variable or some such.) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump exclusion switches and functions/types
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: The existing patch's behavior is that the rightmost switch wins, ie, if an object's name matches more than one pattern then it is included or excluded according to the rightmost switch it matches. My first thought is that the rule should be to apply all the inclusion switches (implicitly including everything if there are none), then apply all the exclusion switches. I kinda like that, because it makes the behavior completely independent of switch ordering, which seems like a good property to preserve. Anyone else have an opinion pro or con? That leads to including non-schema objects only if there are no schema inclusion switches. Which seems pretty logical since if you're explicitly including objects then you'll only expect objects explicitly included to be dumped and you'll quickly realize there's no switch to bring in those non-schema objects. Maybe there should be a switch to include them just for completeness. Well, pg_dump already has a --blobs switch, which has been a no-op (because now the default) since 8.1, but it's still in the switch parser. It wouldn't take much to revive it for the purpose of causing blobs to be dumped even when there's an inclusion switch. As for PLs, I'm not really too worried about dumping them per se (since it's usually easy enough to create the ones you're using). The functionality we're really lacking there is the --include-dependencies switch that was discussed upthread ... which I think is a fine idea but should wait for 8.3. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Man pages
I've built man pages for 8.2beta1. They are on the FTP server at the usual place and should appear in the next tarball. Please let me know if you find formatting mistakes. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump exclusion switches and functions/types
Tom, I kinda like that, because it makes the behavior completely independent of switch ordering, which seems like a good property to preserve. Anyone else have an opinion pro or con? The only con argument I can think of is that tar and rsync, whose syntax is familiar to a lot of sysadmins, apply switches left-to-right. However, I don't feel that that is a compelling argument. The include/exclude switch order processing is something I've always *hated* about tar and has messed me up more times than I can count. Also, Windows users could care less if we behave like tar. So +1 to go with orderless switching. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_dump exclusion switches and functions/types
I wrote: One argument that occurs to me for importing the psql code is that it's solved the problem of including a schema name in the pattern. It would be a lot nicer to say -t schema.table than to have to say -t table -n schema. The more I think about this, the more I think the above is a killer argument. We really should have had the ability to say -t schema.table ever since schemas were added in 7.3, but no one got around to making it happen. If we go over to interpreting the arguments as standard regexes then we'll never be able to do that, because we'll have foreclosed the meaning of dot. The psql pattern code was specifically designed as a compromise notation adapted to SQL needs, and IMHO it's served pretty well --- so I think we should adopt that into pg_dump rather than pure regex notation. The psql code does allow you to get at most of the functionality of regexes... Actually, it lets you get at all of it, though perhaps a bit awkwardly. The transformations it makes are . = schema vs name separator * = .* ? = . So the only regex patterns you can't write directly are dot, R* and R? for which you can use these locutions: . = ? R* = (R+|) R? = (R|) (Perhaps this should be documented somewhere...) So I propose that we should revise the patch to use psql's \d code to determine which objects match a pattern. I think that together with Greg's idea of processing all inclusions before all exclusions should answer the concerns I've got about the patch. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] FailedAssertion() in 8.2beta1
On Sat, 7 Oct 2006, Tom Lane wrote: Sergey E. Koposov [EMAIL PROTECTED] writes: And the java program crashing the backend is attached. (it is generally one prepared statement , which i didn't succeded to crash from psql) Right, because the bug was in exec_bind_message, which you can't invoke from psql :-(. Fixed, but we really need to think harder about having a test suite that makes use of the Parse/Bind/Execute protocol path... Thanks Tom, the problem went away. Regards, Sergey *** Sergey E. Koposov Max Planck Institute for Astronomy/Sternberg Astronomical Institute Tel: +49-6221-528-349 Web: http://lnfm1.sai.msu.ru/~math E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_dump exclusion switches and functions/types
On Fri, Oct 06, 2006 at 10:28:21PM -0400, Gregory Stark wrote: Tom Lane [EMAIL PROTECTED] writes: The existing patch's behavior is that the rightmost switch wins, ie, if an object's name matches more than one pattern then it is included or excluded according to the rightmost switch it matches. This is, erm, poorly documented, but it seems like useful behavior so I don't have an objection myself. I don't know, it sounds like it's the source of the confusion you identify later. My first thought is that the rule should be to apply all the inclusion switches (implicitly including everything if there are none), then apply all the exclusion switches. +1 :) Order-dependent switches are a giant foot gun. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] The improvement for psql of 8.2beta1 not implemented under Windows
According to the release notes of 8.2, the following item should have been implemented, E.1.3.11. psql ChangesSave multi-line statements as a single entry, rather than one line at a time (Sergey E. Koposov) This makes up-arrow recall of queries easier. The test shows that it's OK under Linux (Slackware), but malfunctioned on Windows XP.Daojing.Zhou from P.R.Chttp://www.pgsqldb.org/
