Update MSVC build process for new timezone data.
Missed this dependency in commits 7cce222c9 et al.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7b0cb5eccdc9f4eb9a52b1d5c9815a7a5161a9fa
Modified Files
--
src/tools/msvc/Install.pm | 7 ---
1
Update MSVC build process for new timezone data.
Missed this dependency in commits 7cce222c9 et al.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/6d4ae6a8e782d87ffb6aab62f75787b2722daa2d
Modified Files
--
src/tools/msvc/Install.pm | 7 ---
1 file c
Update MSVC build process for new timezone data.
Missed this dependency in commits 7cce222c9 et al.
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/1601a9413fbfb98370c3299e3c9da514a0331c6d
Modified Files
--
src/tools/msvc/Install.pm | 7 ---
1
Update MSVC build process for new timezone data.
Missed this dependency in commits 7cce222c9 et al.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/cd3bde814612ffebe11a754116a70010ae195784
Modified Files
--
src/tools/msvc/Install.pm | 7 ---
1
Update MSVC build process for new timezone data.
Missed this dependency in commits 7cce222c9 et al.
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/44261d47d32f3b1957fd6856caae2dd6cef17d80
Modified Files
--
src/tools/msvc/Install.pm | 7 ---
1
Update MSVC build process for new timezone data.
Missed this dependency in commits 7cce222c9 et al.
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/a2826ff8b167f7f23ee60ee11f04ec9a5d2aac82
Modified Files
--
src/tools/msvc/Install.pm | 7 ---
1
I wrote:
> Instead I propose that we should make sure that the palloc request size
> for XLogReaderState->main_data is always maxalign'd. The existing
> behavior in DecodeXLogRecord of palloc'ing it only just barely big
> enough for the current record seems pretty brain-dead performance-wise
> eve
Andres Freund writes:
> On 2017-11-25 14:50:41 -0500, Tom Lane wrote:
>> Meanwhile, skink has come back with a success as of 0f2458f, rendering
>> the other mystery even deeper --- although at least this confirms the
>> idea that the crashes we are seeing predate the generation.c patch.
> Hm, won
Replace raw timezone source data with IANA's new compact format.
Traditionally IANA has distributed their timezone data in pure source
form, replete with extensive historical comments. As of release 2017c,
they've added a compact single-file format that omits comments and
abbreviates command keyw
Replace raw timezone source data with IANA's new compact format.
Traditionally IANA has distributed their timezone data in pure source
form, replete with extensive historical comments. As of release 2017c,
they've added a compact single-file format that omits comments and
abbreviates command keyw
Replace raw timezone source data with IANA's new compact format.
Traditionally IANA has distributed their timezone data in pure source
form, replete with extensive historical comments. As of release 2017c,
they've added a compact single-file format that omits comments and
abbreviates command keyw
Replace raw timezone source data with IANA's new compact format.
Traditionally IANA has distributed their timezone data in pure source
form, replete with extensive historical comments. As of release 2017c,
they've added a compact single-file format that omits comments and
abbreviates command keyw
Replace raw timezone source data with IANA's new compact format.
Traditionally IANA has distributed their timezone data in pure source
form, replete with extensive historical comments. As of release 2017c,
they've added a compact single-file format that omits comments and
abbreviates command keyw
Replace raw timezone source data with IANA's new compact format.
Traditionally IANA has distributed their timezone data in pure source
form, replete with extensive historical comments. As of release 2017c,
they've added a compact single-file format that omits comments and
abbreviates command keyw
On 2017-11-25 12:00:15 -0800, Andres Freund wrote:
> Hi,
>
> On 2017-11-25 14:50:41 -0500, Tom Lane wrote:
> > I wrote:
> > > Tomas Vondra writes:
> > >> BTW I also see these failures in hstore:
> >
> > >> ==15168== Source and destination overlap in memcpy(0x5d0fed0, 0x5d0fed0,
> > >> 40)
> > >>
Hi,
On 2017-11-25 14:50:41 -0500, Tom Lane wrote:
> I wrote:
> > Tomas Vondra writes:
> >> BTW I also see these failures in hstore:
>
> >> ==15168== Source and destination overlap in memcpy(0x5d0fed0, 0x5d0fed0,
> >> 40)
> >> ==15168==at 0x4C2E00C: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:101
I wrote:
> Tomas Vondra writes:
>> BTW I also see these failures in hstore:
>> ==15168== Source and destination overlap in memcpy(0x5d0fed0, 0x5d0fed0, 40)
>> ==15168==at 0x4C2E00C: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
>> ==15168==by 0x15419A06: hstoreUniquePairs (hstore_io.c:343
Avoid formally-undefined use of memcpy() in hstoreUniquePairs().
hstoreUniquePairs() often called memcpy with equal source and destination
pointers. Although this is almost surely harmless in practice, it's
undefined according to the letter of the C standard. Some versions of
valgrind will compl
Avoid formally-undefined use of memcpy() in hstoreUniquePairs().
hstoreUniquePairs() often called memcpy with equal source and destination
pointers. Although this is almost surely harmless in practice, it's
undefined according to the letter of the C standard. Some versions of
valgrind will compl
Avoid formally-undefined use of memcpy() in hstoreUniquePairs().
hstoreUniquePairs() often called memcpy with equal source and destination
pointers. Although this is almost surely harmless in practice, it's
undefined according to the letter of the C standard. Some versions of
valgrind will compl
Avoid formally-undefined use of memcpy() in hstoreUniquePairs().
hstoreUniquePairs() often called memcpy with equal source and destination
pointers. Although this is almost surely harmless in practice, it's
undefined according to the letter of the C standard. Some versions of
valgrind will compl
Avoid formally-undefined use of memcpy() in hstoreUniquePairs().
hstoreUniquePairs() often called memcpy with equal source and destination
pointers. Although this is almost surely harmless in practice, it's
undefined according to the letter of the C standard. Some versions of
valgrind will compl
Avoid formally-undefined use of memcpy() in hstoreUniquePairs().
hstoreUniquePairs() often called memcpy with equal source and destination
pointers. Although this is almost surely harmless in practice, it's
undefined according to the letter of the C standard. Some versions of
valgrind will compl
Repair failure with SubPlans in multi-row VALUES lists.
When nodeValuesscan.c was written, it was impossible to have a SubPlan in
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby
would produce an InitPlan instead. We therefore took a shortcut in the
logic that throws away
Repair failure with SubPlans in multi-row VALUES lists.
When nodeValuesscan.c was written, it was impossible to have a SubPlan in
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby
would produce an InitPlan instead. We therefore took a shortcut in the
logic that throws away
Repair failure with SubPlans in multi-row VALUES lists.
When nodeValuesscan.c was written, it was impossible to have a SubPlan in
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby
would produce an InitPlan instead. We therefore took a shortcut in the
logic that throws away
Repair failure with SubPlans in multi-row VALUES lists.
When nodeValuesscan.c was written, it was impossible to have a SubPlan in
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby
would produce an InitPlan instead. We therefore took a shortcut in the
logic that throws away
Repair failure with SubPlans in multi-row VALUES lists.
When nodeValuesscan.c was written, it was impossible to have a SubPlan in
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby
would produce an InitPlan instead. We therefore took a shortcut in the
logic that throws away
Repair failure with SubPlans in multi-row VALUES lists.
When nodeValuesscan.c was written, it was impossible to have a SubPlan in
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby
would produce an InitPlan instead. We therefore took a shortcut in the
logic that throws away
Andres Freund writes:
> I don't really see a point in doing this renaming in the first
> place. It's not like the Temp suffix has become inaccurate. I'd perhaps
> not add it in the green field, but I don't see a need to change an
> existing function name. If anything it seems confusing because you
Update buffile.h/.c comments for removal of non-temp option.
Commit 11e264517 removed BufFile's isTemp flag, thereby eliminating
the possibility of resurrecting BufFileCreate(). But it left that
function in place, as well as a bunch of comments describing how things
worked for the non-temp-file c
Improve planner's handling of set-returning functions in grouping columns.
Improve query_is_distinct_for() to accept SRFs in the targetlist when
we can prove distinctness from a DISTINCT clause. In that case the
de-duplication will surely happen after SRF expansion, so the proof
still works. Con
Improve planner's handling of set-returning functions in grouping columns.
Improve query_is_distinct_for() to accept SRFs in the targetlist when
we can prove distinctness from a DISTINCT clause. In that case the
de-duplication will surely happen after SRF expansion, so the proof
still works. Con
Avoid projecting tuples unnecessarily in Gather and Gather Merge.
It's most often the case that the target list for the Gather (Merge)
node matches the target list supplied by the underlying plan node;
when this is so, we can avoid the overhead of projecting.
This depends on commit f455e1125e2588
34 matches
Mail list logo
