Gregory Stark wrote:
>
> I'm debugging this problem with stalled transactions waiting on locks which
> have already been granted and I'm puzzled by something. What is this PGPROC
> entry from?
>
> It's not a real process (pid is 0) and it's not garbage either (prev and next
> both point to a real PGPROC entry, namely MyProc which as you can see is
> waiting for this PGPROC).
Doesn't this look like your pointer arithmetic being borked? There are
too many values that look invalid.
> (gdb) p *(PGPROC*)(ShmemBase + MyProc->links.prev)
> $2 = {links = {prev = 2520941752, next = 2520941752}, sem = {semId = 1,
> semNum = 0}, waitStatus = 0, xid = 0, xmin = 0, pid = 0,
> databaseId = 0, roleId = 0, inCommit = 0 '\0', inVacuum = 0 '\0',
> isAutovacuum = 0 '\0', lwWaiting = 0 '\0', lwExclusive = 2 '\002',
> lwWaitLink = 0x0, waitLock = 0x2, waitProcLock = 0x0, waitLockMode = 0,
> heldLocks = 0, myProcLocks = {{prev = 0, next = 1}, {
> prev = 4294967296, next = 0}, {prev = 3028785127, next = 360654}, {prev
> = 73183493944770560, next = 137438953600}, {
> prev = 2520929504, next = 2520929072}, {prev = 2520940536, next =
> 2520940536}, {prev = 1, next = 0}, {prev = 0,
> next = 4294967296}, {prev = 4294967296, next = 0}, {prev = 2, next =
> 0}, {prev = 0, next = 0}, {prev = 1, next = 4294967296}, {
> prev = 0, next = 4000475635}, {prev = 360707, next =
> 73183493944770560}, {prev = 128, next = 2520933680}, {prev = 2520933680,
> next = 2520914616}}, subxids = {overflowed = -72 '�', nxids = 0, xids
> = {0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0,
> 0, 0, 1, 0, 0, 1, 0, 0, 1626942462, 0, 16384, 16430, 0, 16777216, 2, 0,
> 2520930944, 0, 2520930944, 0, 2520914784, 0, 2520914784,
> 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0}}}
> (gdb) p MyProc-ShmemBase
> $3 = (PGPROC *) 0xff9ac36e36e264b8
> (gdb) p (unsigned long)MyProc-ShmemBase
> $4 = 2520941752
>
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
