Hi all!
We seem to be getting this error (in german) once in a while on a rather
complex database:
FEHLER: konnte auf den Status von Transaktion 0 nicht zugreifen
DETAIL: kann Datei >>/var/databases/postgres/data/pg_subtrans/57DA<<
nicht erstellen: Die Datei existiert bereits
which roughly tra
On Fri, Jan 06, 2006 at 01:24:41AM -0500, Greg Stark wrote:
> > 5% based on block-based sampling is reasonable; that means a straight 5% of
> > the on-disk size of the table, so 5gb for a 100gb table. With random-row
> > sampling, that would require as much as 25% of the table, making it easier
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> ERROR: could not access status of transaction 0
> DETAIL: could not create file
> /var/databases/postgres/data/pg_subtrans/57DA<<: File exists
> and seems to be generated in backend/access/transam/slru.c
> it looks like we got those(with changing
On Thu, 5 Jan 2006, Tom Lane wrote:
> The ReadBuffer bug I just fixed could result in disappearance of catalog
> rows, so this observation is consistent with the theory that that's
> what's biting you. It's not proof though...
Well, I applied that patch that you sent me the link to (the bufmgr.c
Jeremy Drake <[EMAIL PROTECTED]> writes:
> Well, I applied that patch that you sent me the link to (the bufmgr.c
> one), and rebuilt (PORTDIR_OVERLAY is cool...)
> I ran my nine processes which hammer things overnight, and in the
> morning one of them was dead.
> DBD::Pg::st execute failed: ERROR
On Fri, 6 Jan 2006, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > Well, I applied that patch that you sent me the link to (the bufmgr.c
> > one), and rebuilt (PORTDIR_OVERLAY is cool...)
>
> > I ran my nine processes which hammer things overnight, and in the
> > morning one of the
Jeremy Drake <[EMAIL PROTECTED]> writes:
>>> DBD::Pg::st execute failed: ERROR: duplicate key violates unique
>>> constraint "pg_type_typname_nsp_index"
>>
>> Hm, did you REINDEX things beforehand? This could be leftover corruption...
> Yes. I ran that VACUUM FULL ANALYZE VERBOSE which I email
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Before we start debating merits of proposals based on random reads, can
> someone confirm that the sampling code actually does read randomly?
Well, it's not so much that it's not "random", as that it's not
sequential --- it skips blocks, and therefore y
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>ERROR: could not access status of transaction 0
>>DETAIL: could not create file
>>/var/databases/postgres/data/pg_subtrans/57DA<<: File exists
>
>
>>and seems to be generated in backend/access/transam/slru.c
>>it looks like w
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Before we start debating merits of proposals based on random reads, can
> someone confirm that the sampling code actually does read randomly? I
> looked at it yesterday; there is a comment that states that blocks to be
> scanned are passed to the analy
Greg,
> These numbers don't make much sense to me. It seems like 5% is about as
> slow as reading the whole file which is even worse than I expected. I
> thought I was being a bit pessimistic to think reading 5% would be as
> slow as reading 20% of the table.
It's about what *I* expected. Disk s
Josh Berkus writes:
> > These numbers don't make much sense to me. It seems like 5% is about as
> > slow as reading the whole file which is even worse than I expected. I
> > thought I was being a bit pessimistic to think reading 5% would be as
> > slow as reading 20% of the table.
>
> It's about
I have developed a patch that writes a warning in the server log when a user
changes a restart-only parameter in the configuration file and does a reload.
The problem is that you will see this warning once for each running server
process (unless you sent the HUP signal only to a specific proces
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I have developed a patch that writes a warning in the server log when a user
> changes a restart-only parameter in the configuration file and does a reload.
> The problem is that you will see this warning once for each running server
> process (unles
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote
>
>> Feasibility: Our bufmgr lock rewrite already makes this possible. But to
>> enable it, we may need more work: (w1) make bufferpool relation-wise,
>> which makes our estimation of data page residence more easy and reliable.
>> (w2) add aggresive pre-re
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> For b1, it actually doesn't matter much though. With bitmap we definitely
> can give a better EXPLAIN numbers for seqscan only, but without the bitmap,
> we seldom make wrong choice of choosing/not choosing sequential scan.
I think you have a more
16 matches
Mail list logo
