Darci jose wrote:
I am not obtaining to intalar postgre 8,1 in fedora 3.
It can give an aid of as to install?
This is not a bug.
http://www.postgresql.org/
Click "downloads"
Click "FTP browser"
binary > v8.1.1 > linux > rpms > fedora > fedora-core-3
Download whatever RPMs you require and inst
The following bug has been logged online:
Bug reference: 2143
Logged by: Robert Osowiecki
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: Linux 2.6.14-gentoo-r5 #2 SMP Thu Dec 22 11:58:01 CET
2005 i686 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel G
On 1/4/06, Robert Osowiecki <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2143
> Logged by: Robert Osowiecki
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1.1
> Operating system: Linux 2.6.14-gentoo-r5 #2 SMP Thu Dec 2
"Robert Osowiecki" <[EMAIL PROTECTED]> writes:
> BUT when on "where ar_code = 'FOO'" unique_code_i index is used and query
> returns NO ROWS!
Could you be more specific? Which values of 'FOO' does this happen for?
What is the datatype of ar_code? If it's a string type, what locale and
encoding
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
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
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'
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
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 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
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
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
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
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
Tom Lane napisał(a):
"Robert Osowiecki" <[EMAIL PROTECTED]> writes:
BUT when on "where ar_code = 'FOO'" unique_code_i index is used and query
returns NO ROWS!
Could you be more specific? Which values of 'FOO' does this happen for?
I haven't checked for everyone. I'll be doing an
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
Tom Lane napisal:
Robert Osowiecki <[EMAIL PROTECTED]> writes:
Hm, are you using any plperl functions? This could be the same problem
already identified with plperl messing up the locale settings.
Yes, I am. Where can I read about that other problem, especially: does
plperl spoil locale
Robert Osowiecki <[EMAIL PROTECTED]> writes:
> Yes, I am. Where can I read about that other problem, especially: does
> plperl spoil locale with each pgperl function call or only when creating
> language?
It was discussed a week or two ago. We're still testing a patch, but
in the meantime you c
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
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
> 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.
---
Tom Lane napisał(a):
It was discussed a week or two ago. We're still testing a patch, but
in the meantime you can work around it by making sure that the
postmaster is started with environment variables LC_COLLATE and LC_CTYPE
matching the settings used in the database.
It seems to work. Th
The following bug has been logged online:
Bug reference: 2144
Logged by: John Supplee
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: Fedore Core 4
Description:Domain NOT NULL constraints ignored in rules
Details:
I have a database with
The following bug has been logged online:
Bug reference: 2145
Logged by: Glenn Gentry
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: Win32
Description:FTP Mirror to download is not found
Details:
I tried every suggested USA mirror for F
The following bug has been logged online:
Bug reference: 2142
Logged by: Brian Hirt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: redhat 7.3
Description:autovacuum process (PID 1641) was terminated by signal
11
Details:
When I'm doing
Please disregard. I submitted last night via the web and when it
didn't go through I joined the list and sent again. I guess it was
just slow to go through.
Thanks again to everyone who earlier today.
--brian
On Jan 3, 2006, at 10:52 PM, Brian Hirt wrote:
The following bug has been log
"John Supplee" <[EMAIL PROTECTED]> writes:
> Description:Domain NOT NULL constraints ignored in rules
Works for me:
regression=# create domain dint as int not null;
CREATE DOMAIN
regression=# create table t1 (f1 dint);
CREATE TABLE
regression=# create view v1 as select * from t1;
CREATE V
Have you already tried to close your browser, re-open the browser and
gone to the site again?
I have had problems in the past where I went to a download site, made a
selection, canceled the download before it finished, re-navigated
through the site, returned to the download site and then none of t
28 matches
Mail list logo
