On Thu, Mar 23, 2023 at 2:15 AM Andres Freund wrote:
>
> Currently the new verify_heapam() follows ctid chains when XMAX_INVALID is
> set
> and expects to find an item it can dereference - but I don't think that's
> something we can rely on: Afaics HOT pruning can break chains, but doesn't
>
On Wed, Mar 22, 2023 at 4:06 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > The patch looks mostly good to me. However, I have one
> > question/comment as follows:
> >
> > -
> > +
> > binary (boolean)
> >
> >
> > To allow references to the binary option, we add the
>
>
> * No more dedicated struct to carry around the type of an update.
>
> We just use two boolean arguments to the pgstats function instead. The
> struct didn't seem to be adding much, and it was distracting to track
> the information this way within heap_update().
>
That's probably a good
At Wed, 22 Mar 2023 14:27:40 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Mon, 20 Mar 2023 13:46:51 -0400, "Gregory Stark (as CFM)"
> wrote in
> > Kyotoro Horiguchi, any chance you'll be able to work on this for this
> > commitfest? If so shout (or anyone else is planning to push it over
> >
Here are some review comments for patch v20-0001.
==
General.
1.
That function 'pg_get_publication_tables' does not seem to be
described in the PG documentation. Why isn't it in the "System Catalog
Information Functions" table [1] ?
I asked this same question a long time ago but then the
On Tue, 21 Mar 2023 23:16:25 +0100
Brar Piening wrote:
> On 17.01.2023 at 23:43, Karl O. Pinc wrote:
> > It's good you asked. After poking about the XSLT 1.0 spec to
> > refresh my memory I abandoned the "mode" approach entirely. The
> > real "right way" is to use the import mechanism.
>
On Thu, Mar 16, 2023 at 01:17:59PM +0530, Bharath Rupireddy wrote:
> FWIW, I rebased the tests tweaking patch and attached it here as v9.
> This should keep the pg_walinspect tests consistent across comments,
> spaces, new lines and using count(*) >= 1 for all successful function
> executions.
Hi Andres Freund
This patch improves performance significantly,Commitfest 2023-03 is coming
to an end,Is it not submitted yet since the patch still needs to be improved?
Best wish
发件人: Nathan Bossart
发送时间: 2023年2月21日 13:49
收件人: Bharath Rupireddy
抄送: Andres
Hi,
Commit dee663f7 made WAIT_EVENT_SLRU_FLUSH_SYNC redundant, so here's a
patch to remove it.
In case it's useful again, here's how I noticed:
for X in ` grep WAIT_EVENT_ src/include/utils/wait_event.h |
sed '/^#/d;s/,//;s/ = .*//' `
do
if ! ( git grep $X |
grep -v
On Thu, Mar 23, 2023 at 2:50 PM Thomas Munro wrote:
> In rem: commit 3500ccc3,
>
> for X in ` grep -E '^[^*]+event_name = "'
> src/backend/utils/activity/wait_event.c |
>sed 's/^.* = "//;s/";$//;/unknown/d' `
> do
> if ! git grep "$X" doc/src/sgml/monitoring.sgml > /dev/null
>
Hi!
Comments in src/backend/libpq/auth.c [1] say:
(after successfully finding the final DN to check the user-supplied
password against)
/* Unbind and disconnect from the LDAP server */
and later
/*
* Need to re-initialize the LDAP connection, so that we can bind to
* it with a different username.
On Monday, March 20, 2023 5:20 pmhouzj.f...@fujitsu.com wrote:
>
> On Thursday, March 16, 2023 12:30 PM Amit Kapila
> wrote:
>
> >
> > On Wed, Mar 15, 2023 at 2:00 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > I noticed that there are some duplicated codes in pgoutput_change()
> > function
Hi,
On 2023-03-22 13:45:52 -0700, Andres Freund wrote:
> On 2023-03-22 09:19:18 -0400, Robert Haas wrote:
> > On Fri, Mar 17, 2023 at 8:31 AM Aleksander Alekseev
> > wrote:
> > > The patch needed a rebase due to a4f23f9b. PFA v12.
> >
> > I have committed this after tidying up a bunch of things
Hi,
On 2023-03-21 01:25:11 +0300, Alexander Korotkov wrote:
> I'm going to push patchset v15 if no objections.
Just saw that this went in - didn't catch up with the thread before,
unfortunately. At the very least I'd like to see some more work on cleaning up
the lazy tuple slot stuff. It's
On Wed, Mar 22, 2023 at 05:14:08PM -0700, Peter Geoghegan wrote:
> * Small adjustments to the documentation.
>
> Nearby related items were tweaked slightly to make everything fit
> together a bit better. For example, the description of n_tup_hot_upd
> is revised to make it obvious that
On Wed, Mar 22, 2023 at 5:14 PM Michael Paquier wrote:
> On Wed, Mar 22, 2023 at 05:05:10PM -0700, Peter Geoghegan wrote:
> > I'd go further than that myself: I haven't had any use for FPIs at
> > all. If I was going to do something with FPIs then I'd just use
> > pg_waldump, since I'd likely
On Wed, Mar 22, 2023 at 05:05:10PM -0700, Peter Geoghegan wrote:
> I'd go further than that myself: I haven't had any use for FPIs at
> all. If I was going to do something with FPIs then I'd just use
> pg_waldump, since I'd likely want to get them onto the filesystem for
> analysis anyway. (Just
On Fri, Mar 17, 2023 at 3:22 PM Peter Geoghegan wrote:
> I think that this is pretty close to being committable already.
Attached revision has some small tweaks by me. Going to commit this
revised version tomorrow morning.
Changes:
* No more dedicated struct to carry around the type of an
On Tue, Mar 21, 2023 at 11:33 PM Michael Paquier wrote:
> > The new pg_get_wal_block_info outputs columns in an order that doesn't
> > seem like the most useful possible order to me. This gives us another
> > reason to have separate GetWALRecordInfo and GetWALBlockInfo utility
> > functions
On Wed, Mar 22, 2023 at 02:52:23PM -0400, Melanie Plageman wrote:
> This comment still has the t_ prefix as does the one for tuples_updated
> and deleted.
>
> otherwise, LGTM.
Good catch. pgstat_count_heap_update() has a t_tuples_hot_updated,
and pgstat_update_heap_dead_tuples() a
On Wed, Mar 22, 2023 at 8:35 AM Melanie Plageman
wrote:
> After reading what you said, I was interested to see how substantial the
> I/O cost with non-compressed FPI would be.
>
> Using a patch with a parameter to pg_get_wal_block_info() to skip
> outputting FPI, I found that on a fast local nvme
On Wed, Mar 22, 2023 at 4:46 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Wed, Mar 22, 2023 at 4:32 PM Eske Rahn wrote:
>
>> Hi,
>>
>> Thanks for the quick answer *:-D*
>>
>> That was a nice sideeffect of lateral.
>>
>> In the example, the calling code also gets simplified:
>>
On Wed, Mar 22, 2023 at 4:32 PM Eske Rahn wrote:
> Hi,
>
> Thanks for the quick answer *:-D*
>
> That was a nice sideeffect of lateral.
>
> In the example, the calling code also gets simplified:
>
> WITH x AS (
> SELECT clock_timestamp() rowstart, *, clock_timestamp() rowend FROM (
>
On Wed, Mar 22, 2023 at 02:21:12PM -0400, Melanie Plageman wrote:
> Apologies as I know this docs update has already been committed, but
> buffers fetched and blocks fetched both feel weird to me. If you have a
> cache hit, you don't end up really "fetching" anything at all (since
>
On Wed, Mar 22, 2023 at 05:18:28PM -0500, Justin Pryzby wrote:
> Wow, good point. I think to make it work we'd need put
> huge_pages_active into BackendParameters and handle it in
> save_backend_variables(). If so, that'd be strong argument for using a
> GUC, which already has all the necessary
On Wed, Mar 22, 2023 at 04:37:01PM +0900, Michael Paquier wrote:
> I have noted something.. For the WIN32 case, we have that:
>
> +++ b/src/backend/port/win32_shmem.c
> @@ -327,6 +327,8 @@ retry:
> Sleep(1000);
> continue;
> }
> +
> + huge_pages_active =
Hi,
On 2023-03-22 14:56:22 -0700, Andres Freund wrote:
> A patch addressing some, but not all, of those is attached. With that I don't
> see any crashes or false-positives anymore.
That patch missed that, as committed, the first if (ItemIdIsRedirected())
check sets lp_valid[n] = true even if the
Hi,
On 2023-03-22 13:45:52 -0700, Andres Freund wrote:
> On 2023-03-22 09:19:18 -0400, Robert Haas wrote:
> > On Fri, Mar 17, 2023 at 8:31 AM Aleksander Alekseev
> > wrote:
> > > The patch needed a rebase due to a4f23f9b. PFA v12.
> >
> > I have committed this after tidying up a bunch of things
On Tuesday, March 21, 2023, Eske Rahn wrote:
> Hi,
>
> I have noticed a rather odd behaviour that is not strictly a bug, but is
> unexpected.
>
> It is when a immutable (or stable) PG function is returning results in a
> record structure a select on these calls the function repeatedly for each
>
On Wed, Mar 22, 2023 at 2:14 PM Peter Geoghegan wrote:
> > Currently the new verify_heapam() follows ctid chains when XMAX_INVALID is
> > set
> > and expects to find an item it can dereference - but I don't think that's
> > something we can rely on: Afaics HOT pruning can break chains, but
> What about using an uint64 for calls? That seems more appropriate to me (even
> if
> queryDesc->totaltime->calls will be passed (which is int64), but that's
> already
> also the case for the "rows" argument and
> queryDesc->totaltime->rows_processed)
That's fair
> I'm not sure it's worth
Hi,
I have noticed a rather odd behaviour that is not strictly a bug, but is
unexpected.
It is when a immutable (or stable) PG function is returning results in a
record structure a select on these calls the function repeatedly for each
element in the output record.
See below for an example.
On Tue, Mar 21, 2023, at 8:18 AM, Amit Kapila wrote:
> Now, how do we avoid these problems even if we have our own version of
> functionality similar to pg_dump for selected objects? I guess we will
> face similar problems. If so, we may need to deny schema sync in any
> such case.
There are 2
On Wed, Mar 22, 2023 at 1:45 PM Andres Freund wrote:
> At the very least there's missing verification that tids actually exists in
> the
> "Update chain validation" loop, leading to:
> TRAP: failed Assert("ItemIdHasStorage(itemId)"), File:
>
Hi,
On 2023-03-22 09:19:18 -0400, Robert Haas wrote:
> On Fri, Mar 17, 2023 at 8:31 AM Aleksander Alekseev
> wrote:
> > The patch needed a rebase due to a4f23f9b. PFA v12.
>
> I have committed this after tidying up a bunch of things in the test
> case file that I found too difficult to
Andres Freund writes:
> This commit unfortunately broke --wal-segsize. If I use a slightly larger than
> the default setting, I get:
> initdb --wal-segsize 64 somepath
> running bootstrap script ... 2023-03-22 13:06:41.282 PDT [639848] FATAL:
> "min_wal_size" must be at least twice
Hi,
This commit unfortunately broke --wal-segsize. If I use a slightly larger than
the default setting, I get:
initdb --wal-segsize 64 somepath
running bootstrap script ... 2023-03-22 13:06:41.282 PDT [639848] FATAL:
"min_wal_size" must be at least twice "wal_segment_size"
Greetings,
Andres
On Wed, 2023-03-22 at 12:16 -0400, Robert Haas wrote:
> If nobody's too unhappy with the idea, I plan to commit this soon,
> both because I think that the feature is useful, and also because I
> think it's an important security improvement.
Is there any chance I can convince you to separate the
Peter Eisentraut writes:
> On 05.10.22 15:59, Tom Lane wrote:
>> What did you think of the compromise proposal to change only
>> the paths that pg_config outputs? I've not tried to code that,
>> but I think it should be feasible.
> I don't think I understand what this proposal actually means.
> On 22 Mar 2023, at 18:54, Robert Haas wrote:
> Basically, I think 0001 is a good idea -- I'm much more nervous about
> 0002. I think we should get 0001 polished up and committed.
Correct me if I'm wrong, but I believe you commented on v27-0001 of the login
event trigger patch series? Sorry
Robert Haas writes:
> I have committed this after tidying up a bunch of things in the test
> case file that I found too difficult to understand -- or in some cases
> just incorrect, like:
My animal mamba doesn't like this one bit.
I suspect the reason is that it's big-endian (PPC) and the
On Wed, 2023-03-22 at 14:42 -0400, Tom Lane wrote:
> This isn't going to help much unless we change the wire protocol
> so that RowDescription messages carry these UUIDs instead of
> (or in addition to?) the OIDs of the column datatypes. While
> that's not completely out of the question, it's a
Hi,
On 2023-03-20 10:32:49 -0700, Andres Freund wrote:
> On 2023-03-20 11:58:08 +0100, Peter Eisentraut wrote:
> > Oh, this patch set grew quite quickly. ;-)
>
> Yep :)
Unless somebody sees a reason to wait, I am planning to commit:
meson: add install-{quiet, world} targets
meson: add
On Mon, Mar 20, 2023 at 10:05:21AM +0100, Drouvot, Bertrand wrote:
> Hi,
>
> On 3/20/23 8:32 AM, Michael Paquier wrote:
> >
> > /* Total time previously charged to function, as of function start
> > */
> > - instr_time save_f_total_time;
> > + instr_time
Jeff Davis writes:
> On Wed, 2023-03-22 at 10:21 +0100, Peter Eisentraut wrote:
>> I've been thinking that we need some new kind of identifier to allow
>> clients to process types in more sophisticated ways.
>> For example, each type could be (self-)assigned a UUID, which is fixed
>> for that
I wrote:
> Peter Eisentraut writes:
>> I would remove the
>> #if DEF_PGPORT != 5432
>> This was in the previous code too, but now if we remove it, then we
>> don't have any more hardcoded 5432 left, which seems like a nice
>> improvement in cleanliness.
> Hm. That'll waste a few cycles during
On Mon, Mar 20, 2023 at 6:58 AM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 3/20/23 12:43 AM, Michael Paquier wrote:
> > At the
> > end, documenting both still sounds like the best move to me.
>
> Agree.
>
> Please find attached
> v1-0001-pg_stat_get_xact_blocks_fetched-and_hit-doc.patch doing so.
>
In the previous version, I didn't notice (unlike cfbot) the compiler
warning. Fixed in version 6.
-
Pavel Luzanov
From 1b8b5743df23637b70e8d4ad0df0e1f892c595f3 Mon Sep 17 00:00:00 2001
From: Pavel Luzanov
Date: Wed, 22 Mar 2023 20:54:41 +0300
Subject: [PATCH v6] psql: show membership
On Tue, 2023-03-21 at 10:35 +0100, Peter Eisentraut wrote:
> [PATCH v6 1/6] Support language tags in older ICU versions (53 and
> earlier).
>
> In pg_import_system_collations(), this is now redundant and can be
> simplified:
>
> - if (!pg_is_ascii(langtag) ||
On Wed, 2023-03-22 at 10:12 +0100, Peter Eisentraut wrote:
> Sending type names is kind of useless if what comes back with the
> result
> (RowDescription) are OIDs anyway.
>
> The client would presumably have some code like
>
> if (typeoid == 555)
> parseThatType();
>
> So it already
> > Yes. Do we have any concrete use case where the subscriber is an older
> > version, in the first place?
> >
>
> As per my understanding, it is mostly due to the reason that it can
> work today. Today, during an off-list discussion with Jonathan on this
> point, he pointed me to a similar
On Wed, 2023-03-22 at 10:21 +0100, Peter Eisentraut wrote:
> I've been thinking that we need some new kind of identifier to allow
> clients to process types in more sophisticated ways.
>
> For example, each type could be (self-)assigned a UUID, which is
> fixed
> for that type no matter in
On Tue, Mar 15, 2022 at 4:52 PM Daniel Gustafsson wrote:
> Yeah, that was the previously posted v25 from the author (who adopted it from
> the original author). I took the liberty to quickly poke at the review
> comments you had left as well as the ones that I had found to try and progress
> the
Hi,
Tom, see below - I wonder if should provide one more piece of infrastructure
around the saved error stuff...
Have you measured whether this has negative performance effects when *NOT*
using the new option?
As-is this does not work with FORMAT BINARY - and converting the binary input
On Mon, Mar 20, 2023 at 7:34 PM Peter Geoghegan wrote:
> On Sun, Mar 19, 2023 at 8:21 PM Kyotaro Horiguchi
> wrote:
> > It is not an issue with this patch, but as I look at this version, I'm
> > starting to feel uneasy about the subtle differences between what
> > GetWALRecordsInfo and
On Tue, Mar 21, 2023 at 7:59 PM Michael Paquier wrote:
> On Mon, Mar 20, 2023 at 07:56:42AM -0400, Robert Haas wrote:
> > Anyone want to comment on this?
>
> I have not checked the patch in details, but perhaps this needs at
> least one test?
Sure. I was sort of hoping to get feedback on the
Peter Eisentraut writes:
> This patch looks good to me. It's a very nice simplification of the
> initdb.c code, even without the new feature.
Thanks for looking!
> I found that the addition of
> #include
> didn't appear to be necessary. Maybe it was required before
>
On 2023-03-22 09:58:58 -0400, Robert Haas wrote:
> On Wed, Mar 22, 2023 at 1:12 AM Andres Freund wrote:
> > Patch with the two minimal fixes attached. As we don't know whether it's
> > worth
> > changing the strategy, the more minimal fixes seem more appropriate.
>
> LGTM.
Thanks for checking.
Hi,
On 2023-03-22 11:44:20 -0500, Justin Pryzby wrote:
> On Sat, Mar 18, 2023 at 10:33:57AM +0100, Alvaro Herrera wrote:
> > On 2023-Mar-17, Andres Freund wrote:
> >
> > > I started writing a test for vacuum_defer_cleanup_age while working on
> > > the fix
> > > referenced above, but now I am
On Sat, Mar 18, 2023 at 10:33:57AM +0100, Alvaro Herrera wrote:
> On 2023-Mar-17, Andres Freund wrote:
>
> > I started writing a test for vacuum_defer_cleanup_age while working on the
> > fix
> > referenced above, but now I am wondering if said energy would be better
> > spent
> > removing
On Wed, Mar 22, 2023 at 11:35 AM Melanie Plageman
wrote:
>
> On Fri, Mar 17, 2023 at 8:51 PM Michael Paquier wrote:
> >
> > On Fri, Mar 17, 2023 at 04:36:58PM -0700, Peter Geoghegan wrote:
> > > I'm sure that they will do that much more than they would have
> > > otherwise. Since we'll have made
>Среда, 22 марта 2023, 12:45 +03:00 от Daniel Gustafsson :
>
>> On 18 Mar 2023, at 23:25, Иван Панченко < w...@mail.ru > wrote:
>>
>> Hi,
>> PostgreSQL passes bytea arguments to PL/Perl functions as hexadecimal
>> strings, which is not only inconvenient, but also memory and time consuming.
On Wed, Mar 8, 2023 at 2:47 PM Andres Freund wrote:
> Hm - it still feels wrong that we error out in case of failure, despite the
> comment to the function saying:
> * Returns NULL on error and fills the err with palloc'ed error message.
I've amended the comment so that it explains why it's
On 31.01.23 15:00, Onur Tirtir wrote:
We use Valgrind --together with the suppression file provided in
Postgres repo-- to test Citus extension against memory errors.
We replace /bin/postgres executable with a simple bash script that
executes the original postgres executable under Valgrind and
On Fri, Mar 17, 2023 at 8:51 PM Michael Paquier wrote:
>
> On Fri, Mar 17, 2023 at 04:36:58PM -0700, Peter Geoghegan wrote:
> > I'm sure that they will do that much more than they would have
> > otherwise. Since we'll have made pg_get_wal_block_info() so much more
> > useful than
On 22.03.23 11:16, Nazir Bilal Yavuz wrote:
Hi,
On Wed, 15 Mar 2023 at 11:12, Peter Eisentraut
wrote:
On 14.03.23 15:07, Nazir Bilal Yavuz wrote:
I think the uuid side of this is making this way too complicated. I'm
content leaving this as a manual option for now.
There is much more value
Hi,
I noticed that the patchset didn't make much progress since February
and decided to give it another round of code review.
> [...]. But in general, end-of-transaction activities should be kept
> simple, especially between the release phases, so I feel that having to
> remember extra resources
On 3/22/23 2:48 AM, Michael Paquier wrote:
On Tue, Feb 14, 2023 at 06:16:18PM -0500, Jonathan S. Katz wrote:
I opted for the approach in [2]. v5 contains the branching logic for the
UTF8 only tests, and the corresponding output files. I tested locally on
macOS against both UTF8 + C locales.
On Wed, Mar 22, 2023 at 1:12 AM Andres Freund wrote:
> Patch with the two minimal fixes attached. As we don't know whether it's worth
> changing the strategy, the more minimal fixes seem more appropriate.
LGTM.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Mar 22, 2023 at 2:16 PM Amit Kapila wrote:
>
> On Wed, Mar 22, 2023 at 8:29 AM Masahiko Sawada wrote:
> >
> > On Tue, Mar 21, 2023 at 8:18 PM Amit Kapila wrote:
> > >
> > > On Tue, Mar 21, 2023 at 7:32 AM Euler Taveira wrote:
> > >
> > > > You should
> > > > exclude them removing these
On 2023-03-17 21:23, torikoshia wrote:
On 2023-03-07 18:09, Daniel Gustafsson wrote:
On 7 Mar 2023, at 09:35, Damir Belyalov wrote:
I felt just logging "Error: %ld" would make people wonder the meaning
of
the %ld. Logging something like ""Error: %ld data type errors were
found" might be
On Fri, Mar 17, 2023 at 8:31 AM Aleksander Alekseev
wrote:
> The patch needed a rebase due to a4f23f9b. PFA v12.
I have committed this after tidying up a bunch of things in the test
case file that I found too difficult to understand -- or in some cases
just incorrect, like:
elsif ($offnum
Thanks for the review!
On Tue, 2023-03-21 at 16:32 +0100, Christoph Berg wrote:
> I have some comments:
>
> > This allows EXPLAIN to generate generic plans for parameterized statements
> > (that have parameter placeholders like $1 in the statement text).
>
> > +
> > + GENERIC_PLAN
> > +
Rebased after conflicts with bfc9497ece01c7c45437bc36387cb1ebe346f4d2
Also included the fix for feedback from Daniel on patch 2, which he
had shared in the load balancing thread.
On Wed, 15 Mar 2023 at 09:49, Jelte Fennema wrote:
>
> The rebase was indeed trivial (git handled everything
> While not the fault of this patch I find it confusing that we mix
> and for marking up "postgres_fdw", the latter seemingly more correct
> (and less commonly used) than .
I think we traditionally use for an extension module (file)
name. It seems the is used when we want to refer to objects
Rebased patch after conflicts with bfc9497ece01c7c45437bc36387cb1ebe346f4d2
v14-0001-libpq-Run-pgindent-after-a9e9a9f32b3.patch
Description: Binary data
v14-0002-Refactor-libpq-to-store-addrinfo-in-a-libpq-owne.patch
Description: Binary data
v14-0003-Support-load-balancing-in-libpq.patch
Em qua., 22 de mar. de 2023 às 07:01, Daniel Gustafsson
escreveu:
> > On 19 Mar 2023, at 23:41, Michael Paquier wrote:
> >
> > On Fri, Mar 17, 2023 at 12:19:56PM -0300, Ranier Vilela wrote:
> >> Rebased to latest Head.
> >
> > I was looking at this thread, and echoing Daniel's and Alvaro's
> >
If I recall the protocol-extension design correctly, such a setting
could only be set at session start, which could be annoying --- at the
very least we'd have to tolerate entries for unrecognized data types,
since clients couldn't be expected to have checked the list against
the current server in
If there's some extension that offers type "mytype", and perhaps allows
it to be installed in any schema, then it seems that the client library
would know how to parse all instances of "mytype" regardless of the
schema or search_path.
I may be overthinking this.
Dave Cramer
On Tue, 21 Mar 2023
> On 22 Mar 2023, at 12:58, Etsuro Fujita wrote:
>
> On Fri, Feb 17, 2023 at 5:45 PM Etsuro Fujita wrote:
>> Here is a small patch to improve the note, which was added by commit
>> 97da48246 ("Allow batch insertion during COPY into a foreign table."),
>> by adding an explanation about how the
> On Fri, Feb 17, 2023 at 5:45 PM Etsuro Fujita wrote:
>> Here is a small patch to improve the note, which was added by commit
>> 97da48246 ("Allow batch insertion during COPY into a foreign table."),
>> by adding an explanation about how the actual number of rows
>> postgres_fdw inserts at once
On Fri, Feb 17, 2023 at 5:45 PM Etsuro Fujita wrote:
> Here is a small patch to improve the note, which was added by commit
> 97da48246 ("Allow batch insertion during COPY into a foreign table."),
> by adding an explanation about how the actual number of rows
> postgres_fdw inserts at once is
On Wed, Mar 22, 2023 at 4:50 PM David Rowley wrote:
> And now it just clicked with me why Tom left this. Sorry for stepping
> on your toes here.
No problem at all.
Best regards,
Etsuro Fujita
> On 22 Mar 2023, at 04:19, Hayato Kuroda (Fujitsu)
> wrote:
> I have also grepped to detect another wrong markups, and I think at least
> "PostgreSQL" should be changed. PSA the patch.
I agree with that analysis, this instance should be marked up with
but not the other ones. I'll go ahead
On Wed, 22 Mar 2023 at 10:42, Peter Eisentraut
wrote:
>
> On 21.03.23 18:46, Andres Freund wrote:
> > FWIW, I think we should consider getting rid of attcacheoff. I doubt it's
> > worth its weight these days, because deforming via slots starts at the
> > beginning anyway. The overhead of
Hi,
On 3/21/23 2:16 PM, Imseih (AWS), Sami wrote:
This indeed feels a bit more natural seen from here, after looking at
the code paths using an Instrumentation in the executor and explain,
for example. At least, this stresses me much less than adding 16
bytes to EState for something restricted
> From: Amit Kapila
> Sent: Wednesday, March 22, 2023 5:16 AM
> To: Masahiko Sawada
> Cc: Euler Taveira ; Kumar, Sachin
> ; Alvaro Herrera ; pgsql-
> hack...@lists.postgresql.org; Jonathan S. Katz
> Subject: RE: [EXTERNAL]Initial Schema Sync for Logical Replication
>
> CAUTION: This email
Dear Amit, hackers,
> The patch looks mostly good to me. However, I have one
> question/comment as follows:
>
> -
> +
> binary (boolean)
>
>
> To allow references to the binary option, we add the varlistentry id
> here. It looks slightly odd to me to add id for
> On 22 Mar 2023, at 10:39, Peter Eisentraut
> wrote:
> Personally, if a patch isn't rebased up to the minute doesn't bother me at
> all. It's easy to check out as of when the email was sent (or extra bonus
> points for using git format-patch --base). Now, rebasing every month or so
> is
On Mon, 20 Mar 2023 17:05:41 +0900 (JST)
Kyotaro Horiguchi wrote:
> I found an error message added by de4d456b406bf502341ef526710d3f764b41e2c8.
>
> When I incorrectly configured the primary_conninfo with the wrong
> user, I received the following message on the server logs of both
> servers
Hi,
On Wed, 15 Mar 2023 at 11:12, Peter Eisentraut
wrote:
>
> On 14.03.23 15:07, Nazir Bilal Yavuz wrote:
> >> I think the uuid side of this is making this way too complicated. I'm
> >> content leaving this as a manual option for now.
> >>
> >> There is much more value in making the ssl option
One last ping, hoping someone will have more time now than in january.
Perhaps my test is wrong, but I'd like to know why.
Thanks.
Le mar. 17 janv. 2023 à 16:53, Guillaume Lelarge a
écrit :
> Quick ping, just to make sure someone can get a look at this issue :)
> Thanks.
>
>
> Le ven. 6 janv.
On Wed, Mar 22, 2023 at 14:32 PM Kuroda, Hayato/黒田 隼人
wrote:
> Dear Wang,
>
> Thank you for updating patch! Following are comments form v19-0001.
Thanks for your comments.
> 01. logical-replication.sgml
>
> I found a following statement in logical-replication.sgml. I think this may
> cause
On Wed, Mar 22, 2023 at 12:50 PM Peter Smith wrote:
> Here are some review comments for patch code of HEAD_v19-0001
Thanks for your comments.
> ==
> doc/src/sgml/ref/create_publication.sgml
>
> 1.
> +
> + There can be a case where a subscription combines multiple
> +
> On 19 Mar 2023, at 23:41, Michael Paquier wrote:
>
> On Fri, Mar 17, 2023 at 12:19:56PM -0300, Ranier Vilela wrote:
>> Rebased to latest Head.
>
> I was looking at this thread, and echoing Daniel's and Alvaro's
> arguments, I don't quite see why this patch is something we need. I
> would
On Wed, Mar 22, 2023 at 9:00 AM shiy.f...@fujitsu.com
wrote:
>
> On Wed Mar 22, 2023 7:29 AM Peter Smith wrote:
> >
> > Thanks for all the patch updates. Patch v19 LGTM.
> >
>
> +1
>
The patch looks mostly good to me. However, I have one
question/comment as follows:
-
+
On 18.03.23 00:54, Andres Freund wrote:
I think a good compromise would be buildtype=debugoptimized, which is -O2
with debug symbols, which also sort of matches the default in the autoconf
world.
Looks like that'd result in a slightly worse build with msvc, as afaict we
wouldn't end up with
> On 18 Mar 2023, at 23:25, Иван Панченко wrote:
>
> Hi,
> PostgreSQL passes bytea arguments to PL/Perl functions as hexadecimal
> strings, which is not only inconvenient, but also memory and time consuming.
> So I decided to propose a simple transform extension to pass bytea as native
> Perl
On 21.03.23 18:46, Andres Freund wrote:
FWIW, I think we should consider getting rid of attcacheoff. I doubt it's
worth its weight these days, because deforming via slots starts at the
beginning anyway. The overhead of maintaining it is not insubstantial, and
it's just architecturally ugly to to
On 21.03.23 10:59, Alvaro Herrera wrote:
This led me to suggesting that perhaps we need to be more lenient when
it comes to new contributors. As I said, for seasoned contributors,
it's not a problem to keep up with our requirements, however silly they
are. But people who spend their evenings a
1 - 100 of 125 matches
Mail list logo
