On 2019-Jul-05, Tom Lane wrote:
> FWIW, I don't think there's a need for every catversion on the back branch
> to look older than any catversion on HEAD. The requirement so far as the
> core code is concerned is only for non-equality. Now, extension code does
> often do something like "if
Tomas Vondra writes:
> I've pushed the REL_12_STABLE backpatches too, now. I've ended up using
> 201907031 and 201907032 - those values precede the first catversion bump
> in master (201907041), so the back branch looks "older". And there's a
> bit of slack for additional bumps (if the unlikely
On Fri, Jul 05, 2019 at 10:36:59AM +0200, Tomas Vondra wrote:
On Fri, Jul 5, 2019, 03:28 Tom Lane wrote:
Tomas Vondra writes:
> I was about to push into REL_12_STABLE, when I realized that maybe we
> need to do something about the catversion first. REL_12_STABLE is still
> on 201906161,
On Fri, Jul 5, 2019, 03:28 Tom Lane wrote:
> Tomas Vondra writes:
> > I was about to push into REL_12_STABLE, when I realized that maybe we
> > need to do something about the catversion first. REL_12_STABLE is still
> > on 201906161, while master got to 201907041 thanks to commit
> >
Tomas Vondra writes:
> I was about to push into REL_12_STABLE, when I realized that maybe we
> need to do something about the catversion first. REL_12_STABLE is still
> on 201906161, while master got to 201907041 thanks to commit
> 7b925e12703. Simply cherry-picking the commits would get us to
>
On Tue, Jul 02, 2019 at 10:38:29AM +0200, Tomas Vondra wrote:
On Sun, Jun 30, 2019 at 08:30:33PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Attached is a slightly improved version of the serialization patch.
I reviewed this patch, and tested it on hppa and ppc. I found one
serious bug: in
On Sun, Jun 30, 2019 at 08:30:33PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Attached is a slightly improved version of the serialization patch.
I reviewed this patch, and tested it on hppa and ppc. I found one
serious bug: in the deserialization varlena case, you need
-
Tomas Vondra writes:
> Attached is a slightly improved version of the serialization patch.
I reviewed this patch, and tested it on hppa and ppc. I found one
serious bug: in the deserialization varlena case, you need
- dataptr += MAXALIGN(len);
+
On Thu, Jun 27, 2019 at 01:26:32PM +0200, Tomas Vondra wrote:
On Thu, Jun 27, 2019 at 12:04:30AM -0400, Tom Lane wrote:
Tomas Vondra writes:
OK. Attached is a patch ditching the alignment in serialized data. I've
ditched the macros to access parts of serialized data, and everything
gets
On Thu, Jun 27, 2019 at 12:04:30AM -0400, Tom Lane wrote:
Tomas Vondra writes:
OK. Attached is a patch ditching the alignment in serialized data. I've
ditched the macros to access parts of serialized data, and everything
gets copied.
I lack energy to actually read this patch right now, and I
Tomas Vondra writes:
> OK. Attached is a patch ditching the alignment in serialized data. I've
> ditched the macros to access parts of serialized data, and everything
> gets copied.
I lack energy to actually read this patch right now, and I don't currently
have an opinion about whether it's
On Wed, Jun 26, 2019 at 12:31:13PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Wed, Jun 26, 2019 at 11:26:21AM -0400, Tom Lane wrote:
#define SizeOfMCVList(ndims,nitems) \
is both woefully underdocumented and completely at variance with
reality. It doesn't seem to be accounting for
Tomas Vondra writes:
> On Wed, Jun 26, 2019 at 11:26:21AM -0400, Tom Lane wrote:
>> #define SizeOfMCVList(ndims,nitems) \
>> is both woefully underdocumented and completely at variance with
>> reality. It doesn't seem to be accounting for the actual data values.
> I agree about the macro being
On Wed, Jun 26, 2019 at 11:26:21AM -0400, Tom Lane wrote:
Tomas Vondra writes:
Attached is a patch that should (hopefully) fix this. It essentially
treats the item as (char *) and does all pointer arithmetics without any
additional casts. So there are no intermediate casts.
This passes the
Tomas Vondra writes:
> Attached is a patch that should (hopefully) fix this. It essentially
> treats the item as (char *) and does all pointer arithmetics without any
> additional casts. So there are no intermediate casts.
This passes the eyeball test, and it also allows my OpenBSD/hppa
On Wed, Jun 26, 2019 at 09:49:46AM +0200, Tomas Vondra wrote:
On Tue, Jun 25, 2019 at 11:52:28PM -0400, Tom Lane wrote:
I'm seeing a reproducible bus error here:
#0 0x00417420 in statext_mcv_serialize (mcvlist=0x62223450, stats=Variable
"stats" is not available.
)
at mcv.c:785
785
Tomas Vondra writes:
> On Tue, Jun 25, 2019 at 11:52:28PM -0400, Tom Lane wrote:
>> You can *not* cast something to an aligned pointer type if it's not
>> actually certain to be aligned suitably for that type.
> OK. So the solution is to ditch the casts altogether, and then do plain
> pointer
On Tue, Jun 25, 2019 at 11:52:28PM -0400, Tom Lane wrote:
I'm seeing a reproducible bus error here:
#0 0x00417420 in statext_mcv_serialize (mcvlist=0x62223450, stats=Variable
"stats" is not available.
)
at mcv.c:785
785 memcpy(ITEM_BASE_FREQUENCY(item, ndims),
I'm seeing a reproducible bus error here:
#0 0x00417420 in statext_mcv_serialize (mcvlist=0x62223450, stats=Variable
"stats" is not available.
)
at mcv.c:785
785 memcpy(ITEM_BASE_FREQUENCY(item, ndims),
>base_frequency, sizeof(double));
What appears to be happening is
19 matches
Mail list logo
