standard?
Based on 1 and 2, I suggest we change transaction_timestamp() to advance
on COMMIT in procedure, and document this. I have no idea on #3.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
lease has inaccurate text
> about the default partition, but that's a separate issue, which I was
> unaware of.
Oh, OK, thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you wi
of the press release, we ended up using the
> > equivalent of "for the data that does not match any other partition".
>
> Yeah, "any other partition" is what the existing description uses too, so:
>
> Having a "default" partition for storing
ibly newer than
> statement_timestamp() seems like a normal consequence of
> transactions being created intra-statement.
Yes, that is a good point. My thought has always been that statements
are inside of transactions, but the opposite is now possible.
--
Bruc
opy have
non-destructive behavior on the old cluster once started, so it does
make some sense to merge them, unlike link.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, Oct 10, 2018 at 06:13:56PM -0400, Bruce Momjian wrote:
> On Wed, Oct 10, 2018 at 06:06:01PM -0400, Bruce Momjian wrote:
> > On Wed, Oct 10, 2018 at 12:55:33PM -0700, Andres Freund wrote:
> > > Several people argued for introducing it, you're the only one that was
> &
On Wed, Oct 10, 2018 at 06:06:01PM -0400, Bruce Momjian wrote:
> On Wed, Oct 10, 2018 at 12:55:33PM -0700, Andres Freund wrote:
> > Several people argued for introducing it, you're the only one that was
> > against it. Adrien, Amit Kapila, Peter Geoghegan, and I all said we
>
On Wed, Oct 10, 2018 at 12:55:33PM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-10-08 21:28:02 -0400, Bruce Momjian wrote:
> > On Mon, Oct 8, 2018 at 05:44:32PM +0200, Adrien NAYRAT wrote:
> > > On 10/8/18 5:20 PM, Bruce Momjian wrote:
> > > >Uh, wher
On Mon, Sep 3, 2018 at 04:13:40PM -0700, Andres Freund wrote:
> On September 3, 2018 3:01:29 PM PDT, Bruce Momjian
> wrote:
> >On Mon, Sep 3, 2018 at 02:53:59PM -0700, Andres Freund wrote:
> >> On 2018-09-03 14:56:28 -0400, Bruce Momjian wrote:
> >> > On Mon
, e.g. inaccurate cost estimates.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Mon, Sep 3, 2018 at 02:53:59PM -0700, Andres Freund wrote:
> On 2018-09-03 14:56:28 -0400, Bruce Momjian wrote:
> > On Mon, Sep 3, 2018 at 11:42:31AM -0700, Andres Freund wrote:
> > > > and JIT, so it doesn't have to be 100% accurate.
> > >
> > > JIT d
On Mon, Sep 3, 2018 at 01:30:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > What if we globally or locally cache the _cost_ of plans, so we can
> > consult that cache before planning and enable certain optimizations?
>
> But what would you use as cache key? And
On Mon, Sep 3, 2018 at 11:42:31AM -0700, Andres Freund wrote:
> On September 3, 2018 11:33:35 AM PDT, Bruce Momjian
> wrote:
> >On Mon, Sep 3, 2018 at 01:30:33PM -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > What if we globally or locally cache the
-04
NOTICE: transaction 2018-09-20 19:38:22.575685-04
This surprised me since I expected a new timestamp after commit. Is
this something we want to change or document? Are there other
per-transaction behaviors we should adjust?
--
Bruce Momjian http://momjian.us
Enterpris
()
doesn't --- that seems very odd. It would mean that new statements in a
function don't change statement_timestamp(), but new transctions in a
function do --- again, very odd.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As
On Fri, Sep 21, 2018 at 06:28:22AM -0400, Bruce Momjian wrote:
> On Fri, Sep 21, 2018 at 02:34:25PM +0900, Michael Paquier wrote:
> > On Thu, Sep 20, 2018 at 10:12:06PM -0700, Andres Freund wrote:
> > > Isn't the point that transaction_timestamp() does *not* currently change
>
On Wed, Sep 26, 2018 at 02:38:25PM +0200, Peter Eisentraut wrote:
> On 22/09/2018 00:35, Bruce Momjian wrote:
> > I have always thought of clock/statement/transation as decreasing levels
> > of time precision, and it might be odd to change that. I don't think we
> > want t
On Tue, Sep 25, 2018 at 03:01:31PM -0700, David G. Johnston wrote:
> On Sat, Sep 22, 2018 at 5:27 PM, Bruce Momjian wrote:
>
> On Fri, Sep 21, 2018 at 06:35:02PM -0400, Bruce Momjian wrote:
> > Does the SQL standard have anything to say about CURRENT_TIMESTAMP in
>
On Fri, Sep 21, 2018 at 06:35:02PM -0400, Bruce Momjian wrote:
> Does the SQL standard have anything to say about CURRENT_TIMESTAMP in
> procedures? Do we need another function that does advance on procedure
> commit?
I found a section in the SQL standards that talks about it, bu
e sweep. What if we
mark entries as unused every 10 queries, mark them as used on first use,
and delete cache entries that have not be used in the past 10 queries.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprised
style guide of the documentation, those
should
be full sentences.
Author: Daniel Gustafsson
Reviewed-by: Michael Paquier, Álvaro Herrera
Discussion: https://1e8d49b4-16bc-4420-b4ed-58501d9e0...@yesql.se
--
Bruce Momjian http:
can do 10-11 minute precision. I am not sure the
complexity is worth it.
For a size trigger, should removal be effected by how many expired cache
entries there are? If there were 10k expired entries or 50, wouldn't
you want them removed if they have not been accessed in X minutes?
In the wors
revolve
> around what to do during dump/reload. Although even CREATE OR REPLACE
> offers interesting definitional questions. In the end there are just
> too many different behaviors that somebody might want.)
I wrote a blog on this topic in 2017:
https://momjian.us/main/blog
a way to access a smart card for authentication, though
I did wrote a presentation on how to use PIV devices for server-side and
client-side encryption:
https://momjian.us/main/writings/crypto_hw_use.pdf
--
Bruce Momjian http://momjian.us
EnterpriseDB
Chen Huajun
Diagnosed-by: Chen Huajun, Peter Geoghegan, Andrey Borodin
Discussion:
https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com
Author: Alexander Korotkov
Backpatch-through: 9.4
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
ors. It's my
> oversight, I forget how much better our xlog system became since 9.4
> :)
>
> I've pushed bf0e5a73be fixing that.
I can confirm the compiler warning is now gone. Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB
e Oracle ASH.
>
> If so, does sampling have no significant impact on performance? Even if the
> interval is 0.01 s or more.
I am replying late, but one of the reasons that sampling is used is that
decreasing the sampling interval increases to overhead of the sampling
process, but doesn't af
On Wed, Nov 28, 2018 at 08:51:54AM -0500, Bruce Momjian wrote:
> On Wed, Nov 28, 2018 at 10:46:51AM -0300, Alvaro Herrera wrote:
> > On 2018-Nov-28, Bruce Momjian wrote:
> >
> > > On Wed, Nov 28, 2018 at 03:25:34PM +0900, Etsuro Fujita wrote:
> > > > Here is
On Wed, Nov 28, 2018 at 10:46:51AM -0300, Alvaro Herrera wrote:
> On 2018-Nov-28, Bruce Momjian wrote:
>
> > On Wed, Nov 28, 2018 at 03:25:34PM +0900, Etsuro Fujita wrote:
> > > Here is a small patch for removing $SUBJECT.
> >
> > Agreed. Patch applied through
s.]
I remember the good performance numbers from this feature. How does
this interact with the JIT executor feature, which is also designed to
speed up the executor? Is it something that can be combined with JIT?
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Wed, Nov 28, 2018 at 03:25:34PM +0900, Etsuro Fujita wrote:
> Here is a small patch for removing $SUBJECT.
Agreed. Patch applied through PG 10, where this first appeared.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.
t.
>
> Any thoughts from others about whether to rename clientdn to client_dn
> to allow better naming of the new fields?
Makes sense. The SSL acronyms can get very complex.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
appear in the releaes notes. I think the "a.k.a." can be
simply removed.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
e clarified the documentation for this option. This additional
release note text is not necessary.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
line 1: ""foo
This seems like a bug to me. Looking at the code, psql issues the
prompts for STDIN, but when it sees \. alone on a line, it has no idea
you are in a quoted CSV string, so it thinks the copy is done and sends
the result to the server. I can't see an easy way to fix this
On Thu, Mar 28, 2019 at 12:10:23PM -0300, Alvaro Herrera wrote:
> On 2019-Mar-28, Bruce Momjian wrote:
>
> > I am seeing psql crash and massive regression test failures in git head.
> > The psql crash happens if .psqlrc contains:
> >
> > \set COMP_KEYWORD_CAS
est seem to be crashing from \d. For example, in
src/test/regress/results/tablespace.out, once this line appears:
\d testschema.test_index1
the file ends, while the expected file has many more lines.
--
Bruce Momjian http://momjian.us
EnterpriseDB
a stance on this issue, but making unclear statements
isn't helping the discussion.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Mon, Feb 25, 2019 at 02:24:18PM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Mon, Feb 25, 2019 at 11:33:33AM -0500, Stephen Frost wrote:
> > > I don't want to see more users stumbling over the issues with the
> > > exclusive
reason to not fix bgwriter_lru_maxpages comment?
Frankly, I was surprised postgresql.conf.sample was changed in a back
branch since it will cause people who diff $PGDATA/postgresql.conf with
share/postgresql.conf.sample to see differences they didn't make.
--
Bruce Momjian http://momjian
//www.postgresql.org/message-id/20190222035816.uozqvc4wjyag3...@momjian.us
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Tue, Mar 5, 2019 at 12:24:14AM -0300, Alvaro Herrera wrote:
> On 2019-Mar-04, Bruce Momjian wrote:
>
> > On Thu, Feb 28, 2019 at 10:28:44AM +0300, Sergei Kornilov wrote:
> > > Hello
> > >
> > > postgresql.conf.sample was ch
loc savings, then yes you
> really do want to replace everything...)
Could it be that allocating List* structures near the structure it
points to is enough of a benefit in terms of cache hits that it is a
loss when moving to a List* array?
--
Bruce Momjian http://momjian.us
EnterpriseDB
Isn't this case problematic even when a backup was taken by pg_basebackup?
> > Because of lack of recovery.signal, no archived WAL files are replayed and
> > the database may not reach to the latest point.
>
> It is problematic because we have a message encouraging users to delete
&g
ucture, and a copy is required?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
t; pg_policy). The same is true for functions and system views. Is it
> better to unify them into 'boolean' for consistency and so as not
> unnecessarily confuse users? FYI the name of boolean type is 'boolean'
> in the standard.
Yes, I think so.
--
Bruce Momjian http://momj
other issue is that you will change share/postgresql.conf.sample,
but not $PGDATA/postgresql.conf until initdb is run, meaning if someone
diffs the two files, they will see differences that they did not make.
Making defaults more accurate is not worth that confusion.
--
Bruce Momjian
o address the most pressing problem of unlimited cache size
bloat and then take a holistic look at all memory allocation. If we
are going to address that in a global way, I don't see the relation
cache as the place to start.
--
Bruce Momjian http://momjian.us
EnterpriseDB
if there is interest.
Should I put it on PGXN eventually? It is something we would want in
/contrib?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave
; based on find_my_exec. (I'm amused to notice that pg_upgrade
> currently takes the trouble to find out its own path, and then does
> precisely nothing with the information.)
Good point. You are right that when it was outside of the source tree,
and even in /contrib, that would not have worked eas
On Tue, Mar 19, 2019 at 02:43:49AM -0400, Bruce Momjian wrote:
> > 3. Actually, I'm kind of wondering why pg_upgrade has a --new-bindir
> > option at all, rather than just insisting on finding the new-version
> > executables in the same directory it is in. This seems like, at be
size as a way to keep the systems tables in
cache, which we know we will need for the next query.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
>
> I think you're not working incrementally enough here. I strongly suggest
> solving the negative cache entry problem, and then incrementally go from
> there after that's committed. The likelihood of this patch ever getting
> merged otherwise seems extremely small.
Agreed --- the p
On Thu, Feb 14, 2019 at 01:31:49AM +, Tsunakawa, Takayuki wrote:
> From: Bruce Momjian [mailto:br...@momjian.us]
> > > That being said, having a "minimal size" threshold before starting
> > > with the time-based eviction may be a good idea.
> >
> &g
On Thu, Feb 14, 2019 at 04:25:27PM +0100, Peter Eisentraut wrote:
> On 06/02/2019 10:00, Bruce Momjian wrote:
> > I think "materialize" is the right word since "materialized" would be
> > past tense.
>
> It's an adjective. The sentence is, &
We removed channel binding from PG 11 in August of 2018 because we were
concerned about downgrade attacks. Are there any plans to enable it for
PG 12?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I
On Sat, Feb 16, 2019 at 10:12:19AM +0900, Michael Paquier wrote:
> On Fri, Feb 15, 2019 at 04:17:07PM -0500, Bruce Momjian wrote:
> > We removed channel binding from PG 11 in August of 2018 because we were
> > concerned about downgrade attacks. Are there any plans to enable i
ARED queries worked, we got many questions about
odd query performance until we finally documented it in 2016 in commit
fab9d1da4a213fab08fe2d263eedf2408bc4a27a. If we change the inlining
behavior later, we can update the docs.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Fri, Jan 25, 2019 at 01:01:22PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > but I am able to see the failure using STDIN:
> >
> > COPY test FROM STDIN CSV;
> > Enter data to be copied followed by a newline.
> >
these all kind of require a change to the COPY format, which
hasn't changed in many years.
> - psql could be told somehow that the next piece of inline data is in
> the CSV format, and then pass it through a CSV parser.
That might be the cleanest solution, but how would we actually input
multi
│ 53415 │ 59615 │ 68334 │85885 │
> ├┼┼─┼─┼──┤
> │ 1000 │ 60152 │ 20445 │ 60003 │24047 │
> └┴┴─┴─┴──┘
It is nice it is a smaller patch. Please remind me of the performance
On Sun, Jan 27, 2019 at 10:10:36PM +0900, Michael Paquier wrote:
> On Thu, Jan 24, 2019 at 10:09:30PM -0500, Bruce Momjian wrote:
> > This seems like a bug to me. Looking at the code, psql issues the
> > prompts for STDIN, but when it sees \. alone on a line, it has
_mbstrlen(). Or if someone else wants to give that a go, feel free.
It might be valuable to just inline the UTF8 case.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
ds instead of minutes? (I can't see
why you would not clean up all unreferenced objects after _minutes_ of
disuse, but removing them after seconds of disuse seems undesirable.)
What are the odds you would retain the entires you want with a fast
target?
What is the value of being able to change a specif
On Fri, Jan 25, 2019 at 08:14:19AM +, Tsunakawa, Takayuki wrote:
> Hi Horiguchi-san, Bruce,
>
> From: Bruce Momjian [mailto:br...@momjian.us]
> > I suggest you go with just syscache_prune_min_age, get that into
> > PG 12, and we can then reevaluate what we need. If you
hat is useful if
> it could be turned on remotely so the remote GUC feature but it
> was too complex...
Well, I am thinking if we want to do something like this, we should do
it for all GUCs, not just for this one, so I suggest we not do this now
either.
--
Bruce Momjian
With our scanner keywords list now more cache-aware, and with us
planning to use Bison for years to come, has anyone ever looked at
reordering the bison state machine array to be more cache aware, e.g.,
having common states next to each other rather than scattered around the
array?
--
Bruce
er does not make a
> mistake.
I wrote a blog entry about this:
https://momjian.us/main/blogs/pgblog/2017.html#June_2_2017
This is certainly an area we can improve, but it would require changes
in several parts of the system to handle cases where the tablespace
disappea
On Wed, Jan 30, 2019 at 06:32:11PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
> > Well, these all kind of require a change to the COPY format, which
> > hasn't changed in many years.
>
> Not for the first two. As an example of solution #2, it could look li
On Sat, Jan 26, 2019 at 12:49:50AM +0100, David Fetter wrote:
> On Fri, Jan 25, 2019 at 05:38:59PM -0500, Bruce Momjian wrote:
> > With our scanner keywords list now more cache-aware, and with us
> > planning to use Bison for years to come, has anyone ever looked at
> > reord
d in base 16; otherwise, a zero base is taken as
10 (decimal) unless the next character is '0', in which case it is taken
as 8 (octal).
so it looks like the behavior is just a side-effect of our strtol call.
I am not sure it is worth documenting though.
--
Bruce Momjia
think is what was the intention.
>
> I can willingly admit that I had never even noticed the tutorial directory
> until I yesterday stumbled across it. The commit introducing the above
> wording
> is by now old enough to drive.
>
Agreed, thanks more. ;-)
--
Bruce Momjian
issues referencing the source code in gdb.
>
> I'm very interested to learn how the professionals explore the codebase!
Uh, the developer FAQ has some info on this:
https://wiki.postgresql.org/wiki/Developer_FAQ
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Tue, Feb 5, 2019 at 12:02:23PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Feb 5, 2019 at 11:55:37AM -0500, Tom Lane wrote:
> >> There's been talk periodically of having an aggressive triage effort
> >> to try to sort through the pending patches
gt; Withdrawn: 4.
> > Rejected: 3.
> > Returned with Feedback: 52.
> > Total: 230.
>
> Wow, thank you so much for your hard work. The last CF for PG 12 should be
> tough...
Agreed. I am somewhat concerned about this and am wondering what we can
do now to limit problems.
-
On Tue, Feb 5, 2019 at 11:55:37AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Feb 4, 2019 at 06:34:50AM +, Tsunakawa, Takayuki wrote:
> >> Wow, thank you so much for your hard work. The last CF for PG 12 should
> >> be tough...
>
> > Ag
l see ;o)
Why can't we just explose the hash computation as an SQL function and
let people call it with pg_stat_activity.query or wherever they want the
value? We can install multiple functions if needed.
--
Bruce Momjian http://momjian.us
EnterpriseDB
GUC
full_page_writes) stored in WAL so they are protected from partial
writes, hence are less likely to need checksum protection to detect
corruption.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
e to do that yet, and most people use link anyway.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Use correct connection name variable in ecpglib.
Fixed-by: Kuroda-san
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient
3 in decimal. From the modes table below, we see
> - * that it means that the codeword encodes three 12-bit integers. In
> decimal,
> + * that it means that the codeword encodes three 20-bit integers. In
> decimal,
> * those integers are 18, 50 and 20. Because we encode deltas rat
On Thu, Mar 14, 2019 at 12:53:02AM -0700, Mitar wrote:
> Hi!
>
> On Fri, Jan 25, 2019 at 2:32 PM Bruce Momjian wrote:
> > I wrote a blog entry about this:
> >
> > https://momjian.us/main/blogs/pgblog/2017.html#June_2_2017
> >
> > This is certain
rhead of
implementing it.
I do think the Pluggable storage API is the right approach, and, if you
are going to go that route, adding #4 compression seems very worthwhile.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://
ull full-page-writes from WAL, or from PGDATA. It avoids the need to
scan 16MB WAL files, and the WAL files and modblock files could be
expired independently.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Mon, Apr 15, 2019 at 09:04:13PM -0400, Robert Haas wrote:
> On Mon, Apr 15, 2019 at 4:31 PM Bruce Momjian wrote:
> > Can I throw out a simple idea? What if, when we finish writing a WAL
> > file, we create a new file 00010001.modblock which
> > lists all
');
EXPLAIN ANALYZE VERBOSE EXECUTE e ('pg_class');
--> EXPLAIN ANALYZE VERBOSE EXECUTE e ('pg_class');
The last explain will _not_ show any log_planner_stats duration, though
it does show an EXPLAIN planning time:
Planning Time: 0.012 ms
It this expected behavior?
--
Bruce Momj
or non-\x
display? What do people want the non-pspg pager to do?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Ms. As opposed to the proposed undo and SLRU
> SMGRs that provide layouts specialised for different life cycles.
A bigger issue is that our documention often refers to "disk" as storage
when including SSD storage, which clearly have no disks. They are
"solid state drives", not d
#2 is not needed for WAL:
https://en.wikipedia.org/wiki/Disk_encryption_theory#Problem_definition
2. Data retrieval and storage should both be fast operations, no
matter where on the disk the data is stored.
because you are not writing into random parts of the WAL.
Us
ild. A year is not too much; IMO it's
> barely enough.
It would be nice to address channel binding as part of this.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Sun, May 12, 2019 at 10:49:07AM -0400, Jonathan Katz wrote:
> Hi Bruce,
>
> On 5/11/19 4:33 PM, Bruce Momjian wrote:
> > I have posted a draft copy of the PG 12 release notes here:
> >
> > http://momjian.us/pgsql_docs/release-12.html
> >
> > They a
On Mon, May 13, 2019 at 01:37:25PM +1200, David Rowley wrote:
> On Sun, 12 May 2019 at 08:33, Bruce Momjian wrote:
> >
> > I have posted a draft copy of the PG 12 release notes here:
> >
> > http://momjian.us/pgsql_docs/release-12.html
>
> I notice
On Sun, May 12, 2019 at 09:49:40AM -0400, Bruce Momjian wrote:
> On Sun, May 12, 2019 at 10:00:38AM +0300, Oleg Bartunov wrote:
> > Bruce,
> >
> > I noticed that jsonpath in your version is mentioned only in functions
> > chapter, but commit
> > 72b6460336e86ad5
sql.org/message-id/flat/CAEepm%3D0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug%40mail.gmail.com
>
> ? The required change in pg_bsd_indent isn't quite done, but it
> could be done by next week.
Yes, I think we are good with everything above. I am thinking you
should do the run since you did the pg_ind
d spurious
> > conflicts?
>
> 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 out-of-tree patches would scream.
My regular backpatch pain is S
On Thu, Jun 13, 2019 at 09:14:13PM -0400, Bruce Momjian wrote:
> On Mon, Jun 3, 2019 at 12:04:54PM -0400, Robert Haas wrote:
> >
> > What I'm talking about here is that it also has to be reasonably
> > possible to write an encryption key command that does something
>
On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote:
> On 6/13/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
> >> Yeah, in principle since data key of 2 tier key architecture should
> >> not go outside
On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote:
> On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> >> In any case it doesn't address my first point, which is limiting the
> >> volume encrypted with
On Fri, Jun 14, 2019 at 09:37:37PM -0400, Joe Conway wrote:
> On 6/14/19 6:09 PM, Bruce Momjian wrote:
> > On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote:
> >> On 6/13/19 11:07 AM, Bruce Momjian wrote:
> >> > In addition, while the 8k blocks would use
On Thu, Jun 13, 2019 at 09:11:08AM -0400, Bruce Momjian wrote:
> On Thu, Jun 13, 2019 at 03:33:48PM +0900, Michael Paquier wrote:
> > On Wed, Jun 12, 2019 at 05:25:37PM -0400, Bruce Momjian wrote:
> > > Since we did not backpatch this fix, I am hesitant to spell out exactly
&g
301 - 400 of 2600 matches
Mail list logo
