On Thu, Aug 1, 2013 at 3:52 PM, Amit Langote wrote:
> Build using:
> CFLAGS="-g -O0" ./configure --with-pam --enable-cassert --enable-debug
> --prefix=/home/amit/dev/pginstall/
>
> --
> Amit Langote
Umm, I guess I forgot to "make clean" before building with the latest
HEAD. Now, I rebuilt after "
Build using:
CFLAGS="-g -O0" ./configure --with-pam --enable-cassert --enable-debug
--prefix=/home/amit/dev/pginstall/
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello,
initdb using the latest HEAD (9.4dev) fails with:
[amit@centos64vm postgresql]$ initdb -D ~/dev/pgdata/
The files belonging to this database system will be owned by user "amit".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
On Thu, May 31, 2012 at 9:51 AM, Tom Lane wrote:
> Robert Haas writes:
>> The one thing that still seems a little odd to me is that this caused
>> a pin count to get orphaned. It seems reasonable that ignoring the
>> AccessExclusiveLock could result in not-found errors trying to open a
>> missin
Robert Haas writes:
> The one thing that still seems a little odd to me is that this caused
> a pin count to get orphaned. It seems reasonable that ignoring the
> AccessExclusiveLock could result in not-found errors trying to open a
> missing relation, and even fsync requests on a missing relatio
On Thu, May 31, 2012 at 7:49 AM, Erik Rijkers wrote:
> On Thu, May 31, 2012 13:14, Robert Haas wrote:
>> On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers wrote:
>>> In my test, I run the bash code (the bits that I posted earlier) in a while
>>> loop so that the
>>> table
>>> is CREATEd, COPYied int
On Thu, May 31, 2012 13:14, Robert Haas wrote:
> On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers wrote:
>> In my test, I run the bash code (the bits that I posted earlier) in a while
>> loop so that the
>> table
>> is CREATEd, COPYied into, and DROPped every few seconds -- perhaps that
>> wasn't c
On 31 May 2012 12:14, Robert Haas wrote:
> On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers wrote:
>> In my test, I run the bash code (the bits that I posted earlier) in a while
>> loop so that the table
>> is CREATEd, COPYied into, and DROPped every few seconds -- perhaps that
>> wasn't clear. T
On Thu, May 31, 2012 at 1:06 AM, Erik Rijkers wrote:
> In my test, I run the bash code (the bits that I posted earlier) in a while
> loop so that the table
> is CREATEd, COPYied into, and DROPped every few seconds -- perhaps that
> wasn't clear. That loop
> is necessary; a few iterations are of
On 31.05.2012 08:06, Erik Rijkers wrote:
On Thu, May 31, 2012 03:30, Robert Haas wrote:
On Wed, May 30, 2012 at 6:00 PM, Erik Rijkers wrote:
directory
2012-05-30 23:40:57.909 CEST 3909 CONTEXT: writing block 5152 of relation
base/21268/26569
xlog redo multi-insert (init): rel 1663/21
On Thu, May 31, 2012 03:30, Robert Haas wrote:
> On Wed, May 30, 2012 at 6:00 PM, Erik Rijkers wrote:
>> directory
>> 2012-05-30 23:40:57.909 CEST 3909 CONTEXT: writing block 5152 of relation
>> base/21268/26569
>> xlog redo multi-insert (init): rel 1663/21268/26581; blk 3852; 35
>> tupl
On Wed, May 30, 2012 at 6:00 PM, Erik Rijkers wrote:
> (I double-checked that I got your latest commit in)
>
> I'm afraid it's not yet resolved; the sync-slave still crashes almost
> immediately:
>
> master logfile says:
> 2012-05-30 23:30:07.846 CEST 3918 LOG: standby wal_receiver_01 is now the
On Wed, May 30, 2012 22:25, Robert Haas wrote:
> On Wed, May 30, 2012 at 2:52 PM, Robert Haas wrote:
>> On Wed, May 30, 2012 at 1:47 PM, Robert Haas wrote:
The process holding the AccessExclusiveLock is the startup process. It's
holding the lock on behalf of the transaction in the maste
On Wed, May 30, 2012 at 2:52 PM, Robert Haas wrote:
> On Wed, May 30, 2012 at 1:47 PM, Robert Haas wrote:
>>> The process holding the AccessExclusiveLock is the startup process. It's
>>> holding the lock on behalf of the transaction in the master. But something's
>>> wrong, and the AccessExclusiv
On Wed, May 30, 2012 at 1:47 PM, Robert Haas wrote:
>> The process holding the AccessExclusiveLock is the startup process. It's
>> holding the lock on behalf of the transaction in the master. But something's
>> wrong, and the AccessExclusiveLock doesn't stop a regular backend from
>> acquiring the
On Wed, May 30, 2012 at 1:07 PM, Heikki Linnakangas
wrote:
> There's something wrong with the way AccessExclusiveLocks work on a standby.
> I did "begin; truncate foo; -- leave the xact open" in the master, and
> waited until the xlog records are shipped to the standby. Then I did this in
> the st
On 26.05.2012 12:21, Erik Rijkers wrote:
But when that if-block is added the client crashes after a while (sometimes
almost immediately; it
never survives longer then 20 minutes):
2012-05-26 10:44:22.617 CEST 10274 ERROR: could not fsync file
"base/21268/32807": No such file
or directory
2012
pg 9.2 git master
AMD 8120 (8-core) / 6 GB memory / Centos 6.2
I have experimented a bit with dropping a table from master, then querying that
table from a
sync-rep slave. It is a little worrying that this, the first test I tried,
crashes the slave.
There are two instance on one machine, head
[ Forgot the list. ]
2011/5/12, Yves Weißig :
> I'm currently debugging my developed AM and are running into this problem:
>
> TRAP: FailedAssertion("!(((bool) (((void*)(tid) != ((void *)0)) &&
> ((tid)->ip_posid != 0", File: "indexam.c", Line: 488)
>
> Can anybody explain what it means? I'm
Hi together,
I'm currently debugging my developed AM and are running into this problem:
TRAP: FailedAssertion("!(((bool) (((void*)(tid) != ((void *)0)) &&
((tid)->ip_posid != 0", File: "indexam.c", Line: 488)
Can anybody explain what it means? I'm having difficulties to understand
what went
On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql)
Right, because the bug was in exec_bind_message, which you can't inv
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> And the java program crashing the backend is attached. (it is generally
> one prepared statement , which i didn't succeded to crash from psql)
Right, because the bug was in exec_bind_message, which you can't invoke
from psql :-(. Fixed, but we re
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> As I did before, I send the strace ouput showing what jdbc is sending to the
> backend.
Thanks. I've been able to reproduce it now, and I think the plan is
actually OK, but for some reason the wrong rtable list is getting sent
along to the execut
Tom Lane <[EMAIL PROTECTED]> writes:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
>> I've found a bug with 8.2beta1:
>
> Can you put together a self-contained test case for this? The planner
> is evidently generating an incorrect plan from that messy view, but
> trying to reverse-engineer th
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
And the java program crashing the backend is attached. (it is generally
one prepared statement , which i didn't succeded to crash from psql) (it's
possible to rewrite it in C with libpq, but I cannot do that very easily).
As I did before, I send t
On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
So, the database schema with little data and a few functions is here
http://lnfm1.sai.msu.ru/~math/public
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> Will it be enough to provide the testcase for just that 'expain UPDATE' ?
Whatever makes it crash ;-)
My guess is that there's some rewriter interaction involved, which means
that the rule itself is part of the problem --- you'll likely not be
abl
On Sat, 7 Oct 2006, Sergey E. Koposov wrote:
cas=# explain UPDATE table_list SET description = 'tag{image
SRC="/vizier/new2.gif"}3rd release of DENIS (2005Sep)' WHERE id =
cas_get_table_id ('cas_data_sega','b_denis_denis5' );
QUERY PLAN
On Sat, 7 Oct 2006, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
I'll try, but it will be quite hard.
is evidently generating an incorrect plan from that messy view, b
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I've found a bug with 8.2beta1:
Can you put together a self-contained test case for this? The planner
is evidently generating an incorrect plan from that messy view, but
trying to reverse-engineer the complete scenario from what you've told
us loo
Hello -hackers,
I've found a bug with 8.2beta1:
1) Log message:
LOG: duration: 9.144 ms bind : UPDATE table_list SET description
= $1 WHERE id = cas_get_table_id ( $2,$3 )
DETAIL: parameters: $1 = '\tag{image SRC="/vizier/new2.gif"}3rd release of
DENIS (2005Sep)', $2 = 'cas_data_sega', $3 =
31 matches
Mail list logo
