> On Jun 30, 2020, at 2:47 PM, Mark Dilger wrote:
>
>
>
>> On May 19, 2020, at 4:47 PM, Tom Lane wrote:
>>
>> I wrote:
>>> However, we do have to have a benefit to show those people whose
>>> queries we break. Hence my insistence on ha
renaming makes sense to me. Those commands work on objects that are
>> relkinds, except for one OBJECT_TYPE. So, let's get 0001 patch
>> merged. Any objections from others?
>
> I have been through this one again and applied it as cc35d89.
> --
> Michael
> On Jul 10, 2020, at 11:00 PM, Michael Paquier wrote:
>
> On Wed, Jul 01, 2020 at 05:04:19PM -0700, Mark Dilger wrote:
>> Most of the work in this patch is mechanical replacement of if/else
>> if/else statements which hinge on relkind to switch statements on
>>
re an "invalid" relkind is returned;
Ok.
> and once
> that's in place, replace if tests with switch blocks where it makes
> sense to do so.
Ok.
>
> Also, I suggest that this thread is not a good one for this patch.
> Subject is entirely not appropriate. Open a new thread perhaps?
I've changed the subject line.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
00 00 00 00 08 00 00 ===> . . . . . . . .
46 00 00 00 01 00 00 00 ===> p . . . . . . .
00 00 00 00 01 00 00 00 ===> . . . . . . . .
01 00 00 00 00 00 00 00 ===> . . . . . . . .
01 00 00 00 19 46 06 46 ===> . . . . % p l p
43 49 47 06 05 4c 3d 06 ===> g s q l _ v a l
45 40 3d 4a 06 48 15 18 ===> i d a t o r ! $
06 45 3e 40 45 48 02 46 ===> l i b d i r / p
06 46 43 49 47 06 ===> l p g s q l
Is there any interest in this stuff, and if so, where should it live? I'm
happy to
reorganize this a bit if there is general interest in such a submission.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
7;t understand the prejudice against commas used this way. What is wrong
with:
$i++, $j++ if defined $k;
rather than:
if (defined $k)
{
$i++;
$j++;
}
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 11, 2020, at 9:47 AM, Andrew Dunstan
> wrote:
>
>
> On 4/11/20 12:28 PM, Mark Dilger wrote:
>>
>>> On Apr 11, 2020, at 9:13 AM, Andrew Dunstan
>>> wrote:
>> Hi Andrew. I appreciate your interest and efforts here. I hope you don&
gt;
> *<"-fallthrough">
> *<"@fallthrough@">
> *<"lint -fallthrough[ \t]*">
> *<"[ \t]*FALLTHR(OUGH|U)[ \t]*">
>
> Thoughts?
Naturally, I'm +1 for this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Not having received any feedback on this, I've dusted the modules off for
submission as-is.
v1-0001-Adding-HeapFile-related-perl-modules.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 14, 2020, at 6:17 PM, Peter Geoghegan wrote:
>
> On Wed, Apr 8, 2020 at 3:51 PM Mark Dilger
> wrote:
>> Recently, as part of testing something else, I had need of a tool to create
>> surgically precise corruption within heap pages. I wanted to make the
&
> On Apr 6, 2020, at 5:14 PM, Thomas Munro wrote:
>
> On Sun, Apr 5, 2020 at 11:31 AM Thomas Munro wrote:
>> On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
>> wrote:
>>> The "xid8_" warts are partly motivated by having a type named "xid8", whic
> maybe as an extended regex. And a better fix here instead of marking the
> fourth group as non-capturing would be simply to get rid of the parens
> altogether. The serve no purpose at all.
But then you'd have to use something else in position 4, which complicates the
code.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 19, 2020, at 3:55 PM, Michael Paquier wrote:
>
> On Thu, Mar 19, 2020 at 11:47:46AM -0700, Mark Dilger wrote:
>> On Mar 19, 2020, at 11:30 AM, Mark Dilger
>> wrote:
>>> Will post v3 shortly.
>
> Thanks for sending a new version of the patch
ib-module.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
sion!
Can you elaborate on "top-down"? I'm not sure what that means in this context.
I don't mind going further with this project if I understand what you are
suggesting.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
th the
> rootdescend stuff from amcheck. It should be composable.
>
> The interface you've chosen is a good starting point. But let's not miss an
> opportunity to make everything work together.
Ok, I'll work in that direction and repost when I have somethi
> On Apr 20, 2020, at 12:42 PM, Andres Freund wrote:
>
> Hi,
>
> On 2020-04-20 10:59:28 -0700, Mark Dilger wrote:
>> I have been talking with Robert about table corruption that occurs
>> from time to time. The page checksum feature seems sufficient to
>> detec
ions, a bgworker based mode that
periodically checks your database? The work along those lines is not included
in v4, but if it were part of v5, would you have specific design preferences?
v4-0001-Adding-verify_heapam-to-amcheck-contrib-module.patch
Description: Binary data
—
Mark Dilger
> On Apr 29, 2020, at 11:41 AM, Robert Haas wrote:
>
> On Wed, Apr 22, 2020 at 10:43 PM Mark Dilger
> wrote:
>> It's simple enough to extend the tap test a little to check for those
>> things. In v3, the tap test skips tests if the page size is not 8k, and
> On May 12, 2020, at 5:34 PM, Peter Geoghegan wrote:
>
> On Mon, May 11, 2020 at 10:21 AM Mark Dilger
> wrote:
>> 2) amcheck's btree checking functions have been refactored to be able to
>> operate in two modes; the original mode in which all errors are report
d expect from any number of faulty
storage systems. The one "contrived" aspect of my testing in this regard is
that the script I use to write random nonsense to random locations in heap
files is smart enough not to write random junk to the page headers. This is
because if I corrupt the page headers, the backend never even gets as far as
running the verify_heapam functions, as the page cache rejects loading the page.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 13, 2020, at 5:36 PM, Peter Geoghegan wrote:
>
> On Wed, May 13, 2020 at 5:18 PM Mark Dilger
> wrote:
>> I am not removing any assertions. I do not propose to remove any
>> assertions. When I talk about "hardening against assertions", that i
mPointerData, not because other aspects of the patch are unacceptable
(I'm not ready to even contemplate that yet), but because I'm not sure what
your complaint is about. Can you restrict the patch to just address that one
issue?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 14, 2020, at 1:02 PM, Peter Eisentraut
> wrote:
>
> On 2020-05-11 19:21, Mark Dilger wrote:
>> 1) A new module, pg_amcheck, which includes a command line client for
>> checking a database or subset of a database. Internally it functions by
>> query
#x27;m still
unclear whether you believe this is a bug, or whether you just don't like the
naming that is used.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
;ll notice it outputs:
y = { { 5, 10 }, 15 }
and not the { { 0, 1}, 2 } that you would expect if y were merely pointing at x.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
argument types. You might need
to add explicit type casts.
So if we put that in the set of characters disallowed for infix operators, we
would only be breaking custom infix operators named that, which seems like less
breakage to me than removing postfix operators of all kinds.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ed data files
are. But a single, consistent design for extra-grammatical error checks could
help augment those files fairly well, too.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 25, 2020, at 2:55 AM, Peter Eisentraut
> wrote:
>
> On 2020-05-22 18:53, Mark Dilger wrote:
>> I like the general direction you are going with this, but the decision in
>> v1-0006 to move the error for invalid object types out of gram.y and into
> On May 26, 2020, at 4:59 PM, David G. Johnston
> wrote:
>
> On Tue, May 26, 2020 at 4:19 PM Mark Dilger
> wrote:
> I'd also appreciate +1 and -1 votes on the overall idea, in case this entire
> feature, regardless of implementation, is simply something the
> On May 27, 2020, at 1:13 AM, Dave Page wrote:
>
> Hi
>
> On Wed, May 27, 2020 at 12:19 AM Mark Dilger
> wrote:
>
> I think it makes sense that packagers could put the LIBEXECDIR in the PATH so
> that 3rd-party scripts which call pg_ctl, initdb, etc. cont
> On May 27, 2020, at 1:50 AM, Magnus Hagander wrote:
>
> On Wed, May 27, 2020 at 1:19 AM Mark Dilger
> wrote:
> Hackers,
>
> Attached is a patch for a `pg' command that consolidates various PostgreSQL
> functionality into a single command, along the lines of
ds from contrib modules without the
"pg" command needing to know anything about them. This, too, is still open to
conversation and debate.
I'd like to hear from more community members on this. I'm listening.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
sr/bin
2.4 GHz 8-Core Intel Core i9
32 GB 2667 MHz DDR4
Reading this thread, I think the lack of a performance impact on laptop
hardware was expected, but perhaps confirmation that it does not make things
worse is useful?
Since this patch doesn't seem to do any harm, I would
o-back, with the four
that are set by SelectConfigFiles() at the top with comments about why they are
special, and the rest after that with comments about why they need or do not
need canonicalization.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
de_combining_table.pl, and future callers can
pass in the numbers they want? Or is there some advantage to having it this
way?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 28, 2020, at 8:54 PM, John Naylor wrote:
>
> On Fri, May 29, 2020 at 5:59 AM Mark Dilger
> wrote:
>>
>>> On May 21, 2020, at 12:12 AM, John Naylor
>>> wrote:
>
>>> very picky in general. As a test, it also successfully finds a
&g
One line change to remove a duplicate check.
v1-0001-Code-cleanup.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jun 1, 2020, at 8:53 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> One line change to remove a duplicate check.
>
> The comment just above this mentions a connection to the "Finish printing
> the footer information about a table" stanza below. I thin
> On Jun 1, 2020, at 9:59 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Yeah, I noticed the `git blame` last night when writing the patch that you
>> had originally wrote the code around 2017, and that the duplication was
>> introduced in a patch committed by
> On Mar 4, 2020, at 7:43 PM, Mark Dilger wrote:
>
> Hackers,
>
> as mentioned in [1], I have created an implementation of command counter
> statistics very similar in purpose to the one already pending in the
> commitfest going by the name "pg_stat_sql"
> On Jun 2, 2020, at 9:58 AM, Mark Dilger wrote:
>
>>
>> On Mar 4, 2020, at 7:43 PM, Mark Dilger wrote:
>>
>> Hackers,
>>
>> as mentioned in [1], I have created an implementation of command counter
>> statistics very similar in purpose
> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote:
>
> David Rowley writes:
>> As far as I can see the patch is ready to go, but I'll defer to Mark,
>> who's also listed on the reviewer list for this patch.
>
> Mark, are you planning to do further review on this patch?
> I'd like to move it alon
> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote:
>
> David Rowley writes:
>> As far as I can see the patch is ready to go, but I'll defer to Mark,
>> who's also listed on the reviewer list for this patch.
>
> Mark, are you planning to do further review on this patch?
> I'd like to move it alon
> On Jan 27, 2019, at 12:04 PM, Mark Dilger wrote:
>
>
>
>> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote:
>>
>> David Rowley writes:
>>> As far as I can see the patch is ready to go, but I'll defer to Mark,
>>> who's also listed
> On Feb 7, 2019, at 12:14 AM, Peter Eisentraut
> wrote:
>
> Here is a patch that makes more use of unconstify() by replacing casts
> whose only purpose is to cast away const. Also a preliminary patch to
> remove casts that were useless to begin with.
>
> --
> Peter Eisentraut
> On Jan 29, 2020, at 1:02 PM, Andrew Dunstan
> wrote:
>
> On Wed, Jan 29, 2020 at 4:32 PM Andrew Dunstan
> wrote:
>>
>>
>> On 1/28/20 5:28 PM, Mark Dilger wrote:
>>>
>>>
>>>> +# There doesn't seem to be any easy way
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
> 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
, 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
> On Aug 8, 2018, at 7:47 AM, Tom Lane wrote:
>
> Isaac Morland writes:
>> On 8 August 2018 at 09:58, Tom Lane wrote:
>>> When the security team was discussing this issue before, we speculated
>>> about ideas like inventing a function trust mechanism, so that attacks
>>> based on search path
> 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
ors.
Thanks, Álvaro! I do not feel alienated, and I hope Haribabu Kommi does not
either.
Haribabu, do you have an opinion on which of the two patches should proceed? I
don't recall seeing a response from you about whether you liked what I did with
your patch. Perhaps you were waiting on
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 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
y that set of tests to fail?
The code is correctly handling an uncorrupted table, but then more or less
randomly failing some of the time when processing a corrupt table.
Tom identified a problem with an uninitialized variable. I'm putting together
a new patch set to address it.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> 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
ing turned the build-farm red,
this is quite ironic feedback! Thanks all the same for the sentiment.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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
801 - 900 of 980 matches
Mail list logo
