Its worth noting that the JDBC's behavior when you switch back to
autocommit is to immediately commit the open transaction.
Personally, I think committing immediately or erroring are unsurprising
behaviors. The current behavior is surprising and obviously wrong.
Rolling back without an error woul
As someone who has bitten by index corruption due to collation changes
between glibc versions that shipped CentOS 6 and CentOS 7, don't even try
to do this with anything other than C collation. The default collation
_will_ deterministically leave you with a silently corrupt database if you
store an
>
> On Fri, 2016-03-11 at 17:24 +0100, Michael Paquier wrote:
> > On Fri, Mar 11, 2016 at 5:19 PM, Anastasia Lubennikova wrote:
> > >
> > > BTW, if you know a good way to corrupt index (and do it
> > > reproducible) I'd be
> > > very glad to see it.
> > You can use for example dd in non-truncate mo
>
> Even if it does fit in memory I suspect memory bandwidth is more important
> than clock cycles.
http://people.freebsd.org/~lstewart/articles/cpumemory.pdf
This paper is old but the ratios should still be pretty accurate. Main
memory is 240 clock cycles away and L1d is only 3. If the experi
as the denominator in that calculation should
help to smooth out that noise and show a clearer picture.
However, I'm happy with the committed version. Thanks Tom.
- Matt K.
On Thu, Feb 19, 2015 at 9:40 PM, Tom Lane wrote:
> Matt Kelly writes:
> > Attached is the fixed version. (hopeful
​Actually, I just did one more code review of myself, and somehow missed
that I submitted the version with the wrong oid. The oid used in the first
version is wrong (1) and was from before I read the docs on properly
picking one.
Attached is the fixed version. (hopefully with the right mime-t
On Thu, Jan 29, 2015 at 8:42 PM, Tom Lane wrote:
> Matt Kelly writes:
> > Jim, I'm not sure I understand what you mean? This new function follows
> > the same conventions as everything else in the file. TimestampTz is
> just a
> > typedef for int64.
>
> ..
This is now: https://commitfest.postgresql.org/4/128/
On Thu, Jan 29, 2015 at 7:01 PM, Matt Kelly wrote:
> Robert, I'll add it to the commitfest.
>
> Jim, I'm not sure I understand what you mean? This new function follows
> the same conventions as everything else in the
fields of the global stats struct.
- Matt K.
On Thu, Jan 29, 2015 at 6:49 PM, Jim Nasby wrote:
> On 1/28/15 11:18 PM, Matt Kelly wrote:
>
>> In a previous thread Tom Lane said:
>>
>> (I'm also wondering if it'd make sense to expose the stats timestamp
>
In a previous thread Tom Lane said:
(I'm also wondering if it'd make sense to expose the stats timestamp
> as a callable function, so that the case could be dealt with
> programmatically as well. But that's future-feature territory.)
(http://www.postgresql.org/message-id/27251.1421684...@sss.pg
t_timestamp() for monitoring code to use to
determine if its using a stale snapshot, as well as helping to smooth
graphs of the statistics that are based on highly granular snapshotting.
- Matt Kelly
onsuming a
core and half of CPU. I think its not worth tying these two things
together. Its probably worth it to make these two separate discussions and
separate patches.
- Matt Kelly
*Just sanity checking myself: Shutting down the server, applying the
different patch, 'make clean ins
across the server just like work_mem.
Obviously, this shouldn't block your current patch but its worth revisiting.
- Matt Kelly
13 matches
Mail list logo
