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
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
> On May 17, 2019, at 12:10 PM, Tom Lane wrote:
>
> Andres Freund writes:
>> On 2019-05-17 13:47:02 -0400, Tom Lane wrote:
>>> I dunno, how far back are you thinking? I've occasionally wished we
>>> could reindent all the back branches to match HEAD, but realistically,
>>> people carrying ou
On Wed, May 22, 2019 at 10:07 AM Tom Lane wrote:
>
> I wrote:
> > Hearing no objections, I'll plan on running pgindent tomorrow sometime.
>
> And done.
>
> > The new underlying pg_bsd_indent (2.1) is available now from
> > https://git.postgresql.org/git/pg_bsd_indent.git
>
> Please update your loc
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
Hackers,
The return value of gimme_edge_table is not used anywhere in the
core code, so far as I can see. But the value is computed as
/* return average number of edges per index */
return ((float) (edge_total * 2) / (float) num_gene);
which involves some floating point math. I'm not sure
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
Hackers,
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. In this same
file, 'replace_s' calls 'create_s' and if it gets back NULL, returns
the error code -1. Otherwise
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.
&
Hackers,
In src/backend/storage/ipc/barrier.c, BarrierAttach
goes to the bother of storing the phase before
releasing the spinlock, and then returns the phase.
In nodeHash.c, ExecHashTableCreate ignores the
phase returned by BarrierAttach, and then immediately
calls BarrierPhase to get the phase
Hackers,
I have seen other lengthy discussions about fsync semantics, and if this
question is being addressed there, this question might not be relevant.
Two calls to durable_unlink at log level DEBUG1 are ignoring the
return value. Other calls at ERROR and FATAL are likewise ignoring
the return
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?
>
>
Hackers,
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 squashed.
I don't know if a pipe stream over "locale -a" could ever fail to
close, but it seems sensible t
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
On Thu, May 23, 2019 at 5:24 PM Michael Paquier wrote:
>
> On Thu, May 23, 2019 at 08:27:19AM -0700, Mark Dilger wrote:
> > On Thu, May 23, 2019 at 7:54 AM Tom Lane wrote:
> >> Are we sure that's not just a newly-introduced bug, ie it has not
> >> been te
Hackers,
The return value of RegisterSnapshot is being ignored in a
few places in indexam.c and tableam.c, suggesting an
intimate knowledge of the inner workings of the snapshot
manager from these two files. I don't think that is particularly
wise, and I don't see a performance justification for
> On Oct 9, 2018, at 12:22 PM, Andres Freund wrote:
>
> In-Reply-To: <20180928223240.kgwc4czzzekrp...@alap3.anarazel.de>
>
> Hi,
>
> As discussed below (at [1]), I think we should remove $subject. I plan
> to do so, unless somebody protests soon-ish. I thought it'd be better
> to call atte
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Patch applies cleanly on master (b238527664ec6f6c9d00dba4cc2f3dab1c8b8b04
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Sorry about the prior review; I neglected to select all the appropriate
to a server crash, at least on some
architectures with some compilers.
The idea that set_var_from_var might be called on const_zero (or const_one,
etc.) is not hypothetical. It is being done in numeric.c.
If this is safe, somebody needs to be a lot clearer about why that is so. There
are no
> This patch got committed as c1898c3e1e235ae35b4759d233253eff221b976a
> on Sun Sep 10 16:20:41 2017 -0700, but I've only just gotten around to
> reviewing it.
>
> I believe this is wrong and should be reverted, at least in part.
>
> The NumericVar struct has the field 'digits' as non-const:
>
> On Feb 24, 2018, at 2:01 PM, Tomas Vondra
> wrote:
> Sadly, this patch series does not seem to move forward very much, and
> I'm not sure how to change that :-/
I'll take a look at the new patch set this evening. I have been using your
previous version of these patches applied against postg
> On Feb 24, 2018, at 2:01 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, fixing some minor bitrot
> and duplicate OIDs.
The three patches apply cleanly, compile, and pass check-world.
You might consider using PointerGetDatum in compare_scalars_simple
rath
> On Mar 3, 2018, at 2:40 PM, Tomas Vondra wrote:
>
> An updated patch version, fixing the breakage caused by fd1a421fe6
> twiddling with pg_proc.
Hi Tomas, thanks again for this most useful patch!
Perhaps this is intentional, but there seems to be a place in
src/backend/parser/parse_utilcmd.
> On Mar 3, 2018, at 2:40 PM, Tomas Vondra wrote:
>
> An updated patch version, fixing the breakage caused by fd1a421fe6
> twiddling with pg_proc.
Hi Tomas!
Reviewing the sgml documentation, I think something like the following should
be added:
diff --git a/doc/src/sgml/catalogs.sgml b/doc/s
> On Jan 29, 2024, at 7:03 AM, Jelte Fennema-Nio wrote:
>
> So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
> +1 to indicate support against/for the change.
-1 for me.
-Infinity for refactoring the entire codebase and backpatching.
—
Mark Dilger
Enterp
> On Jan 29, 2024, at 7:35 AM, Isaac Morland wrote:
>
> On Mon, 29 Jan 2024 at 10:31, Mark Dilger
> wrote:
>
> -Infinity for refactoring the entire codebase and backpatching.
>
> I don't think anybody is proposing re-working the existing codebase. I
>
still preventing either party from hijacking privileges of the other.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Feb 22, 2023, at 10:49 AM, Jeff Davis wrote:
>
> On Wed, 2023-02-22 at 09:27 -0800, Mark Dilger wrote:
>> Another option is to execute under the intersection of their
>> privileges, where both the definer and the invoker need the
>> privileges in order for t
ges a bit.
>
> - Assorted cosmetic and comment changes.
>
> I think this is easier to follow and more nearly correct, but what do
> you (and others) think?
Thanks, Robert. Quickly skimming over this patch, it looks like something
reviewable. Your changes to t/004_verify_heapam
EZE shaves 10-12% off the tests. I didn't
> change that, but we also fire off a psql for each tuple for heap_page_items(),
> with offset $N no less. That seems to be another 500ms.
I don't recall the reasoning. Feel free to optimize the tests.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ondering if you had a particular client use case in mind when you added this
block?
The new function pg_encrypted_in() appears totally untested, but I have to
wonder if that's because we're not round-trip testing pg_dump with column
encryption...? The code coverage in pg_dump looks fai
ike
> use constant ROWCOUNT => 17;
> so I just made it a variable.
Seems fair. I certainly don't mind.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
icious content into the publication. I
think you are focused on all the bad actors on the subscription-side database
and what they can do to each other. That's also valid, but I get the
impression that you're losing sight of the risk posed by malicious publishers.
Or maybe you ar
f a privilege
deescalation than a privilege escalation, so where's the risk? That's not a
rhetorical question. Is there a risk here? Or are we just concerned that most
users will set up replication with superuser or some other high-privilege user,
and we're trying to protect them from the consequences of that choice?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
synchronous feedback per block. Thus, this table AM function
> must change its meaning.
>
> I think the way the patches are split up could be improved. I will
> think more about this. There are also probably a few mistakes with
> which comments are updated in whi
oes implement those two functions and does use the
TBMIterateResult *tbmres argument, yes. I would deal with the issue in very
much the same way that your patches modify heapam. I don't really have any
additional comments about that.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
id 0 gets used.
Thanks
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
he
> amcheck/pg_amcheck tests.
Ok, I can confirm that. I find the assertion
Assert(epoch != (uint32)-1);
a bit simpler to reason about, but either way, I agree it is a bug. Thanks for
finding this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e such "salt"ing (again, maybe
the wrong word) because I'm just trying to discuss the general feature, not get
into the weeds about which cryptographic algorithm to select.
Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jan 10, 2023, at 9:26 AM, Mark Dilger wrote:
>
>-- Cryptographically connected to the encrypted record
>patient_id BIGINT NOT NULL,
>patient_ssn CHAR(11),
>
>-- The encrypted record
>patient_record TEXT ENCRYPTED WITH (colu
ckly
switched my focus elsewhere.
> , and (b) what people think of (1)-(3) above
There are different ways of solving (1), and Jeff and I discussed them in Dec
2021. My recollection was that idea (3) was the cleanest. Other ideas might
be simpler than (3), or they may just appear simpler bu
do, because at some
point in the future we might extend what things are allowed in that string, and
we have to keep everything that contemplates that string in sync. I may have
been overly hesitant to tackle that problem. Or maybe I just ran short of
round tuits.
—
Mark Dilger
e server itself, all the test infrastructure can use a
single, shared solution.
As for the implementation, I just briefly scanned the patch.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 24, 2022, at 12:06 PM, Andrew Dunstan wrote:
>
>
> On 3/24/22 12:49, Mark Dilger wrote:
>>
>>> On Mar 17, 2022, at 8:41 AM, Andrew Dunstan wrote:
>>>
>>> If we abandoned that for this form of GRANT/REVOKE I think we could
>>&g
s trying to use regular expression characters in a place where they
> are not allowed to do that. I argue that we should instead just be
> comparing "}" against the database name and see whether it happens to
> match.
I think your change is fine, so I've rolled it int
ER SYSTEM, but I'm not sure there's much point in that.
How about putting them under src/test/modules/unsafe_tests ?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
her GRANT/REVOKE operation calls such a hook.
I think ALTER DEFAULT PRIVILEGES does, though that's not quite the same thing.
I don't have a strong opinion on this. Joshua, what's your take?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
27;ll let you make the change. I don't see a problem with
what you are proposing.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s v15. We should review the
conversation from December and January which included some arguments for
allowing revokes of SET on USERSET from PUBLIC. I don't want to keep going
around in circles on this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 30, 2022, at 6:59 AM, Mark Dilger wrote:
>
> We should review the conversation from December and January which included
> some arguments for allowing revokes of SET on USERSET from PUBLIC. I don't
> want to keep going around in circles on this.
Hmm, I guess t
> On Apr 4, 2022, at 8:36 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> If we want to backtrack to v8, that's fine. I can rebase that, port
>> some of the other changes from v14 to it, and repost it as v15.
>
> Are you working on that? I've set as
> On Mar 21, 2022, at 10:03 PM, Thomas Munro wrote:
>
> On Fri, Mar 18, 2022 at 4:22 PM Mark Dilger
> wrote:
>> (FYI, I got a test failure from src/test/recovery/t/013_crash_restart.pl
>> when testing v1-0001. I'm not sure yet what that is about.)
>
>
o this in the postgres 15 development
cycle. Alas, that did not happen. Worse, I have several other projects that
will keep me busy for the next few months, at least.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
d and not
yet restarted, won't things go off the rails?
I'm writing a parallel test just for this. Will get back to you.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ou just got this failure, could you look in the log to
> see if there's a pump_until report?
I was running `make -j12 check-world` against my local patched version of
master:
commit 80399fa5f208c4acd4ec194c47e534ba8dd3ae7c (HEAD -> 0001)
Author: Mark Dilger
Date: Mon Mar 28 13:35:11
> On Apr 4, 2022, at 11:07 AM, Tom Lane wrote:
>
> I was hoping to see regress_log_013_crash_restart, though.
regress_log_013_crash_restart
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 4, 2022, at 10:44 AM, Mark Dilger wrote:
>
> I'm writing a parallel test just for this. Will get back to you.
Ok, that experiment didn't accomplish anything, beyond refreshing my memory
regarding Cluster.pm preferring sockets over ports.
—
Mark Dilger
ceive data from server"
from pqsecure_raw_read()?
It's a bit hard to prove to myself which paths might be followed through this
code. Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
not libpq behavior, so I'm inclined
> to just make it lax.
+1.
I've gotten this test failure only a few times in perhaps the last six months,
so if we narrow the opportunity for test failure without closing it entirely,
we're just making the test failures that much harder to
ng a catalog search.
>
> Thoughts?
That sounds right. Do you already have something like that coded, or would you
like me to post a patch?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 4, 2022, at 5:12 PM, Tom Lane wrote:
>
> Wrote it already, no need for you to do it.
Thanks!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ccomplish the same thing
> with less code?
We don't *quite* want the literal left string. If it is quoted, we still want
the quotes removed. For example:
\d "robert.haas".accounts.acme
needs to return robert.haas (without the quotes) as the database name.
Likewise, for em
GED TABLE test_parallel_jsonb_value AS
+CREATE TABLE test_parallel_jsonb_value AS
SELECT i::text::jsonb AS js
FROM generate_series(1, 50) i;
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
as been revoked.
So yes, +1 from me.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ot a "config". If we're going to use a single letter, I'd
prefer /p/.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
the build configuration (as in the
"pg_config" tool), text search configuration, etc.
While grep'ing through doc/src/sgml, I see no instances of "conf" ever
referring to configuration parameters. It only ever refers to configuration
files. I'd prefer not adding it to the list of synonyms.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
'm not going to kick up a fuss about \dconf.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
te to get the list of parameters. I frequently can't recall the
exact spelling of them.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
, and you can pg_fatal(...) or ereport(ERROR, ...) or whatever.
It looks like I'll need to post a new version of the patch with an argument
telling the function to ignore dots, but I'm not prepared to say that for sure.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
been any agreement on that point, I've just rebased the
patch to apply cleanly against the current master:
v9-0001-Reject-patterns-with-too-many-parts-or-wrong-db.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s a new node, this global variable prevents
the new node from getting the port already assigned to the old stopped node,
except when port assignment wraps around. Without sharing the global,
wrap-around need not happen for port collisions.
Or am I reading the code wrong?
—
Mark Dilger
> On Apr 18, 2022, at 1:19 PM, Andrew Dunstan wrote:
>
> that seems quite separate from the present issue.
Thanks for the clarification. I agree, given your comments, that it is
unrelated to this thread.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
without the other.)
I wasn't going to report this yet, having not yet completely narrowed this
down, but I wonder if anybody else is seeing this?
I'll try again on master
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 27, 2022, at 10:11 AM, Mark Dilger
> wrote:
>
> I'll try again on master
Still with coverage and dtrace enabled, I get the same thing, except that
master formats the logs a bit differently:
# Postmaster PID for node "primary" is 19797
psql::1: E
loptions for tables and indexes.
This could use some regression tests to exercise the custom reloptions.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
uld at least refactor to pass the
minimum amount of state information through the table AM API.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
purpose of the patch, at least for my perl
version, perl 5, version 28, subversion 1 (v5.28.1). With just the /aeg
modifier, it works fine.
--
Mark Dilger
> On Jan 8, 2024, at 5:41 AM, Mark Dilger wrote:
>
> The /r modifier defeats the purpose of the patch, at least for my perl
> version, perl 5, version 28, subversion 1 (v5.28.1). With just the /aeg
> modifier, it works fine.
Nevermind. I might be wrong about that. I did
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hether not invoking the hook in these cases is
defensible. Does anybody have any recollection of an intentional choice not to
invoke in these locations?
Patch attached.
v1-0001-Adding-missing-Object-Access-hook-invocations.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterp
> On Mar 16, 2020, at 5:14 PM, Alvaro Herrera wrote:
>
> On 2020-Mar-16, Mark Dilger wrote:
>
>> Hackers,
>>
>> While working on object access hooks, I noticed several locations where I
>> would expect the hook to be invoked, but no actual invoc
> On Mar 17, 2020, at 11:49 AM, Andres Freund wrote:
>
> On 2020-03-16 16:03:51 -0700, Mark Dilger wrote:
>> While working on object access hooks, I noticed several locations
>> where I would expect the hook to be invoked, but no actual invocation.
>> I think this
> On Mar 17, 2020, at 9:33 PM, Michael Paquier wrote:
>
> On Tue, Mar 17, 2020 at 12:39:35PM -0700, Mark Dilger wrote:
>> I agree that this does not need to be back-patched. I was debating
>> whether it constitutes a bug for the purpose of putting the fix into
>>
> On Mar 19, 2020, at 11:17 AM, Alvaro Herrera wrote:
>
> On 2020-Mar-18, Mark Dilger wrote:
>
>> Here is the latest patch.
>
> So you insist in keeping the Drop hook calls?
My apologies, not at all. I appear to have attached the wrong patch. Will
post v3
> On Mar 19, 2020, at 11:30 AM, Mark Dilger
> wrote:
>
> Will post v3 shortly.
v3-0001-Adding-missing-Object-Access-hook-invocations.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
#x27;s say, one in two chance
that your customer didn't use checksums. Why are we even allowing this to be
turned off? Is there a usage case compelling that option?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 26, 2020, at 12:37 PM, Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
>>> On Mar 26, 2020, at 9:34 AM, Stephen Frost wrote:
>>> I'm not actually argueing about which hash functions we should suppo
arly a judgement call, having to do with how cautious any
particular person thinks we should be. I don't feel strongly enough to stand
in the way if the general concensus is that this is a good enough
implementation.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ment could be made for treating txid_current as the preferred
form, and xid8_current merely as a synonym, but then I can't make sense of the
change your patch makes to the docs:
+
+In releases of PostgreSQL before 13 there was
+ no xid8 type, so variants of these functions were pr
> On Apr 2, 2020, at 9:06 AM, Mark Dilger wrote:
>
> ("xid8_current" is not exercised by name anywhere in the regression suite,
> that I can see.)
I spoke too soon. That's exercised in the new xid.sql test file. It didn't
show up in my 'git diff&
401 - 500 of 980 matches
Mail list logo
