were. You’d just need information passed down that collations
can be ignored for this comparison, or that a built-in byte-for-byte equality
comparator should be used rather than the collation’s equality comparator, or
some such solution.
I’m guessing I’m wrong about at least one of these things, and I’m hoping
somebody enlightens me.
Thanks so much in advance,
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ented
nondeterministic collations without reworking these other interfaces”, but once
again, I’m hoping to be corrected if I’ve gone off in the wrong direction here.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jan 30, 2020, at 12:02 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> According to Tom:
>>> (BTW, before v12 the text '=' operator indeed did not care for collation,
>>> so this example would've worked. But the change in behavior i
> On Jan 30, 2020, at 12:29 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Would it make sense to catch a qual with unassigned collation
>> somewhere in the planner, where the qual's operator family is
>> estatblished, by checking if the operator family behavi
and get a
fix in upstream...
Mark
On Thu, Jan 30, 2020 at 4:46 PM Tom Lane wrote:
> Mark Charsley writes:
> > This line
> >
> https://github.com/postgres/postgres/blob/30012a04a6c8127397a8ab71e160d9c7e7fbe874/src/interfaces/libpq/fe-exec.c#L1073
> > triggers data race error
> On Feb 2, 2020, at 6:14 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I put the CommandTag enum in src/common because there wasn’t any reason
>> not to do so. It seems plausible that frontend test frameworks might want
>> access to this enum.
>
Thank
> On Feb 4, 2020, at 7:34 PM, Andres Freund wrote:
>
> Hi,
Thanks for reviewing! I am pretty much in agreement with your comments, below.
> On 2020-02-04 18:18:52 -0800, Mark Dilger wrote:
>> In master, a number of functions pass a char *completionTag argument
> On Feb 5, 2020, at 4:51 AM, Etsuro Fujita wrote:
>
> On Wed, Jan 29, 2020 at 9:15 PM Etsuro Fujita wrote:
>> On Tue, Jan 28, 2020 at 1:39 PM Mark Dilger
>> wrote:
>>> I have added tests checking correctness and showing some partition pruning
>>> lim
idth=32)
-> Seq Scan on alpha_pos_pos alpha (cost=0.00..1.06 rows=1 width=16)
Filter: ((b = '1'::double precision) AND (a = '1'::double precision))
-> Seq Scan on beta_hi beta (cost=0.00..1.04 rows=1 width=16)
Filter: ((b = '1'::double precision) AND (a = '1'::double precision))
(5 rows)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Feb 11, 2020, at 11:09 AM, Alvaro Herrera wrote:
>
> On 2020-Feb-07, Mark Dilger wrote:
>
>> Andres,
>>
>> The previous patch set seemed to cause confusion, having separated
>> changes into multiple files. The latest patch, heavily influenced b
> On Feb 11, 2020, at 12:50 PM, Alvaro Herrera wrote:
>
> On 2020-Feb-11, Mark Dilger wrote:
>
>> I thought about generating the files rather than merely checking them.
>> I could see arguments both ways. I wasn’t sure whether there would be
>> broad suppo
> On Feb 11, 2020, at 1:02 PM, Alvaro Herrera wrote:
>
> On 2020-Feb-11, Mark Dilger wrote:
>
>>> No thanks.
>>
>> I’m not sure which option you are voting for:
>>
>> (Option #1) Have the perl script generate the .c and .h file from a .dat
hutils.h-for-frontend-use.patch
Description: Binary data
v2-0004-Move-src-backend-utils-hash-hashfn.c-to-src-commo.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Feb 14, 2020, at 8:15 AM, David Fetter wrote:
>
> On Fri, Feb 14, 2020 at 10:33:04AM -0500, Robert Haas wrote:
>> On Thu, Feb 13, 2020 at 11:26 AM Mark Dilger
>> wrote:
>>> I have made these changes and rebased Robert’s patches but
>>> ot
> On Feb 14, 2020, at 8:29 AM, David Fetter wrote:
>
> On Fri, Feb 14, 2020 at 08:16:47AM -0800, Mark Dilger wrote:
>>> On Feb 14, 2020, at 8:15 AM, David Fetter wrote:
>>>
>>> On Fri, Feb 14, 2020 at 10:33:04AM -0500, Robert Haas wrote:
>>>&
ng like ::IO::File and ::File::Temp
which could be thin wrappers around IO::File and File::Temp that automatically
do the tie()ing for you. (Replace with whichever name seems best.)
Is this too convoluted to be worth the bother?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
you finished running and whether you want a rowcount and/or
lastoid are orthogonal issues. We already have problems with there being
different commandtags for different versions of morally the same commands.
Take for example "SELECT FOR KEY SHARE" vs. "SELECT FOR NO KEY
> On Feb 28, 2020, at 5:42 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Feb 28, 2020, at 3:05 PM, Tom Lane wrote:
>>> Is there a way to drop that logic altogether by making the tagname string
>>> be "INSERT 0" for the INSERT case? Or wo
> On Mar 2, 2020, at 8:12 AM, Alvaro Herrera wrote:
>
> On 2020-Feb-29, Mark Dilger wrote:
>
>> You may want to think about the embedding of InvalidOid into the EndCommand
>> output differently from how you think about the embedding of the rowcount
>> into
serves
no useful purpose that I can see. But I understand if you are just trying to
have the patch change fewer parts of the code, and if you feel more comfortable
about reverting that part of the patch, as the committer, I think that's your
prerogative.
Did you want to do that yourself,
> On Mar 2, 2020, at 1:57 PM, Alvaro Herrera wrote:
>
> On 2020-Mar-02, Mark Dilger wrote:
>
>> I think it is more natural to change event trigger code to reason
>> natively about CommandTags rather than continuing to reason about
>> strings. The conversion b
>-
>
> https://www.postgresql-archive.org/GSoC-Summery-of-pg-performance-farm-td6034578.html
>-
>
> https://www.postgresql-archive.org/GSOC-18-Performance-Farm-Project-Initialization-Project-td6010380.html
>-
>
> https://www.postgresql-archive.org/GS
, false)
PG_CMDTAG(CMDTAG_ALTER_ACCESS_METHOD, "ALTER ACCESS METHOD", true, false,
false)
PG_CMDTAG(CMDTAG_ALTER_AGGREGATE, "ALTER AGGREGATE", true, false, false)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
MaxBackends gets expensive for
folks running a high number of backends. Taking that from 192 tags down to one
or two dozen seems worthwhile.
I expect to post on a separate thread before the day is over.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
terprisedb.com
v1-0001-Implementing-the-cmdstats-subsystem.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t it'd provide
> security against calling functions you didn't intend to without
> any visible changes in normal application behavior. The security
> team gave up on that approach because it seemed too complicated to
> pursue as a secretly-developed security patch, but I still think
> it's the right long-term answer.
Do you have a WIP patch partially developed for this? If it is no
longer secret, perhaps the rest of us could take a look?
mark
I am still having problems rebasing this patch. I can not figure it out on
my own.
On Sun, 27 May 2018 at 5:31 pm, Mark Rofail wrote:
> issue 1: `pg_constraint.c:564`
> I need to check that `conppeqop` is not null and copy it but I don't know
> how to check its type since its a c
> On Sep 11, 2020, at 8:36 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Thu, Sep 3, 2020 at 11:50 AM Mark Dilger
>> wrote:
>>> Since newer pg_dump binaries can be used to dump data from older servers,
>>> and since users might then load
> On Sep 11, 2020, at 11:25 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> On Sep 11, 2020, at 8:36 AM, Tom Lane wrote:
>>> My inclination is to simply not change pg_dump. There is no need to break
>>> the use-case of loading the output back into the serve
> On Sep 11, 2020, at 12:54 PM, Robert Haas wrote:
>
> On Fri, Sep 11, 2020 at 3:23 PM Mark Dilger
> wrote:
>> Another option would be to have pg_dump take a strictness mode option. I
>> don't think the option should have anything to do with postfix operators
ch lower down my priority list. Thank you, Michael, for the reminder!
>
> It seems fine to mark the patch as RwF at the end of commitfest, but
> that's two weeks away. I don't understand what is accomplished by doing
> it ahead of time, other than alienating the patch auth
to be an enum sort of thing, maybe the output
> column title could be "collabel" with values "bare" or "requires_AS".
>
> So I'm thinking about making these changes in gram.y:
>
> ImplicitAlias -> BareColLabel
> implicit_alias_keyword -> bare_label_keyword
>
> and corresponding terminology changes elsewhere.
That sounds ok to me.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
const void *key)
return h[a % 2463] + h[b % 2463];
}
-static const unicode_norm_info UnicodeNormInfo_NFC_QC = {
- UnicodeNormProps_NFC_QC,
- NFC_QC_hash_func,
- 1231
-};
-
static const pg_unicode_normprops UnicodeNormProps_NFKC_QC[] = {
{0x00A0, UNICODE_NORM_QC_NO},
{0x00A8, UNICODE_NORM_QC_NO},
--
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Sep 19, 2020, at 3:58 PM, John Naylor wrote:
>
> On Sat, Sep 19, 2020 at 1:46 PM Mark Dilger
> wrote:
>
>> 0002 and 0003 look good to me. I like the way you cleaned up a bit with the
>> unicode_norm_props struct, which makes the code a bit more tidy, and o
at this feeling of safety is not justified.
I am inclined to just restrict verify_heapam() to superusers and be done. What
do you think?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Oct 01, 2020 at 12:12:44PM -0700, Andres Freund wrote:
> Hi Mark,
>
> shoveler has been failing for a while with an odd error. E.g.
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=shoveler&dt=2020-09-18%2014%3A01%3A48
>
> Illegal instruction
> pg_dumpa
On Thu, Oct 01, 2020 at 09:12:53PM -0400, Tom Lane wrote:
> Mark Wong writes:
> > I'm getting Tom set up with access too, in case he has time before me to
> > get a stack trace to see what's happening...
>
> tl;dr: it's hard to conclude that this is anything
> On Oct 6, 2020, at 11:27 PM, Andrey Borodin wrote:
>
>
>
>> 7 окт. 2020 г., в 04:20, Mark Dilger
>> написал(а):
>>
>>
>>
>>> On Oct 5, 2020, at 5:24 PM, Mark Dilger
>>> wrote:
>>>
>>> - This version
end/utils/misc/guc.c
Thoughts?
v1-0001-Removing-gratuitous-inclusion-of-xlog_internal.h.patch
Description: Binary data
v1-0002-Moving-RmgrData-from-xlog_internal.h-to-its-own-h.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 19, 2020, at 7:05 PM, Andres Freund wrote:
>
> Hi,
>
> On 2020-10-19 18:29:27 -0700, Mark Dilger wrote:
>> Please find access/xlog_internal.h refactored in the attached patch
>> series. This header is included from many places, including external
>
hrough v2-0009 still apply cleanly, but v2-0010 no longer applies. It
seems to be conflicting with Heikki's work from August. Could you rebase
please?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 21, 2020, at 1:13 PM, Alvaro Herrera wrote:
>
> On 2020-Oct-21, Robert Haas wrote:
>
>> On Wed, Oct 7, 2020 at 9:01 PM Mark Dilger
>> wrote:
>>> This next version, attached, has the acl checking and associated
>>> documentation changes s
> On Oct 21, 2020, at 1:51 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> There is still something screwy here, though, as this compiles, links and
>> runs fine for me on mac and linux, but not for Robert.
>
> Are you using --enable-nls at all on your Mac
arc64 machine, but it's hard to tell, since none of
> the other sparc64 critters have run yet. In any case I don't know why
> that would cause a failure. The messages in the log aren't very
> illuminating, unfortunately. :-(
>
> Mark, any ideas what might cause specificall
> On Oct 22, 2020, at 9:01 AM, Mark Dilger wrote:
>
>
>
>> On Oct 22, 2020, at 7:06 AM, Robert Haas wrote:
>>
>> On Thu, Oct 22, 2020 at 8:51 AM Robert Haas wrote:
>>> Committed. Let's see what the buildfarm thinks.
>>
>>
> On Oct 22, 2020, at 1:00 PM, Robert Haas wrote:
>
> On Thu, Oct 22, 2020 at 3:15 PM Mark Dilger
> wrote:
>> The 0001 attached patch addresses the -Werror=maybe-uninitialized problem.
>
> I am skeptical. Why so much code churn to fix a compiler warning? And
&g
causing
this particular regression test failure.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
{
Yeah, I reached the same conclusion before submitting the fix upthread. I
structured it a bit differently, but I believe fxid will now always get set
before being used, though sometimes the function returns before doing either.
I had the same thought about compilers not catching that, too.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 22, 2020, at 1:31 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Oct 22, 2020, at 1:09 PM, Tom Lane wrote:
>>> ooh, looks like prairiedog sees the problem too. That means I should be
>>> able to reproduce it under a debugger, if you'
> On Oct 22, 2020, at 2:06 PM, Tom Lane wrote:
>
> I wrote:
>> Mark Dilger writes:
>>> It is seeking to position 32 and writing '\x77\x77\x77\x77'. x86_64 is
>>> little-endian, and ppc32 and sparc64 are both big-endian, right?
>
>> T
> On Oct 22, 2020, at 2:06 PM, Tom Lane wrote:
>
> I wrote:
>> Mark Dilger writes:
>>> It is seeking to position 32 and writing '\x77\x77\x77\x77'. x86_64 is
>>> little-endian, and ppc32 and sparc64 are both big-endian, right?
>
>> T
> On Oct 22, 2020, at 2:26 PM, Peter Geoghegan wrote:
>
> On Thu, Oct 22, 2020 at 5:51 AM Robert Haas wrote:
>> Committed. Let's see what the buildfarm thinks.
>
> This is great work. Thanks Mark and Robert.
That's the first time I've laughed today. Hav
tinct is to go the other direction and have even less
knowledge about pages in the test. That would work if instead of expecting
corruption for every time the test writes the file, instead to have it just
make sure that it gets corruption reports at least some of the times that it
does so. That seems more maintainable long term.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
.
Ahh, crud. It's because
syswrite($fh, '\x77\x77\x77\x77', 500)
is wrong twice. The 500 was wrong, but the string there isn't the bit pattern
we want -- it's just a string literal with backslashes and such. It should
have been double-quoted.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 22, 2020, at 6:50 PM, Mark Dilger wrote:
>
>
>
>> On Oct 22, 2020, at 6:46 PM, Tom Lane wrote:
>>
>> I wrote:
>>> I get
>>> off = , flags = 2, len = 3bbb
>>> on a little-endian machine, and
>>> off = 3bbb, f
> On Oct 22, 2020, at 7:01 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Ahh, crud. It's because
>> syswrite($fh, '\x77\x77\x77\x77', 500)
>> is wrong twice. The 500 was wrong, but the string there isn't the bit
>> pattern we wa
> On Oct 22, 2020, at 9:21 PM, Mark Dilger wrote:
>
>
>
>> On Oct 22, 2020, at 7:01 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> Ahh, crud. It's because
>>> syswrite($fh, '\x77\x77\x77\x77', 500)
>>>
> On Oct 23, 2020, at 11:04 AM, Tom Lane wrote:
>
> I wrote:
>> Mark Dilger writes:
>>> The patch I *should* have attached last night this time:
>
>> Thanks, I'll do some big-endian testing with this.
>
> Seems to work, so I pushed it (after som
Patch attached.
v23-0001-Sanity-checking-line-pointers.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
possibly correct
> since I wasn't running in UTF8 encoding, but I'm not entirely sure of
> that either.
>
> This is with RHEL8's lcov-1.13-4.el8 package. I suppose the first
> question is does anybody else see that?
I don't see it on mac nor on ubuntu64. I ge
> On Oct 23, 2020, at 4:12 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> You certainly appear to be right about that. I've added the extra checks,
>> and extended the regression test to include them. Patch attached.
>
> Pushed with some more fooling ab
ther
> hand, having all that code might allow better testing not only of this
> particular patch but also other scenarios involving corrupted pages,
> so maybe it's wrong to view all that code as a burden that we have to
> carry specifically to test this; or, alternatively, maybe it&#
> On Oct 26, 2020, at 7:00 AM, Robert Haas wrote:
>
> On Mon, Oct 26, 2020 at 9:56 AM Mark Dilger
> wrote:
>> Much of the test in 0002 could be ported to work without committing the rest
>> of 0002, if the pg_amcheck command line utiilty is not wanted.
>
> How
> On Oct 26, 2020, at 9:12 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Oct 21, 2020 at 11:45 PM Mark Dilger
>> wrote:
>>> Done that way in the attached, which also include Robert's changes from v19
>>> he posted earlier today.
>
&g
h (ok it is a distributed
storage system but still a highly popular open src product) have
switched to using cmake (relatively) recently. Both these projects were
using autoconf etc related builds previously and seem to be doing just
fine with cmake.
regards
Mark
I don't care about the syntax / keywords in the example above. I'm just
looking to get the benefits of the parallel aggregation when I don't care
about ordering while preserving the order for these cases where it matters.
mark
> 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
Perhaps you don't think that is a big enough problem to be worth
guarding against.
This patch is not that complicated, but it does create a new coding
requirement to keep bootparse.y and genbki.pl from getting out of sync.
It might be simpler to just change genbki.pl to quote everything rather
than applying this patch. I don't have an opinion on that.
mark
genbki_bootparse_keywords.patch.1
Description: Binary data
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
> 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&
|| defined(_MSC_VER) ||
defined(HAVE_CRTDEFS_H)
+#define errcode __msvc_errcode
+#include
+#undef errcode
+#else
#include
+#endif
#include "postgres.h"
Let me know if there are any tests you'd like me to perform to further
investigate.
mark
> 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
> 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 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 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
il.com
How would we change this so it would be more exhaustive and accurate?
Regards,
Mark Rofail
|| NEW.id_bac ||''','' '
>
> || NEW.id_dossier ||''', '
>
> || NEW.boo_en_migration ||');';
>
>
>
> --RAISE NOTICE 'Creating Partition:%',
> NEW.id_dossier_bac_history;
> EXECUTE new_insert;
> -- RETURN NULL;
> END;
> $$ LANGUAGE plpgsql VOLATILE;
>
>
> INSERT INTO t_dossier_bac_history_insert_table
> SELECT * FROM t_dossier_bac_history;
mark
on current-vintage Macs.
>
> If anyone's interested in reviewing this, I'll stick it into the
> next commitfest.
Sure, I'll take a look.
mark
hich to
use for whichever version of OS X they happen to be running. It's of no
consequence to me, since my oldest mac is running 10.6.8, but somebody
from the museum of old macs might feel differently.
mark
> 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 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
rray_agg(gs::numeric) AS a, array_agg(gs::numeric) AS b
+ FROM generate_series(1,1000) gs
+ );
+ANALYZE mcv_lists;
+
+DROP TABLE mcv_lists;
Which gives me the following regression.diffs:
*** /Users/mark/master/postgresql/src/test/regress/expected/stats_ext.out
2017-11-25 08:06:37.00
omment
could be added here mentioning that 'kinds' is a bitmask, and that these
#defines are related?
mark
izeof(nulls));
memset(replaces, 0, sizeof(replaces));
memset(values, 0, sizeof(values));
Patch attached as 0001_extended_stats_sizeof.patch.1
mark
0001_extended_stats_sizeof.patch.1
Description: Binary data
e through the loop, since the compiler might not be able to prove to
itself that data->numrows
does not get changed. Perhaps you should compute it just once prior to
entering the outer loop,
store it in a variable of integer type, round 'delta' off and store in an
integer, and do integer comparisons
within the loop? Just a thought
mark
's not true and we
+ /* Now it's safe to access the dimention info. */
+* Nowe we know the total expected MCV size, including all the pieces
+ /* pased by reference, but fixed length (name, tid,
...) */
In src/include/statistics/statistics.h, there is some extraneous whitespace
that needs
removing.
mark
hat fact to the comments
rather than
changing the elogs to ereports.
mark
> 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 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
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..88188b
> 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
> 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 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
un into a branch
post-global-indent-run and would rather this not keep happening.
Sorry if this has been debated before. A quick search did not turn up
any previous conversation, but that doesn't mean it has never been
discussed.
mark
> 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 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 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
pe
of query, then you might see some partition pruning.
Cheers
Mark
) AS s
If this is not a bug, but rather something that users can hit through normal
resource
exhaustion, then perhaps the comments in dsa.c can be changed to make that
clear.
Thanks!
mark
> 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
1001 - 1100 of 1167 matches
Mail list logo
