On Fri, Apr 2, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:
> Dear fellow hackers,
>
> This patch is one day late, my apologies for missing the deadline this year.
Uh, the deadline for the last commitfest was March 1, 2021, not April
1.
--
Bruce Momjian https://momjian
nutes/seconds. This seems like an
improvement.
This also changes the regression test output, I think for the better:
SELECT INTERVAL '1.5 weeks';
i
--
- 10 days 12:00:00
+ 10 days
The new output is less precise, but pr
atch which I think covers all
the right areas.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Fri, Apr 2, 2021 at 02:00:03PM -0700, John W Higgins wrote:
> On Fri, Apr 2, 2021 at 11:05 AM Bruce Momjian wrote:
> While maybe there is an argument to fixing the negative/positive rounding
> issue
> - there is no way this gets solved without breaking the current implementation
On Fri, Apr 2, 2021 at 07:47:32PM -0400, Bruce Momjian wrote:
> I have modified the patch to prevent partial months from creating
> partial hours/minutes/seconds, so the output is now at least consistent
> based on the three units:
>
> SELECT ('6.54321 years&#x
imprecise, which doesn't seem worth it.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
n
and with the patch it is:
SELECT interval '0.3 years' + interval '0.4 years' - interval '0.7
years';
?column?
--
1 mon
What it isn't, is zero months, which is the obviously ideal answer.
--
Bruce Momjian
ments over the current behavior, I think
> that's fine.
I wish I could figure out how to improve it any futher. What is odd is
that I have never seen this reported as a problem before. I plan to
apply this early next week for PG 14.
--
Bruce Momjian https://momjian.us
EDB
tm->tm_mon += (fval * MONTHS_PER_YEAR);
>
> Around line 194:
> tm->tm_year += val;
> tm->tm_mon += (fval * MONTHS_PER_YEAR);
>
> Is rint() needed for these two cases ?
Ah, yes, good point. Updated patch att
On Sun, Apr 4, 2021 at 10:18:50PM +0800, Julien Rouhaud wrote:
> On Fri, Apr 02, 2021 at 01:33:28PM +0800, Julien Rouhaud wrote:
> > On Thu, Apr 01, 2021 at 03:27:11PM -0400, Bruce Momjian wrote:
> > >
> > > OK, I am happy with your design decisions, thanks.
>
On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> On Fri, Apr 02, 2021 at 10:21:26PM -0400, Bruce Momjian wrote:
> > I wish I could figure out how to improve it any futher. What is odd is
> > that I have never seen this reported as a problem before. I plan to
>
On Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote:
> On Mon, Apr 05, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> > On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> > > > https://www.postgresql.org/docs/current/datatype-datetime.html#DA
On Mon, Apr 5, 2021 at 01:06:36PM -0700, Bryn Llewellyn wrote:
> > On 05-Apr-2021, at 11:37, Bruce Momjian wrote On:
> > Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote :
>
> It seems to me that this whole business is an irrevocable mess. The
> origi
ll the good feedback we got on this, and I
know many users have waited a long time for this feature.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
aOn Wed, Apr 7, 2021 at 04:15:50PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied. I am ready to adjust this with any improvements people
> > might have. Thank you for all the good feedback we got on this, and I
> > know many users have waited a long
On Thu, Apr 8, 2021 at 05:56:25AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 04:22:55PM -0400, Bruce Momjian wrote:
> > aOn Wed, Apr 7, 2021 at 04:15:50PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Patch applied. I am ready to adj
On Wed, Apr 7, 2021 at 07:01:25PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Uh, I think your patch missed a few things. First, you use "%zd"
> > (size_t) for the printf string, but calls to pgstat_get_my_queryid() in
> > src/backend/utils/error/elog.c us
On Thu, Apr 8, 2021 at 08:47:48AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 07:38:35PM -0400, Bruce Momjian wrote:
> > On Wed, Apr 7, 2021 at 07:01:25PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Uh, I think your patch missed a fe
On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > > I am also confused about the inconsistency of calling the GUC
> > > compute_query_id (with underscore), but pg_stat_activity.queryid. If we
> > > make it pg_stat_activity.query_id, it doesn't m
On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > Unless I'm missing something this will output the query id in the next log
> > line? The new code should be added before the newline is output, and the
> > comma
> > should also be output before t
On Thu, Apr 8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote:
> On Wed, Apr 07, 2021 at 10:31:01PM -0400, Bruce Momjian wrote:
> > On Wed, Apr 7, 2021 at 08:54:02PM -0400, Bruce Momjian wrote:
> > > > Unless I'm missing something this will output the query i
xecutorStart which
> > > will report queryid, so do we need it here?
> >
> > Correct, it's not actually needed. The overhead should be negligible but
> > let's
> > get rid of it. Updated fix patchset attached.
>
> Sorry I messed up the last commit, v4
On Wed, Apr 7, 2021 at 11:27:04PM -0400, Álvaro Herrera wrote:
> On 2021-Apr-07, Bruce Momjian wrote:
>
> > On Thu, Apr 8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote:
>
> > > Thanks! And I agree with using query_id in the new field names while
> &g
On Fri, Apr 9, 2021 at 12:38:29AM +0800, Julien Rouhaud wrote:
> On Thu, Apr 08, 2021 at 11:34:25AM -0400, Bruce Momjian wrote:
> >
> > OK, let's get some details. First, pg_stat_statements.queryid already
> > exists (no underscore), and I don't th
On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote:
> On 2021-Apr-08, Bruce Momjian wrote:
>
> > pg_stat_activity.queryid is new, but I can imagine cases where you would
> > join pg_stat_activity to pg_stat_statements to get an estimate of how
> > long the qu
On Mon, Apr 5, 2021 at 02:01:58PM -0400, Bruce Momjian wrote:
> On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote:
> Well, bug or not, we are not going to change back branches for this, and
> if you want a larger discussion, it will have to wait for PG 15.
>
a whole bunch of options that
> sound good, sometimes including this one. And in the best case they then ask
> on -performance why their queries are slow and we tell them to turn it back
> off
> to fix their issues. This changes to no longer put it in .sample, and calling
&
days
Yes, that changed is caused by the rounding fixes, and not by the unit
pushdown adjustments.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
eck for this to
> pg_upgrade?
>
> First time mailing list user here so many apologies for any missteps I have
> made in this message.
Yes, I think a patch would be good, but the fix might be for pg_dump
instead, which pg_upgrade uses.
--
Bruce Momjian https://m
ternal field is that the
approximations between units are not precise enough to flow accurately.
With my patch, the output is now:
SELECT INTERVAL '3 years 10.241604 months';
interval
3 years 10 mons 7 days
It used to flow to seconds.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Mon, Apr 12, 2021 at 07:38:21PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Apr 12, 2021 at 03:09:48PM -0700, Bryn Llewellyn wrote:
> >> After all, you've bitten the bullet now and changed the behavior. This
> >> means that the semantics of some
ow, which in the current patch is
only when fractional internal units are specified.
> If some application wants to model flow-down, then it can do so with
> trivial programming and full control over its own definition of the
> rules.
--
Bruce Momjian https://momjian.us
EDB
On Thu, Apr 8, 2021 at 01:01:42PM -0400, Bruce Momjian wrote:
> On Thu, Apr 8, 2021 at 12:51:06PM -0400, Álvaro Herrera wrote:
> > On 2021-Apr-08, Bruce Momjian wrote:
> >
> > > pg_stat_activity.queryid is new, but I can imagine cases where you would
> &
ted myself and what
I saw from Tomas was that spilling sort or spilling hash are both 2.5x
slower. Are we sure the quoted statement is true?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
nc with the actual code behavior would be impossible.
> (For one thing, some aspects can be affected by extension datatype
> behaviors.)
I know Tom put a wink on that, but I actually do feel that the only
clean way to do this is to give users a way to issue the query in a
non-executing way that
On Wed, Jul 29, 2020 at 03:34:22PM -0700, Peter Geoghegan wrote:
> Hi Bruce,
>
> On Fri, Jun 26, 2020 at 3:24 PM Bruce Momjian wrote:
> > Patch attached and applied to PG 13.
>
> I committed the hash_mem_multiplier GUC to Postgres 13 just now.
>
> There should
On Wed, Jul 29, 2020 at 07:00:43PM -0700, Peter Geoghegan wrote:
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> > > for the usual reasons. More importantly, the "Allow hash aggregation
On Wed, Jul 29, 2020 at 08:43:24PM -0700, David G. Johnston wrote:
> On Wednesday, July 29, 2020, Peter Geoghegan wrote:
>
> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian wrote:
> > > There should be a note about this in the Postgres 13 release notes,
> >
be to make it more
secure, so maybe this works, but it seems tricky.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Mon, Aug 3, 2020 at 11:35:50AM -0700, Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 10:45 AM Peter Geoghegan wrote:
> > On Thu, Jul 30, 2020 at 10:32 AM Bruce Momjian wrote:
> > > I came up with a more verbose documentation suggestion, attached.
> >
> > I&
int4range(1,7)
t
<@ element is contained by 42 <@ int4range(1,7) f
There is an anyrange/anyrange version, and an anyrange/anyelement
version of @> and <@. Anyway, for the docs, I think we can either
remove the duplicate entry, or modify it to clarify one is for
anyrange/anyrange and another is for anyrange/anyelement. I suggest the
first option.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
Ah, seems Tom has even more detail so we will continue to discuss on
that thread.
---
On Mon, Aug 3, 2020 at 07:51:51PM -0400, Bruce Momjian wrote:
> On Sun, Aug 2, 2020 at 08:43:53PM -0700, David G. Johnston wr
have kept the same ICU
version so indexes will not need to be reindexed.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
ase cycle.
Look here:
https://www.postgresql.org/developer/roadmap/
The next major release of PostgreSQL is planned to be the 13
release. A tentative schedule for this version has a release in the
third quarter of 2020.
Most likely Sept/Oct.
--
Bruce Momjian
-bao-0810
It seems interesting, but I don't know anyone working on this.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
using pg_upgrade, then a new ICU version should be used for the
new cluster.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
percentage of indexes are affected by
collations, and it would be great if we could tell users how to easily
identify them.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
o re-indent everything.
>
> Well, we can certainly do a tree-wide re-indent anytime we're ready.
> I doubt it would be very painful right now, with so little new work
> since the last run.
Uh, I thought Tom was saying we need to reindent all branches, which
would be a big change for
cking for reindex,
or each _collation_ version? If the later, do we store the collation
version for each index?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Tue, Aug 18, 2020 at 09:44:35AM +0900, Michael Paquier wrote:
> On Mon, Aug 17, 2020 at 02:23:57PM -0400, Bruce Momjian wrote:
> > Also, is it the ICU library version we should be tracking for reindex,
> > or each _collation_ version? If the later, do we store the collation
e to weigh the complexity of using pg_upgrade with index
rebuild vs. the simpler pg_dump. Right now, you know pg_upgrade in link
mode is going to be fast, but with the reindex, you have a much more
complex decision to make.
--
Bruce Momjian https://momjian.us
EnterpriseDB
at as
>the start position.
>
If someone can confirm this, I will apply it? Magnus?
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
ment just
> made me worried that I might be missing some fundamental concept. Thanks for
> your opinion.
I have developed the attached patch to address this.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a
nly. Added to the commitfest 2020-09.
>
> 1. https://www.postgresql.org/message-id/flat/
> 57083a441ddd2f3b9cdc0967c6689384cddeeedb.camel%40cybertec.at#
> f7198de1af14f7c5d84e7095b6b52bff
FYI, patch applied.
--
Bruce Momjian https://momjian.us
EnterpriseDB
On Fri, Aug 21, 2020 at 08:07:34PM -0700, David G. Johnston wrote:
> On Fri, Aug 21, 2020 at 5:41 PM Bruce Momjian wrote:
>
> On Wed, Jul 22, 2020 at 06:58:33AM +0200, Antonin Houska wrote:
> > Tom Lane wrote:
> >
> > > I don't particularly wan
erify-ca" but it is ignored. We should
> reject that combination the same way with "cert"+"no-verify".
Are you saying we should _require_ clientcert=verify-full when 'cert'
authentication is used? I don't see the point of that --- I just
upda
lines of the form:
...
> I can't find a reference to the code that limits this. AFAICT the
> documentation
> has been there since day 1.
>
> Question is, which one is right. Is there a reason we'd want to restrict it to
> absolute pathnames?
I think it should work ju
On Tue, Aug 25, 2020 at 10:41:26AM +0900, Kyotaro Horiguchi wrote:
> At Mon, 24 Aug 2020 20:01:26 -0400, Bruce Momjian wrote in
> > I have slightly adjusted the doc part of the patch, attached.
>
> Thanks.
>
> In a pg_hba.conf record specifying certificate
>
On Tue, Aug 25, 2020 at 11:00:49AM +0900, Kyotaro Horiguchi wrote:
> At Mon, 24 Aug 2020 21:49:40 -0400, Bruce Momjian wrote in
> > > > Are you saying we should _require_ clientcert=verify-full when 'cert'
> > > > authentication is used? I don't see th
On Tue, Aug 25, 2020 at 11:41:55AM +0900, Kyotaro Horiguchi wrote:
> Thank you for the patience.
>
> At Mon, 24 Aug 2020 22:06:45 -0400, Bruce Momjian wrote in
> > On Tue, Aug 25, 2020 at 11:00:49AM +0900, Kyotaro Horiguchi wrote:
> > > At Mon, 24 Aug 2020 21:49
On Tue, Aug 25, 2020 at 03:53:20PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian wrote in
> > > > I don't see "no-verify" mentioned anywhere in our docs.
> > >
> > > no-verify itself is mentioned here.
>
if they are kept for that reason, we should document that so we
know not to revisit this issue for them.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
ig problem though.
>
> Nope, just mildly irritating for quite a long time:-) So I'd go for back
> patching if it applies cleanly.
Can we get Peter's patch for this applied soon? Thanks. Should I apply
it?
--
Bruce Momjian https://momjian.us
EnterpriseDB
generate_series(-2, 4) i
> ) t(c)
> ORDER BY 2;
>
> c| distance
> -+--
> <(-200,NaN),50> |0
> <(-100,NaN),50> |0
> <(0,NaN),50>|0
> <(100,NaN),50> |0
> <(200,N
On Wed, Aug 26, 2020 at 11:41:39AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian wrote in
> > I think there are a few problems here. In the docs, it says "will still
> > verify", but it doesn't say if it verifies the CA, or th
I see a compiler warning on git master:
sharedfileset.c:288:8: warning: variable ‘found’ set but not used
[-Wunused-but-set-variable]
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its
On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian wrote in
> > > Because we think we need any named value for every alternatives
> > > including the default value?
> >
> > Well, not putting cl
On Thu, Aug 27, 2020 at 04:09:25PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian wrote in
> bruce> On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> > > At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian
> > >
On Thu, Aug 27, 2020 at 03:41:40PM -0400, Bruce Momjian wrote:
> On Thu, Aug 27, 2020 at 04:09:25PM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian wrote
> > in
> > bruce> On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi w
uot; question, I suggest we also
> change the example to point to the data/log directory which is likely to exist
> in a lot more of the cases. I keep getting people who ask "who is josh" based
> on the /home/josh path. Not that it's that important, but...
Thanks, and
On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote:
> Hello, Bruce.
>
> At Thu, 27 Aug 2020 15:41:40 -0400, Bruce Momjian wrote in
> > > My point here is just "are we OK to remove it?"
> >
> > Yes, in PG 14. Security is confusing enoug
d be helpful for this.
I don't think there was enough value to do statistics migration just for
pg_upgrade, but doing it for pg_upgrade and FDWs seems like it might
have enough demand to justify the required work and maintenance.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Mon, Aug 31, 2020 at 12:19:52PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I don't think there was enough value to do statistics migration just for
> > pg_upgrade, but doing it for pg_upgrade and FDWs seems like it might
> > have en
On Mon, Aug 31, 2020 at 12:56:21PM -0400, Stephen Frost wrote:
> Greetings,
> * Bruce Momjian (br...@momjian.us) wrote:
> The point I was making was that it has value and people did realize it
> but there's only so many resources to go around when it comes to hacking
> on
gt; the value.
>
> I've received some more replies to your email as soon as I had replied. I
> don't insist on my proposal, just go ahead with your simpler changes.
Patch applied.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
On Mon, Aug 31, 2020 at 01:26:59PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I actually don't know which statement above is correct, because of the
> > "forever" maintenance.
>
> I can understand not being sure which is corr
s, I don't buy Bruce's argument that it's going to require more
> maintenance effort than any other part of the system does.
Well, my point is that even bucket/calculation/data text respresentation
changes could affect dumping statistics, and that is kind of rare for
other changes we
On Mon, Aug 31, 2020 at 05:46:22PM -0400, Bruce Momjian wrote:
> On Mon, Aug 31, 2020 at 01:53:01PM -0400, Tom Lane wrote:
> > Stephen Frost writes:
> > > Feature work either requires changes to pg_dump, or not. I agree that
> > > features which don't require pg
On Mon, Aug 24, 2020 at 04:58:34PM +0900, Michael Paquier wrote:
> On Fri, Aug 21, 2020 at 06:03:32PM -0400, Bruce Momjian wrote:
> > On Tue, Aug 18, 2020 at 02:41:09PM +0200, Bernd Helmle wrote:
> >> protocol.sgml describes the protocol messages received by a BASE_BACKUP
>
On Tue, Sep 1, 2020 at 01:59:25PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 31 Aug 2020 11:34:29 -0400, Bruce Momjian wrote in
> > On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote:
> > > Ok, this is that. If we spcify clientcert=no-verify other th
ker to be
configurable.
Interestingly, you can use period as s delimiter if you are copying from
a file that doesn't need an end-of-data marker and you never need to
escape the delimiter, but that seems like too rare a use case to allow
period to be supported as a delimiter.
--
Bruce Mom
On Tue, Sep 1, 2020 at 12:05:02PM -0400, Bruce Momjian wrote:
> > copy test from '/tmp/data' DELIMITER ',';
> >
> > An end-of-copy marker corrupt error will be raised.
> >
> > This requires users to escape the end-of-data marker manually i
end-of-data in data?
So, you are using comma as the delimiter, but have \. (backslash-period)
as a data value. You need to double-up backslashes in your input data,
no matter what is after the backslash. You just happen to hit backslash
period, but other things like \N could
On Wed, Sep 2, 2020 at 10:45:30AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 1 Sep 2020 11:47:34 -0400, Bruce Momjian wrote in
> > OK, I have developed the attached patch based on yours. I reordered the
> > tests, simplified the documentation, and removed the hint since they
>
1 BC, and we have Oracle, which to_date() is
supposed to match, making -1 as 1 BC.
Because we already have the to_date/make_date inconsistency, and the -1
to -2 BC mapping is confusing, and doesn't match Oracle, I think the
clean solution is to change PG 14 to treat -1 as 1 BC
On Wed, Apr 1, 2020 at 08:57:18AM -0300, Ranier Vilela wrote:
> Hi,
> New patch with yours suggestions.
Patch applied to head, thanks.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is
On Fri, Sep 4, 2020 at 09:39:45AM -0300, Ranier Vilela wrote:
> Em qui., 3 de set. de 2020 às 23:57, Bruce Momjian
> escreveu:
>
> On Wed, Apr 1, 2020 at 08:57:18AM -0300, Ranier Vilela wrote:
> > Hi,
> > New patch with yours suggestions.
>
>
On Fri, Sep 4, 2020 at 11:31:55PM +0800, Kelly Min wrote:
> hello, hackers.
>
>
> I found a comment error in buffer descriptors comment. The cache line size is
> 64 bytes, not 64 bits
Thanks, fix applied to all active branches.
--
Bruce Momjian https://momjian.us
On Fri, Sep 4, 2020 at 12:45:36PM -0700, David G. Johnston wrote:
> On Thu, Sep 3, 2020 at 6:21 PM Bruce Momjian wrote:
>
> On Wed, Jul 15, 2020 at 09:26:53AM -0700, David G. Johnston wrote:
>
> > Whether to actually change the behavior of to_date is up for deb
On Sun, Sep 6, 2020 at 04:59:11PM +0200, Peter Eisentraut wrote:
> On 2020-08-25 21:48, Bruce Momjian wrote:
> > On Sat, Jul 4, 2020 at 08:47:53AM +0200, Fabien COELHO wrote:
> > >
> > > Hello Peter,
> > >
> > > > The original styleshe
that was the conclusion. I think it helped to have the discussion
verbally with everyone hearing every word, rather than via email where
people jump into the discussion not hearing earlier points.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
le) and encrypting the checksum for rudimenary integrity
checking.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
mprovements to it
> (independently of TDE or anything else discussed currently).
Yes, 100% agree on that. The good part is that TDE would not be paying
the cost for that. ;-)
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.c
ders and no tuples, and pages
with headers and only a few tuples. If any of those are insecure, they
all are. Therefore, I don't see any reason to treat them differently.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote:
>
> > Yes, that's the direction that I was thinking also and specifically with
> > XTS as the encryption algorithm to allow us to exclude the LSN but
On Tue, Oct 12, 2021 at 08:25:52AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Oct 12, 2021 at 08:40:17AM +0300, Ants Aasma wrote:
> > > On Mon, 11 Oct 2021 at 22:15, Bruce Momjian wrote:
> > >
> > &
On Tue, Oct 12, 2021 at 08:49:28AM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > I thought he was saying that when you extend a file, you might have to
> > extend it with all zeros, rather than being able to extend it with
> > an actual encrypte
ched by anything even remotely like the
> existing code.
Also, the current code handles renames of schemas and objects, but this
would not.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
> On Tue, 12 Oct 2021 at 16:14, Bruce Momjian wrote:
>
> Well, how do you detect an all-zero page vs a page that encrypted to all
> zeros?
>
> Page encrypting to all zeros is for all practical purposes
On Wed, Oct 13, 2021 at 12:48:51AM +0300, Ants Aasma wrote:
> On Wed, 13 Oct 2021 at 00:25, Bruce Momjian wrote:
>
> On Tue, Oct 12, 2021 at 11:21:28PM +0300, Ants Aasma wrote:
> > Page encrypting to all zeros is for all practical purposes impossible to
> hit.
&g
301 - 400 of 2952 matches
Mail list logo
