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
s in src/fe_utils/print.c:
/* is string only whitespace? */
if ((*ptr)[strspn(*ptr, " \t")] == '\0')
My larger concern is that people may be using space before a command
word to avoid having it be interpreted as a command. Take for example
the following contr
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
T to_char('1997-02-10'::date, '-WW-D')
This is wrong, because this should be week 7 instead. On the other hand,
the ISO week formats work very well.
I'll have a look at the code and try to fix it in the patch as well.
Kind regards,
Mark
Am 2019-10-08 17:49, s
5
(1 row)
postgres=# SELECT to_date('2019-2-1', '-WW-D');
to_date
2019-01-06
(1 row)
I added the patch as plain text attachment. It contains the code and, of
course, the regression tests. Some existing tests failed, because they
worked with the old out
Hi,
I got the advice to split the patches for:
- fixing the to_char() function
- changing the to_date()/to_timestamp() behaviour
So I appended the split patches.
Kind regards,
Mark Lorenz
From 4e35bd88bef1916e7d11ad0776b3075e3183f7d0 Mon Sep 17 00:00:00 2001
From: Mark Lorenz
Date: Fri, 20
Hi Tom,
thanks for answering!
I commited two different patches:
---
The first one is for the strange behaviour of to_char(), which could be
seen as a bug, I believe. As described earlier, to_char() with the
'WW-D' pattern could return wrong week numbers.
The non-ISO week number is defi
while preparing the patch for the Commitfest, I found a bug in the
to_char() function that is quite correlated with this issue:
SELECT to_char('1997-02-01'::date, '-WW-D')
returns: 1997-05-7 -> which is ok, I believe. Feb, 1st was on
Saturday,
so counting from Sundays, it was day 7 of w
f%40four-two.de is still up-to-date)From 4e35bd88bef1916e7d11ad0776b3075e3183f7d0 Mon Sep 17 00:00:00 2001
From: Mark Lorenz
Date: Fri, 20 Dec 2019 14:30:41 +0100
Subject: [PATCH 1/3] change to_date()/to_timestamp() behaviour with
'-WW-D' pattern
Currently, the D part is ignored at
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
e the silence as a cold shoulder.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jan 28, 2020, at 8:32 AM, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
> wrote:
>> Since you’ve committed your 0004 and 0005 patches, this v6 patch set is now
>> based on a fresh copy of master.
>
> I think the first question for 00
Thanks for your review. I considered all of this along with your review
comments in another email prior to sending v7 in response to that other email a
few minutes ago.
> On Jan 28, 2020, at 7:17 AM, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
> w
Seq Scan on alpha t1
>Filter: (a = ANY ('{äbç,ὀδυσσεύς}'::text[]))
> (6 rows)
>
> SELECT t1.a, t2.a FROM alpha t1 INNER JOIN beta t2 ON (t1.a = t2.a) WHERE
> t1.a IN ('äbç', 'ὀδυσσεύς');
> ERROR: could not determine which collation to use for string hashing
> HINT: Use the COLLATE clause to set the collation explicitly.
>
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
0001-WIP-patch-to-demonstrate-problem.patch
Description: Binary data
> On Jan 28, 2020, at 6:46 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> While reviewing the partition-wise join patch, I ran into an issue that
>> exists in master, so rather than responding to that patch, I’m starting this
>> new thread.
>> I notic
> On Jan 28, 2020, at 7:38 PM, Mark Dilger wrote:
>
>
>
>> On Jan 28, 2020, at 6:46 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> While reviewing the partition-wise join patch, I ran into an issue that
>>> exists in master, so ra
ty last year about getting the
authentication/authorization completely integrated. I think the main
issue was how to integrate this app while using resources outside of the
community infrastructure. We may have to continue working around that.
Otherwise, I think the rest make sense. Let us know if you have any
more questions.
Regards,
Mark
--
Mark Wong
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/
;ll see if changing to LZ4 makes any different.
best wishes
Mark
On 11/04/19 4:01 PM, Mark Kirkwood wrote:
On 9/04/19 12:27 PM, Ashwin Agrawal wrote:
Heikki and I have been hacking recently for few weeks to implement
in-core columnar storage for PostgreSQL. Here's the design and initial
implementation of Zedstore, compressed in-core columnar st
onfig change, so it's not an explanation as to why they started
> > to fail only recently.
>
> No, but it does point at another area of the code in which a relevant
> change could've occurred.
>
> While we're looking at this --- Mark, if you could install gdb
>
On Fri, May 03, 2019 at 11:45:33AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-03 10:08:59 -0700, Mark Wong wrote:
> > Ok, I think I have gdb installed now...
>
> Thanks! Any chance you could turn on force_parallel_mode for the other
> branches it applies to too? M
wonder if this is a SIGSEGV that actually signals an OOM
> situation. Linux, if it can't actually extend the stack on-demand due to
> OOM, sends a SIGSEGV. The signal has that information, but
> unfortunately the buildfarm code doesn't print it. p $_siginfo would
> show us some of
On Tue, May 14, 2019 at 10:52:07AM -0400, Tom Lane wrote:
> Mark Wong writes:
> > Slowly catching up on my collection of ppc64le animals...
>
> Oh, btw ... you didn't answer my question from before: are these animals
> all running on a common platform (and if so, wha
signals an OOM
> >> situation. Linux, if it can't actually extend the stack on-demand due to
> >> OOM, sends a SIGSEGV. The signal has that information, but
> >> unfortunately the buildfarm code doesn't print it. p $_siginfo would
> >> show us some o
Hackers,
most places that use SPI_connect ... SPI_finish check the
return value of SPI_finish and elog if it failed. There
are a few places that do not, and it is unclear to me
why this is safe. SPI_finish appears to be needed to
clean up memory contexts.
Examples can be found in:
src/backend
ainst the public sources of 9.1 and 9.5 and then try to merge the
changed sources into my forks, I could give it a try. I'm not
sure if this is the sort of thing you have in mind
mark
On Sun, May 19, 2019 at 02:38:26PM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-14 08:31:37 -0700, Mark Wong wrote:
> > Ok, I have this added to everyone now.
> >
> > I think I also have caught up on this thread, but let me know if I
> > missed
On Mon, May 20, 2019 at 12:15:49PM -0700, Mark Wong wrote:
> On Sun, May 19, 2019 at 02:38:26PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2019-05-14 08:31:37 -0700, Mark Wong wrote:
> > > Ok, I have this added to everyone now.
> > >
> > > I
s probably won't
come up for me, since the older forks are defunct and unlikely to
be patched by me.)
mark
On Fri, May 17, 2019 at 6:12 PM Tom Lane wrote:
>
> Mark Dilger writes:
> > most places that use SPI_connect ... SPI_finish check the
> > return value of SPI_finish and elog if it failed. There
> > are a few places that do not, and it is unclear to me
> > why thi
On Wed, May 22, 2019 at 1:52 PM Tom Lane wrote:
>
> Mark Dilger writes:
> > On Fri, May 17, 2019 at 6:12 PM Tom Lane wrote:
> >> One reasonable solution would be to change the callers that got this
> >> wrong. Another one would be to reconsider whether the err
Hackers,
I have been auditing the v12 source code for places
which inappropriately ignore the return value of a function
and have found another example which seems to me
a fertile source of future bugs.
In src/backend/nodes/list.c, list_delete_cell frees the list
and returns NIL when you delete t
sure that this matters
much, but (1) it deceives a reader of this code into thinking that this
calculation is meaningful, which it is not, and (2) gimme_edge_table is
called inside a loop, so this is happening repeatedly, though admittedly
that loop is perhaps not terribly large.
mark
On Wed, May 22, 2019 at 10:21 PM Michael Paquier wrote:
>
> On Wed, May 22, 2019 at 06:20:01PM -0700, Mark Dilger wrote:
> > What to do about this is harder to say. In the following
> > patch, I'm just doing what I think is standard for callers
> > of list_delete_c
g code's
use of malloc and calloc.
There is a comment higher up in dict_snowball.c that seems to
use some handwaving about all this, or perhaps it is documenting
something else entirely. In any event, I find the documentation
about dictCtx insufficient to explain why this memory handling
is correct.
mark
On Thu, May 23, 2019 at 7:54 AM Tom Lane wrote:
>
> Michael Paquier writes:
> > On Wed, May 22, 2019 at 06:20:01PM -0700, Mark Dilger wrote:
> >> What to do about this is harder to say. In the following
> >> patch, I'm just doing what I think is standard f
On Thu, May 23, 2019 at 8:46 AM Tom Lane wrote:
>
> Mark Dilger writes:
> > In src/backend/snowball/libstemmer/utilities.c, 'create_s' uses
> > malloc (not palloc) to allocate memory, and on memory exhaustion
> > returns NULL rather than throwing an exception.
&
that it just ignored.
I don't know that there is anything wrong with this, but
if the phase can be retrieved after the spinlock is
released, why hold the spinlock extra long in
BarrierAttach?
Just asking....
mark
checked.
This code appears to have been changed in
1b02be21f271db6bd3cd43abb23fa596fcb6bac3.
Is this code safe against fsync failures? If so, can I get an explanation
that I might put into a code comment patch?
mark
On Thu, May 23, 2019 at 11:07 AM Tom Lane wrote:
>
> Andres Freund writes:
> > On 2019-05-23 10:46:02 -0700, Mark Dilger wrote:
> >> Is this code safe against fsync failures? If so, can I get an explanation
> >> that I might put into a code comment patch?
>
>
seems sensible to log an error if it does.
Thoughts?
mark
On Thu, May 23, 2019 at 3:23 PM Tom Lane wrote:
>
> Mark Dilger writes:
> > I only see three invocations of ClosePipeStream in the sources.
> > In two of them, the return value is checked and an error is raised
> > if it failed. In the third, the error (if any) is squa
On Thu, May 23, 2019 at 3:44 PM Thomas Munro wrote:
>
> On Fri, May 24, 2019 at 4:10 AM Mark Dilger wrote:
> > In src/backend/storage/ipc/barrier.c, BarrierAttach
> > goes to the bother of storing the phase before
> > releasing the spinlock, and then returns the phas
401 - 500 of 1160 matches
Mail list logo
