On Mittwoch, 16. April 2008 Michael Monnerie wrote:
> problem with duplicate primary index entries...
I created the bayes db fresh, named it bayes_pg_v2 and re-relearned all
ham/spam from 3 concurrent connections into the db. No problem so far.
But I renamed the old, broken db and tried a
and g
On Tue, Apr 15, 2008 at 9:36 AM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Apr 9, 2008 at 4:47 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
> > Hello all
> >
> > my struggle with the database continues (see earlier thread titled "too
> > many trigger records found for relation xyz").
On Thu, Apr 17, 2008 at 3:38 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
> 2008-04-17 13:05:30 EEST [8435]: [32-1] ERROR: could not open relation
> 1663/16386/359232: No such file or directory
>
Looks like a corrupt index to me. DId you try REINDEX on the table ?
Thanks,
Pavan
--
Pavan Deol
On Thu, Apr 17, 2008 at 1:36 PM, Pavan Deolasee <[EMAIL PROTECTED]>
wrote:
> On Thu, Apr 17, 2008 at 3:38 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
> >
> > 2008-04-17 13:05:30 EEST [8435]: [32-1] ERROR: could not open relation
> > 1663/16386/359232: No such file or directory
> >
>
> Looks lik
Στις Thursday 17 April 2008 08:46:24 ο/η Achilleas Mantzios έγραψε:
> Στις Thursday 17 April 2008 08:25:22 ο/η Tom Lane έγραψε:
> > Achilleas Mantzios <[EMAIL PROTECTED]> writes:
> > >> Did you make the dump using 8.3's pg_dump?
> >
> > > Yes, with 8.3.1's pg_dump (data only dump)
> >
> > That wo
"Mikko Partio" <[EMAIL PROTECTED]> writes:
> Seems like the whole db is falling apart.
I think you've got really serious filesystem-level problems. Have you
tried running any hardware diagnostics? Are you sure you're using a
stable kernel version?
regards, tom lane
--
Michael Monnerie <[EMAIL PROTECTED]> writes:
> I'd like to drop that broken db, or should I keep it for analyzation?
Looking back over the thread, it seems that the problems you saw could
be explained by the VACUUM-related bugs we fixed in 8.1.9 and 8.1.10;
although obviously this theory requires
On Thu, Apr 17, 2008 at 6:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mikko Partio" <[EMAIL PROTECTED]> writes:
> > Seems like the whole db is falling apart.
>
> I think you've got really serious filesystem-level problems. Have you
> tried running any hardware diagnostics? Are you sure you're
"Mikko Partio" <[EMAIL PROTECTED]> writes:
> On Thu, Apr 17, 2008 at 6:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I think you've got really serious filesystem-level problems. Have you
>> tried running any hardware diagnostics? Are you sure you're using a
>> stable kernel version?
> I run fsck
On Thu, Apr 17, 2008 at 6:59 PM, Mikko Partio <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, Apr 17, 2008 at 6:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Mikko Partio" <[EMAIL PROTECTED]> writes:
> > > Seems like the whole db is falling apart.
> >
> > I think you've got really serious filesystem-
On Thu, Apr 17, 2008 at 7:06 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mikko Partio" <[EMAIL PROTECTED]> writes:
> > On Thu, Apr 17, 2008 at 6:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> I think you've got really serious filesystem-level problems. Have you
> >> tried running any hardware dia
Hi all,
I just upgraded one of my servers and I'm having a bit of trouble
getting some of the kerberos authentication bits working.
Specifically, any Kerberos instance run out of a v5srvtab doesn't work
so well. Using stashed tickets or normal principals worked fine.
Gritty details follow.
Peter
Hi.
I have a mostly insert/select database, so vacumming is generally not
much needed.. but among the tables I have one which is used as a
message-queue so a lot of insert/updates/deletes on small simple records
on that one.
How do I check that autovacumm is running at all? (I think i have
Hi,
I have daily cron jobs for database update, which where working fine on
Fedore Core 6. No I move it on Ubuntu Server 7.10 and postgres gives error:
"unexpected EOF on client connection"
while update running from cron. If I run this update manually from root
user - it works fine. Here is upda
>>> On Thu, Apr 17, 2008 at 3:21 PM, in message <[EMAIL PROTECTED]>,
David Jorjoliani <[EMAIL PROTECTED]> wrote:
> I have daily cron jobs for database update, which where working fine on
> Fedore Core 6. No I move it on Ubuntu Server 7.10 and postgres gives error:
>
> "unexpected EOF on client
On Fri, 18 Apr 2008 00:21:23 +0400
David Jorjoliani <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have daily cron jobs for database update, which where working fine on
> Fedore Core 6. No I move it on Ubuntu Server 7.10 and postgres gives error:
>
> "unexpected EOF on client connection"
>
> while upda
On Donnerstag, 17. April 2008 Tom Lane wrote:
> Before you zap the database, would you be willing to make the actual
> database files (not a dump, but the stored files) available? I'd
> be interested to take a closer look at that index.
Yes, could you please give me the quick hint how to find out
On Donnerstag, 17. April 2008 Tom Lane wrote:
> This latest bit with many fewer index entries than table entries is
> just weird, though. The 8.1.10 VACUUM bug could have led to having
> *more* index entries than table entries, but not the other way
> around.
Somehow I can think of it like that:
Hi,
We have our production postgres 8.0.10 database running on linux x86_64
machine. Recently we have started getting an error from one of our
database while running vacuumdb. We are not getting this error during
backups just only during vacuuming of a database. Can anyone please help
us figure ou
Michael Monnerie <[EMAIL PROTECTED]> writes:
> On Donnerstag, 17. April 2008 Tom Lane wrote:
>> Before you zap the database, would you be willing to make the actual
>> database files (not a dump, but the stored files) available? I'd
>> be interested to take a closer look at that index.
> Yes, cou
"Bhella Paramjeet-PFCW67" <[EMAIL PROTECTED]> writes:
> We have our production postgres 8.0.10 database running on linux x86_64
> machine. Recently we have started getting an error from one of our
> database while running vacuumdb. We are not getting this error during
> backups just only during vac
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> It probably wouldn't be a bad idea to include some checkcommands.conf
> templates and example service or hostgroup examples. See below.
Thank you, just committed and pushed. Will be in version 1.5.1, or in
1.6.0 if we get there first. You ca
> su -l postgres -c "gunzip -c /backup/rms.gz | psql rms"
You could also try:
/bin/zcat /backup/rms.gz | /usr/local/postgres/bin/psql rms
THINK BEFORE YOU PRINT - Save paper if you don't really need to print this
***Confidentiality and Privilege Notice***
The ma
On Fri, Apr 18, 2008 at 1:18 AM, Jesper Krogh <[EMAIL PROTECTED]> wrote:
>
>
> So it seems to be running.
Yes.
> But shouldn't it hit the table a lot more?
That depends on your autovac settings, especially
autovacuum_vacuum_scale_factor. If it is set to 0.2 (which is
default), then autovacuum w
We're having what seem like serious performance issues with pg_dump, and
I hope someone can help.
We have several tables that are used to store binary data as bytea (in
this example image files), but we're having similar time issues with
text tables as well.
In my most recent test, the sample
I tried with full paths:
su -l postgres -c "/bin/gunzip -c /backup/rms.gz |
/usr/lib/postgresql/8.2/bin/psql rms"
su -l postgres -c "/bin/gunzip -c /backup/rms.gz | /usr/bin/psql rms"
su -l postgres -c "/bin/zcat /backup/rms.gz |
/usr/lib/postgresql/8.2/bin/psql rms"
su -l postgres -c "/bin/zcat
26 matches
Mail list logo
