> I concluded that patching vacuum.c was much the cleanest way to do it.
> Here's the patch against 8.1 branch.
Great, it looks like this patch fixes the remainder of my original problem as
well !
( http://archives.postgresql.org/pgsql-bugs/2005-11/msg00276.php )
--
Best,
Frank.
---
On Jan 4, 2006, at 11:47 AM, Tom Lane wrote:
Brian Hirt <[EMAIL PROTECTED]> writes:
I was just writing to let you know I created an easily reproducible
test case too, but I guess you don't need that now.
Does your test case agree with my description of the problem?
(If you're not sure, crank
Brian Hirt <[EMAIL PROTECTED]> writes:
> Also, if a patch is produced, I'd love to get a copy of it.
I concluded that patching vacuum.c was much the cleanest way to do it.
Here's the patch against 8.1 branch.
regards, tom lane
Index: src/backend/commands/vacuum.c
Brian Hirt <[EMAIL PROTECTED]> writes:
> I was just writing to let you know I created an easily reproducible
> test case too, but I guess you don't need that now.
Does your test case agree with my description of the problem?
(If you're not sure, crank up log_min_messages and watch the log
to see
Cool,
I was just writing to let you know I created an easily reproducible
test case too, but I guess you don't need that now.
Let me know if there is anything else I can do to help.
Also, if a patch is produced, I'd love to get a copy of it. We just
upgraded our production servers to 8.1.1
Brian Hirt <[EMAIL PROTECTED]> writes:
> I can analyze that table without problems. I don't know if it's the
> same table every time. I'm trying to set up a development
> environment where i can test this stuff better without messing up our
> production systems. The table does have an expr
Tom,
I can analyze that table without problems. I don't know if it's the
same table every time. I'm trying to set up a development
environment where i can test this stuff better without messing up our
production systems. The table does have an expresional index.
basement=# select relna
On 1/4/06, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 04, 2006 at 12:20:28PM -0500, Jaime Casanova wrote:
> > On 1/4/06, Brian Hirt <[EMAIL PROTECTED]> wrote:
> > > that's strange, because I'm running 8.1.1.
> >
> > what Tom is saying is that a patch was applied after 8.1.1 was
> > launc
On Wed, Jan 04, 2006 at 12:20:28PM -0500, Jaime Casanova wrote:
> On 1/4/06, Brian Hirt <[EMAIL PROTECTED]> wrote:
> > that's strange, because I'm running 8.1.1.
>
> what Tom is saying is that a patch was applied after 8.1.1 was
> launched...
Is that what Tom is saying? The commit message he pos
Brian Hirt <[EMAIL PROTECTED]> writes:
> Is there more information i can provide to help find the problem?
How about the schema of the table in question? If the backtrace is
to be trusted, it's OID 32465292.
Does it crash if you ANALYZE that table manually?
regards, tom
On 1/4/06, Brian Hirt <[EMAIL PROTECTED]> wrote:
> that's strange, because I'm running 8.1.1.
>
what Tom is saying is that a patch was applied after 8.1.1 was
launched... it will be fixed in 8.1.2 and if you are installing from
sources you can apply yourself the patch to your tree source recompile
that's strange, because I'm running 8.1.1.
[EMAIL PROTECTED] root]# /usr/pg-8.1/bin/postmaster --version
postmaster (PostgreSQL) 8.1.1
Is there more information i can provide to help find the problem?
On Jan 4, 2006, at 10:04 AM, Tom Lane wrote:
Brian Hirt <[EMAIL PROTECTED]> writes:
When I'
Brian Hirt <[EMAIL PROTECTED]> writes:
> When I'm doing a database load of a 5gb database, autovacuum always
> segfaults shortly after the load finishes.
This sure looks like the same bug already fixed in 8.1.1:
2005-11-28 08:35 alvherre
* src/backend/postmaster/autovacuum.c: Set a snap
Hi.When I'm doing a database load of a 5gb database, autovacuum alwayssegfaults shortly after the load finishes. The load is being done via slony during the initial copy set command while building a slave, not throughpg_restore. LOG: autovacuum process (PID ...) was terminated by signal 11LOG: t
14 matches
Mail list logo
