On Thu, Mar 6, 2008 at 6:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> While working on the previously discussed refactoring of
> heap_page_prune, I came to the realization that its use of
> CacheInvalidateHeapTuple is not just a PANIC risk but simply wrong :-(
> The semantics aren't right: inval
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> It says
> ! failed, that wasn't supposed to happen
> and then it crashes:
fennec is evidently running python 2.5 --- which we don't support in
pre-8.2 branches. I proposed back-patching those fixes awhile ago
but it was met with less than approval ...
Has this been addressed?
---
Oleg Bartunov wrote:
> On Tue, 5 Feb 2008, Magnus Hagander wrote:
>
> > No. It's on the list, but other things around the release haev priority.
>
> I just returned from my Europe trip and have
While working on the previously discussed refactoring of
heap_page_prune, I came to the realization that its use of
CacheInvalidateHeapTuple is not just a PANIC risk but simply wrong :-(
The semantics aren't right: inval.c assumes that it's dealing with
transactional invalidations, but what we are
It says
(1 row)
SELECT import_succeed();
+ NOTICE: ('import failed -- No module named whrandom',)
import_succeed
!
! failed, that wasn't supposed to happen
(1 row)
-- test import and simple argument handling
and
On Wed, Mar 5, 2008 at 7:29 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Is this a bug that needs to be fixed?
>
Since it's not unusual to find DOCTYPEs inside XML document I guess
so. Maybe low priority but I hope it will be fixed soon. Now we make
the database add and remove the doctype lin
Is this a bug that needs to be fixed?
---
Lawrence Oluyede wrote:
> As specified in the W3C Recommendation for XML the DOCTYPE element is
> perfectly valid in a document.
> I have a bunch of XML files generated by the boost
On Wed, Mar 5, 2008 at 11:06 PM, Magnus Hagander <[EMAIL PROTECTED]>
wrote:
> On Wed, Mar 05, 2008 at 12:04:30PM -0500, Bruce Momjian wrote:
> > Gurjeet Singh wrote:
> > > libpqxx seems to have moved around quite a bit. The attached patch
> corrects
> > > libpqxx's homepage.
> >
> > Thanks, patch
On Wed, Mar 05, 2008 at 12:04:30PM -0500, Bruce Momjian wrote:
> Gurjeet Singh wrote:
> > libpqxx seems to have moved around quite a bit. The attached patch corrects
> > libpqxx's homepage.
>
> Thanks, patch applied and back-patched to 8.3.X.
Do we really need to keep these things in the README?
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> On Wed, Mar 5, 2008 at 10:13 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Actually, maybe it *has* been seen before. Gavin, are you in the habit
>> of running concurrent VACUUM FULLs on system catalogs, and if so have
>> you noted that they occasionally g
Gurjeet Singh wrote:
> libpqxx seems to have moved around quite a bit. The attached patch corrects
> libpqxx's homepage.
Thanks, patch applied and back-patched to 8.3.X.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://postgres.en
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> 2008-03-04 05:45:20 EST [6742]: [7-1] PANIC: deadlock detected
> 2008-03-04 05:45:20 EST [6742]: [8-1] DETAIL: Process 6742 waits for
> AccessShareLock on relation 2619 of database 16385; blocked by process 6740.
> Process 6740 waits for AccessShareLoc
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think we really are at too much risk of PANIC the way it's being done
>> now. Has anyone got a better idea?
> We could do the pruning in two phases: first figure out what to do
> without modifyng anything, outside critical-s
Added to TODO:
o Allow COPY FROM to create index entries in bulk
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php
---
ITAGAKI Takahiro wrote:
> This is a proposal of fast data loading us
2008-03-04 05:45:20 EST [6742]: [7-1] PANIC: deadlock detected
2008-03-04 05:45:20 EST [6742]: [8-1] DETAIL: Process 6742 waits for
AccessShareLock on relation 2619 of database 16385; blocked by process 6740.
Process 6740 waits for AccessShareLock on relation 1247 of database 16385;
blocked by pr
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> The panic may have made it if this is what you were looking for:
> 2008-03-04 05:45:20 EST [6742]: [7-1] PANIC: deadlock detected
> 2008-03-04 05:58:33 EST [8751]: [3-1] PANIC: deadlock detected
That's what I expected to find, but where's the DETAIL
Tom Lane wrote:
The reason the critical section is so large is that we're manipulating
the contents of a shared buffer, and we don't want a failure to leave a
partially-modified page in the buffer. We could fix that if we were to
memcpy the page into local storage and do all the pruning work the
On Wed, Mar 5, 2008 at 10:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> > 2008-03-04 05:45:47 EST [6698]: [1-1] LOG: process 6698 still waiting
> for
> > AccessShareLock on relation 1247 of database 16385 after 1001.519 ms
> > 2008-03-04 05:45:47 EST [6
On Wed, Mar 5, 2008 at 10:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> > 2008-03-04 05:45:47 EST [6698]: [1-1] LOG: process 6698 still waiting
> for
> > AccessShareLock on relation 1247 of database 16385 after 1001.519 ms
> > 2008-03-04 05:45:47 EST [6
On Wed, Mar 5, 2008 at 10:13 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I wrote:
> > In particular, if that's the problem, why has this not been seen before?
> > The fact that it's going through heap_page_prune doesn't seem very
> > relevant --- VACUUM FULL has certainly always had to invoke
> > Ca
"Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> 2008-03-04 05:45:47 EST [6698]: [1-1] LOG: process 6698 still waiting for
> AccessShareLock on relation 1247 of database 16385 after 1001.519 ms
> 2008-03-04 05:45:47 EST [6698]: [2-1] STATEMENT: VACUUM FULL
> autograph.autograph_creators
> 2008-03-04
2008-03-04 05:45:47 EST [6698]: [1-1] LOG: process 6698 still waiting for
AccessShareLock on relation 1247 of database 16385 after 1001.519 ms
2008-03-04 05:45:47 EST [6698]: [2-1] STATEMENT: VACUUM FULL
autograph.autograph_creators
2008-03-04 05:46:28 EST [6730]: [1-1] LOG: process 6730 still w
I wrote:
> In particular, if that's the problem, why has this not been seen before?
> The fact that it's going through heap_page_prune doesn't seem very
> relevant --- VACUUM FULL has certainly always had to invoke
> CacheInvalidateHeapTuple someplace or other. So I still want to see
> the deadloc
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Why not just unconditionally finish the phase 2 as part of InitPostgres ?
You're jumping to a patch before we even understand what's happening.
In particular, if that's the problem, why has this not been seen before?
The fact that it's going through h
On Wed, Mar 5, 2008 at 3:41 PM, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
>
>
>
> Two backends try to vacuum full two different catalog tables. Each acquires
> an
> exclusive lock on the respective catalog relation. Then each try to
> initialize its
> own catalog cache. But to do that they nee
On Wed, Mar 5, 2008 at 8:26 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gavin M. Roy" <[EMAIL PROTECTED]> writes:
> > (gdb) where
> > #0 0x003fe362e21d in raise () from /lib64/tls/libc.so.6
> > #1 0x003fe362fa1e in abort () from /lib64/tls/libc.so.6
> > #2 0x0063a2e3 in errfin
Bruce Momjian wrote:
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
John Smith wrote:
[3] I am not certain how widespread they might be, but I think there
may be some backward compatibility concerns with the patch you are
proposing.
Well, the current behavior is certainly bro
Bryce Nesbitt wrote:
I've got a patch to psql that offers a "no wider than terminal" option,
patched against cvs head. Would anyone be willing to test this before I
submit the patch?
Just post the patch to pgsql-patches, no need to be shy :-). That's the
best way to get people to test it.
28 matches
Mail list logo
