On Thur, Sep 23, 2021 11:06 AM Greg Nancarrow wrote:
> On Wed, Sep 22, 2021 at 9:33 PM houzj.f...@fujitsu.com
> wrote:
> >
> > >
> > > How do you suggest changing it?
> >
> > Personally, I think we'd better move the code about changing
> > publication's tablelist into AlterPublicationTables and
Hi, guys, I encount a problem on compiling pssql, the environment is:
os: macos big sur version 11.5.2 (20G95)
compiler: gcc-11 (Homebrew GCC 11.2.0) 11.2.0
error message:
/usr/local/bin/gcc-11 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmi
Andrew Dunstan 于2021年3月28日周日 下午9:07写道：
>
> On 3/17/21 7:59 AM, wenjing wrote:
> > ok
> >
> > The cause of the problem is that the name of the dependent function
> > (readNextTransactionID) has changed. I fixed it.
> >
> > This patch(V43) is base on 9fd2952cf4920d563e9cea51634c5b364d57f71a
> >
> >
Hi,
On 23.09.2021 10:09, zhang listar wrote:
> Hi, guys, I encount a problem on compiling pssql, the environment is:
> os: macos big sur version 11.5.2 (20G95)
> compiler: gcc-11 (Homebrew GCC 11.2.0) 11.2.0
I've just tried building with gcc-11 on Catalina (yes, it's time to
upgrade) and it went
Thanks for your reply, I do make distclean and git clean -fdx, but it does
no help.
the code: master, c7aeb775df895db240dcd6f47242f7e08899adfb
It looks like the macos issue, because of the ignoring of some lib, it
drives the compiling error.
Sergey Shinderuk 于2021年9月23日周四 下午3:35写道：
> Hi,
>
> On
On Thu, Sep 23, 2021 at 5:02 PM houzj.f...@fujitsu.com
wrote:
>
> > Sounds like a good idea.
> > Is it possible to incorporate the existing
> > CheckPublicationAlterTables() and CheckPublicationAlterSchemas() functions
> > into your suggested update?
> > I think it might tidy up the error-checking
On 23.09.2021 10:50, zhang listar wrote:
> Thanks for your reply, I do make distclean and git clean -fdx, but it
> does no help.
>
> the code: master, c7aeb775df895db240dcd6f47242f7e08899adfb
> It looks like the macos issue, because of the ignoring of some lib, it
> drives the compiling error.
M
Hi John,
> Any thoughts on the doc patch?
It so happened that I implemented a similar feature in TimescaleDB [1].
I discovered that it's difficult from both developer's and user's
perspectives to think about the behavior of the function in the
context of given TZ and its complicated rules, as yo
Thanks. It is the binuitls problem. I do "brew uninstall binutils" and
compile successfully.
Actually it is the lib $(which ranlib) -V problem.
The similar issue here: https://github.com/bitcoin/bitcoin/issues/20825
Sergey Shinderuk 于2021年9月23日周四 下午4:03写道：
> On 23.09.2021 10:50, zhang listar wro
On Thu, Sep 23, 2021 at 4:58 AM Thomas Munro wrote:
>
> One small detail I'd like to draw attention to is this bit, which
> differs slightly from the [non-working] previous attempts by mapping
> to two different errors:
>
> + * If there's no O_CREAT flag, then we'll pretend the file is
>
Hi Tom,
On Wed, 22 Sep 2021, at 17:09, Tom Lane wrote:
> > The main change is a switch to using SPI for expression evaluation. The
> > plans are also cached along the same lines as the RI trigger plans.
>
> I really dislike this implementation technique. Aside from the likely
> performance hit
On Fri, Sep 17, 2021 at 9:36 AM vignesh C wrote:
>
> On Thu, Sep 16, 2021 at 7:20 PM Alvaro Herrera
> wrote:
> >
> > On 2021-Sep-16, vignesh C wrote:
> >
> > > diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
> > > index e3068a374e..c50bb570ea 100644
> > > --- a/src/backend/par
>
> What kind of reasons do you see where users prefer to delay except to
> avoid data loss in the case where users unintentionally removed some
> data from the primary?
>
>
> Debugging. Suppose I have a problem, but that problem occurs once a week
or a month. When this problem occurs again a moni
On 30.07.21 20:26, Tomas Vondra wrote:
Here's a an updated version of this patch - rebased to current master,
and fixing some of the issues raised in Peter's review.
This patch needs an update, as various conflicts have arisen now.
As was discussed before, it might be better to present a separ
On Wed, Sep 22, 2021 at 03:18:43PM +, Jacob Champion wrote:
> On Wed, 2021-09-22 at 10:20 +0200, Peter Eisentraut wrote:
>> This should be added to each level of a function call that represents a
>> test. This ensures that when a test fails, the line number points to
>> the top-level locatio
Em ter., 21 de set. de 2021 às 20:12, Ranier Vilela
escreveu:
> Em ter., 21 de set. de 2021 às 19:21, Tom Lane
> escreveu:
>
>> Andres Freund writes:
>> > On 2021-09-21 15:09:11 -0300, Ranier Vilela wrote:
>> >> Currently when determining where CoerceToDomainValue can be read,
>> >> it evaluate
On Tue, Sep 7, 2021 at 11:40 PM Victor Spirin
wrote:
>
> I checked the pgrename_windows_posix_semantics() function on Windows 7.
> It returns error 87: Parameter is incorrect. Hence, it is necessary to
> check the Windows version and call the old pgrename function for old
> Windows.
>
> The FILE_
On Wed, Sep 8, 2021 at 9:40 AM Victor Spirin wrote:
> Is this code better? Maybe there is another correct method?
Hmm, if we want to use the system header's struct definition, add some
space for a path at the end, and avoid heap allocation, perhaps we
could do something like:
struct {
FILE_R
On Wed, Sep 22, 2021 at 02:14:59PM +0530, Amit Kapila wrote:
> On Wed, Sep 22, 2021 at 11:14 AM Noah Misch wrote:
> > +1, great win for a one-liner.
>
> +1. It reduced the build time of Postgres from "Time Elapsed
> 00:01:57.60" to "Time Elapsed 00:01:38.11" in my Windows env. (Win 10,
> MSVC 201
Hi hackers,
> the function works as if it was timestamp. E.g. time_bucket_ng("3
> month", "2021 Oct 03 12:34:56 TZ") = "2021 Jan 01 00:00:00 TZ" no
That was a typo. What I meant was:
time_bucket_ng("3 month", "2021 Feb 03 12:34:56 TZ")
February, not October. Sorry for the confusion.
--
Best r
Hi,
I finally had time to take a closer look at the patch again, so here's
some review comments. The thread is moving fast, so chances are some of
the comments are obsolete or were already raised in the past.
1) I wonder if we should use WHERE or WHEN to specify the expression.
WHERE is not
On Wed, Sep 22, 2021 at 11:01 PM Tom Lane wrote:
>
> Magnus Hagander writes:
> > On Wed, Sep 22, 2021 at 6:30 PM Tom Lane wrote:
> >> I thought the point about FDWs was important because actual work (by
> >> FDW authors) is needed to make anything happen. The extra parallelism
> >> inside plpgs
Page explaining progress reporting views, for all versions, have "The
tables" expression several times when it points to a single table. So,
singular expressions should be used, right ?
"The tables below describe the information that will be reported and
provide information about how to interpret
Em qui., 23 de set. de 2021 às 09:41, Marcos Pegoraro
escreveu:
> Page explaining progress reporting views, for all versions, have "The
> tables" expression several times when it points to a single table. So,
> singular expressions should be used, right ?
>
> "The tables below describe the inform
On Thu, Sep 23, 2021 at 07:37:27AM +0100, Simon Riggs wrote:
> On Thu, 16 Sept 2021 at 05:33, Julien Rouhaud wrote:
>
> > Would any of that be a reasonable approach?
>
> The way I summarize all of the above is that
> 1) nobody is fundamentally opposed to the idea
> 2) we just need to find real-w
>
>
> Page explaining progress reporting views, for all versions, have "The
>> tables" expression several times when it points to a single table. So,
>> singular expressions should be used, right ?
>>
>> "The tables below describe the information that will be reported and
>> provide information abo
Em qui., 23 de set. de 2021 às 10:37, Marcos Pegoraro
escreveu:
>
>> Page explaining progress reporting views, for all versions, have "The
>>> tables" expression several times when it points to a single table. So,
>>> singular expressions should be used, right ?
>>>
>>> "The tables below describe
On Wed, Sep 22, 2021 at 9:46 PM Fabrice Chapuis wrote:
>
> If you would like I can test the patch you send to me.
>
Okay, please find an attached patch for additional logs. I would like
to see the logs during the time when walsender appears to be writing
to files. We might need to add more logs t
> *Table 27.32. pg_stat_progress_analyze View*
> and
> *Table 27.33. ANALYZE phases*
>
you´re right, I didn´t see that always have a phases table later. sorry ...
Hi Wenjing
we have reviewed the code, and done the regression tests, all tests is pass,
we believe the feature code quality is ready for production ; and I will change
the status to "Ready for commit"
Julien Rouhaud writes:
> My POC's grammar is only like:
> CREATE HYPOTHETICAL INDEX opt_index_name ON relation_expr '(' index_params ')'
> {
> IndexStmt *n = makeNode(IndexStmt);
> n->idxname = $4;
> n->relation = $6;
> n->accessMethod
On Thu, Sep 23, 2021 at 4:13 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
>
> Hi John,
>
> > Any thoughts on the doc patch?
>
> It so happened that I implemented a similar feature in TimescaleDB [1].
>
> I discovered that it's difficult from both developer's and user's
> perspectives t
On Thu, Sep 23, 2021 at 2:55 AM tushar wrote:
> l checked and look like the issue is still not fixed against v7-* patches -
>
> postgres=# create subscription test CONNECTION 'host=127.0.0.1 user=edb
> dbname=postgres' PUBLICATION p with (create_slot = true);
> ERROR: could not create replicati
On Wed, Sep 22, 2021 at 12:41 PM Jeevan Ladhe
wrote:
> If I set prefs->autoFlush to 0, then LZ4F_compressUpdate() returns an
> error: ERROR_dstMaxSize_tooSmall after a few iterations.
>
> After digging a bit in the source of LZ4F_compressUpdate() in LZ4 repository,
> I
> see that it throws this e
Thanks for your patch, we are going to set up a lab in order to debug the
function.
Regards
Fabrice
On Thu, Sep 23, 2021 at 3:50 PM Amit Kapila wrote:
> On Wed, Sep 22, 2021 at 9:46 PM Fabrice Chapuis
> wrote:
> >
> > If you would like I can test the patch you send to me.
> >
>
> Okay, please f
On Wed, Sep 22, 2021 at 10:28 AM Nitin Jadhav
wrote:
> Thanks Justin for the detailed explanation. Done the necessary changes.
Not really. The documentation here does not make a ton of sense:
+ Sets the time interval between each progress update of the operations
+ performed by
I wrote:
> I think you have a point that it could be stated more simply and
generally. I'll try to move in that direction.
On second thought, I don't think this is helpful. Concrete examples are
easier to reason about.
--
John Naylor
EDB: http://www.enterprisedb.com
This took some time because backpatching the tests was more work than I
anticipated -- function name changes, operators that don't exist,
definition of the WAL segment size in pg_settings. I had to remove the
second test in branches 13 and earlier due to lack of LSN+bytes
operator. Fortunately, t
On Tue, Sep 21, 2021 at 11:53 PM Michael Paquier wrote:
> I am not sure either as that's a tradeoff between an underestimation
> and no information. The argument of consistency indeed matters.
> Let's see if others have any opinion to share on this point.
Well, if we think the information won't
Hi,
I've pushed both of these patches, with some minor tweaks (freeing the
statistics list, and deleting the new context), and backpatched them all
the way to 10.
Thanks for the report & patch, Justin!
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgre
On Wed, Sep 22, 2021 at 12:00 PM Jonathan S. Katz wrote:
> - Numerous performance ...
> - B-tree...
> - Subscripting ...
> - Range types ...
> - Stored ...
> - Extended ...
> - SEARCH / CYCLE ...
> - libpq ...
> - TOAST ...
> (- emergency mode vacuum ...)
My opinion is that this is awfully long f
Hi,
I did a bit of testing today and noticed that we don't set indexlist properly
at the right time in some cases when using partitioned tables.
I attached a simple case where the indexlist doesn't seems to be set at the
right time. get_relation_info in plancat.c seems to process it only afte
On Sun, 12 Sept 2021 at 22:10, Justin Pryzby wrote:
>
> On Tue, Jul 20, 2021 at 08:27:02PM -0400, Alvaro Herrera wrote:
> > I have to wonder if there really *is* a use case for CLUSTER in the
> > first place on regular tables, let alone on partitioned tables, which
> > are likely to be large and t
On 2021-Sep-23, Jeremy Schneider wrote:
> On 9/22/21 20:11, Amit Kapila wrote:
> >
> > On Thu, Sep 23, 2021 at 3:06 AM Jeremy Schneider
> > wrote:
> >>
> >> Any chance of back-patching this?
> >
> > Normally, we don't back-patch code improvements unless they fix some
> > bug or avoid future ba
On Mon, Sep 20, 2021 at 11:20 AM Amul Sul wrote:
> Ok, understood, I have separated my changes into 0001 and 0002 patch,
> and the refactoring patches start from 0003.
I think it would be better in the other order, with the refactoring
patches at the beginning of the series.
> In the 0001 patch,
On HEAD, I see these headers failing to compile standalone:
$ src/tools/pginclude/cpluspluscheck
In file included from /tmp/cpluspluscheck.XxTv1i/test.cpp:3:
./src/include/common/unicode_east_asian_fw_table.h:3:32: error: elements of
array 'const mbinterval east_asian_fw []' have incomplete type
> On 22 Sep 2021, at 10:06, Daniel Gustafsson wrote:
> Agreed, I will go ahead and prep backpatches for 318df8 and 72bbff4cd.
These commits are enough to keep 14 happy, and I intend to apply them tomorrow
after another round of testing and caffeine.
For the 13- backbranches we also need to back
On Wed, Sep 22, 2021 at 3:07 PM Shruthi Gowda wrote:
> > - The comment in binary_upgrade_set_pg_class_oids() is still not
> > accurate. You removed the sentence which says "Indexes cannot have
> > toast tables, so we need not make this probe in the index code path"
> > but the immediately precedin
On Thu, Sep 23, 2021 at 2:37 PM Tom Lane wrote:
>
> On HEAD, I see these headers failing to compile standalone:
>
> $ src/tools/pginclude/cpluspluscheck
> In file included from /tmp/cpluspluscheck.XxTv1i/test.cpp:3:
> ./src/include/common/unicode_east_asian_fw_table.h:3:32: error: elements
of arra
Hi,
I wanted to do a review of this patch, but I'm a bit confused about
which patch(es) to review. There's the v5 patch, and then these two
patches - which seem to be somewhat duplicate, though.
Can anyone explain what's the "current" patch version, or perhaps tell
me which of the patches to
John Naylor writes:
> On Thu, Sep 23, 2021 at 2:37 PM Tom Lane wrote:
>> On HEAD, I see these headers failing to compile standalone:
>> $ src/tools/pginclude/cpluspluscheck
>> In file included from /tmp/cpluspluscheck.XxTv1i/test.cpp:3:
>> ./src/include/common/unicode_east_asian_fw_table.h:3:32:
On 8/23/21 2:00 PM, Platon Pronko wrote:
> Hi!
>
> Apparently I did forget something, and that's the patch itself :)
> Thanks for Justin Pryzby for pointing this out.
>
> Attaching the patch now.
>
>
(Please avoid top-posting on PostgreSQL lists)
This patch seems basically sound. A couple of t
On Thu, Sep 23, 2021 at 3:24 PM Tom Lane wrote:
>
> John Naylor writes:
> > On Thu, Sep 23, 2021 at 2:37 PM Tom Lane wrote:
> >> On HEAD, I see these headers failing to compile standalone:
> >> $ src/tools/pginclude/cpluspluscheck
> >> In file included from /tmp/cpluspluscheck.XxTv1i/test.cpp:3:
On Wed, Sep 8, 2021 at 2:06 AM Dilip Kumar wrote:
> But I am attaching both the patches in case you want to play around.
I don't really see any reason not to commit 0001. Perhaps some very
minor grammatical nitpicking is in order here, but apart from that I
can't really see anything to criticize
Joe Wildish" writes:
> On Wed, 22 Sep 2021, at 17:09, Tom Lane wrote:
> The main change is a switch to using SPI for expression evaluation. The
> plans are also cached along the same lines as the RI trigger plans.
>>
>> I really dislike this implementation technique. Aside from the likely
>> p
On Thu, Sep 23, 2021 at 2:51 PM Daniel Gustafsson wrote:
> For the 13- backbranches we also need to backport 22e1943f1 ("pgcrypto: Check
> for error return of px_cipher_decrypt()" by Peter E) in order to avoid
> incorrect results for decrypt tests on disallowed ciphers. Does anyone have
> any con
On 9/23/21 9:31 PM, Robert Haas wrote:
On Wed, Sep 8, 2021 at 2:06 AM Dilip Kumar wrote:
But I am attaching both the patches in case you want to play around.
I don't really see any reason not to commit 0001. Perhaps some very
minor grammatical nitpicking is in order here, but apart from that
On Thu, Sep 23, 2021 at 5:34 AM Joe Wildish wrote:
> Regarding the deparse-and-reparse --- if I understand correctly, the core
> problem is that we have no way of going from a node tree to a string, such
> that the string is guaranteed to have the same meaning as the node tree? (I
> did try jus
On Thu, Sep 23, 2021 at 4:00 PM Tomas Vondra
wrote:
> I did find some suspicious behavior on the bigger box I have available
> (with 2x xeon e5-2620v3), see the attached spreadsheet. But it seems
> pretty weird because the worst affected case is with no parallel workers
> (so the queue changes sho
On Tue, Sep 14, 2021 at 9:30 PM Alvaro Herrera wrote:
>
> On 2021-Sep-13, Melanie Plageman wrote:
>
> > I also think it makes sense to rename the pg_stat_buffer_actions view to
> > pg_stat_buffers and to name the columns using both the buffer action
> > type and buffer type -- e.g. shared, strateg
On 23.09.21 12:34, Michael Paquier wrote:
On Wed, Sep 22, 2021 at 03:18:43PM +, Jacob Champion wrote:
On Wed, 2021-09-22 at 10:20 +0200, Peter Eisentraut wrote:
This should be added to each level of a function call that represents a
test. This ensures that when a test fails, the line numbe
extended stats objects are allowed on partitioned tables since v10.
https://www.postgresql.org/message-id/flat/CAKJS1f-BmGo410bh5RSPZUvOO0LhmHL2NYmdrC_Jm8pk_FfyCA%40mail.gmail.com
8c5cdb7f4f6e1d6a6104cb58ce4f23453891651b
But since 859b3003de they're not populated - pg_statistic_ext(_data) is empty
On 23.09.21 20:51, Daniel Gustafsson wrote:
For the 13- backbranches we also need to backport 22e1943f1 ("pgcrypto: Check
for error return of px_cipher_decrypt()" by Peter E) in order to avoid
incorrect results for decrypt tests on disallowed ciphers. Does anyone have
any concerns about applying
On 9/23/21 10:31 PM, Robert Haas wrote:
On Thu, Sep 23, 2021 at 4:00 PM Tomas Vondra
wrote:
I did find some suspicious behavior on the bigger box I have available
(with 2x xeon e5-2620v3), see the attached spreadsheet. But it seems
pretty weird because the worst affected case is with no para
> On 23 Sep 2021, at 23:26, Peter Eisentraut
> wrote:
>
> On 23.09.21 20:51, Daniel Gustafsson wrote:
>> For the 13- backbranches we also need to backport 22e1943f1 ("pgcrypto: Check
>> for error return of px_cipher_decrypt()" by Peter E) in order to avoid
>> incorrect results for decrypt tests
Hello Fujii-san,
On Tue, 7 Sep 2021 02:34:17 +0900
Fujii Masao wrote:
> On 2021/07/29 13:23, Yugo NAGATA wrote:
> > Hello,
> >
> > On Fri, 18 Jun 2021 15:58:48 +0200 (CEST)
> > Fabien COELHO wrote:
> >
> >> Attached Yugo-san patch with some updates discussed in the previous mails,
> >> so as
On 9/22/21 12:57 PM, Greg Sabino Mullane wrote:
> Some super quick nitpicks; feel free to ignore/apply/laugh off.
Thanks. I incorporated many of the suggestions.
Here is the press release at is stands. As we are past the deadline for
feedback, we are going to start the translation effort for the
On Thu, Sep 23, 2021 at 5:36 PM Tomas Vondra
wrote:
> (c) This can't explain the slowdown for cases without any Gather nodes
> (and it's ~17%, so unlikely due to binary layout).
Yeah, but none of the modified code would even execute in those cases,
so it's either binary layout, something wrong in
On Thu, Sep 23, 2021 at 08:18:41PM +0200, Matthias van de Meent wrote:
> On Sun, 12 Sept 2021 at 22:10, Justin Pryzby wrote:
> >
> > On Tue, Jul 20, 2021 at 08:27:02PM -0400, Alvaro Herrera wrote:
> > > I have to wonder if there really *is* a use case for CLUSTER in the
> > > first place on regula
On Mon, Aug 30, 2021 at 5:41 AM Andres Freund wrote:
> - if (F.getAttributes().hasFnAttribute(llvm::Attribute::NoInline))
> + if (F.getAttributes().hasAttribute(llvm::Attribute::FunctionIndex,
> llvm::Attribute::NoInline))
Yeah, that's already stopped working since you wrote it a few
Hi,
On Fri, Sep 3, 2021 at 4:33 AM Mark Dilger wrote:
>
>
>
> > On Aug 30, 2021, at 12:06 AM, Masahiko Sawada wrote:
> >
> > I've attached rebased patches.
>
> Thanks for these patches, Sawada-san!
Sorry for the very late response.
Thank you for the suggestions and the patch!
>
> The first pa
On 2021/09/24 7:26, Yugo NAGATA wrote:
That makes sense. Failures of setup connection or initial connection doesn't
seem 'static problems'. I rewrote this description to explain exit status 1
indicates also interal errors and early errors.
Exit status 1 indicates static problems such as in
On 2021-Sep-23, Alvaro Herrera wrote:
> However, I notice now that the pg_rewind tests reproducibly fail in
> branch 14 for reasons I haven't yet understood. It's strange that no
> other branch fails, even when run quite a few times.
Turns out that this is a real bug (setting EndOfLog seems insu
On Fri, Sep 24, 2021 at 12:45 AM Tomas Vondra
wrote:
>
> Hi,
>
> I wanted to do a review of this patch, but I'm a bit confused about
> which patch(es) to review. There's the v5 patch, and then these two
> patches - which seem to be somewhat duplicate, though.
>
> Can anyone explain what's the "cur
On Wed, Sep 8, 2021 at 10:13 PM Juan José Santamaría Flecha
wrote:
> On Thu, Jul 8, 2021 at 12:32 AM Victor Spirin wrote:
>> > #if defined(_MSC_VER) && _MSC_VER >= 1900
>> > -#define MIN_WINNT 0x0600
>> > +#define MIN_WINNT 0x0A00
>> > #else
>> > #define MIN_WINNT 0x0501
>> > #endif
>> >
Yes, it is more appropriate to set a duration time to determine whether
secure_write() is stuck, but it is difficult to define how long the duration
time is.
in my first patch, I add a GUC to allow the user to set the time, or it can be
hardcoded if a time deemed reasonable is provided?
-
Hi
> The above comments are fixed in the attached, as well as a pass over the
> docs
> and extended tests to actually test matching a foreign server. What do
> think
> about this version? I'm still not convinced that there aren't more quoting
> bugs in the parser, but I've left that intact for
On 2021/09/24 0:05, Robert Haas wrote:
On Thu, Sep 23, 2021 at 2:55 AM tushar wrote:
l checked and look like the issue is still not fixed against v7-* patches -
postgres=# create subscription test CONNECTION 'host=127.0.0.1 user=edb
dbname=postgres' PUBLICATION p with (create_slot = true)
On Tue, Sep 21, 2021 at 2:53 PM Masahiko Sawada wrote:
>
> I've attached the updated version patches. Please review them.
>
Some comments on the v14-0001 patch:
(1)
Patch comment
The existing patch comment doesn't read well. I suggest the following updates:
BEFORE:
Add pg_stat_subscription_err
On 2021-09-23 22:28, Andrew Dunstan wrote:
2. It would possibly be better to pass the relevant parts of the options
to print_aligned_vertical_line() rather than the whole options
structure. It feels odd to pass both that and opt_border.
What do you think about doing it the other way around - p
On Tue, Sep 21, 2021 at 6:05 PM Greg Nancarrow wrote:
>
> On Tue, Sep 21, 2021 at 4:12 PM vignesh C wrote:
> >
> > > (1)
> > > In get_object_address_publication_schema(), the error message:
> > >
> > > + errmsg("publication tables of schema \"%s\" in publication \"%s\"
> > > does not exist",
> >
On Fri, Sep 24, 2021 at 8:40 AM Amit Kapila wrote:
>
> On Fri, Sep 24, 2021 at 12:45 AM Tomas Vondra
> wrote:
> >
> > Hi,
> >
> > I wanted to do a review of this patch, but I'm a bit confused about
> > which patch(es) to review. There's the v5 patch, and then these two
> > patches - which seem to
On 2021/09/21 15:08, kuroda.hay...@fujitsu.com wrote:
Dear Fujii-san, Horiguchi-san,
Based on your advice, I made a patch
that communize two parsing functions into one.
new internal function parse_format_string() was added.
(This name may be too generic...)
log_line_prefix() and parse_pgfdw_a
On Fri, Sep 24, 2021 at 2:01 AM Robert Haas wrote:
>
> On Thu, Sep 23, 2021 at 4:00 PM Tomas Vondra
> wrote:
> > I did find some suspicious behavior on the bigger box I have available
> > (with 2x xeon e5-2620v3), see the attached spreadsheet. But it seems
> > pretty weird because the worst affec
On Thu, Sep 23, 2021 at 6:03 PM Tomas Vondra
wrote:
>
> 6) parse_oper.c
>
> I'm having some second thoughts about (not) allowing UDFs ...
>
> Yes, I get that if the function starts failing, e.g. because querying a
> dropped table or something, that breaks the replication and can't be
> fixed witho
On Fri, Sep 24, 2021 at 10:50 AM Amit Kapila wrote:
> > 12) misuse of REPLICA IDENTITY
> >
> > The more I think about this, the more I think we're actually misusing
> > REPLICA IDENTITY for something entirely different. The whole purpose of
> > RI was to provide a row identifier for the subscribe
On Thu, Sep 16, 2021 at 7:09 AM Peter Geoghegan wrote:
>
> On Wed, Apr 21, 2021 at 8:21 AM Robert Haas wrote:
> > Now, the reason for this is that when we discover dead TIDs, we only
> > record them in memory, not on disk. So, as soon as VACUUM ends, we
> > lose all knowledge of whether those TID
On Wed, Sep 22, 2021 at 8:52 AM Masahiko Sawada wrote:
>
> On Wed, Sep 22, 2021 at 3:02 AM vignesh C wrote:
> >
> >
> > Attached v30 patch has the fixes for the same.
> >
>
> Thank you for updating the patches.
>
> Here are random comments on v30-0002 patch:
>
> +
> + if (st
On Wed, Sep 22, 2021 at 11:27 AM tanghy.f...@fujitsu.com
wrote:
>
> On Wednesday, September 22, 2021 11:22 AM Masahiko Sawada
> wrote:
> >
> > ---
> > + if (!IsA(node, String))
> > + ereport(ERROR,
> > +
On Wed, Sep 22, 2021 at 11:31 AM Amit Kapila wrote:
>
> On Tue, Sep 21, 2021 at 11:39 PM vignesh C wrote:
> >
> > On Tue, Sep 21, 2021 at 9:03 AM Greg Nancarrow wrote:
> > >
> > > On Fri, Sep 17, 2021 at 10:09 PM vignesh C wrote:
> > > >
> > > > Attached v29 patch has the fixes for the same.
>
On Thu, Sep 23, 2021 at 12:22 PM houzj.f...@fujitsu.com
wrote:
>
> From Thurs, Sep 23, 2021 12:09 PM Amit Kapila wrote:
> > On Wed, Sep 22, 2021 at 5:03 PM Hou Zhijie wrote:
> > >
> > > Personally, I think we'd better move the code about changing publication's
> > > tablelist into AlterPublicati
On Thu, Sep 23, 2021 at 6:03 PM Tomas Vondra
wrote:
>
> 13) turning update into insert
>
> I agree with Ajin Cherian [4] that looking at just old or new row for
> updates is not the right solution, because each option will "break" the
> replica in some case. So I think the goal "keeping the replic
On Thu, Sep 23, 2021 at 1:56 PM Amit Kapila wrote:
>
> On Wed, Sep 22, 2021 at 8:52 AM Masahiko Sawada wrote:
> >
> > On Wed, Sep 22, 2021 at 3:02 AM vignesh C wrote:
> > >
> > ---
> > This patch introduces some new static functions to publicationcmds.c
> > but some have function prototypes but
On Thu, Sep 23, 2021 at 12:32 PM houzj.f...@fujitsu.com
wrote:
>
> On Thur, Sep 23, 2021 11:06 AM Greg Nancarrow wrote:
> > On Wed, Sep 22, 2021 at 9:33 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> > > >
> > > > How do you suggest changing it?
> > >
> > > Personally, I think we'd better move th
On Fri, Sep 24, 2021 at 11:06 AM Dilip Kumar wrote:
>
> On Fri, Sep 24, 2021 at 10:50 AM Amit Kapila wrote:
>
> > > 12) misuse of REPLICA IDENTITY
> > >
> > > The more I think about this, the more I think we're actually misusing
> > > REPLICA IDENTITY for something entirely different. The whole p
On Thu, Sep 23, 2021 at 10:21:20AM -0400, Tom Lane wrote:
>
> I do have sympathy for the idea that extensions would like to define
> their own statement types. I just don't see a practical way to do it
> in our existing parser infrastructure. This patch certainly doesn't
> offer that.
Allowing
Hi,
I think there's a word missing in the following comment:
/*
* See if the partition bounds for inputs are exactly the same, in
* which case we don't need to work hard: the join rel have the same
* partition bounds as inputs, and the partitions with the same
On Fri, Sep 24, 2021 at 11:52 AM Amit Kapila wrote:
>
> On Fri, Sep 24, 2021 at 11:06 AM Dilip Kumar wrote:
> >
> > On Fri, Sep 24, 2021 at 10:50 AM Amit Kapila
> > wrote:
> >
> > > > 12) misuse of REPLICA IDENTITY
> > > >
> > > > The more I think about this, the more I think we're actually mis
On Fri, Sep 24, 2021 at 12:04 PM Amit Kapila wrote:
>
> One possibility in this regard could be that we enhance Replica
> Identity .. Include (column_list) where all the columns in the include
> list won't be sent
Instead of RI's include column list why we can not think of
row_filter's columns li
99 matches
Mail list logo
