Applied patches v6-0002 and v6-0003 to master branch, and the `make
check` test is ok.
Here is my test result in 10 times average on 3 virtual machines:
before the patches:
abort.1 = 2.5473 ms
abort.2 = 4.1572 ms
after the patches with OPTIONS (ADD parallel_abort 'true'):
abort.1 =
e Engineer
Highgo Software Inc. (Canada)
www.highgo.ca
From c25b55580b1b3f3faac63b4d72291c80fb2c9c1f Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Tue, 1 Dec 2020 20:47:01 -0800
Subject: [PATCH] add table access method as an option to pgbench
---
doc/src/sgml/ref/pgbench.sgml
for tables.
Thanks,
--
David
Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca
From 1d6f434d56c36f95da82d1bae4f99bb917351c08 Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Mon, 7 Dec 2020 13:42:00 -0800
Subject: [PATCH] add table access method as an option to pgbench
---
doc/s
tablespace is an extraneous word ?
Thanks a lot for pointing this out. I will fix it in next patch once get all
issues clarified.
On Sun, Dec 27, 2020 at 09:14:53AM -0400, Fabien COELHO wrote:
src/test/regress/sql/create_am.sql:CREATE ACCESS METHOD heap2 TYPE TABLE
HANDLER heap_tableam_hand
Thanks for the patch, Mead.
For 'MAXVACUUMCOSTLIMIT", it would be nice to follow the current GUC
pattern to do define a constant.
For example, the constant "MAX_KILOBYTES" is defined in guc.h, with a
pattern like, "MAX_" to make it easy to read.
Best regards,
David
On 2021-02-08 6:48 a.m.
I verified the patch
"v2-0001-Free-disk-space-for-dropped-relations-on-commit.patch" on master
branch "0cc9932740f2bf572303b68438e4caf62de9". It works for me. Below is my
test procedure and results.
=== Before the patch ===
#1 from psql console 1, create table and index then insert enough d
tests easier at some points.
The attached file is quick patch for this.
Thoughts?
Thank you,
--
David
Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca
From 798f970e22034d33146265ed98922c605d0dc237 Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Tue, 24 Nov 2020 15:14:42 -080
Thank a lot for your comments, Michael.
On 2020-11-24 7:41 p.m., Michael Paquier wrote:
On Tue, Nov 24, 2020 at 03:32:38PM -0800, David Zhang wrote:
But, providing another option for the end user may not be a bad idea, and it
might make the tests easier at some points.
My first thought is
Thanks a lot again for the review and comments.
On 2020-11-25 9:36 p.m., Michael Paquier wrote:
On Wed, Nov 25, 2020 at 12:13:55PM -0800, David Zhang wrote:
The previous patch was based on branch "REL_13_STABLE". Now, the attached
new patch v2 is based on master branch. I followed th
Thanks Fabien for the comments.
On 2020-11-25 11:29 p.m., Fabien COELHO wrote:
Hello David,
The previous patch was based on branch "REL_13_STABLE". Now, the
attached new patch v2 is based on master branch. I followed the new
code structure using appendPQExpBuffer to append the new clause
"u
On 2021-01-09 5:44 a.m., youichi aramaki wrote:
+ " create tables with using specified
table access method,\n"
In my opinion, this sentence should be "create tables with specified table access
method" or "create tables using specified table access m
document.
Thank you,
On 2021-01-14 3:51 p.m., David Zhang wrote:
On 2021-01-09 5:44 a.m., youichi aramaki wrote:
+ " create tables with using specified table access
method,\n"
In my opinion, this sentence should be "create tables with specified
table access method&quo
On 2021-01-15 1:22 p.m., Andres Freund wrote:
Hi,
On 2020-11-25 12:41:25 +0900, Michael Paquier wrote:
On Tue, Nov 24, 2020 at 03:32:38PM -0800, David Zhang wrote:
But, providing another option for the end user may not be a bad idea, and it
might make the tests easier at some points.
My
Hi Hackers,
Inside the test script `src/test/recovery/t/001_stream_rep.pl`, a
comment at line 30 says `my_backup` is "not mandatory",
30 # Take backup of standby 1 (not mandatory, but useful to check if
31 # pg_basebackup works on a standby).
32 $node_standby_1->backup($backup_name);
howev
Thanks a lot Michael for the explanation.
On 2021-12-13 4:05 a.m., Michael Paquier wrote:
On Fri, Dec 10, 2021 at 01:44:40PM -0800, David Zhang wrote:
Inside the test script `src/test/recovery/t/001_stream_rep.pl`, a comment at
line 30 says `my_backup` is "not mandatory",
30 # T
Hi Tang,
Thanks a lot for the patch.
I did a quick test based on the latest patch V3 on latest master branch
"commit 4753ef37e0eda4ba0af614022d18fcbc5a946cc9".
Case 1: before patch
1 postgres=# set a
2 all allow_system_table_mods
application_name array_nulls
Hi,
This is a very interesting topic. I did apply the 2nd patch to master branch
and performed a quick test. I can observe below information,
postgres=# select * from pg_lwlock_blocking_pid(26925);
requested_mode | last_holder_pid | last_holder_mode | nb_holders
+---
I found the function "table_relation_size" is only used by buffer
manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and
"RELKIND_MATVIEW", i.e.
case RELKIND_RELATION:
case RELKIND_TOASTVALUE:
case RELKIND_MATVIEW:
{
/*
*
On 2020-09-09 12:41 a.m., gkokola...@pm.me wrote:
‐‐‐ Original Message ‐‐‐
On Tuesday, 8 September 2020 22:26, David Zhang wrote:
I found the function "table_relation_size" is only used by buffer
manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE&qu
I evaluated the effectiveness of the patch using a simple
multi-statement transaction:
BEGIN;
SAVEPOINT s;
INSERT INTO ft1 VALUES (10, 10);
INSERT INTO ft2 VALUES (20, 20);
RELEASE SAVEPOINT s;
COMMIT;
where ft1 and ft2 are foreign tables created on different foreign
servers hosted on different
Right, the file difference is caused by "-At".
On the other side, in order to keep the output message more consistent with
other tools, I did a litter bit more investigation on pg_dump to see how it
handles this situation. Here is my findings.
pg_dump using WRITE_ERROR_EXIT to throw the error m
On 2020-01-16 5:20 a.m., Daniel Verite wrote:
David Zhang wrote:
If I change the error log message like below, where "%m" is used to pass the
value of strerror(errno), "could not write to output file:" is copied from
function "WRITE_ERROR_EXIT".
-
On 2020-01-20 2:42 a.m., Daniel Verite wrote:
David Zhang wrote:
Yes, I agree with you. For case 2 "select repeat('111', 100) \g
/mnt/ramdisk/file", it can be easily fixed with more accurate error
message similar to pg_dump, one example could be something like
On 2020-01-28 4:14 a.m., Daniel Verite wrote:
David Zhang wrote:
The error "No space left on device" can be logged by fprintf() which is
redefined as pg_fprintf() when print_aligned_text() is called
Are you sure? I don't find that redefinition. Besides
print_alig
Thank you for the patch.
I applied this patch manually to the master branch, resolving a conflict
in `numeric.h`. It successfully passed both `make check` and `make
check-world`.
Best regards,
David
g is not required by psql client:
$ psql -d "sslmode=verify-ca sslrootcert=rootCA.crt user=david
dbname=postgres ssl_ocsp_stapling=0" -h 127.0.0.1 -p 5432
psql (17devel)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384,
compression: off)
Type "help" for
Yes, I agree that proper test coverage is needed here. Will think
about how to accomplish this.
Tried to apply this patch to current master branch and the build was ok,
however it crashed during initdb with a message like below.
"performing post-bootstrap initialization ... Segmentation fa
It appears you must "make clean; make install" to correctly compile after
applying the patch.
In a git repository, I've learnt to rely on this simple formula, even
if it means extra cycles when running ./configure:
git clean -d -x -f
Thank you all for pointing out that it needs make clean first.
Hi Postgres hackers,
I'm reaching out to gather some comments on enhancing the efficiency of
migrating particularly large tables with significant data volumes in
PostgreSQL.
When migrating a particularly large table with a significant amount of
data, users sometimes tend to split the table i
OCSP responses for server side certificates with
`good`, `revoked` and `unknown`, and then 3) add some test cases to
t/001_ssltests.pl.
Any comments or feedback would be greatly appreciated!
Thank you,
David
On 2024-02-05 3:51 p.m., David Zhang wrote:
Hello PostgreSQL Hackers,
This pro
Best regards,
David
From ddc07447152331c09daecf0202178cfe77a817a9 Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Tue, 27 Feb 2024 10:06:18 -0800
Subject: [PATCH] correct description for server_ca and client_ca
---
src/test/ssl/conf/client_ca.config | 8 +---
src/test/ssl/conf/server_ca.co
Sep 17 00:00:00 2001
From: David Zhang
Date: Tue, 5 Mar 2024 15:31:22 -0800
Subject: [PATCH 1/3] support certificate status check using OCSP stapling
---
src/backend/libpq/be-secure-openssl.c | 87
src/backend/libpq/be-secure.c | 1 +
src/backend/uti
o such file or
directory
I believe this can help end users quickly realize the mistake.
Thank you,
David
From bb6264791aab6a3e8150704fc8f1c8774c27018d Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Wed, 6 Mar 2024 15:51:11 -0800
Subject: [PATCH] improve ssl files error code
---
src/backend/libpq/be-secure-common.c | 19
On 2022-10-12 2:13 a.m., bt22nakamorit wrote:
There was a mistake in the error message for \! so I updated the patch.
Tried to apply this patch to the master branch, but got the error like
below.
$ git apply --check patch-view.diff
error: patch failed: src/bin/psql/command.c:2693
error: src/bi
On 2022-12-19 7:51 a.m., Nikita Malakhov wrote:
Sorry to bother - but is this patch used in IvorySQL?
Here:
https://www.ivorysql.org/docs/Global%20Unique%20Index/create_global_unique_index
According to syntax it definitely looks like this patch.
The global unique index is one of the features re
I checked the commit log.
About 001_basic.pl, it had been added at 2017 once but been reverted soon
[1][2].
322bec added the file again at 2022[3], so I chose 2022.
About 002_pg_upgrade.pl, it has been added at the same time[3].
Definitively it should be 2022.
It is great to make sure each
On 2023-03-16 4:46 p.m., Peter Smith wrote:
A rebase was needed due to the recent REPLICA IDENTITY push [1].
PSA v2.
- A published table must have a replica identity configured in
+ A published table must have a replica identity
configured in
+1
order to be able to replicate UP
I tried to apply the patch to master and plan to run some tests, but got
below errors due to other commits.
$ git apply --check
v7-0003-postgres-fdw-Add-support-for-parallel-abort.patch
error: patch failed: doc/src/sgml/postgres-fdw.sgml:479
error: doc/src/sgml/postgres-fdw.sgml: patch does no
This is a very useful feature. I applied the patch to the master branch,
and both make check and make check-world passed without any issues.
Just one comment here, based on the example below,
host db jim 127.0.0.1/32 md5 # #foo#
... it returns the following pg_hba_file_rules records:
pos
On 2023-09-13 12:19 a.m., Alvaro Herrera wrote:
On 2023-Sep-13, bt23nguyent wrote:
Hi,
Currently, the psql's tab completion feature does not support properly for
ATTACH PARTITION. When key is typed after "ALTER TABLE
ATTACH PARTITION ", all possible table names should be displayed, however,
Hi Fabien,
Should we consider the case "\ ", i.e. one or more spaces after the backslash?
For example, if I replace a user map
"mymap /^(.*)@mydomain\.com$ \1" with
"mymap /^(.*)@mydomain\.com$ \ "
"\1"
by adding one extra space after the backslash, then I got the pg_role="\\"
but I
On 2020-04-01 10:25 p.m., Fabien COELHO wrote:
Hello,
FWIW, I don't think so. Generally a trailing backspace is an escape
character for the following newline. And '\ ' is a escaped space,
which is usualy menas a space itself.
In this case escape character doesn't work generally and I think
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I applied the patch to the latest master branch and run a test below. The
Hi,
I got an error when I was trying to insert a circle using the syntax
(the 3rd one) specified in the latest document.
https://www.postgresql.org/docs/current/datatype-geometric.html#DATATYPE-CIRCLE
< ( x , y ) , r >
( ( x , y ) , r )
( x , y ) , r
x , y , r
Here is how to reproduce
Thanks a lot for updating the patch.
Tried to apply the patches to master branch, no warning found and
regression test passed.
Now, we have many places (5) calling the same function with a constant
number 3. Is this a good time to consider redefine this number a
macro somewhere?
Thank
Hi Bruce,
Thank you for helping review the patches in such detail.
On 2022-11-25 9:48 a.m., Bruce Momjian wrote:
Looking at the patch, I am unclear how the the patch prevents concurrent
duplicate value insertion during the partitioned index checking. I am
actually not sure how that can be done
Thanks a lot for all the comments.
On 2022-11-29 3:13 p.m., Tom Lane wrote:
... not to mention creating a high probability of deadlocks between
concurrent insertions to different partitions. If they each
ex-lock their own partition's index before starting to look into
other partitions' indexes,
On 2022-11-29 6:16 p.m., Tom Lane wrote:
Assuming that you are inserting into index X, and you've checked
index Y to find that it has no conflicts, what prevents another
backend from inserting a conflict into index Y just after you look?
AIUI the idea is to prevent that by continuing to hold an e
Thanks a lot for the improvement, and it will definitely help provide
more very useful information.
I noticed the document psql-ref.sgml has been updated for both `du+` and
`dg+`, but only `du` and `\du+` are covered in regression test. Is that
because `dg+` is treated exactly the same as `du+
On 2023-02-10 2:27 p.m., David G. Johnston wrote:
On Fri, Feb 10, 2023 at 2:08 PM David Zhang wrote:
I noticed the document psql-ref.sgml has been updated for both
`du+` and
`dg+`, but only `du` and `\du+` are covered in regression test. Is
that
because `dg+` is treated
On 2023-02-15 1:37 p.m., David G. Johnston wrote:
On Wed, Feb 15, 2023 at 2:31 PM David Zhang wrote:
There is a default built-in role `pg_monitor` and the behavior
changed after the patch. If `\dg+` and `\du+` is treated as the
same, and `make check` all pass, then I assume there
Hi Etsuro,
The patch needs rebase due to commits 4036bcbbb, 8c8d307f8 and
82699edbf, so I updated the patch. Attached is a new version, in
which I also tweaked comments a little bit.
After rebase the file `postgres_fdw.out` and applied to master branch,
make and make check are all ok for pos
Hi Karina,
I am not very clear about why `build_reloptions` is removed in patch
`v2-0002-better-error-message-for-setting-parameters-for-p.patch`, if
you can help explain would be great.
From my observation, it seems the WITH option has different behavior
when creating partitioned table and
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Applied the patch `v2_support_of_tzh_tzm_patterns.patch` to `REL_14_STABL
Thanks a lot for the patch update.
On 2022-05-02 1:25 a.m., Etsuro Fujita wrote:
Hi,
On Wed, Apr 20, 2022 at 4:55 AM David Zhang wrote:
I tried to apply the patch to master and plan to run some tests, but got
below errors due to other commits.
I rebased the patch against HEAD. Attached is
Hi,
> > MaxAllocSize is pretty easy:
> > SELECT pg_logical_emit_message(false, long, long) FROM
repeat(repeat(' ', 1024), 1024*1023) as l(long);
> >
> > on a standby:
> >
> > 2022-03-11 16:41:59.336 PST [3639744][startup][1/0:0] LOG: record
length 2145386550 at 0/360 too long
>
> Thanks
A little confused here, does this patch V3 intend to solve this problem "record
length 2145386550 at 0/360 too long"?
No, not once the record exists. But it does remove Postgres' ability
to create such records, thereby solving the problem for all systems
that generate WAL through Postgres
Hi,
I tried to apply this patch v5 to current master branch but it complains,
"git apply --check
v5-0001-Add-protections-in-xlog-record-APIs-against-large.patch
error: patch failed: src/include/access/xloginsert.h:43
error: src/include/access/xloginsert.h: patch does not apply"
then I checked
On 2022-08-01 8:37 a.m., Simon Riggs wrote:
Using the above test case, I'm getting a further 4-7% improvement on
already committed code with the attached patch, which follows your
proposal.
I ran two test cases: for committed patch `hash_sort_by_hash.v3.patch`, I can
see about 6 ~ 7% improveme
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Applied the v6 patch to master branch and ran regression test for con
On 2021-09-06 1:16 a.m., Ronan Dunklau wrote:
Le vendredi 3 septembre 2021, 22:54:25 CEST David Zhang a écrit :
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant
On 2021-08-18 1:29 a.m., Kyotaro Horiguchi wrote:
At Tue, 17 Aug 2021 17:04:44 +0900, Michael Paquier wrote
in
On Fri, Jul 02, 2021 at 06:22:56PM -0300, Ranier Vilela wrote:
Em qui., 1 de jul. de 2021 às 17:20, Mahendra Singh Thalor <
mahi6...@gmail.com> escreveu:
Please can we try to hit th
Hi Drouvot,
I can reproduce the issue you mentioned on REL_12_STABLE as well as Master
branch, but the patch doesn't apply to REL_12_STABLE. After applied it to
Master branch, it returns some wired result when run the query in the first
time.
As you can see in the log below, after the first tim
Hi Drouvot,
I don't see extra data in your output and it looks like your
copy/paste is missing some content, no?
On my side, that looks good and here is what i get with the patch applied:
I ran the test again, now I got the same output as yours, and it looks
good for me. (The issue I mention
I believe before users can make a backup using pg_basebackup and then
start the backup as an independent Primary server for whatever reasons.
Now, if this is still allowed, then users need to be aware that the
backup_label must be manually deleted, otherwise, the backup won't be
able to start a
On 2023-07-16 6:27 p.m., Michael Paquier wrote:
Delete a backup_label from a fresh base backup can easily lead to data
corruption, as the startup process would pick up as LSN to start
recovery from the control file rather than the backup_label file.
This would happen if a checkpoint updates the
Applied v3 patch to master and verified it with below commands,
#Alter view
postgres=# alter view v
ALTER COLUMN OWNER TO RENAME RESET ( SET
postgres=# alter view v set
( SCHEMA
postgres=# alter view v set (
CHECK_OPTION SECURITY_BARRIER SECURITY_INVOKER
post
[..]
For below changes,
else if (TailMatches("CREATE", "VIEW", MatchAny, "AS") ||
- TailMatches("CREATE", "OR", "REPLACE", "VIEW", MatchAny,
"AS"))
+ TailMatches("CREATE", "VIEW", MatchAny, "WITH", "(*)", "AS")
||
+ TailMatches("CREATE", "OR", "REPLAC
Thanks a lot David Rowley for your suggestion in details.
On 2024-04-08 3:23 p.m., David Rowley wrote:
On Tue, 9 Apr 2024 at 09:52, David Zhang wrote:
Finding the exact ctid seems overkill for what you need. Why you
could just find the maximum block with:
N = pg_relation_size
2b8ea600dd740a07 Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Thu, 2 May 2024 15:15:13 -0700
Subject: [PATCH] fix the wrong comment to keep the consistency
---
src/include/libpq/libpq.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/include
On 2024-05-03 4:53 a.m., Daniel Gustafsson wrote:
On 3 May 2024, at 13:48, Peter Eisentraut wrote:
Maybe it's easier if we just replaced
prototypes for functions in xxx.c
with
declarations for xxx.c
throughout src/include/libpq/libpq.h.
+1
+1
--
Daniel Gustafsson
David
It looks like this wording "prototypes for functions in" is used many
times in src/include/, in many cases equally inaccurately, so I would
suggest creating a more comprehensive patch for this.
I noticed this "prototypes for functions in" in many header files and
briefly checked them. It ki
re safe.
Attached v3 patch.
regards,
Ranier Vilela
From 25bd8af7acfd6bf2e23cdfac93828d810cfbb5b4 Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Fri, 19 Aug 2022 14:43:01 -0700
Subject: [PATCH] Replace many memset calls with struct initialization
This replaces all memset() calls with str
I have applied the patch to the latest master branch and successfully executed
'./configure && make && make check' on macOS Ventura. However, during the
process, a warning was encountered: "mixing declarations and code is
incompatible with standards before C99 [-Wdeclaration-after-statement]". M
rkitems.pl Bailout called. Further testing stopped:
command "initdb -D
/Users/david/hg/sandbox/postgres/src/test/modules/brin/tmp_check/t_01_workitems_tango_data/pgdata
-A trust -N" died with signal 6
t/01_workitems.pl Dubious, test returned 255 (wstat 65280, 0xf
/* set up OCSP stapling callback */
+ SSL_CTX_set_tlsext_status_cb(SSL_context, ocsp_stapling_cb);
It seems like this should only be done if ssl_ocsp_file is set?
+1
Thanks a lot for reviewing and providing all your feedback!
Best regards,
David Zhang
_basic_verify is documented at here,
https://docs.openssl.org/3.0/man3/OCSP_resp_find_status/
Thank you,
DavidFrom 368c77885d7925334e8dabcce655b6a82f0a9a8f Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Tue, 6 Aug 2024 15:38:14 -0700
Subject: [PATCH 2/2] v1 WIP OCSP simplify .res generat
Hi Daniel,
Thank you for all the information.
On 2024-08-07 12:20 a.m., Daniel Gustafsson wrote:
While I have only skimmed the patch so far and need more review before I can
comment on it, I do have a question on the expected use of OCSP support in
postgres. With OCSP becoming optional [0], an
Hi Hackers,
When I was working on an extension on Windows platform, I used the
command 'vcregress contribcheck' to run the regression test for my
module. However, this command will run the regression test for all the
modules, I couldn't find a way to regress test my module only. I think
it wo
Hi Tom,
Thanks for the review.
Generated a new patch v2 (attached) following your suggestion and
performed the same test again. The test results looks good including the
"make check".
On 2020-04-06 3:16 p.m., Tom Lane wrote:
David Zhang writes:
I got an error when I was trying
Hi,
Here is the parallel backup performance test results with and without
the patch "parallel_backup_v15" on AWS cloud environment. Two
"t2.xlarge" machines were used: one for Postgres server and the other
one for pg_basebackup with the same machine configuration showing below.
Machine confi
Hi hackers,
I found two email threads below,
https://www.postgresql.org/message-id/b0d099ca-f9c3-00ed-0c95-4d7a9f7c97fc%402ndquadrant.com
https://www.postgresql.org/message-id/CA%2B4BxBwBHmDkSpgvnfG_Ps1SEeYhDRuLpr1AvdbUwFh-otTg8A%40mail.gmail.com
and I understood "OUT parameters in procedures
h a huge percentage of
the absolute time
in the base run of just the postgres server and pg_basebackup client.
With Regards,
Sumanta Mukherjee.
EnterpriseDB: http://www.enterprisedb.com
On Thu, Apr 30, 2020 at 1:18 PM David Zhang <mailto:david.zh...@highgo.ca>> wrote:
Hi,
Than
Hi Michael,
I performed a quick test for the path "msvc-build-init-v2.patch" using
below cases:
1. perl build.pl
2. perl build.pl debug psql
3. perl build.pl RELEASE psql
4. perl build.pl deBUG psql
5. perl build.pl psql
The above cases (case-insensitive) are all working great without any
war
ce)
C:\>psql -d postgres -U postgres -h 192.168.0.19 -At -c "select
repeat('111', 200)" >> E:/file
Error printing tuples (No space left on device)
### macOS Mojave 10.14
postgres=# select repeat('111', 100) \g /Volumes/sdcard/file
Error printing tuples (N
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
The issue has been verified using below steps:
1. $ initdb -D /home/test/
1. Tried to apply the patch to PG 12.2 commit
45b88269a353ad93744772791feb6d01bc7e1e42 (HEAD -> REL_12_2, tag: REL_12_2), it
doesn't work. Then tried to check the patch, and found the errors showing below.
$ git apply --check
0001-Fastpath-for-sending-changes-to-output-plugin-in-log.patch
error:
After manually applied the patch, a diff regenerated is attached.
On 2020-02-18 4:16 p.m., David Zhang wrote:
1. Tried to apply the patch to PG 12.2 commit
45b88269a353ad93744772791feb6d01bc7e1e42 (HEAD -> REL_12_2, tag: REL_12_2), it
doesn't work. Then tried to check the patch, and f
Hi Alvaro,
Thanks for your review, now the new patch with the error message in PG
style is attached.
On 2020-02-28 8:03 a.m., Alvaro Herrera wrote:
On 2020-Feb-18, David Zhang wrote:
3. I think a better way to resolve this issue will still be the solution
with an extra %m, which can make
Hi Dilip,
I repeated the same test cases again and can't reproduce the
disconnection issue after applied your new patch.
Best regards,
David
On 2020-03-02 9:11 p.m., Dilip Kumar wrote:
On Wed, Feb 19, 2020 at 6:00 AM David Zhang wrote:
After manually applied the patch, a diff regene
Hi Hackers,
I found one interesting behavior when "--with-gssapi" is enabled,
given a very "common" configuration in gp_hba.conf like below,
host postgres david 192.168.0.114/32 trust
the query message is always encrypted when using a very "common" way
connect to PG ser
Hi,
I can reproduce this pg_restore crash issue (pg_dump crash too when
running with multiple jobs) on MacOS 10.14 Mojave and MacOS 10.15
Catalina using following steps.
1. build pg_resotre from 12.2 with "--with-gssapi" enabled, or use the
release from https://www.postgresql.org/download/ma
Hi,
My understanding is that the "archiver" won't even start if
"archive_mode = on" has been set on a "replica". Therefore, either
(XLogArchiveMode == ARCHIVE_MODE_ALWAYS) or (XLogArchiveMode !=
ARCHIVE_MODE_OFF) will produce the same result.
Please see how the "archiver" is started in
src/
On 2020-09-24 5:00 p.m., Fujii Masao wrote:
On 2020/09/25 8:15, David Zhang wrote:
Hi,
My understanding is that the "archiver" won't even start if
"archive_mode = on" has been set on a "replica". Therefore, either
(XLogArchiveMode == ARCHI
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
"make installcheck-world" test was performed on branch "REL_1
make installcheck-world” test.
--
David
Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca
From 7df445121d3cf2aa7c0c22c831a8a920bc818d6e Mon Sep 17 00:00:00 2001
From: David Zhang
Date: Fri, 25 Sep 2020 15:39:24 -0700
Subject: [PATCH] fix a potential overflow issue for InitBufTable
96 matches
Mail list logo
