> - 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
> On Fri, Apr 04, 2014 at 02:36:05AM +0000, 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.postgr
EAD
look at shorten_name_via_symlink 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 o
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
> 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 "traspare
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 like this.
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
x27;s enough room on the page) or convert it to a redirect (if not).
>
> Last night I was thinking the fourth state could be named TOMBSTONE,
> but maybe it'd be better to use DEAD for this case and rename the
> existing "removable dead tuple" state to PLACEHOLDER, since
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 sub
hi,
> On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi
> 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 u
hi,
> On Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi
> wrote:
>>> On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs wrote:
>>>
>>>>> 5. Make the WAL writer more responsive, maybe using latches, so that
>>>>> it doesn't take as long
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 t
regular tables,
> but it's hard to know how seriously to take that until the locking
> issue is debugged.
>
> Any ideas?
latestCompletedXid got backward due to concurrent updates
and it fooled TransactionIdIsInProgress?
YAMAMOTO Takashi
>
> --
> Robert Haas
> En
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
> On Sun, Aug 28, 2011 at 8:28 PM, YAMAMOTO Takashi
> 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 ideal
hi,
> On men, 2011-08-22 at 04:09 +0000, 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 seem
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
| transaction modes for ordinary SQL SELECT commands.
as a novice user who has been annoyed by them, i'm curious about
the rationale of the unusual 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
5554bc3e6dcf1013 with this
> patch applied. i haven't seen the symptom yet. i'll keep it running for
> a while.
i haven't seen the symptom since them. so i guess it was fixed by
your patch. thanks!
YAMAMOTO Takashi
>
> btw, i've noticed the following
hi,
> YAMAMOTO Takashi 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 ne
ing for
a while.
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://d
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
t;. I'll take a look at the possibility of adding a
>>> warning or some such when an HTAB expands past its maximum size.
>
> I see from your later post that you are running with this patch. Has
> that reported anything yet?
i got nothing except the following one. (in the ser
hi,
> YAMAMOTO Takashi 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 me
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
ures.
>
> -Kevin
i tested ede45e90dd1992bfd3e1e61ce87bad494b81f54d + ssi-multi-update-1.patch
with my application and got the following assertion failure.
YAMAMOTO Takashi
Core was generated by `postgres'.
Program terminated with signal 6, Aborted.
#0 0xbbba4cc7 in _lwp_kill () fr
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
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 is
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 0
hi,
all of the following answers are with the patch you provided in
other mail applied.
> YAMAMOTO Takashi wrote:
>
>> i have seen this actually happen. i've confirmed the creation of
>> the loop with the attached patch. it's easily reproducable with
>>
be around when a tuple
> ID is re-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
hi,
> YAMAMOTO Takashi 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 Check
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-
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
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
37 matches
Mail list logo
