Re: [HACKERS] Perfomance degradation 9.3 (vs 9.2) for FreeBSD

2014-04-22 Thread YAMAMOTO Takashi
- NetBSD: crashes under load; this could have been fixed but when I ran the benchmarks in 2012 none of the developers seemed to care. do you mean this? https://mail-index.netbsd.org/tech-kern/2012/08/29/msg013918.html YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-04-04 Thread YAMAMOTO Takashi
On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote: Thanks. To avoid socket path length limitations, I lean toward placing the socket temporary directory under /tmp rather than placing under the CWD: http://www.postgresql.org/message-id/flat/20121129223632.ga15

Re: [HACKERS] Securing make check (CVE-2014-0067)

2014-04-03 Thread YAMAMOTO Takashi
and shorten_name_via_proc. YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SYSV shared memory vs mmap performance

2013-02-05 Thread YAMAMOTO Takashi
hi, Hi, On Mon, Jan 28, 2013 at 03:27:28PM +, YAMAMOTO Takashi wrote: can you give me a pointer? This bug report for a start: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46833 thanks! YAMAMOTO Takashi This is the only one I've filled; I also remember having irc

Re: [HACKERS] SYSV shared memory vs mmap performance

2013-01-28 Thread YAMAMOTO Takashi
hi, I'm less optimistic on the NetBSD front: even though I reported major show-stopper bugs (system died under load and was unable to complete a pgbench run), no one seemed to care. can you give me a pointer? YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] huge tlb support

2012-07-09 Thread YAMAMOTO Takashi
if they can, so I wonder exactly what Andres was testing on ... if you mean the trasparent hugepage feature, iirc it doesn't affect MAP_SHARED mappings like this. YAMAMOTO Takashi regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] huge tlb support

2012-07-09 Thread YAMAMOTO Takashi
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: Also, I was under the impression that recent Linux kernels use hugepages automatically if they can, so I wonder exactly what Andres was testing on ... if you mean the trasparent hugepage feature, iirc it doesn't affect MAP_SHARED mappings

Re: [HACKERS] gistVacuumUpdate

2012-01-18 Thread YAMAMOTO Takashi
hi, On 13.01.2012 06:24, YAMAMOTO Takashi wrote: hi, gistVacuumUpdate was removed when old-style VACUUM FULL was removed. i wonder why. it was not practical and REINDEX is preferred? anyway, the removal seems incomplete and there are some leftovers: F_TUPLES_DELETED F_DELETED

Re: [HACKERS] VACUUM in SP-GiST

2012-01-17 Thread YAMAMOTO Takashi
? with a concurrent split moving leaf tuples between pages, can't it make bulkdelete fail reporting some TIDs and make CREATE INDEX CONCURRENTLY create duplicates? YAMAMOTO Takashi regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

[HACKERS] gistVacuumUpdate

2012-01-12 Thread YAMAMOTO Takashi
hi, gistVacuumUpdate was removed when old-style VACUUM FULL was removed. i wonder why. it was not practical and REINDEX is preferred? anyway, the removal seems incomplete and there are some leftovers: F_TUPLES_DELETED F_DELETED XLOG_GIST_PAGE_DELETE YAMAMOTO Takashi

[HACKERS] ordering op for WHERE

2011-12-28 Thread YAMAMOTO Takashi
hi, does it make sense to teach the planner (and the executor?) use an ordering op to optimize queries like the following? select * from t where a - 1000 10 YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] synchronous commit vs. hint bits

2011-12-01 Thread YAMAMOTO Takashi
hi, On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: Yes, I would expect that. What kind of increase are you seeing? Is it causing a problem for you, or are you just making an observation? i was curious because my application uses async commits mainly

Re: [HACKERS] synchronous commit vs. hint bits

2011-11-30 Thread YAMAMOTO Takashi
hi, On Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs si...@2ndquadrant.com wrote: 5. Make the WAL writer more responsive, maybe using latches, so that it doesn't take as long for the commit record to make it out

Re: [HACKERS] reduce null bitmap size

2011-11-11 Thread YAMAMOTO Takashi
hi, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: how about making heap_form_tuple and its variants use smaller natts for tuples whose trailing columns are NULL? This idea has been proposed before, and rejected on the basis that it's unlikely to save enough to be worth the cycles

[HACKERS] reduce null bitmap size

2011-11-09 Thread YAMAMOTO Takashi
hi, how about making heap_form_tuple and its variants use smaller natts for tuples whose trailing columns are NULL? depending on the schema, it can save considerable space. the most of code are ready to deal with such tuples for ALTER TABLE ADD COLUMN anyway. (except system catalogs?) YAMAMOTO

Re: [HACKERS] ProcArrayLock contention

2011-11-09 Thread YAMAMOTO Takashi
TransactionIdIsInProgress? YAMAMOTO Takashi -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] tab stop in README

2011-08-31 Thread YAMAMOTO Takashi
On Sun, Aug 28, 2011 at 8:28 PM, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: On men, 2011-08-22 at 04:09 +, YAMAMOTO Takashi wrote: i know that postgresql uses ts=4 for C source code. but how about documatation? I'd say ideally don't use any tabs at all. i agree. It appears

Re: [HACKERS] tab stop in README

2011-08-29 Thread YAMAMOTO Takashi
hi, On men, 2011-08-22 at 04:09 +, YAMAMOTO Takashi wrote: i know that postgresql uses ts=4 for C source code. but how about documatation? I'd say ideally don't use any tabs at all. i agree. src/backend/access/transam/README seems to have both of ts=4 and ts=8 mixed. It appears

[HACKERS] tab stop in README

2011-08-22 Thread YAMAMOTO Takashi
hi, i know that postgresql uses ts=4 for C source code. but how about documatation? src/backend/access/transam/README seems to have both of ts=4 and ts=8 mixed. YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Large Objects versus transactional behavior

2011-05-13 Thread YAMAMOTO Takashi
semantics. is there any chance to just make large objects obey the normal semantics in future? YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SSI bug?

2011-04-11 Thread YAMAMOTO Takashi
. thanks! YAMAMOTO Takashi btw, i've noticed the following message in the server log. is it normal? LOG: could not truncate directory pg_serial: apparent wraparound YAMAMOTO Takashi Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ -- Sent via

Re: [HACKERS] SSI bug?

2011-04-08 Thread YAMAMOTO Takashi
hi, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: LOG: could not truncate directory pg_serial: apparent wraparound Did you get a warning with this text?: memory for serializable conflict tracking is nearly exhausted there is not such a warning near the above aparent wraparound

Re: [HACKERS] SSI bug?

2011-04-07 Thread YAMAMOTO Takashi
not truncate directory pg_serial: apparent wraparound YAMAMOTO Takashi Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] SSI bug?

2011-03-29 Thread YAMAMOTO Takashi
hi, [no residual SIReadLock] i read it as there are many (7057) SIReadLocks somehow leaked. am i wrong? YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SSI bug?

2011-03-28 Thread YAMAMOTO Takashi
has more entries than expected DETAIL: The maximum was set to 32 on creation. YAMAMOTO Takashi Thanks, -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] SSI bug?

2011-03-25 Thread YAMAMOTO Takashi
hi, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: thanks for quickly fixing problems. Thanks for the rigorous testing. :-) i tested the later version (a2eb9e0c08ee73208b5419f5a53a6eba55809b92) and only errors i got was out of shared memory. i'm not sure if it was caused by SSI

Re: [HACKERS] SSI bug?

2011-03-18 Thread YAMAMOTO Takashi
hi, thanks for quickly fixing problems. i tested the later version (a2eb9e0c08ee73208b5419f5a53a6eba55809b92) and only errors i got was out of shared memory. i'm not sure if it was caused by SSI activities or not. YAMAMOTO Takashi the following is a snippet from my application log

Re: [HACKERS] SSI bug?

2011-02-22 Thread YAMAMOTO Takashi
failure. YAMAMOTO Takashi Core was generated by `postgres'. Program terminated with signal 6, Aborted. #0 0xbbba4cc7 in _lwp_kill () from /usr/lib/libc.so.12 (gdb) bt #0 0xbbba4cc7 in _lwp_kill () from /usr/lib/libc.so.12 #1 0xbbba4c85 in raise (s=6) at /siro/nbsd/src/lib/libc/gen/raise.c:48 #2

Re: [HACKERS] SSI bug?

2011-02-17 Thread YAMAMOTO Takashi
hi, YAMAMOTO Takashi wrote: with your previous patch or not? With, thanks. i tried. unfortunately i can still reproduce the original loop problem. WARNING: [0] target 0xbb51ef18 tag 4000:4017:7e3:78:0 prior 0xbb51f148 next 0xb b51edb0 WARNING: [1] target 0xbb51f148 tag 4000:4017

Re: [HACKERS] SSI bug?

2011-02-17 Thread YAMAMOTO Takashi
hi, YAMAMOTO Takashi wrote: might be unrelated to the loop problem, but... Aha! I think it *is* related. There were several places where data was uninitialized here; mostly because Dan was working on this piece while I was working on separate issues which added the new fields. I

Re: [HACKERS] SSI bug?

2011-02-17 Thread YAMAMOTO Takashi
for newpredlocktag.myTarget. vacuum on the table succeeded with the attached patch. the latter part of the patch was necessary to avoid targetList corruption, which later seems to make DeleteChildTargetLocks loop inifinitely. YAMAMOTO Takashi #0 0x0823cf6c in PredicateLockAcquire (targettag

Re: [HACKERS] SSI bug?

2011-02-13 Thread YAMAMOTO Takashi
-used, causing problems. Please try the attached patch and see if it fixes the problem for you. If it does, then there's no need to try to track the other things I was asking about. thanks. unfortunately the problem still happens with the patch. YAMAMOTO Takashi Thanks! -Kevin

Re: [HACKERS] SSI bug?

2011-02-13 Thread YAMAMOTO Takashi
hi, all of the following answers are with the patch you provided in other mail applied. YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: i have seen this actually happen. i've confirmed the creation of the loop with the attached patch. it's easily reproducable with my application. i can

Re: [HACKERS] SSI bug?

2011-02-12 Thread YAMAMOTO Takashi
hi, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote: it seems that PredicateLockTupleRowVersionLink sometimes create a loop of targets (it founds an existing 'newtarget' whose nextVersionOfRow chain points to the 'oldtarget') and it later causes CheckTargetForConflictsIn loop forever

[HACKERS] SSI bug?

2011-02-10 Thread YAMAMOTO Takashi
hi, it seems that PredicateLockTupleRowVersionLink sometimes create a loop of targets (it founds an existing 'newtarget' whose nextVersionOfRow chain points to the 'oldtarget') and it later causes CheckTargetForConflictsIn loop forever. YAMAMOTO Takashi -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [NOVICE] systable_getnext_ordered

2011-02-01 Thread YAMAMOTO Takashi
hi, I wrote: y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: after systable_getnext_ordered returned NULL, is it ok to call it again? I wouldn't rely on it working. i'm wondering because inv_truncate seems to do it and expecting NULL. Hmm, that may well be a bug. Have you tested

Re: [HACKERS] [NOVICE] systable_getnext_ordered

2011-02-01 Thread YAMAMOTO Takashi
hi, thanks for taking a look. y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes: the attached patch is to avoid unnecessary detoast'ing and EOF marker pages when possible. does it make sense? The blob page size is already chosen not to allow for out-of-line storage, not to mention