- 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
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
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
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
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
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
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
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
?
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
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
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
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
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
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
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
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
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
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
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
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
. 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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
37 matches
Mail list logo