> On May 15, 2018, at 10:20 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>>>> If none of the animals
>>>> are configured to detect this bug, perhaps the community needs another
>>>> Windows animal configured along the lines of the build machine
> On May 15, 2018, at 9:54 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I'm curious why the Windows build farm members did not pick this up. Or
>> perhaps they did? (I don't get emails about that.)
>
> They did not, and I too was wondering why not
> On May 15, 2018, at 9:29 AM, Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (hornschnor...@gmail.com) wrote:
>>> On May 15, 2018, at 8:58 AM, Tom Lane wrote:
>>> Mark Dilger writes:
>>>> My best guess at the moment is:
>>>
>
> On May 15, 2018, at 8:58 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> My best guess at the moment is:
>
>> diff --git a/src/backend/utils/init/globals.c
>> b/src/backend/utils/init/globals.c
>> index c1f0441b08..0a3163398f 100644
>> --- a/src
Hackers,
There was a bug report sent by Hao Lee about Windows build breakage,
"BUG #15167: error C2365: 'errcode' : redefinition; previous definition"
https://www.postgresql.org/message-id/152446498404.19807.4659286570762153837%40wrigleys.postgresql.org
Heikki was the only person who responded to
> On May 6, 2018, at 12:08 PM, John Naylor wrote:
>
> On 5/7/18, Mark Dilger wrote:
>> Hackers,
>>
>> Have you already considered and rejected the idea of having
>> genbki.pl/Catalog.pm define constants that can be used in
>> the catalog .dat files? I&
Hackers,
Have you already considered and rejected the idea of having
genbki.pl/Catalog.pm define constants that can be used in
the catalog .dat files? I'm mostly curious if people think
the resulting .dat files are better or worse using constants
of this sort. For example:
diff --git a/src/bac
Hackers,
There are not yet any examples in the postgres sources where this
oversight causes problems, but in genbki.pl, where it makes the
decision whether to quote a token:
# Quote value if needed. We need not quote values that satisfy
# the "id" pattern in bootscanner.l, curren
> On May 1, 2018, at 2:11 PM, Andres Freund wrote:
>
> Hi,
>
> On 2018-05-01 14:09:39 -0700, Mark Dilger wrote:
>> I don't care which order the data is in, as long as x[i] and y[i] are
>> matched correctly. It sounds like this patch would force me
> On Mar 27, 2018, at 7:58 AM, Tom Lane wrote:
>
> David Rowley writes:
>> On 27 March 2018 at 13:26, Alvaro Herrera wrote:
>>> synchronized_seqscans is another piece of precedent in the area, FWIW.
>
>> This is true. I guess the order of aggregation could be made more
>> certain if we remove
>>
+ textprosrc BKI_DEFAULT("${proname}")
BKI_FORCE_NOT_NULL;
>>
>>> That one I kinda like.
>>
>> Agreed, this seems more compelling. However, I think we need more than
>> one compelling example to justify the additional infrastructure.
>
> I'll look for more.
Th
> On Apr 25, 2018, at 1:31 PM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger wrote:
>>> There still seems to be a lot of boilerplate in the .dat files
>>> that could be eliminated. ...
>
>>> {... typ
> On Apr 25, 2018, at 1:00 PM, Robert Haas wrote:
>
> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger wrote:
>> There still seems to be a lot of boilerplate in the .dat files
>> that could be eliminated. Tom mentioned upthread that he did
>> not want too much magic
> On Apr 9, 2018, at 2:25 PM, Tomas Vondra wrote:
>
>
>
> On 04/09/2018 11:08 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2018-04-09 13:55:29 -0700, Mark Dilger wrote:
>>> I can also imagine a master and standby that are similarly provisioned,
>>&
> On Apr 9, 2018, at 1:43 PM, Tomas Vondra wrote:
>
>
>
> On 04/09/2018 10:25 PM, Mark Dilger wrote:
>>
>>> On Apr 9, 2018, at 12:13 PM, Andres Freund wrote:
>>>
>>> Hi,
>>>
>>> On 2018-04-09 15:02:11 -0400, Robert Ha
> On Apr 9, 2018, at 12:13 PM, Andres Freund wrote:
>
> Hi,
>
> On 2018-04-09 15:02:11 -0400, Robert Haas wrote:
>> I think the simplest technological solution to this problem is to
>> rewrite the entire backend and all supporting processes to use
>> O_DIRECT everywhere. To maintain adequate p
> On Apr 9, 2018, at 10:26 AM, Joshua D. Drake wrote:
> We have plenty of YEARS of people not noticing this issue
I disagree. I have noticed this problem, but blamed it on other things.
For over five years now, I have had to tell customers not to use thin
provisioning, and I have had to add co
> On Mar 3, 2018, at 2:40 PM, Tomas Vondra wrote:
>
> An updated patch version, fixing the breakage caused by fd1a421fe6
> twiddling with pg_proc.
Hi Tomas!
Reviewing the sgml documentation, I think something like the following should
be added:
diff --git a/doc/src/sgml/catalogs.sgml b/doc/s
> On Mar 3, 2018, at 2:40 PM, Tomas Vondra wrote:
>
> An updated patch version, fixing the breakage caused by fd1a421fe6
> twiddling with pg_proc.
Hi Tomas, thanks again for this most useful patch!
Perhaps this is intentional, but there seems to be a place in
src/backend/parser/parse_utilcmd.
> On Feb 24, 2018, at 2:01 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, fixing some minor bitrot
> and duplicate OIDs.
The three patches apply cleanly, compile, and pass check-world.
You might consider using PointerGetDatum in compare_scalars_simple
rath
> On Feb 24, 2018, at 2:01 PM, Tomas Vondra
> wrote:
> Sadly, this patch series does not seem to move forward very much, and
> I'm not sure how to change that :-/
I'll take a look at the new patch set this evening. I have been using your
previous version of these patches applied against postg
> This patch got committed as c1898c3e1e235ae35b4759d233253eff221b976a
> on Sun Sep 10 16:20:41 2017 -0700, but I've only just gotten around to
> reviewing it.
>
> I believe this is wrong and should be reverted, at least in part.
>
> The NumericVar struct has the field 'digits' as non-const:
>
to a server crash, at least on some
architectures with some compilers.
The idea that set_var_from_var might be called on const_zero (or const_one,
etc.) is not hypothetical. It is being done in numeric.c.
If this is safe, somebody needs to be a lot clearer about why that is so. There
are no
> On Feb 12, 2018, at 6:35 PM, Tom Lane wrote:
>
> Andrew Kane writes:
>> Thanks everyone for the feedback. The current enum implementation requires
>> you to create a new type and add labels outside a transaction prior to an
>> insert.
>
> Right ...
>
>> Since enums have a fixed number of la
> On Feb 12, 2018, at 5:08 PM, Andrew Kane wrote:
>
> Thanks everyone for the feedback. The current enum implementation requires
> you to create a new type and add labels outside a transaction prior to an
> insert.
>
> -- on table creation
> CREATE TYPE city AS ENUM ();
> CREATE TABLE "users"
her users.
Extending this to help the community as a whole in the form of something
general purpose seems difficult, which is why I never tried to
contribute it.
Could you perhaps tell me how similar your situation is to mine, and
whether my approach is anything like what you were contemplating? I am
curious to hear an answer to Tom's question, upthread, about why you
would not just use the enumeration type that postgres already supplies.
Mark Dilger
> BTW while working on the regression tests, I've noticed that brin.sql
> fails to test a couple of minmax opclasses (e.g. abstime/reltime). Is
> that intentional or is that something we should fix eventually?
I believe abstime/reltime are deprecated. Perhaps nobody wanted to
bother adding test
> On Dec 19, 2017, at 5:16 PM, Tomas Vondra
> wrote:
>
>
>
> On 12/19/2017 08:38 PM, Mark Dilger wrote:
>>
>>> On Nov 18, 2017, at 12:45 PM, Tomas Vondra
>>> wrote:
>>>
>>> Hi,
>>>
>>> Apparently there
> On Dec 19, 2017, at 5:16 PM, Tomas Vondra
> wrote:
>
>
>
> On 12/19/2017 08:38 PM, Mark Dilger wrote:
>>
>>> On Nov 18, 2017, at 12:45 PM, Tomas Vondra
>>> wrote:
>>>
>>> Hi,
>>>
>>> Apparently there
> On Dec 19, 2017, at 4:31 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> On 12/19/2017 08:17 PM, Mark Dilger wrote:
>>
>> I tested your latest patches on my mac os x laptop and got one test
>> failure due to the results of 'explain' coming up differe
> On Dec 12, 2017, at 10:32 PM, Amit Langote
> wrote:
>
> On 2017/12/12 15:39, Amit Langote wrote:
>> On 2017/12/12 15:35, Amit Langote wrote:
>>> Works for me, updated patch attached.
>>
>> Oops, attached the old one with the last email.
>>
>> Updated one really attached this time.
>
> Adde
> On Nov 18, 2017, at 12:45 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Apparently there was some minor breakage due to duplicate OIDs, so here
> is the patch series updated to current master.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development,
> On Nov 27, 2017, at 8:47 AM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch series, fixing the issues
> reported by Mark Dilger:
>
> 1) Fix fabs() issue in histogram.c.
>
> 2) Do not rely on extra_data being StdAnalyze
> On Dec 13, 2017, at 12:07 AM, Andres Freund wrote:
>
> Hi,
>
> On 2017-07-17 12:54:31 -0700, Mark Dilger wrote:
>> These types provide a 4-byte datatype for storing real-world second
>> precision timestamps, as occur in many log files.
>
> These seem to
> On Dec 8, 2017, at 9:21 AM, Stephen Frost wrote:
>
> Mark,
>
> * Mark Dilger (hornschnor...@gmail.com) wrote:
>>> On Dec 7, 2017, at 10:24 PM, Bruce Momjian wrote:
>>> I think the big problem with two-stage pg_upgrade is that the user steps
>>> are
> On Dec 7, 2017, at 10:24 PM, Bruce Momjian wrote:
>
> On Thu, Dec 7, 2017 at 10:37:30AM -0500, Stephen Frost wrote:
>> Alexander,
>>
>> * Alexander Kukushkin (cyberd...@gmail.com) wrote:
>>> Couple of months ago we at Zalando upgraded a few databases of different
>>> sizes to 9.6.
>>
>> Tha
> On Dec 5, 2017, at 4:07 PM, Thomas Munro
> wrote:
>
> On Wed, Dec 6, 2017 at 9:35 AM, Mark Dilger wrote:
>>> On Dec 5, 2017, at 11:25 AM, Thomas Munro
>>> wrote:
>>> Does the plan have multiple Gather nodes with Parallel Bitmap Heap Scan?
>>
> On Dec 5, 2017, at 11:25 AM, Thomas Munro
> wrote:
>
> On Wed, Dec 6, 2017 at 6:17 AM, Mark Dilger wrote:
>> I'm not asking for help configuring my system. If this is a run of the mill
>> out of memory
>> type error, I'll deal with it mysel
Hackers,
I'm getting the error in $subject and am only posting here because (a) the
comments
in src/backend/utils/mmgr/dsa.c circa line 720 suggest that this is a bug, and
(b) the
DSA code appears to be fairly new to the postgresql project, and perhaps not
fully
debugged.
I am running against
> On Nov 28, 2017, at 2:57 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Nov 28, 2017, at 12:47 PM, Tom Lane wrote:
>>> I think that'd be taking it too far, especially given that the dependency
>>> on a typedefs list means that the git hook
> On Nov 28, 2017, at 12:47 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I have no objection, but if the community intends to keep everything
>> indented per project standards, why is there no git hook to reject
>> improperly indented code at commit time? I'
> On Nov 28, 2017, at 1:22 PM, Peter Eisentraut
> wrote:
>
> On 11/28/17 14:07, Mark Dilger wrote:
>> Upon further review, I have noticed that `pg_ctl stop` does not work once
>> the org.postgresql.postgres service has been started. I was trying to stop,
>> reins
> On Nov 28, 2017, at 11:51 AM, Robert Haas wrote:
>
> If nobody minds too much, I'd like to update typedefs.list and
> pgindent the whole tree again. We've generally done a pretty good job
> with pgindenting patches as they are committed this cycle, but we're
> starting to accumulate things he
> On Nov 28, 2017, at 11:17 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Upon further review, I have noticed that `pg_ctl stop` does not work once
>> the org.postgresql.postgres service has been started. I was trying to stop,
>> reinstall and re-initdb and restar
> On Nov 15, 2017, at 12:02 PM, Mark Dilger wrote:
>
>
>> On Nov 15, 2017, at 11:00 AM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>>> On Nov 15, 2017, at 8:32 AM, Tom Lane wrote:
>>>> The stuff in contrib/start-scripts/osx/ does no
> On Nov 26, 2017, at 10:28 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>>boolnulls[Natts_pg_replication_origin];
>>memset(&nulls, 0, sizeof(nulls));
>
>> around lines 277 through 303. Patch below.
>
> AFAIK this is not
Hackers,
boolnulls[Natts_pg_replication_origin];
...
memset(&nulls, 0, sizeof(nulls));
around lines 277 through 303. Patch below.
mark
diff --git a/src/backend/replication/logical/origin.c
b/src/backend/replication/logical/origin.c
index 55382b4b24..88188bd190 10
> On Nov 25, 2017, at 2:05 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> It looks to me like Alvaro introduced this in the original version of the
>> file which
>> was created in commit 7b504eb282ca2f5104b5c00b4f05a3ef6bb1385b. Grep'ing
>> through
> On Nov 25, 2017, at 3:33 PM, Tomas Vondra
> wrote:
>
>
>
> On 11/25/2017 10:01 PM, Mark Dilger wrote:
>>
>>> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
>>> wrote:
>>>
>>> Hi,
>>>
>>> Attached is an upda
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
Hi Tomas,
In src/backend/statistics/dependencies.c, you have introduced a comment:
+ /*
+* build an
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Suppo
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Suppo
Hackers, Alvaro,
In src/backend/statistics/extended_stats.c, in statext_store, there is a
section:
Datum values[Natts_pg_statistic_ext];
boolnulls[Natts_pg_statistic_ext];
boolreplaces[Natts_pg_statistic_ext];
memset(nulls, 1, Natts_pg_statistic_ext * sizeo
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Suppo
> On Nov 18, 2017, at 12:28 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, adopting the psql describe
> changes introduced by 471d55859c11b.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Suppo
> On Nov 15, 2017, at 1:37 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I have tested this on 10.11.6. I had no trouble following the instructions
>> in the README and everything worked as described.
>> As far as I can tell, this patch has not yet been submitted
> On Nov 15, 2017, at 11:00 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Nov 15, 2017, at 8:32 AM, Tom Lane wrote:
>>> The stuff in contrib/start-scripts/osx/ does not, as far as I know,
>>> work at all on any recent release of macOS, because System
> On Nov 15, 2017, at 8:32 AM, Tom Lane wrote:
>
> The stuff in contrib/start-scripts/osx/ does not, as far as I know,
> work at all on any recent release of macOS, because SystemStarter
> is long gone. I propose replacing it with the attached, which
> I've tested on current-vintage Macs.
>
I
> On Nov 15, 2017, at 8:32 AM, Tom Lane wrote:
>
> The stuff in contrib/start-scripts/osx/ does not, as far as I know,
> work at all on any recent release of macOS, because SystemStarter
> is long gone. I propose replacing it with the attached, which
> I've tested on current-vintage Macs.
>
>
901 - 959 of 959 matches
Mail list logo
