On Thu, Jul 13, 2023 at 10:55 AM Masahiko Sawada wrote:
>
> On Wed, Jul 12, 2023 at 11:15 PM Masahiko Sawada
> wrote:
> >
> > > I think this is a valid concern. Can't we move all the checks
> > > (including the remote attrs check) inside
> > > IsIndexUsableForReplicaIdentityFull() and then call
On Fri, Jul 14, 2023 at 2:15 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > > I think it's appropriate to add on the restrictions page. (But mentioning
> > > that this
> > restriction is only for subscriber)
> > >
> > > If the list were larger, then the restrictions page could be divided into
> > > pub
On Mon, Jul 10, 2023 at 03:43:07PM +0900, Michael Paquier wrote:
> On Wed, Jul 05, 2023 at 08:49:26PM -0700, Nathan Bossart wrote:
>> On Thu, Jul 06, 2023 at 08:21:18AM +0900, Michael Paquier wrote:
>>> Removing the GUC from this table is kind of annoying. Cannot this be
>>> handled like default_w
On 2023-07-14 18:22, David G. Johnston wrote:
For PostgreSQL this is even moreso (i.e, huge means count > 1) since
the
order of rows in the returning clause is not promised to be related to
the
order of the rows as seen in the supplied insert command. A manual
insert
returning should ask for n
On Fri, Jul 14, 2023 at 3:12 PM Chapman Flack wrote:
> If someone really does want to do a huge INSERT and get the generated
> values back in increments, it might be clearer to write an explicit
> INSERT RETURNING and issue it with executeQuery, where everything will
> work as expected.
>
>
For P
Thanks for the reviews, both of you!
On Fri, Jul 14, 2023 at 5:04 AM Andrew Dunstan wrote:
> Seems reasonable at first glance. Isn't it going to save some work anyway
> later on, so the performance hit could end up negative?
Theoretically it could, if the OID list sent during getPolicies()
shri
On 2023-07-14 17:31, Chapman Flack wrote:
So when getGeneratedKeys was later added, a way of getting a ResultSet
after an executeUpdate, did they consciously intend it to come under
the jurisdiction of existing apidoc that concerned the fetch size of
a ResultSet you wanted from executeQuery?
...
On Fri, Jul 14, 2023 at 12:51 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > I agree that the documented contract of the insert command tag says it
> > reports the size of the entire tuple store maintained by the server
> during
> > the transaction instead of just the most recent count on
On 2023-07-14 17:02, Dave Cramer wrote:
The fly in the ointment here is when they setFetchSize and we decide to
use a Portal under the covers.
A person might language-lawyer about whether setFetchSize even applies
to the kind of thing done with executeUpdate.
Hmm ... the apidoc for setFetchSiz
On Fri, 14 Jul 2023 at 16:32, wrote:
> On 2023-07-14 15:49, Dave Cramer wrote:
> > On Fri, 14 Jul 2023 at 15:40, wrote:
> >> Perhaps an easy rule would be, if the driver itself adds RETURNING
> >> because of a RETURN_GENERATED_KEYS option, it should also force the
> >> fetch count to zero and co
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-14 15:49, Dave Cramer wrote:
On Fri, 14 Jul 2023 at 15:40, wrote:
Perhaps an easy rule would be, if the driver itself adds RETURNING
because of a RETURN_GENERATED_KEYS option, it should also force the
fetch count to zero and collect all the returned rows before
executeUpdate returns,
Here's a v5 of the patch, rebased to current master and fixing a couple
compiler warnings reported by cfbot (%lu vs. UINT64_FORMAT in some debug
messages). No other changes compared to v4.
cfbot also reported a failure on windows in pg_dump [1], but it seem
pretty strange:
[11:42:48.708]
=?UTF-8?B?SXZhbiBQYW5jaGVua28=?= writes:
> Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut < pe...@eisentraut.org
> >:
>> If the transform deals with a built-in type, then they should just be
>> added to the respective pl extension directly.
> The new extension bytea_plperl can be easily
"David G. Johnston" writes:
> I agree that the documented contract of the insert command tag says it
> reports the size of the entire tuple store maintained by the server during
> the transaction instead of just the most recent count on subsequent fetches.
Where do you see that documented, exactl
On Fri, 14 Jul 2023 at 15:40, wrote:
> On 2023-07-14 14:19, David G. Johnston wrote:
> > Because of the returning they all need a portal so far as the server is
> > concerned and the server will obligingly send the contents of the
> > portal
> > back to the client.
>
> Dave's pcap file, for the f
I believe I have found something interesting that might be the root of the
problem with RTEPermissionInfo. But I do not know how to fix it exactly. In
AGE's code, the execution of it goes through a function called
analyze_cypher_clause() which does the following:
static Query *analyze_cypher_claus
On Fri, Jul 14, 2023 at 02:02:28PM +0900, Michael Paquier wrote:
> Objection withdrawn.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 2023-07-14 14:19, David G. Johnston wrote:
Because of the returning they all need a portal so far as the server is
concerned and the server will obligingly send the contents of the
portal
back to the client.
Dave's pcap file, for the fetch count 0 case, does not show any
portal name used i
Op 7/4/23 om 23:32 schreef Bruce Momjian:
https://momjian.us/pgsql_docs/release-16.html
I noticed these:
'new new RULES' should be
'new RULES'
'Perform apply of large transactions' should be
'Performs apply of large transactions'
(I think)
'SQL JSON paths' should be
'SQL/JSON
On Fri, Jul 14, 2023 at 11:34 AM wrote:
> On 2023-07-12 21:30, David G. Johnston wrote:
> > Right, and executeUpdate is the wrong API method to use, in the
> > PostgreSQL
> > world, when executing insert/update/delete with the non-SQL-standard
> > returning clause. ... ISTM that you are trying to
> On 14 Jul 2023, at 20:41, Cary Huang wrote:
> Perhaps calling "tm2timestamp(&pgtm_time, 0, NULL, &ts)" without checking the
> return code would be just fine. I see some other usages of tm2timstamp() in
> other code areas also skip checking the return code.
I think we want to know about any f
On Fri, 14 Jul 2023 at 14:34, wrote:
> On 2023-07-12 21:30, David G. Johnston wrote:
> > Right, and executeUpdate is the wrong API method to use, in the
> > PostgreSQL
> > world, when executing insert/update/delete with the non-SQL-standard
> > returning clause. ... ISTM that you are trying to ma
Hello
> The way we typically ship extensions in contrib/ is to not create a new base
> version .sql file for smaller changes like adding a few functions. For this
> patch we should keep --1.2.sql and instead supply a 1.2--1.3.sql with the new
> functions.
Thank you for pointing this out. It
On 2023-07-14 14:19, David G. Johnston wrote:
Is there some magic set of arguments I should be using besides: tcpdump
-Ar
filename ?
I opened it with Wireshark, which has a pgsql protocol decoder.
Regards,
-Chap
On 2023-07-12 21:30, David G. Johnston wrote:
Right, and executeUpdate is the wrong API method to use, in the
PostgreSQL
world, when executing insert/update/delete with the non-SQL-standard
returning clause. ... ISTM that you are trying to make user-error less
painful.
In Dave's Java reproduce
On Thu, 2023-05-18 at 16:49 -0400, Bruce Momjian wrote:
> I have completed the first draft of the PG 16 release notes.
The release notes still have:
- Have initdb use ICU by default if ICU is enabled in the binary (Jeff Davis)
Option --locale-provider=libc can be used to disable ICU.
But thi
On Fri, Jul 14, 2023 at 10:39 AM wrote:
> On 2023-07-14 12:58, Dave Cramer wrote:
> > See attached pcap file
>
> So if the fetch count is zero and no portal is needed,
> or if the fetch count exceeds the row count and the command
> completion follows directly with no suspension of the portal, the
On Thu, 2023-05-18 at 16:49 -0400, Bruce Momjian wrote:
> I have completed the first draft of the PG 16 release notes.
The release notes say:
- Prevent \df+ from showing function source code (Isaac Morland)
Function bodies are more easily viewed with \ev and \ef.
That should be \sf, not \ev
On Fri, 14 Jul 2023 at 13:39, wrote:
> On 2023-07-14 12:58, Dave Cramer wrote:
> > See attached pcap file
>
> So if the fetch count is zero and no portal is needed,
> or if the fetch count exceeds the row count and the command
> completion follows directly with no suspension of the portal, then
>
On 2023-07-14 12:58, Dave Cramer wrote:
See attached pcap file
So if the fetch count is zero and no portal is needed,
or if the fetch count exceeds the row count and the command
completion follows directly with no suspension of the portal, then
it comes with the correct count, but if the portal
See attached pcap file
after the execute of the portal it returns INSERT 0 0
Dave Cramer
On Fri, 14 Jul 2023 at 12:57, David G. Johnston
wrote:
> On Fri, Jul 14, 2023 at 9:50 AM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>>
>> Fixing that test in some manner and recompiling psq
On Fri, Jul 14, 2023 at 9:50 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> Fixing that test in some manner and recompiling psql seems like it should
> be the easiest way to produce a core-only test case.
>
>
Apparently not - since it (ExecQueryUsingCursor) literally wraps the query
On Fri, Jul 14, 2023 at 9:30 AM Dave Cramer wrote:
> David,
>
> I will try to get a tcpdump file. Doing this in libpq seems challenging as
> I'm not aware of how to create a portal in psql.
>
Yeah, apparently psql does something special (like ignoring it...) with its
FETCH_COUNT variable (set to
David,
I will try to get a tcpdump file. Doing this in libpq seems challenging as
I'm not aware of how to create a portal in psql.
Chap
The only difference is one instance uses a portal to fetch the results, the
other (correct one) is a normal insert where all of the rows are returned
immediatel
On 2023-07-12 20:57, Dave Cramer wrote:
Without a cursor it returns right away as all of the results are
returned
by the server. However with cursor you have to wait until you fetch the
rows before you can get the CommandComplete message which btw is wrong
as
it returns INSERT 0 0 instead of I
Richard Guo writes:
> So +1 to 0001 patch.
> Also +1 to 0002 patch.
Pushed, thanks for looking at it!
regards, tom lane
On Thu, Jul 13, 2023 at 6:07 PM Dave Cramer wrote:
> On Thu, 13 Jul 2023 at 10:24, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Thursday, July 13, 2023, Dave Cramer wrote:
>>
>>>
>>> Any comment on why the CommandComplete is incorrect ?
>>> It returns INSERT 0 0 if a cursor
On 7/14/23 16:42, Matthias van de Meent wrote:
> On Fri, 14 Jul 2023 at 16:21, Tomas Vondra
> wrote:
>>
>>
>>
>>
>> On 7/11/23 13:20, Matthias van de Meent wrote:
>>> On Mon, 10 Jul 2023 at 22:04, Tomas Vondra
>>> wrote:
Approximation in what sense? My understanding was we'd get a range o
Hi,
While looking at [1] I started to wonder why it is safe that
CreateCheckPoint() updates XLogCtl->RedoRecPtr after releasing the WAL
insertion lock:
/*
* Now we can release the WAL insertion locks, allowing other xacts to
* proceed while we are flushing disk buffers.
>Четверг, 6 июля 2023, 14:48 +03:00 от Peter Eisentraut < pe...@eisentraut.org
>>:
>
>On 22.06.23 22:56, Greg Sabino Mullane wrote:
>> * Do all of these transforms need to be their own contrib modules? So
>> much duplicated code across contrib/*_plperl already (and *plpython too
>> for that matt
Farias de Oliveira writes:
> 3905 elog(ERROR, "invalid perminfoindex %u in RTE with relid
> %u",
> (gdb) bt
> #0 getRTEPermissionInfo (rteperminfos=0x138a500, rte=0x138a6b0) at
> parse_relation.c:3905
> #1 0x00676e29 in GetResultRTEPermissionInfo
> (relinfo=relinfo@en
Hi,
As I think I mentioned before, I like this idea. However, I don't like the
implementation too much.
On 2023-06-15 13:11:57 +0530, Dilip Kumar wrote:
> diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> index b2430f617c..a025fb91e2 100644
> --- a/src/backen
On Fri, 14 Jul 2023 at 15:57, Tomas Vondra
wrote:
>
> On 7/11/23 23:11, Matthias van de Meent wrote:
>> On Thu, 6 Jul 2023 at 16:13, Tomas Vondra
>> wrote:
>>>
>>> One thing I was wondering about is whether it might be better to allow
>>> the workers to process overlapping ranges, and then let t
On 7/9/23 23:44, Tomas Vondra wrote:
> ...
>>> Yes, my previous message was mostly about backwards compatibility, and
>>> this may seem a bit like an argument against it. But that message was
>>> more a question "If we do this, is it actually backwards compatible the
>>> way we want/need?")
>>>
>>>
On Fri, 14 Jul 2023 at 16:21, Tomas Vondra
wrote:
>
>
>
>
> On 7/11/23 13:20, Matthias van de Meent wrote:
>> On Mon, 10 Jul 2023 at 22:04, Tomas Vondra
>> wrote:
>>> Approximation in what sense? My understanding was we'd get a range of
>>> distances that we know covers all rows in that range. So
On 7/14/23 16:02, Ashutosh Bapat wrote:
> ...
>
H, that might work. I feel a bit uneasy about having to keep all
relfilenodes, not just sequences ...
>>>
>>> From relfilenode it should be easy to get to rel and then see if it's
>>> a sequence. Only add relfilenodes for the se
Thanks Amit and Tom for the quick response. I have attached a file that
contains the execution of the code via GDB and also what the backtrace
command shows when it gets the error. If I forgot to add something or if it
is necessary to add anything else, please let me know.
Thank you,
Matheus Faria
On 7/11/23 13:20, Matthias van de Meent wrote:
> On Mon, 10 Jul 2023 at 22:04, Tomas Vondra
> wrote:
>> On 7/10/23 18:18, Matthias van de Meent wrote:
>>> On Mon, 10 Jul 2023 at 17:09, Tomas Vondra
>>> wrote:
On 7/10/23 14:38, Matthias van de Meent wrote:
>> I haven't really thought
On 7/14/23 15:50, Ashutosh Bapat wrote:
> On Fri, Jul 14, 2023 at 3:59 PM Tomas Vondra
> wrote:
>
>>
The new patch detects that, and triggers ERROR on the publisher. And I
think that's the correct thing to do.
>>>
>>> With this behaviour users will never be able to setup logical
On Fri, Jul 14, 2023 at 4:10 PM Tomas Vondra
wrote:
>
> I don't think that's true - this will create 1 record with
> "created=true" (the one right after the CREATE SEQUENCE) and the rest
> will have "created=false".
I may have misread the code.
>
> I realized I haven't modified seq_desc to show
On 7/11/23 23:11, Matthias van de Meent wrote:
> On Thu, 6 Jul 2023 at 16:13, Tomas Vondra
> wrote:
>>
>> On 7/5/23 16:33, Matthias van de Meent wrote:
>>> ...
>>>
Maybe. I wasn't that familiar with what parallel tuplesort can and can't
do, and the little I knew I managed to forget s
On Fri, Jul 14, 2023 at 3:59 PM Tomas Vondra
wrote:
>
> >>
> >> The new patch detects that, and triggers ERROR on the publisher. And I
> >> think that's the correct thing to do.
> >
> > With this behaviour users will never be able to setup logical
> > replication between old and new servers consi
fujii.y...@df.mitsubishielectric.co.jp писал 2023-07-10 10:35:
I have modified the program except for the point "if the version of
the remote server is less than PG17".
Instead, we have addressed the following.
"If check_partial_aggregate_support is true and the remote server
version is older tha
On 2023-06-29 Th 12:24, Jacob Champion wrote:
On 3/20/23 10:43, Tom Lane wrote:
I'd be more willing to consider the proposed patch if it weren't such
a hack --- as you say, it doesn't fix the problem when the table has
policies, so it's hardly a general-purpose solution. I fear that it's
also
Hello Fabien,
Thank you for your review!
On Mon, 3 Jul 2023 20:39:23 +0200 (CEST)
Fabien COELHO wrote:
>
> Yugo-san,
>
> Some feedback about v1 of this patch.
>
> Patch applies cleanly, compiles.
>
> There are no tests, could there be one? ISTM that one could be done with a
> "SELECT pg_sl
On Tue, Jul 11, 2023 at 4:31 PM Zhijie Hou (Fujitsu)
wrote:
>
> We have been researching how to create a test that detects failures resulting
> from future syntax changes, where the deparser fails to update properly.
>
> The basic idea comes from what Robert Haas suggested in [1]: when running the
On 7/14/23 09:34, Ashutosh Bapat wrote:
> On Thu, Jul 13, 2023 at 9:47 PM Tomas Vondra
> wrote:
>
>>
6) simplified protocol versioning
>>>
>>> I had tested the cross-version logical replication with older set of
>>> patches. Didn't see any unexpected behaviour then. I will test again
Peter Eisentraut writes:
> Ah, there was a reason. The headerscheck and cpluspluscheck targets
> need jsonpath_gram.h to be built first. Which previously happened
> indirectly somehow? I have fixed this in the new patch version. I also
> fixed the issue that Álvaro reported nearby.
Have we
Hi,
Amit Kapila , 14 Tem 2023 Cum, 11:11 tarihinde
şunu yazdı:
> Yeah, it is quite surprising that Design#2 is worse than master. I
> suspect there is something wrong going on with your Design#2 patch.
> One area to check is whether apply worker is able to quickly assign
> the new relations to ta
Hello Daniel,
Thanks for the explanation, it sounds reasonable. I'm glad it is not a bug.
Regards,
Martin.
On 14/07/2023 10:29, Daniel Gustafsson wrote:
On 14 Jul 2023, at 07:53, Martin Butter wrote:
While adapting a Java implementation of the SQL parser, I noticed that in
structures JsonArr
On 14.07.23 09:54, Peter Eisentraut wrote:
diff --git a/src/tools/pginclude/cpluspluscheck
b/src/tools/pginclude/cpluspluscheck
index 4e09c4686b..287395887c 100755
--- a/src/tools/pginclude/cpluspluscheck
+++ b/src/tools/pginclude/cpluspluscheck
@@ -134,6 +134,9 @@ do
test "$f" = src/inter
On Thu, 13 Jul 2023 at 20:14, Jeff Davis wrote:
>
> On Thu, 2023-07-13 at 18:01 +0100, Dean Rasheed wrote:
> > For some use cases, I can imagine allowing OLD/NEW.colname would mean
> > you wouldn't need pg_merge_action() (if the column was NOT NULL), so
> > I
> > think the features should work wel
Dear Amit, Sergei,
> > I think it's appropriate to add on the restrictions page. (But mentioning
> > that this
> restriction is only for subscriber)
> >
> > If the list were larger, then the restrictions page could be divided into
> > publisher
> and subscriber restrictions. But not for one very
> On 13 Jul 2023, at 22:52, Andres Freund wrote:
> On 2023-07-12 11:54:18 +0200, Daniel Gustafsson wrote:
>> Looking more at this I wonder if we in HEAD should make this a bit nicer by
>> extending the --check phase to catch this? I did a quick hack along these
>> lines in the 0003 commit attach
> On 14 Jul 2023, at 07:53, Martin Butter
> wrote:
> While adapting a Java implementation of the SQL parser, I noticed that in
> structures JsonArrayAgg, JsonArrayConstructor, JsonArrayQueryConstructor and
> JsonObjectConstrutor, the absent_on_null field defaults to TRUE.
> But in JsonObjectAg
On 2023-Jul-14, Peter Eisentraut wrote:
> diff --git a/src/backend/parser/Makefile b/src/backend/parser/Makefile
> index 9f1c4022bb..3d33b082f2 100644
> --- a/src/backend/parser/Makefile
> +++ b/src/backend/parser/Makefile
> @@ -64,8 +64,8 @@ scan.c: FLEX_FIX_WARNING=yes
> # Force these dependenc
Hi Kuroda-san.
Here are some review comments for the v17-0003 patch. They are all minor.
==
Commit message
1.
Previously tablesync workers establish new connections when it changes
the syncing
table, but this might have additional overhead. This patch allows to
reuse connections
instead.
~
On Thu, Jul 13, 2023 at 8:07 PM Önder Kalacı wrote:
>
> Looks good to me. I have also done some testing, which works as
> documented/expected.
>
Thanks, I have pushed this after minor changes in the comments.
--
With Regards,
Amit Kapila.
On Fri, Jul 14, 2023 at 1:58 AM Melih Mutlu wrote:
>
> Here are some quick numbers with 100 empty tables.
>
> +--++++
> | | 2 sync workers | 4 sync workers | 8 sync workers |
> +--++---
On 13.07.23 01:19, Andres Freund wrote:
One thing in particular that isn't clear right now is how "make world"
should behave if the documentation tools are not found. Maybe we should
make a build option, like "--with-docs", to mirror the meson behavior.
Isn't that somewhat unrelated to distpre
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Passes the default cases; Does not make any trivial changes to th
On Fri, Jul 14, 2023 at 5:44 AM Tom Lane wrote:
> I tried both of those and concluded they'd be too messy for a patch
> that we might find ourselves having to back-patch. So 0001 attached
> fixes it by teaching SS_finalize_plan to treat optimized MIN()/MAX()
> aggregates as if they were already
On Thu, Jul 13, 2023 at 9:47 PM Tomas Vondra
wrote:
>
> >>
> >> 6) simplified protocol versioning
> >
> > I had tested the cross-version logical replication with older set of
> > patches. Didn't see any unexpected behaviour then. I will test again.
> >>
>
> I think the question is what's the expe
74 matches
Mail list logo
