e owned by users who lack bypassrls is interesting.
If we make that work, it will be a more complete solution than option (d).
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
he old owner has
privileges increased.
In both cases, a currently running logical replication worker may finish a
transaction in progress acting with the current privileges of the old owner.
The clearest solution is, as you suggest, to refuse transfer of ownership of
subscriptions that
> 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 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 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 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 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 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
>>
+ 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 10/2/19 8:46 AM, Tom Lane wrote:
Joe Nelson writes:
Isaac Morland wrote:
I hope you'll forgive a noob question. Why does the "After"
initialization for the boolean array have {0} rather than {false}?
I think using a value other than {0} potentially gives the incorrect
impression that
On 10/2/19 11:02 AM, Tom Lane wrote:
Mark Dilger writes:
On 10/2/19 8:46 AM, Tom Lane wrote:
Right. I think that in general it's bad practice for an initializer
to not specify all fields/elements of the target.
There are numerous locations in the code that raise warnings when
-Wmi
On 10/13/19 12:25 PM, Peter Eisentraut wrote:
diff --git a/contrib/hstore/hstore_compat.c b/contrib/hstore/hstore_compat.c
index 1d4e7484e4..d75e9cb23f 100644
--- a/contrib/hstore/hstore_compat.c
+++ b/contrib/hstore/hstore_compat.c
@@ -299,7 +299,7 @@ hstoreUpgrade(Datum orig)
if (valid
On 10/15/19 5:23 AM, Andrew Gierth wrote:
"Mark" == Mark Dilger writes:
>> +#ifdef HSTORE_IS_HSTORE_NEW
Mark> Checking the current sources, git history, and various older
Mark> commits, I did not find where HSTORE_IS_HSTORE_NEW was ever
Mark> defined.
In
> 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
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
> 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"
> 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 10/29/19 11:32 PM, Andres Freund wrote:
Hi,
On 2019-10-29 16:31:11 -0400, Tom Lane wrote:
Andres Freund writes:
one of the most frequent conflicts I see is that two patches add files
to OBJS (or one of its other spellings), and there are conflicts because
another file has been added.
..
Hackers,
please find attached a patch fixing a problem previously discussed [1]
about the code inappropriately ignoring the return value from SPI_execute.
I will be adding this to https://commitfest.postgresql.org/26/ shortly.
Mark Dilger
[1] https://www.postgresql.org/message-id
On 11/5/19 8:27 PM, Michael Paquier wrote:
On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote:
please find attached a patch fixing a problem previously discussed [1] about
the code inappropriately ignoring the return value from SPI_execute.
I will be adding this to https
On 11/5/19 9:54 PM, Pavel Stehule wrote:
st 6. 11. 2019 v 5:28 odesílatel Michael Paquier <mailto:mich...@paquier.xyz>> napsal:
On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote:
> please find attached a patch fixing a problem previously
discuss
ble to commit this patch even if other
SPI patches are rejected.
--
Mark Dilger
>From 019a37280145ef437acd26b4cd2c0ce58aa7709a Mon Sep 17 00:00:00 2001
From: Mark Dilger
Date: Wed, 6 Nov 2019 15:37:50 -0800
Subject: [PATCH v1] Testing COPY inside PL/pgSQL
Adding a test for COPY being run insi
On 11/6/19 6:27 PM, Michael Paquier wrote:
On Wed, Nov 06, 2019 at 04:16:14PM -0800, Mark Dilger wrote:
While working on cleaning up the SPI interface, I found that one of the SPI
error codes, SPI_ERROR_COPY, is never encountered in any test case when
running `make check-world`. This case
ting would indicate the need to
fix bad C code, not the need to catch an exception and take remedial
action at run time. Does this adequately address your concern?
My research so far indicates that most return codes are either totally
unused or of type (b), with only a few of type (a).
--
Mark Dilger
27;ve done and tell me if I've broken it.
--
Mark Dilger
diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index fe2bb8f859..1cddd590b8 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -330,6 +330,41 @@ static int fsync_parent_path(co
an optional $kwargs hash reference.
--
Mark Dilger
eel about it?
If more places like this can be converted to use elog(ERROR), it may be
possible to convert more functions to return void.
[1] https://www.postgresql.org/message-id/13404.1558558354%40sss.pgh.pa.us
[2]
https://www.postgresql.org/message-id/20191106151112.GA1225
On 11/8/19 6:33 AM, Andrew Dunstan wrote:
On 11/8/19 1:16 AM, Craig Ringer wrote:
On Fri, 8 Nov 2019 at 06:28, Mark Dilger mailto:hornschnor...@gmail.com>> wrote:
On 10/31/19 10:02 AM, Andrew Dunstan wrote:
>
> This small patch authored by my colleague
uot;, "bar", and "baz" above are shorthand notation for
things in practice that are already somewhat hard to read, as in:
command_fails_like(
[ 'pg_dump', 'qqq', 'abc' ],
qr/\Qpg_dump: error: too many command-line arguments (first is
"abc")\E/,
'pg_dump: too many command-line arguments');
but adding more to that cruft just makes it worse. Right?
--
Mark Dilger
taking long enough to be significant compared to how
long send() takes?
A bit more information about the performance problem you are
encountering might make it easier to understand the motivation for this
patch.
--
Mark Dilger
output? If so, can you provide a test example that works
differently under your patch?
Thanks!
--
Mark Dilger
diff --git a/src/test/regress/expected/stats_ext.out
b/src/test/regress/expected/stats_ext.out
index b65228fa07..8e20df25fc 100644
--- a/src/test/regress/expected/stats_ext.out
+++ b/s
On 11/9/19 12:33 PM, Mark Dilger wrote:
On 11/6/19 11:58 AM, Tomas Vondra wrote:
On Wed, Nov 06, 2019 at 08:54:40PM +0100, Tomas Vondra wrote:
On Mon, Oct 28, 2019 at 04:20:48PM +0100, Tomas Vondra wrote:
Hi,
PostgreSQL 10 introduced extended statistics, allowing us to consider
eady uses TestLib, so perhaps setting up the environment
can be abstracted into something, perhaps TestLib::run, and then used
everywhere that IPC::Run::run currently is used.
--
Mark Dilger
On 11/11/19 11:28 AM, Andrew Dunstan wrote:
On 11/11/19 1:27 PM, Mark Dilger wrote:
On 11/11/19 8:48 AM, Andrew Dunstan wrote:
On 11/9/19 8:25 AM, Andrew Dunstan wrote:
OK, I agree that we're getting rather baroque here. I could go with
your
suggestion of YA function, or possi
add a node to it might not occur to
people. If the repeated use of
else if (IsA(node, XXX))
were replaced with
switch (nodeTag(node)) {
case XXX:
then the compiler, ala -Wswitch, would alert folks when they forget to
handle a new node type.
--
Mark Dilger
On 11/11/19 2:33 PM, Mark Dilger wrote:
On 11/11/19 1:41 PM, Tom Lane wrote:
Would it be a good idea to move find_expr_references_walker to
nodeFuncs.c, in hopes of making it more visible to people adding
new node types?
I'm not sure that would be enough. The logic of that functi
r, in the form of a patch applied
on top of yours.
--
Mark Dilger
diff --git a/src/backend/statistics/dependencies.c b/src/backend/statistics/dependencies.c
index a6ca11c675..ccf6e41b9c 100644
--- a/src/backend/statistics/dependencies.c
+++ b/src/backend/statistics/dependencies.c
@@ -850,7 +
erested. Currently, the patch is over 2.2MB, gzip'd. I'll
only bother distilling it if you don't already know about these cache
lookup failures.
--
Mark Dilger
On 11/13/19 4:46 PM, Tomas Vondra wrote:
On Wed, Nov 13, 2019 at 03:00:03PM -0800, Mark Dilger wrote:
On 11/11/19 1:41 PM, Tom Lane wrote:
I happened to notice that find_expr_references_walker has not
been taught anything about TableFunc nodes, which means it will
miss the type and
On 11/14/19 7:55 AM, Tomas Vondra wrote:
On Wed, Nov 13, 2019 at 10:04:36AM -0800, Mark Dilger wrote:
On 11/13/19 7:28 AM, Tomas Vondra wrote:
Hi,
here's an updated patch, with some minor tweaks based on the review and
added tests (I ended up reworking those a bit, to make them more
suggestion elsewhere in this thread to
use code in predtest.c sounds good to me.
I don't know if you want to expand the scope of this particular patch to
include that, though.
--
Mark Dilger
On 11/13/19 11:51 AM, Peter Geoghegan wrote:
Can you suggest an alternative?
Dupression
--
Mark Dilger
ions don't appear to matter, as nothing
changes using
`./configure --enable-cassert && make -j4 && make check-world`
--
Mark Dilger
diff --git a/src/test/regress/expected/nonsense.out
b/src/test/regress/expected/nonsense.out
new file mode 100644
index 00..553747
On 11/21/19 6:20 PM, Mark Dilger wrote:
Hackers,
I stumbled upon an assertion while testing master for possible
bugs. I am reporting it here in the hope that this report will
be useful. The attached small regression test patch consistently
triggers an assert in predicate.c:
TRAP
emset(parsed, 0, sizeof(xl_xact_parsed_commit));
parsed->xinfo = 0; /* default, if no XLOG_XACT_HAS_INFO is
* present */
--
Mark Dilger
On 11/21/19 8:03 PM, Tom Lane wrote:
Mark Dilger writes:
I have winnowed down the test a bit further. The attached
smaller patch still triggers the same assertion as the prior
patch did.
FWIW, I can reproduce the assertion failure with your first test,
but not with this simplified one
On 11/22/19 11:07 AM, Tom Lane wrote:
Mark Dilger writes:
On 11/21/19 8:03 PM, Tom Lane wrote:
I also confirm that it only happens in HEAD, not v12. I've not
actually bisected, but a look at the git history for predicate.c
sure makes it look like db2687d1f ("Optimize Predicat
On 11/22/19 11:22 AM, Mark Dilger wrote:
predicate.c was changed a few times after REL_12_STABLE was
branched from master but before Thomas's change that you
initially thought might be to blame. I checked whether
rolling back the changes in predicate.c while keeping your
LISTEN/N
On 11/22/19 3:25 PM, Tom Lane wrote:
I wrote:
Mark Dilger writes:
`git bisect` shows the problem occurs earlier than that, and by
chance the first bad commit was one of yours. I'm not surprised
that your commit was regarding LISTEN/NOTIFY, as the error is
always triggered with a L
you
see the risk you described as "pretty minimal" as still being large
enough to outweigh the risk of anything we might back-patch?
--
Mark Dilger
On 11/23/19 5:01 PM, Tom Lane wrote:
I ran into a couple of issues while trying to devise a regression test
illustrating the LISTEN-in-serializable-transaction issue Mark Dilger
reported. The first one is that an isolation test in which we expect
to see a cross-process NOTIFY immediately
On 11/24/19 8:12 AM, Ranier Vilela wrote:
Hi,
The test "if (zeropadlen > 0)" is redundant and can be salely removed.
It has already been tested in the same path.
I have not tested your patch, but it looks right to me.
--
Mark Dilger
On 11/23/19 8:50 PM, Mark Dilger wrote:
On 11/23/19 5:01 PM, Tom Lane wrote:
I ran into a couple of issues while trying to devise a regression test
illustrating the LISTEN-in-serializable-transaction issue Mark Dilger
reported. The first one is that an isolation test in which we expect
to
On 11/24/19 10:39 AM, Tom Lane wrote:
Mark Dilger writes:
On 11/23/19 8:50 PM, Mark Dilger wrote:
I have finished reading and applying your three patches and have moved
on to testing them. I hope to finish the review soon.
After applying all three patches, the stress test that
On 11/24/19 11:04 AM, Tom Lane wrote:
Mark Dilger writes:
On 11/24/19 10:39 AM, Tom Lane wrote:
After sleeping on it, I'm not really happy with what I did in
PrepareTransaction (that is, invent a separate PrePrepare_Notify
function). The idea was to keep that looking parallel to
On 11/24/19 6:28 PM, Michael Paquier wrote:
On Thu, Nov 07, 2019 at 01:57:57PM -0800, Mark Dilger wrote:
The code and comments don't clearly indicate what you have said in the
email, that you are verifying directories are opened read-only and files are
opened either read-write or write
On 11/24/19 6:53 PM, Mark Dilger wrote:
On 11/24/19 6:28 PM, Michael Paquier wrote:
On Thu, Nov 07, 2019 at 01:57:57PM -0800, Mark Dilger wrote:
The code and comments don't clearly indicate what you have said in the
email, that you are verifying directories are opened read-only and
On 11/25/19 5:08 AM, Andrew Dunstan wrote:
On 11/11/19 4:28 PM, Mark Dilger wrote:
On further consideration, I'm wondering why we don't just
unconditionally use a closed input pty for all these functions (except
run_log). None of them use any input, and making the client w
e(FullTransactionId *dest)
{
- dest->value++;
+ dest->value += 2;
while (XidFromFullTransactionId(*dest) < FirstNormalTransactionId)
dest->value++;
}
or apply the much larger WIP patch, attached, and then be sure to
provide the --enable-xidcheck flag t
ested this change, but I may do so later today or perhaps
on Monday.
--
Mark Dilger
On 11/14/19 12:04 PM, Tomas Vondra wrote:
On Thu, Nov 14, 2019 at 10:23:44AM -0800, Mark Dilger wrote:
On 11/14/19 7:55 AM, Tomas Vondra wrote:
On Wed, Nov 13, 2019 at 10:04:36AM -0800, Mark Dilger wrote:
On 11/13/19 7:28 AM, Tomas Vondra wrote:
Hi,
here's an updated patch, with
r (6
bytes) and macaccdr8 (8 bytes). As for the C type, we use
TransactionId and FullTransactionId (rather than, say, xid32 and
xid64).
In the attached I also took Tom's advice and used unused_oids script
to pick random OIDs >= 8000 for all new objects (ignoring nearby
comments about the range of OIDs used in different sections of the
file).
These two patches (v3) no longer apply cleanly. Could you please
rebase?
--
Mark Dilger
On 11/30/19 5:14 PM, Thomas Munro wrote:
On Sun, Dec 1, 2019 at 12:22 PM Mark Dilger wrote:
These two patches (v3) no longer apply cleanly. Could you please
rebase?
Hi Mark,
Thanks. Here's v4.
Thanks, Thomas.
The new patches apply cleanly and pass 'installcheck'.
--
Mark Dilger
ure if it is possible for the commit message to
arrive before the notify message in the fashion I am describing,
but that's something you might easily check by having
isolationtester sleep before PQconsumeInput on line 861.
--
Mark Dilger
comments, and consider if you can overcome the concerns
he had:
https://www.postgresql.org/message-id/25938.1487367117%40sss.pgh.pa.us
and
https://www.postgresql.org/message-id/30007.1487374499%40sss.pgh.pa.us
--
Mark Dilger
u'd probably do that again and again
for the other ones, and that might be tedious for readers of the
-hackers list who aren't interested. To start, I'd prefer to see
the patch on this thread.
--
Mark Dilger
the second line. We would need to consider if that
behavior change is going to cause more problems for users than your
patch is worth. How common is this problem you are trying to fix?
--
Mark Dilger
k, split your patch for you as described, add an entry to
the commitfest if you haven't already, and mark myself as a
reviewer.
Thanks again for the hard work and the patch!
--
Mark Dilger
and directly?
VACUUM sometable OPTIONALLY (vacuum_threshold = 10, vacuum_scale = 0)
and only default to autovacuum's settings when not specified?
--
Mark Dilger
On 12/8/19 10:25 AM, Mark Dilger wrote:
I was
still expecting multiple patches, perhaps named along the
lines of:
unshadow.RedoRecPtr.patch.1
unshadow.wal_segment_size.patch.1
unshadow.synchronous_commit.patch.1
unshadow.wrconn.patch.1
unshadow.progname.patch.1
On 12/8/19 8:50 PM, Mark Dilger wrote:
On 12/8/19 10:25 AM, Mark Dilger wrote:
I was
still expecting multiple patches, perhaps named along the
lines of:
unshadow.RedoRecPtr.patch.1
unshadow.wal_segment_size.patch.1
unshadow.synchronous_commit.patch.1
unshadow.wrconn.patch.1
in C directly.
See src/backend/commands/tablecmds.c, function DefineRelation.
--
Mark Dilger
On 12/9/19 7:52 AM, Mark Dilger wrote:
Q1.1 If it is possible, is what is done in reality? I have the feeling
that it is not the case and that DDL queries are implemented in C
directly.
See src/backend/commands/tablecmds.c, function DefineRelation.
I realize I could be a bit more
up so you can log into the commitfest
app. https://www.postgresql.org/account/signup/
--
Mark Dilger
On 12/5/19 9:51 AM, Tomas Vondra wrote:
On Thu, Dec 05, 2019 at 06:15:54PM +0100, Tomas Vondra wrote:
On Sun, Dec 01, 2019 at 08:08:58PM +0100, Tomas Vondra wrote:
On Sat, Nov 30, 2019 at 03:01:31PM -0800, Mark Dilger wrote:
Are you planning to submit a revised patch for this?
Yes
d add
them to the patch if you like.
These only test the functional dependencies. If you want to include
something like them in your commit, you might create similar tests for
the mcv statistics, too.
--
Mark Dilger
diff --git a/src/test/regress/expected/stats_ext.out
b/src/test/regress/exp
On 11/30/19 2:23 PM, David Fetter wrote:
On Sat, Nov 30, 2019 at 10:04:07AM -0800, Mark Dilger wrote:
On 11/29/19 2:21 PM, David Fetter wrote:
On Fri, Nov 29, 2019 at 07:01:39PM +0100, David Fetter wrote:
Folks,
Per a suggestion Christophe made, please find attached a patch to
$Subject
On 12/12/19 11:26 AM, David Fetter wrote:
On Thu, Dec 12, 2019 at 08:02:25AM -0800, Mark Dilger wrote:
On 11/30/19 2:23 PM, David Fetter wrote:
On Sat, Nov 30, 2019 at 10:04:07AM -0800, Mark Dilger wrote:
On 11/29/19 2:21 PM, David Fetter wrote:
On Fri, Nov 29, 2019 at 07:01:39PM +0100
On 12/12/19 1:35 PM, Mark Dilger wrote:
Let C = 1.0002065
Let x = xid_age for a table
Let v = clamp(n_dead_tuples / reltuples*2) to max 0.5
Let a = clamp(changes_since_analyze / reltuples) to max 0.5
Let score = C**x + v + a
I should hasten to add that this is just a
On 12/12/19 1:35 PM, Mark Dilger wrote:
Once the xid age reaches one
million, it will start to be the dominant factor.
Actually, it doesn't change much from x = 1 to x = 1,000,000
but I was planning to add another factor to the formula and
forgot before sending the email. I'll
e one hand this causes a memory leak, and on the
other hand it violates SUSv2.
The 4.4BSD version, like glibc 2.0, uses a copy.
SUSv2 removes the const from the prototype, and so does glibc 2.1.3.
"
--
Mark Dilger
test in src/test/isolation but
nothing at all in src/test/regression covering this isolation level.
The one in src/test/isolation doesn't look very comprehensive. I'd
at least expect a test that verifies you don't get a syntax error
when you request READ UNCOMMITTED isolation from SQL.
--
Mark Dilger
Over in [1], I became concerned that, although postgres supports
Read Uncommitted transaction isolation (by way of Read Committed
mode), there was very little test coverage for it:
On 12/18/19 10:46 AM, Mark Dilger wrote:
Looking at the regression tests, I'm surprised read uncommitted ge
On 12/18/19 2:17 PM, Tom Lane wrote:
Mark Dilger writes:
The one in src/test/isolation doesn't look very comprehensive. I'd
at least expect a test that verifies you don't get a syntax error
when you request READ UNCOMMITTED isolation from SQL.
The attached patch set ad
cy
where NULL in a toast column means "allow" rather than "deny" for
some issue, but if this RECOVERY mode is limited to superusers, that
isn't such a big objection.
There may be a number of other gotchas still to be resolved, but
abandoning the patch at this stage strikes me as premature.
--
Mark Dilger
On 12/19/19 7:08 AM, Mark Dilger wrote:
and instead get NULLs for all such rows
To clarify, I mean the toasted column is null for rows
where the value was stored in the toast table rather
than stored inline. I'd prefer some special value
that means "this datum unavailable" s
e I’ll be making more changes anyway. What do you
think of the direction I’m taking in the attached?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
pg_wchar.cleanup.patch.1
Description: Binary data
> On Jan 23, 2020, at 4:27 PM, Andrew Dunstan
> wrote:
>
> On Fri, Jan 24, 2020 at 7:35 AM Mark Dilger
> wrote:
>>
>>
>>> On Jan 22, 2020, at 7:00 PM, Mark Dilger
>>> wrote:
>>>
>>> I have this done in my local repo to
nifest.
> (2) Given an existing backup that has not got a manifest, construct one.
> (3) Cross-check a manifest against a backup and complain about extra
> files, missing files, size differences, or checksum mismatches.
Nothing in there sounds to me like it needs to include random cruft.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
need to be completely permissive, which would include files named in arbitrary
encodings. I don’t see how it does anybody any favors to make the system
appear to back up everything until you hit this unanticipated case and then it
fails.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
require changes in
your 0004 or 0005. It won’t bother me if you commit those two. Andrew?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ded to apply after your 0004 and 0005; they won’t
work directly on master which, as of this writing, only contains your
0001-0003 patches.
0006 finishes moving the json parser to src/include/common and src/common.
0007 adds testing.
I would appreciate somebody looking at the portability issues fo
> On Jan 26, 2020, at 5:09 PM, Andrew Dunstan
> wrote:
>
> We'll need at a minimum something added to src/tools/msvc to build the
> test program, maybe some other stuff too. I'll take a look.
Thanks, much appreciated.
—
Mark Dilger
EnterpriseDB: http://www.enterp
time….
Ok, the tests pass. Here are those two patches again, both regenerated with a
fresh invocation of ‘git format-patch’.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
v5-0006-Relocating-jsonapi-to-common.patch
Description: Binary data
v5-0007-Adding-frontend-tests-for-json-parser.patch
Description: Binary data
I’m betting it was defensive programming, given the context. As such, I don’t
think it would be appropriate to remove this defense in your patch.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jan 27, 2020, at 5:30 AM, Robert Haas wrote:
>
> On Sun, Jan 26, 2020 at 9:05 PM Mark Dilger
> wrote:
>> Ok, the tests pass. Here are those two patches again, both regenerated with
>> a fresh invocation of ‘git format-patch’.
>
> Regarding 0006:
>
s of that language consider them equivalent.
That sounds like something for the translators to hash out.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jan 28, 2020, at 6:51 AM, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> On 2020-01-28 04:05, Mark Dilger wrote:
>>> German uses both Sonnabend and Samstag for Saturday, so don’t you have to
>>> compare to a list of values anyway?
>
>> Ye
.
As long as this implementation doesn’t create a backward-compatibility problem
when doing a more complete implementation later, I’m fine with this patch not
tackling the whole problem.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
full weekday names, but I’m also
only looking at the 53 locales installed in /usr/share/locale/.*/LC_TIME on my
mac.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
301 - 400 of 980 matches
Mail list logo
