On Thu, Aug 30, 2018 at 05:30:30PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > On Wed, Aug 29, 2018 at 11:35:51AM -0400, Tom Lane wrote:
> >> As far as we can tell, that bug is a dozen years old, so it's not clear
> >> why you find that you can reproduce it only in 10.5. But there might be
Justin Pryzby writes:
> Just curious, is there really any difficulty in reproducing this?
Once you have the right test case, it's not hard. But it took us two
months to find one ...
regards, tom lane
On 2018-08-30 14:46:06 -0700, Andres Freund wrote:
> Hi,
>
> On 2018-08-30 17:19:28 -0400, Tom Lane wrote:
> > So, I've been fooling around trying to get it to work without
> > -fno-strict-aliasing, but with little luck so far.
>
> The problem presumably is that pg_checksum_block() accesses the r
Andres Freund writes:
> On 2018-08-30 14:46:06 -0700, Andres Freund wrote:
>> One way to fix it would be to memcpy in/out the modified PageHeader, or
>> just do offset math and memcpy to that offset.
> It took me a bit to reproduce the issue (due to sheer stupidity on my
> part: no, changing the
On Thu, Aug 30, 2018 at 2:40 PM, Thomas Munro
wrote:
> A related topic is the cache-unfriendliness of traditional binary
> searches of sorted data. Check out "Array Layouts for
> Comparison-Based Searching"[1] if you haven't already. It says that
> if your array fits in L2 cache, as our btree pa
On 2018-08-30 18:11:40 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-30 14:46:06 -0700, Andres Freund wrote:
> >> One way to fix it would be to memcpy in/out the modified PageHeader, or
> >> just do offset math and memcpy to that offset.
>
> > It took me a bit to reproduce the iss
On Thu, Aug 30, 2018 at 10:07:38PM +0200, Magnus Hagander wrote:
> I wonder if your tests that pg_control has picked things up belong more in
> the tests of initdb itself?
For the case where checksums are disabled, moving there the check on
control data makes sense.
> Do you think there is value
Andres Freund writes:
> On 2018-08-30 18:11:40 -0400, Tom Lane wrote:
>> I suspect people will complain about the added cost of doing that.
> I think the compiler will just optimize it away.
Maybe. In any case, the attached version avoids any need for memcpy
and is, I think, cleaner code anyhow
On 2018-08-30 19:02:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > It certainly should be warned about. Practically I don't think it's a
> > problem, because we pretty much always operate on a copy of the page
> > when writing out, as otherwise concurrently set hint bits would be
> > troub
To reproduce, compare the output of \dC on two built-in casts(json to jsonb)
and (xml to text) where only the the first is really "with inout".
I've been using the folllowing query which (I believe) correctly shows
the (json to jsonb) cast as "with inout"
SELECT
CONCAT('CREATE CAST (',
Greetings,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 08/28/2018 06:10 PM, Stephen Frost wrote:
> >>Andrew has a buildfarm module that does precisely that, although
> >>I'm not sure what its test dataset is --- probably the regression
> >>database from each branch. I also have
Greetings,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 08/28/2018 06:05 PM, Tom Lane wrote:
> >Dunno about the idea of running the pg_dump TAP tests against back
> >branches. I find that code sufficiently unreadable that maintaining
> >several more copies of it doesn't sound lik
Michael Paquier writes:
> On Thu, Aug 30, 2018 at 10:39:26AM -0400, Tom Lane wrote:
>> (The right fix, of course, is to malloc the work buffer rather than
>> put it on the stack.)
> pg_upgrade/file.c is careful about that (5afcd2a), and has a comment on
> the matter, as does pg_standby.c.
> Now,
On 08/30/18 15:35, Robert Haas wrote:
> On Tue, Aug 28, 2018 at 6:30 AM, Peter Eisentraut
> wrote:
>> CALL compatible with the SQL standard. For example, if you have a
>> function f1(IN a int, OUT b int), you would call it as SELECT f1(x)
>> and the "b" would somehow be the return value. But a p
On Thu, Aug 30, 2018 at 07:37:37PM -0400, Tom Lane wrote:
> Some of these are safe, I think, because the buffers are only used as
> targets for read() and write(). But some are definitely broken.
Yes, I have not spent more than a couple of minutes on this issue. I
noticed some of them easily tho
At Thu, 30 Aug 2018 11:57:05 -0700, Michael Paquier wrote
in <20180830185705.gf15...@paquier.xyz>
> On Thu, Aug 30, 2018 at 08:31:36PM +0200, Alexander Kukushkin wrote:
> > 2018-08-30 19:34 GMT+02:00 Michael Paquier :
> >> I have been struggling for a couple of hours to get a deterministic test
>
On Fri, Aug 31, 2018 at 09:48:46AM +0900, Kyotaro HORIGUCHI wrote:
> Please wait a bit.. I have a concern about this.
Sure, please feel free.
--
Michael
signature.asc
Description: PGP signature
On 2018/08/31 2:28, Peter Eisentraut wrote:
On 17/08/2018 05:32, Tatsuro Yamada wrote:
Hi Robert,
On 2018/08/17 4:32, Robert Haas wrote:
On Thu, Aug 16, 2018 at 1:20 AM, Tatsuro Yamada
wrote:
As you can see, queries with and without a semicolon are mixed, it is hard
to understand the end of
On 28 August 2018 at 22:43, Ashutosh Bapat
wrote:
> On Fri, Aug 24, 2018 at 6:46 AM, Andres Freund wrote:
>>
>>> -/*
>>> - * slot_getsysattr
>>> - * This function fetches a system attribute of the slot's
>>> current tuple.
>>> - * Unlike slot_getattr, if the slot does not con
On Wed, Aug 29, 2018 at 9:39 AM, Masahiko Sawada wrote:
> On Tue, Aug 28, 2018 at 10:34 PM, Michael Paquier wrote:
>> On Tue, Aug 28, 2018 at 04:14:04PM +0900, Masahiko Sawada wrote:
>>> I think the copying from a slot that already reserved WAL would be
>>> helpful for backup cases (maybe you sug
At Thu, 30 Aug 2018 18:48:55 -0700, Michael Paquier wrote
in <20180831014855.gj15...@paquier.xyz>
> On Fri, Aug 31, 2018 at 09:48:46AM +0900, Kyotaro HORIGUCHI wrote:
> > Please wait a bit.. I have a concern about this.
>
> Sure, please feel free.
Thanks.
I looked though the patch and related
On Thu, Aug 30, 2018 at 2:23 PM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
>> I won't be working on this actively in the next commitfest. I will be
>> glad if somebody else wants to take this up. If there's nobody,
>> probably we should mark this entry as "returned with feedback" in the
>> nex
On Fri, Aug 31, 2018 at 02:52:06PM +0900, Kyotaro HORIGUCHI wrote:
> The patch inhibits turning off updateMinRecoveryPoint on other
> than the startup process running crash-recovery except at the end
> of XLogNeedsFlush.
Yes that's a matter of safety, as I put into the truck any modules which
may
101 - 123 of 123 matches
Mail list logo
