Re: [HACKERS] SIGSEGV in BRIN autosummarize

Alvaro Herrera wrote: > Alvaro Herrera wrote: > > > Before pushing, I'll give a look to the regular autovacuum path to see > > if it needs a similar fix. > > Reading that one, my conclusion is that it doesn't have the same problem > because the strings are allocated in AutovacuumMemCxt which is

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Alvaro Herrera wrote: > Before pushing, I'll give a look to the regular autovacuum path to see > if it needs a similar fix. Reading that one, my conclusion is that it doesn't have the same problem because the strings are allocated in AutovacuumMemCxt which is not reset by error recovery. This

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Tom Lane wrote: > What I'm suspicious of as the actual bug cause is the comment in > perform_work_item about how we need to be sure that we're allocating these > strings in a long-lived context. If, in fact, they were allocated in some > context that could get reset during the PG_TRY

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Alvaro Herrera writes: > And the previous code crashes in 45 minutes? That's solid enough for > me; I'll clean up the patch and push in the next few days. I think what > you have now should be sufficient for the time being for your production > system. I'm still of the

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Wed, Oct 18, 2017 at 07:22:27PM +0200, Alvaro Herrera wrote: > Do you still have those core dumps? If so, would you please verify the > database that autovacuum was running in? Just open each with gdb (using > the original postgres binary, not the one you just installed) and do > "print

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby wrote: > On Wed, Oct 18, 2017 at 06:54:09PM +0200, Alvaro Herrera wrote: > > And the previous code crashes in 45 minutes? That's solid enough for > > me; I'll clean up the patch and push in the next few days. I think what > > you have now should be sufficient for the time being

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Wed, Oct 18, 2017 at 06:54:09PM +0200, Alvaro Herrera wrote: > Justin Pryzby wrote: > > > No crashes in ~28hr. It occurs to me that it's a weaker test due to not > > preserving most compilation options. > > And the previous code crashes in 45 minutes? That's solid enough for > me; I'll

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby wrote: > No crashes in ~28hr. It occurs to me that it's a weaker test due to not > preserving most compilation options. And the previous code crashes in 45 minutes? That's solid enough for me; I'll clean up the patch and push in the next few days. I think what you have now

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Tue, Oct 17, 2017 at 09:07:40AM -0500, Justin Pryzby wrote: > On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote: > > Justin Pryzby writes: > > > On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: > > >> Anyway, can give this patch a try? > > > > The

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Alvaro Herrera writes: > cur_datname here seems corrupted -- it points halfway into cur_nspname, > which is also a corrupt value. Yeah. > And I think that's because we're not > checking that the namespace OID is a valid value before calling > get_namespace_name on it.

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On 17 October 2017 at 22:39, Tom Lane wrote: > Justin Pryzby writes: >> On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote: >>> So: where did you get the existing binaries? If it's from some vendor >>> packaging system, what you should do is fetch

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby wrote: > I'm happy to try the patch, but in case it makes any difference, we have few > DBs/schemas: I don't expect that it does. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby writes: > On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote: >> So: where did you get the existing binaries? If it's from some vendor >> packaging system, what you should do is fetch the package source, add >> the patch to the probably-nonempty set of

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Tue, Oct 17, 2017 at 09:34:24AM -0400, Tom Lane wrote: > Justin Pryzby writes: > > On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: > >> Anyway, can give this patch a try? > > > I've only compiled postgres once before and this is a production environment >

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby writes: > On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: >> Anyway, can give this patch a try? > I've only compiled postgres once before and this is a production environment > (althought nothing so important that the crashes are a serious

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On 10/17/2017 02:29 PM, Justin Pryzby wrote: > On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: >> Anyway, can give this patch a try? > > I've only compiled postgres once before and this is a production environment > (althought nothing so important that the crashes are a serious

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: > Justin Pryzby wrote: > > > #1 0x006a52e9 in perform_work_item (workitem=0x7f8ad1f94824) at > > autovacuum.c:2676 > > cur_datname = 0x298c740 "no 1 :vartype 1184 :vartypmod -1 > > :varcollid 0 :varlevelsup 0

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Tue, Oct 17, 2017 at 12:59:16PM +0200, Alvaro Herrera wrote: > Anyway, can give this patch a try? I've only compiled postgres once before and this is a production environment (althought nothing so important that the crashes are a serious concern either). Is it reasonable to wget the postgres

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby wrote: > #1 0x006a52e9 in perform_work_item (workitem=0x7f8ad1f94824) at > autovacuum.c:2676 > cur_datname = 0x298c740 "no 1 :vartype 1184 :vartypmod -1 :varcollid > 0 :varlevelsup 0 :varnoold 1 :varoattno 1 :location 146} {CONST :consttype > 1184 :consttypmod -1

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Justin Pryzby wrote: > On Sun, Oct 15, 2017 at 02:44:58PM +0200, Tomas Vondra wrote: > > Thanks, but I'm not sure that'll help, at this point. We already know > > what happened (corrupted memory), we don't know "how". And core files > > are mostly just "snapshots" so are not very useful in

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Sun, Oct 15, 2017 at 02:44:58PM +0200, Tomas Vondra wrote: > Thanks, but I'm not sure that'll help, at this point. We already know > what happened (corrupted memory), we don't know "how". And core files > are mostly just "snapshots" so are not very useful in answering that :-( Is there

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Sat, Oct 14, 2017 at 08:56:56PM -0500, Justin Pryzby wrote: > On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: > > > Also notice the vacuum process was interrupted, same as yesterday (think > > > goodness for full logs). Our INSERT script is using python > > >

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Hi, On 10/15/2017 03:56 AM, Justin Pryzby wrote: > On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: ... >> It's a bit difficult to guess what went wrong from this backtrace. For >> me gdb typically prints a bunch of lines immediately before the frames, >> explaining what went wrong

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: > > Also notice the vacuum process was interrupted, same as yesterday (think > > goodness for full logs). Our INSERT script is using python > > multiprocessing.pool() with "maxtasksperchild=1", which I think means we > > load > > one

Re: [HACKERS] SIGSEGV in BRIN autosummarize

Hi, On 10/15/2017 12:42 AM, Justin Pryzby wrote: > On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: >> I don't have any reason to believe there's memory issue on the server, So I >> suppose this is just a "heads up" to early adopters until/in case it happens >> again and I can at

Re: [HACKERS] SIGSEGV in BRIN autosummarize

On Fri, Oct 13, 2017 at 10:57:32PM -0500, Justin Pryzby wrote: > I don't have any reason to believe there's memory issue on the server, So I > suppose this is just a "heads up" to early adopters until/in case it happens > again and I can at least provide a stack trace. I'm back; find stacktrace

[HACKERS] SIGSEGV in BRIN autosummarize

I upgraded one of our customers to PG10 Tuesday night, and Wednesday replaced an BTREE index with BRIN index (WITH autosummarize). Today I see: < 2017-10-13 17:22:47.839 -04 >LOG: server process (PID 32127) was terminated by signal 11: Segmentation fault < 2017-10-13 17:22:47.839 -04 >DETAIL:

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Sat, Nov 12, 2005 at 10:46:33PM -0800, Kevin Brown wrote: Hmm...but isn't the version number also something that can be stored in the shared library itself during link time (e.g., via the -soname option to the linker)? The manpage for ld under Linux implies that this will cause the

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Martijn van Oosterhout wrote: None of this applies to PostgreSQL because we open the modules directly, and don't rely on the linker loader. Ah, right. I forgot the context was the server, not one of the utilities... Sorry for the waste of bandwidth... -- Kevin Brown

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Gregory Maxwell wrote: So it turned out that he didn't... Is this a sign that we need to include a versioning symbol in SOs so we can give a nice clear error message module foo compiled for PostgreSQL 8.0.2 this is PostgreSQL 8.1. I think this would rarely work in practice. For example,

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Sat, Nov 12, 2005 at 12:28:48PM +0100, Peter Eisentraut wrote: I think this would rarely work in practice. For example, during the elog-ereport transition, any module compiled against the wrong server would immediately get an unresolved symbol: elog/ereport before you can run your nice

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Martijn van Oosterhout kleptog@svana.org writes: So the idea is to force failure when it would otherwise succeed, not just for the pretty error messages but for stability of the system. Exactly. Peter's right that we'd not always get a nice error message --- but it's not hard to figure out

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

I thought of an alternative approach to the library version problem: what about taking a leaf from the usual shared library versioning approach, ie, put the version number into the library file name? So instead of loading, say, plpgsql.so we'd insist on loading plpgsql.so.8.2. This would avoid

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Sat, Nov 12, 2005 at 10:47:35AM -0500, Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: I would be in favour if storing the CATALOG_VERSION in the pg_finfo struct and rejecting anything that doesn't match. Not sure that CATALOG_VERSION is an amazingly useful thing to

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Martijn van Oosterhout kleptog@svana.org writes: Sure, CATALOG_VERSION isn't that useful, but it's the only thing in the header files that gives any kind of indication what version you're compiling against. PG_VERSION is a string, which diminishes its usefulness considerably. How so? All we

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Sat, Nov 12, 2005 at 11:18:51AM -0500, Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: Sure, CATALOG_VERSION isn't that useful, but it's the only thing in the header files that gives any kind of indication what version you're compiling against. PG_VERSION is a string,

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Martijn van Oosterhout kleptog@svana.org writes: On Sat, Nov 12, 2005 at 11:18:51AM -0500, Tom Lane wrote: How so? All we care about is being able to (1) compare for equality, and (2) print out something useful in error messages. I claim that PG_VERSION does #1 equally well and #2 better.

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Sat, Nov 12, 2005 at 12:03:00PM -0500, Tom Lane wrote: That would be attractive if we could get it to happen without the assumption that the library uses PG_FUNCTION_INFO_V1 ... but if it still needs that assumption, it doesn't seem like much of an improvement. It's not always easy for

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Martijn van Oosterhout kleptog@svana.org writes: If we don't like imposing link time constraints, we could require people to include: #ifdef PG_MAGIC_BLOCK PG_MAGIC_BLOCK; #endif I was hoping to avoid forcing source-code changes, but something like that might be the best solution. Anyone

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Sat, Nov 12, 2005 at 12:44:23PM -0500, Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: If we don't like imposing link time constraints, we could require people to include: #ifdef PG_MAGIC_BLOCK PG_MAGIC_BLOCK; #endif I was hoping to avoid forcing source-code

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Martijn van Oosterhout kleptog@svana.org writes: I was hoping to avoid forcing source-code changes, but something like that might be the best solution. Anyone think it's unreasonable? Alternativly, you could make it optional for a release (print warning that magic block wasn't found). Next

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Tom Lane wrote: On the other hand, it'd be relatively easy for clueless lusers to defeat; I can readily imagine someone copying foo.so.8.2 to foo.so.8.3 when the backend complained that it couldn't find the latter. So maybe it's not what we want. Hmm...but isn't the version number also

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

I fixed path in pg_sphere (and done some more clean up). BTW, I usially install contrib modules before restoring database (of course, it need to dump db without content of modules)... -- Teodor Sigaev E-mail: [EMAIL PROTECTED]

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

I've also modified the Makefile. I removed the special .sql.in : .sql implicit rule and re-organized the Makefile. I didn't commit as it was after 12:00pm when I finished... I'll send you what I did when I return home. If you just replaced the $libdir with $$libdir, then a merge will be easy.

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Wed, 09 Nov 2005 10:54:12 +0300), Teodor Sigaev [EMAIL PROTECTED] confessed: So, I'm as sure as I can be right now. How can I check the .so files installed by the build? Do they reference an absolute path for their dependent .so files (postgres), or will

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Robert Creager wrote: Yup. You're right. So, what is happening here? It will be kind of hard to do a live dump/restore on 1 machine if I cannot have two versions running. Is something not set up correctly on my machine, or in the build (pg_sphere or postgresql) that is preventing two

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On 11/8/05, Tom Lane [EMAIL PROTECTED] wrote: Teodor Sigaev [EMAIL PROTECTED] writes: Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that old .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC. Does look a bit suspicious ... Robert, are you *sure*

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Robert Creager [EMAIL PROTECTED] writes: CREATE FUNCTION sbox_in(cstring) RETURNS sbox AS '/usr/local/pgsql802/lib/pg_sphere', 'spherebox_in' LANGUAGE c IMMUTABLE STRICT; Now if I can just figure out how to get this egg off my face... You'd be a lot better off to define all your

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Gregory Maxwell [EMAIL PROTECTED] writes: On 11/8/05, Tom Lane [EMAIL PROTECTED] wrote: Does look a bit suspicious ... Robert, are you *sure* you've got the right version of pgsphere linked in? So it turned out that he didn't... Is this a sign that we need to include a versioning symbol in

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Wed, Nov 09, 2005 at 10:57:25AM -0500, Tom Lane wrote: There are cases where it would work, and other cases where it wouldn't. Given the pain involved in debugging when it's wrong, maybe we should just endeavor to forbid loading of all wrong-version modules. I'm not sure that there's any

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Wed, 09 Nov 2005 09:56:51 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: Why use an absolute path? Why not just give the name of the .so and let postgres find it in $libdir (i.e. sed -e 's,/usr/local/pgsql.*/lib/,,' on your dump) ? 'cause I didn't know I could? I'll go and fix the

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Wed, 09 Nov 2005 10:42:00 -0500 Tom Lane [EMAIL PROTECTED] wrote: If pg_sphere is supplying a setup procedure that gets this wrong, yell at them. I'll just go fix it, now that I know what the right way is ;-) Thanks, Rob ---(end of

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Hmm, did you recompile pg_sphere module for 8.1? Robert Creager wrote: When grilled further on (Mon, 7 Nov 2005 22:25:17 -0700), Robert Creager [EMAIL PROTECTED] confessed: Sorry, I'll just trickle out the information. tassiv=# \d catalog_ra_decl_index Index public.catalog_ra_decl_index

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Tue, 08 Nov 2005 15:13:32 +0300), Teodor Sigaev [EMAIL PROTECTED] confessed: Hmm, did you recompile pg_sphere module for 8.1? Yes I did. Just did it again to make sure. Is there any way I can do a make installcheck without a reconfigure/make/install of postgresql?

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Robert Creager [EMAIL PROTECTED] writes: v-spl_right is address 0xbp - uninitialized? The whole struct looks pretty uninitialized, which immediately makes me wonder whether gdb has picked up a wrong value for v. Try going down to a lower stack frame and seeing if you can access the struct from

Re: [Pgsphere-dev] Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Robert Creager wrote: Yes I did. Just did it again to make sure. Is there any way I can do a make installcheck without a reconfigure/make/install of postgresql? The db is running on port 5433, not the default of 5432. export PGPORT=5433 If this is a PGSphere problem, should this

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Tue, 08 Nov 2005 09:20:13 -0500), Tom Lane [EMAIL PROTECTED] confessed: Robert Creager [EMAIL PROTECTED] writes: v-spl_right is address 0xbp - uninitialized? The whole struct looks pretty uninitialized, which immediately makes me wonder whether gdb has picked up a

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Robert Creager [EMAIL PROTECTED] writes: Is there any way I can do a make installcheck without a reconfigure/make/install of postgresql? The db is running on port 5433, not the default of 5432. Sure, just export PGPORT=5433 before make installcheck. Doubt it will prove much, though,

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Tom Lane wrote: Robert Creager [EMAIL PROTECTED] writes: v-spl_right is address 0xbp - uninitialized? The whole struct looks pretty uninitialized, which immediately makes me wonder whether gdb has picked up a wrong value for v. Try going down to a lower stack frame and seeing if you can

Re: [Pgsphere-dev] Re: [HACKERS] SIGSEGV taken on 8.1 during

When grilled further on (Tue, 08 Nov 2005 10:06:38 -0500), Tom Lane [EMAIL PROTECTED] confessed: Does PGSphere itself have any regression tests? (Actually, running the contrib regression tests might be more relevant than the main PG tests, since several contrib modules with GIST opclasses

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Teodor Sigaev [EMAIL PROTECTED] writes: Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that old .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC. Does look a bit suspicious ... Robert, are you *sure* you've got the right version of pgsphere linked in?

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

On Tue, 08 Nov 2005 11:12:04 -0500 Tom Lane [EMAIL PROTECTED] wrote: Teodor Sigaev [EMAIL PROTECTED] writes: Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that old .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC. Does look a bit suspicious ...

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Tue, 08 Nov 2005 11:12:04 -0500), Tom Lane [EMAIL PROTECTED] confessed: Teodor Sigaev [EMAIL PROTECTED] writes: Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that old .so is used. spl_(right|left)valid fields was added to GIST_SPLITVEC.

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

works fine contrib_regression=# select count(*) from test_data ; count --- 250 (1 row) contrib_regression=# create index test_data_index on test_data using gist( loc ); CREATE INDEX I've attached a small dump file that when I create an index on the table, it fails. It works on

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

So, I'm as sure as I can be right now. How can I check the .so files installed by the build? Do they reference an absolute path for their dependent .so files (postgres), or will they use ld.so.conf, which might then explain the problem. My ld.so.conf still points to the 8.0.2 version, as I've

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Sun, 6 Nov 2005 20:00:38 -0700), Robert Creager [EMAIL PROTECTED] confessed: Didn't set the core big enough (1Mb). It's now at 50Mb. I am using PGSphere, which should be the only gist indexes in use. gdb /usr/local/pgsql810/bin/postgres core.28053 ... warning: core

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Mon, 7 Nov 2005 08:07:14 -0700), Robert Creager [EMAIL PROTECTED] confessed: I'm currently attached to the dead (dying) process. spl_nright seems pretty large... (gdb) print v-spl_nright $3 = 138311580 Program received signal SIGSEGV, Segmentation fault. 0x08082057 in

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Mon, 7 Nov 2005 22:25:17 -0700), Robert Creager [EMAIL PROTECTED] confessed: Sorry, I'll just trickle out the information. tassiv=# \d catalog_ra_decl_index Index public.catalog_ra_decl_index Column | Type +--- loc| spherekey gist, for table

[HACKERS] SIGSEGV taken on 8.1 during dump/reload

Hey all, I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a segmentation violation 1 hour into the operation. My plan is to re-do the dump/restore, and if it fails again, to re-compile with debug and cassert, and try to get a core. The command line was (8.1.0 is on

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a different result from the 8.1 binaries? cheers andrew Robert Creager wrote: Hey all, I was doing a test run of a live dump from 8.0.2 to 8.1.0, and 8.1.0 took a segmentation violation 1 hour into the operation. My

Re: [HACKERS] SIGSEGV taken on 8.1 during dump/reload

When grilled further on (Sun, 06 Nov 2005 18:52:40 -0500), Andrew Dunstan [EMAIL PROTECTED] confessed: Which version is first in your path, 8.0 or 8.1? If 8.0, do you get a different result from the 8.1 binaries? 8.0 was first. I've specified the correct full path now for the

[HACKERS] SIGSEGV in Postgres 8.0.3 (libpq4)

Hi, I have a set of perl scripts which invoke each other (via system()); eventually I found that they were crashing and ultimately causing Perl to SIGSEGV. I am using Debian testing and have recompiled postgres-8.0.3-15 to include debugging symbols. This is a dual-CPU dual-stacked IPv4/IPv6

Re: [HACKERS] SIGSEGV on cvs tip/7.3.2

Christopher Kings-Lynne [EMAIL PROTECTED] writes: There's been some past speculation about putting in a function call nesting depth limit, but I haven't been able to think of any reasonable way to estimate a safe limit. GUC variable? Hmm...but that would mean that a normal user could still

Re: [HACKERS] SIGSEGV on cvs tip/7.3.2

There's been some past speculation about putting in a function call nesting depth limit, but I haven't been able to think of any reasonable way to estimate a safe limit. The stack size limit varies a lot across different platforms, and the amount of stack space consumed per PL function call

[HACKERS] SIGSEGV

Using cvs source of Dec 4 15:13: test=# \d amount Table public.amount Column | Type | Modifiers +-+ id | integer | not null default

Re: [HACKERS] SIGSEGV

Patrick Welche [EMAIL PROTECTED] writes: test=# select value from amount; server closed the connection unexpectedly This is a known bug also (in the domain-constraint patch, which has turned VALUE into a reserved word, a rather unpleasant price to pay for the feature IMHO). Rod claimed his

Re: [HACKERS] SIGSEGV

On Mon, 2002-12-09 at 19:04, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: test=# select value from amount; server closed the connection unexpectedly This is a known bug also (in the domain-constraint patch, which has turned VALUE into a reserved word, a rather unpleasant price

[HACKERS] SIGSEGV in postgres 7.0.0 for QNX

Hi, I am tring to use the qnx version of postgresql 7.0.0 I have qnx 4.25 and TCP/IP Ihave compiled postgres using gcc I have installed it. then I have started postgres with -D and -i options. The only commad that I can execute is initdb. When I execute any other commandI have a