I used the updated instructions from pg_ctl.diff to install from source.
Worked well for me, new version is more consistent.
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I tested the master branch (commit 8edd0e7), REL_11_STABLE (commit
o me, I
think the others are ok and I won't nit-pick either way on those (unless
you want me to!).
If you agree, I should go through and fix my nodesets to be node-sets.
Yes, I like node-sets better, especially knowing it conforms to the spec's
language.
Thanks,
*Ryan Lambert*
On Tue, Mar 26,
end, I am new to this process but didn't have issues with the previous
patches when I tested those a couple weeks ago.
[1] https://www.postgresql.org/message-id/5c8ecaa4.3090...@anastigmatix.net
Ryan Lambert
On Sat, Mar 23, 2019 at 5:07 PM Chapman Flack wrote:
> On 03/23/19 18:22, Tom L
Perfect, thank you! I do remember seeing that message now, but hadn't
understood what it really meant.
I will test later today. Thanks
*Ryan*
On Sun, Mar 24, 2019 at 9:19 PM Tom Lane wrote:
> Chapman Flack writes:
> > On 03/24/19 21:04, Ryan Lambert wrote:
> >> I am un
ps cleanly.
postgres=# DROP DATABASE testdb FORCE;
DROP DATABASE
The active connections get terminated as expected. Thanks,
[1]
https://www.postgresql.org/message-id/attachment/99536/drop-database-force-20190310_01.patch
*Ryan Lambert*
RustProof Labs
On Sun, Mar 10, 2019 at 12:5
25, 2019 at 4:52 PM Chapman Flack wrote:
> On 03/25/19 18:03, Ryan Lambert wrote:
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, passed
> > Implements feature: tested, passed
> > Spec compliant:
commit to this behavior, and an XPath 1.0 expression cannot control
> it.)
It seems you are standardizing from "node set" to "nodeset", is that the
preferred nomenclature or preference?
Hopefully this helps! Thanks,
Ryan Lambert
[1]
https://www.postgresql.org/messag
t->err_occurred)
Does this sound reasonable? Have I missed some major aspect? If this is
on the right track I can work on creating a patch to move this forward.
Thanks,
*Ryan Lambert*
RustProof Labs
www.rustprooflabs.com
case.
Thanks,
Ryan Lambert
On Sat, Mar 16, 2019 at 4:33 PM Chapman Flack wrote:
> On 03/16/19 17:21, Tom Lane wrote:
> > Chapman Flack writes:
> >> On 03/16/19 16:55, Tom Lane wrote:
> >>> What do you think of the idea I just posted about parsing off the
>
V from the nonce that will affect performance. I don't
know how expensive the forward hash is but it won't be free.
[1]
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf
*Ryan Lambert*
> I didn't either, except it was referenced above as "forward hash". I
> don't know why that was suggested, which is why I listed it as an
> option/suggestion.
My bad, sorry for the confusion! I meant to say "cipher" not "hash". I
was (trying to) refer to the method of generating unpredictable
to want to wait to reencrypt the whole thing.
Ryan Lambert
>
> >>Uh, what if a transaction modifies page 0 and page 1 of the same table
> >>--- don't those pages have the same LSN.
> >
> >No, because WAL being a physical change log, each page gets its own
> >WAL record with its own LSN.
> >
>
> What if you have wal_log_hints=off? AFAIK that won't change
tocols, Algorithms and
Source Code in C (20th Anniversary ed.). John Wiley & Sons.
[2] Biryukov, A., Dunkelman, O., Keller, N., Khovratovich, D., & Shamir, A.
(2009). Key Recovery Attacks of Practical Complexity on AES-256 Variants
with up to 10 Rounds. Retreived from https://eprint.iacr.org/2009/374.pdf
Ryan Lambert
RustProof Labs
ows=100 loops=1)
-> Seq Scan on r10mwide (cost=0.00..242858.60 rows=1060
width=20) (actual time=0.017..3086.504 rows=1000 loops=1)
Planning Time: 0.168 ms
Execution Time: 6495.686 ms
[1]
https://www.postgresql.org/message-id/attachment/102333/percent-incremental-v5.p
://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
[3]
https://stackoverflow.com/questions/8852668/what-is-the-clash-rate-for-md5
Thanks,
Ryan Lambert
RustProof Labs
s.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf
Thanks,
Ryan Lambert
>
tual time=0.014..3847.146 rows=1000 loops=1)
Planning Time: 0.117 ms
Execution Time: 59079.680 ms
(5 rows)
Ryan Lambert
>
>
/103157/percent-incremental-v6-comment-cleanup.patch
Ryan Lambert
The new status of this patch is: Ready for Committer
tests. I reviewed the conversation
to date and from what I can see, all identified bugs have been fixed and
concerns either fixed or addressed. Marking as ready for committer.
[1]
https://www.postgresql.org/message-id/attachment/103486/percent-incremental-v8.patch
Ryan Lambert
The new status
(dbname));
And here:
+$node->safe_psql('postgres', 'CREATE DATABASE foobar2');
+$node->issues_sql_like(
+ [ 'dropdb', '--force', 'foobar2' ],
+ qr/statement: DROP DATABASE (FORCE) foobar2/,
+ 'SQL DROP DATABASE (FORCE) run');
+
I'll try to build and test the patch tomorrow.
Thanks,
*Ryan Lambert*
>
>>
tion [2]?
I'll take some time later this week to examine pg_pooler_state further on a
more appropriately sized server.
Thanks,
[1]
https://www.postgresql.org/message-id/attachment/103046/builtin_connection_proxy-16.patch
[2] https://www.postgresql.org/docs/current/functions-info.html
Ryan Lambert
>
> First of all default value of this parameter is 1000, not 10.
Oops, my bad! Sorry about that, I'm not sure how I got that in my head
last night but I see how that would make it act strange now. I'll adjust
my notes before re-testing. :)
Thanks,
*Ryan Lambert*
On Wed, Aug 7, 2019 at 4
9 |149
150 | 10 | 6 | 146
Ryan Lambert
>
e. I attached a patch with a
few minor changes in the comments. I need to go back to my notes and see
if I covered all the testing I had thought of, I should get to that later
this week.
[1]
https://www.postgresql.org/message-id/attachment/103028/percent-incremental-v6.patch
*Ryan Lambert*
&
I set the status to Waiting on Author since Tom's concerns [1] have not been
addressed.
[1] https://www.postgresql.org/message-id/15707.1564024305%40sss.pgh.pa.us
Thanks,
Ryan
Surafel,
On Wed, Jul 17, 2019 at 3:45 AM Surafel Temesgen
wrote:
>
> Hi Ryan,
> On Tue, Jul 9, 2019 at 4:13 PM Ryan Lambert
> wrote:
>
>>
>> "It is possible for FETCH FIRST N PERCENT to create poorly performing
>> query plans when the N supplied exc
ce to either avoid using
session-specific operations, or not use built-in pooling."
[1]
https://www.postgresql.org/message-id/attachment/102610/builtin_connection_proxy-8.patch
[2]
https://www.postgresql.org/message-id/flat/CAP_rwwmLJJbn70vLOZFpxGw3XD7nLB_7%2BNKz46H5EOO2k5H7OQ%40mail.gmail.com
retested. Looks
great, thanks!
https://www.postgresql.org/message-id/attachment/102334/drop-database-force-20190708.patch
Ryan Lambert
The new status of this patch is: Ready for Committer
your patch to test later today or
tomorrow. Thanks,
Ryan Lambert
Here's what I found tonight in your latest patch (9). The output from git
apply is better, fewer whitespace errors, but still getting the following.
Ubuntu 18.04 if that helps.
git apply -p1 < builtin_connection_proxy-9.patch
:79: tab in indent.
Each proxy launches its own
s://www.postgresql.org/message-id/ede4470a-055b-1389-0bbd-840f0594b758%40postgrespro.ru
Thanks,
Ryan Lambert
On Fri, Jul 19, 2019 at 3:10 PM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 19.07.2019 6:36, Ryan Lambert wrote:
>
> Here's what I found toni
> I attached new version of the patch with fixed indentation problems and
> Win32 specific fixes.
Great, this latest patch applies cleanly to master. installcheck world
still passes.
> "connections_proxies" is used mostly to toggle connection pooling.
> Using more than 1 proxy is be needed only
can of the child node is needed, you could re-use
> the data already collected; but that would require a bunch of additional
> logic. I'm inclined to think that v1 of the patch shouldn't concern
> itself with that sort of optimization.
I don't think this was addressed.
Ryan Lambert
>
all feedback
has been addressed except for the one case that can be improved upon in later
work. Updating status as ready for committer.
Ryan Lambert
The new status of this patch is: Ready for Committer
in
doc\src\sgml\ref\select.sgml
with PERCENT count specifies the maximum number of rows
to return
in percentage.ROW
Another missing space after the period.
previous time we got a different result.In PERCENTAGE option there are"
Ryan Lambert
The new status of this patch is: Waiting on Author
I did some more testing. I initialized a database with 1 million rows with
indexes and joins to test against and ran pgbench with a few different
settings for % to return. I started with a base query not utilizing the
new functionality. The queries used are similar to my prior examples, code
at
alternative.
Agreed. I know little of the inner details about the LSN but what I read
in [1] sounds encouraging in addition to tableoid + pagenum.
[1] https://www.postgresql.org/docs/current/datatype-pg-lsn.html
Ryan Lambert
>
If a random number were generated instead its result would need to be
stored somewhere too, correct?
> That might also allow things like backup software to work
> on these encrypted data files for page-level backups without needing
> access to the key and that'd be pretty neat.
+1
Ryan
concerned. I quickly reviewed the patch
but haven't tested it yet.
Is it realistic to add PERCENT into this patch or would that be a future
enhancement?
Thanks,
*Ryan Lambert*
r, int location);
^~~
gram.y:16695:1: warning: ‘makeAndExpr’ defined but not used
[-Wunused-function]
makeAndExpr(Node *lexpr, Node *rexpr, int location)
^~~
The docs have two instances of "EndtTime" that should be "EndTime".
Ryan Lambert
y probably need some coralling
>
> Overall, it's a pretty good patch and worth working on more. I will
> consider a recommendation on what to do with this.
>
> --
> Simon Riggs http://www.EnterpriseDB.com/
I am increasingly interested in this feature and have heard others asking
for this type of functionality. I'll do my best to continue reviewing and
testing.
Thanks,
Ryan Lambert
[1] https://bornsql.ca/blog/temporal-tables-hidden-columns/
On Fri, Jan 8, 2021 at 11:38 AM Simon Riggs
wrote:
> On Fri, Jan 8, 2021 at 4:50 PM Ryan Lambert
> wrote:
> >
> > On Fri, Jan 8, 2021 at 5:34 AM Simon Riggs
> wrote:
> >>
> >> On Fri, Jan 8, 2021 at 7:34 AM Simon Riggs <
> simon.ri...@enterprisedb.
On Thu, Jan 14, 2021 at 2:22 PM Simon Riggs
wrote:
> On Thu, Jan 14, 2021 at 5:46 PM Surafel Temesgen
> wrote:
>
> > On Fri, Jan 8, 2021 at 7:50 PM Ryan Lambert
> wrote:
> >>
> >> I prefer to have them hidden by default. This was mentioned up-thread
>
On Mon, Jan 11, 2021 at 7:02 AM Simon Riggs
wrote:
> On Sat, Jan 9, 2021 at 10:39 AM Simon Riggs
> wrote:
> >
> > On Fri, Jan 8, 2021 at 9:19 PM Ryan Lambert
> wrote:
> >
> > >> Updated v11 with additional docs and some rewording of messages/tests
>
or out and
warn the user, instead it creates a dump containing only the SET commands.
An error similar to using --functions-only along with --data-only seems
like a good idea.
Cheers,
*Ryan Lambert*
RustProof Labs
Should the status of this patch be updated to ready for comitter to get in
line for Pg 14 deadline?
*Ryan Lambert*
On Sun, Mar 7, 2021 at 11:38 PM Amit Langote
wrote:
> On Fri, Mar 5, 2021 at 7:50 AM Ryan Lambert
> wrote:
> > On Wed, Mar 3, 2021 at 11:03 PM Amit Lang
. An
updated patch was mentioned but has not been attached. Updating status to
Waiting on Author.
Cheers,
-- Ryan Lambert
The new status of this patch is: Waiting on Author
ib/postgresql/git/postgresql/src/backend'
make[1]: *** [Makefile:42: install-backend-recurse] Error 2
make[1]: Leaving directory '/var/lib/postgresql/git/postgresql/src'
make: *** [GNUmakefile:11: install-src-recurse] Error 2
Thanks,
Ryan Lambert
to the quality of the
code, though am happy to test any additional use cases that should be
verified.
Ryan Lambert
a procedure, etc. It'd be silly to introduce an unnecessary
> ambiguity in pg_dump and have to deal with it sometime later.
+1
*Ryan Lambert*
RustProof Labs
52 matches
Mail list logo
