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.
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 errfinish ()
#3
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
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 need
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
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 deadlock
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
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 05:46:28
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
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 [6698]: [2-1]
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 [6698]: [2-1]
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
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 for
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
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
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-section,
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 AccessShareLock on
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
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 get deadlock
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? It
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 applied and
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 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 line
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
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
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 many
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 ...
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.c
28 matches
Mail list logo
