čt 6. 1. 2022 v 8:02 odesílatel Julien Rouhaud napsal:
> Hi Pavel,
>
> On Wed, Mar 24, 2021 at 08:09:13AM +0100, Pavel Stehule wrote:
> >
> > I am continuing to talk with Hannu about syntax. I think so using the
> > compile option is a good direction, but maybe renaming from
> "routine_label"
>
On 10.09.21 15:50, tanghy.f...@fujitsu.com wrote:
(A test case for the enum case should be doable easily.)
Test added.
The enum test is failing on *some* platforms:
t/010_tab_completion.pl .. 26/?
# Failed test 'complete enum values'
# at t/010_tab_completion.pl line 211.
# Actual output
On Thu, Jan 6, 2022 at 3:07 AM Robert Haas wrote:
>
> On Mon, Aug 2, 2021 at 6:38 PM Andres Freund wrote:
> > I guess there's a somewhat hacky way to get somewhere without actually
> > increasing the size. We could take 3 bytes from the fork number and use that
> > to get to a 7 byte relfilenode
At Wed, 05 Jan 2022 20:42:32 -0800, Andres Freund wrote in
> Hi,
>
> On January 5, 2022 8:30:17 PM PST, Kyotaro Horiguchi
> wrote:
> >I'm still not sure the reason the test item failed but I repost the
> >updated version then watch what the CI says.
>
> Fwiw, you can now test the same way
At Wed, 5 Jan 2022 17:18:06 -0600, Justin Pryzby wrote
in
> On Wed, Jan 05, 2022 at 10:45:06AM +0530, Dilip Kumar wrote:
> > On Wed, Jan 5, 2022 at 10:24 AM Bharath Rupireddy
> > wrote:
> > >
> > > Postgres server emits a message at DEBUG1 level when it skips a
> > > checkpoint. At times,
Hi Alvaro,
On Thu, Jan 6, 2022 at 7:27 AM Alvaro Herrera wrote:
> Pushed 0001.
Thank you.
> I had to adjust the query used in pg_dump; you changed the attribute
> name in the query used for pg15, but left unchanged the one for older
> branches, so pg_dump failed for all branches other than 15.
Hi Pavel,
On Wed, Mar 24, 2021 at 08:09:13AM +0100, Pavel Stehule wrote:
>
> I am continuing to talk with Hannu about syntax. I think so using the
> compile option is a good direction, but maybe renaming from "routine_label"
> to "topscope_label" (proposed by Hannu) or maybe "outerscope_label"
On Wed, Jan 5, 2022 at 10:05 PM Dilip Kumar wrote:
> On Thu, Jan 6, 2022 at 11:27 AM SATYANARAYANA NARLAPURAM
> wrote:
>
> > On Wed, Jan 5, 2022 at 9:46 AM Andres Freund wrote:
> >>
> >> Hi,
> >>
> >> On 2021-12-29 11:31:51 -0800, Andres Freund wrote:
> >> > That's pretty much the same -
On Fri, Dec 31, 2021 at 7:56 AM Amit Langote wrote:
>
> On Tue, Dec 28, 2021 at 22:12 Ashutosh Bapat
> wrote:
>>
>> On Sat, Dec 25, 2021 at 9:06 AM Amit Langote wrote:
>> >
>> > Executing generic plans involving partitions is known to become slower
>> > as partition count grows due to a number
On Tue, Dec 21, 2021 at 6:20 AM Tom Lane wrote:
> Robert Haas writes:
> > OK ... but my point is that dump and restore does work. So whatever
> > cases pg_get_expr() doesn't work must be cases that aren't needed for
> > that to happen. Otherwise this problem would have been found long ago.
>
>
I corrected it according to your suggestion.
thanks
Wenjing.
Zhihong Yu 于2021年12月25日周六 02:26写道：
>
>
> On Thu, Dec 23, 2021 at 3:52 AM 曾文旌(义从)
> wrote:
>
>>
>> Fixed a bug found during testing.
>>
>>
>> Wenjing
>>
>>
Hi,
> + if (condition_is_safe_pushdown_to_sublink(rinfo,
>
On Thu, Jan 6, 2022 at 11:27 AM SATYANARAYANA NARLAPURAM
wrote:
> On Wed, Jan 5, 2022 at 9:46 AM Andres Freund wrote:
>>
>> Hi,
>>
>> On 2021-12-29 11:31:51 -0800, Andres Freund wrote:
>> > That's pretty much the same - XLogInsert() can trigger an
>> > XLogWrite()/Flush().
>> >
>> > I think
On Wed, Jan 5, 2022 at 9:46 AM Andres Freund wrote:
> Hi,
>
> On 2021-12-29 11:31:51 -0800, Andres Freund wrote:
> > That's pretty much the same - XLogInsert() can trigger an
> > XLogWrite()/Flush().
> >
> > I think it's a complete no-go to add throttling to these places. It's
> quite
> >
On Thursday, January 6, 2022 12:17 PM Tang, Haiying/唐 海英
wrote:
> Thanks for updating the patch. Here are some comments:
Thank you for your review !
> 1)
> + /*
> + * We would not be here unless this subscription's disableonerr field
> was
> + * true when our worker began applying
On Wed, Jan 5, 2022 at 8:07 AM Peter Eisentraut
wrote:
>
> This patch set looks very interesting.
Thank you for the review!
I'll work on your feedback but in the meantime here are replies to
your questions:
> I'm confused about how to query tables based on application time
> periods. Online,
On Thu, Jan 06, 2022 at 02:19:08PM +0900, Michael Paquier wrote:
> On Wed, Jan 05, 2022 at 05:55:17PM -0600, Justin Pryzby wrote:
> > pg_settings is currently defined with "SELECT *". Is it fine to enumerate a
> > list of columns instead ?
>
> I'd like to think that this is a better practice
At Tue, 4 Jan 2022 21:06:48 -0600, Justin Pryzby wrote
in
> On Wed, Jan 05, 2022 at 11:47:57AM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 28 Dec 2021 20:32:40 -0600, Justin Pryzby
> > wrote in
> In that case, *all* the flags should be exposed. There's currently 20, which
> means it may not
On Wed, Jan 05, 2022 at 10:22:06AM -0500, Tom Lane wrote:
> I think the existing precedent is to skip the test if tar isn't there,
> cf pg_basebackup/t/010_pg_basebackup.pl. But certainly the majority of
> buildfarm animals have it.
Even Windows environments should be fine, aka recent edc2332.
On Wed, Jan 05, 2022 at 05:55:17PM -0600, Justin Pryzby wrote:
> pg_settings is currently defined with "SELECT *". Is it fine to enumerate a
> list of columns instead ?
I'd like to think that this is a better practice when it comes
documenting the columns, but I don't see an actual need for this
On Thu, Jan 06, 2022 at 05:52:01PM +1300, Thomas Munro wrote:
> On Thu, Jan 6, 2022 at 5:00 PM Justin Pryzby wrote:
> > I'm attaching a probable fix. Unfortunately, for patches like this, most of
> > the functionality isn't exercised unless the library is installed and
> > compilation and
On Wed, Jan 5, 2022 at 10:31 AM Michael Paquier wrote:
> On Fri, Dec 24, 2021 at 01:27:26PM +, houzj.f...@fujitsu.com wrote:
> > Here is the perf result of pgoutput_change after applying the patch.
> > I didn't notice something else that stand out.
> >
> > |--2.99%--pgoutput_change
>
On Wed, Jan 05, 2022 at 10:33:38AM -0500, Robert Haas wrote:
> I think we're going to want to offer both options. We can't know
> whether the user prefers to consume CPU cycles on the server or on the
> client. Compressing on the server has the advantage of potentially
> saving transfer bandwidth,
On Wed, Jan 5, 2022 at 9:48 AM Dilip Kumar wrote:
>
> On Wed, Jan 5, 2022 at 9:01 AM Amit Kapila wrote:
> >
> > On Mon, Dec 27, 2021 at 9:54 AM Masahiko Sawada
> > wrote:
> >
> > Do you mean to say that you want to omit it even when we are
> > committing the changes?
> >
> > > Apart from that,
On Thu, Jan 6, 2022 at 5:00 PM Justin Pryzby wrote:
> I'm attaching a probable fix. Unfortunately, for patches like this, most of
> the functionality isn't exercised unless the library is installed and
> compilation and runtime are enabled by default.
By the way, you could add a separate patch
Hi,
On January 5, 2022 8:30:17 PM PST, Kyotaro Horiguchi
wrote:
>At Tue, 4 Jan 2022 16:05:08 -0800, Andres Freund wrote in
>> The tap tests seems to fail on all platforms. See
>> https://cirrus-ci.com/build/4911549314760704
>>
>> E.g. the linux failure is
>>
>> [16:45:15.569]
>>
At Tue, 4 Jan 2022 16:05:08 -0800, Andres Freund wrote in
> The tap tests seems to fail on all platforms. See
> https://cirrus-ci.com/build/4911549314760704
>
> E.g. the linux failure is
>
> [16:45:15.569]
> [16:45:15.569] # Failed test 'inserted'
> [16:45:15.569] # at
On Thu, Jan 6, 2022 at 8:43 AM Peter Smith wrote:
>
> On Wed, Jan 5, 2022 at 9:52 PM Amit Kapila wrote:
> >
> ...
>
> > Another minor comment:
> > +static bool pgoutput_row_filter(enum ReorderBufferChangeType changetype,
> >
> > Do we need to specify the 'enum' type before changetype parameter?
On Thu, Jan 6, 2022 at 3:42 AM Tom Lane wrote:
>
> Commit 6ce16088b caused me to look at pgoutput.c's handling of
> cache invalidations, and I was pretty appalled by what I found.
>
> * rel_sync_cache_relation_cb does the wrong thing when called for
> a cache flush (i.e., relid == 0). Instead of
On Wed, Jan 5, 2022 at 11:16 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-12-29 11:31:51 -0800, Andres Freund wrote:
> > That's pretty much the same - XLogInsert() can trigger an
> > XLogWrite()/Flush().
> >
> > I think it's a complete no-go to add throttling to these places. It's quite
> >
The cfbot showed issues compiling on linux and windows.
http://cfbot.cputube.org/takashi-menjo.html
https://cirrus-ci.com/task/6125740327436288
[02:30:06.538] In file included from xlog.c:38:
[02:30:06.538] ../../../../src/include/access/xlogpmem.h:32:42: error: unknown
type name ‘tli’
On Tue, Jan 04, 2022 at 05:03:10PM +0100, Peter Eisentraut wrote:
> On 04.01.22 03:21, Julien Rouhaud wrote:
>
> > > - if (!lc_collate_is_c(collid) && collid != DEFAULT_COLLATION_OID)
> > > - mylocale = pg_newlocale_from_collation(collid);
> > > + if (!lc_collate_is_c(collid))
> > > + {
>
On Wednesday, January 5, 2022 8:53 PM osumi.takami...@fujitsu.com
wrote:
>
> On Tuesday, December 28, 2021 11:53 AM Wang, Wei/王 威
> wrote:
> > On Thursday, December 16, 2021 8:51 PM osumi.takami...@fujitsu.com
> > wrote:
> > > Attached the updated patch v14.
> >
> > A comment to the timing of
On Wed, Jan 5, 2022 at 9:52 PM Amit Kapila wrote:
>
...
> Another minor comment:
> +static bool pgoutput_row_filter(enum ReorderBufferChangeType changetype,
>
> Do we need to specify the 'enum' type before changetype parameter?
>
That is because there is currently no typedef for the enum
Hi!
On Thu, Jan 6, 2022 at 3:02 AM Bruce Momjian wrote:
>
> On Thu, Dec 30, 2021 at 03:15:16PM +0300, Maxim Orlov wrote:
> > PFA updated working patch v6 for PG15 development cycle.
> > It is based on a patch by Alexander Korotkov version 5 [5] with a few fixes,
> > refactoring and was rebased
On Wed, Jan 05, 2022 at 09:56:26PM +0100, Daniel Gustafsson wrote:
> I think we should remove the link, not because it costs money but because it
> can be purchased from several places, and choosing one to "favor" seems to
> invite criticism. Kind of how we don't link to an online store for
On Thu, Jan 6, 2022 at 1:10 AM Alvaro Herrera wrote:
>
> BTW I think it's not great to commit with the presented split. We would
> have non-trivial short-lived changes for no good reason (0002 in
> particular). I think this whole series should be a single patch, with
Yes, we know that
On Thu, Jan 6, 2022 at 12:23 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > On Thu, Jan 6, 2022 at 12:56 PM Peter Smith wrote:
> >> These are quite rare in the PG src, so I doubt they are intentional.
> >> PSA a patch to remove the trailing commas for all that I found.
>
> > -1. I don't see
Rebased.
On Fri, Nov 5, 2021 at 3:47 PM Takashi Menjo wrote:
>
> Hi Daniel,
>
> The issue you told has been fixed. I attach the v5 patchset to this email.
>
> The v5 has all the patches in the v4, and in addition, has the
> following two new patches:
>
> - (v5-0002) Support build with MSVC on
Thomas Munro writes:
> On Thu, Jan 6, 2022 at 12:56 PM Peter Smith wrote:
>> These are quite rare in the PG src, so I doubt they are intentional.
>> PSA a patch to remove the trailing commas for all that I found.
> -1. I don't see the problem with C99 trailing commas. They avoid
> noisy diff
Peter Eisentraut writes:
> On 03.01.22 22:50, Tom Lane wrote:
>> The attached proposed patch removes some ancient infrastructure for
>> manually testing hot standby.
> I looked into this some time ago and concluded that this test contains a
> significant amount of testing that isn't obviously
On Thu, Jan 6, 2022 at 12:56 PM Peter Smith wrote:
> I saw one (and then went looking and found some more) enum with a
> trailing comma.
>
> These are quite rare in the PG src, so I doubt they are intentional.
>
> PSA a patch to remove the trailing commas for all that I found.
-1. I don't see
On Wed, Jan 05, 2022 at 12:09:16PM -0500, Melanie Plageman wrote:
> On Fri, Dec 17, 2021 at 3:04 PM Justin Pryzby wrote:
> > The rest of these are questions more than comments, and I'm not necessarily
> > suggesting to change the patch:
> >
> > This isn't new in your patch, but for me, it's more
On Wed, Jan 5, 2022 at 06:12:26PM -0600, Justin Pryzby wrote:
> On Wed, Jan 05, 2022 at 06:51:37PM -0500, Bruce Momjian wrote:
> > On Tue, Jan 4, 2022 at 10:22:50PM +, Finnerty, Jim wrote:
> > > I'm concerned about the maintainability impact of having 2 new
> > > on-disk page formats. It's
On Wed, Jan 05, 2022 at 06:51:37PM -0500, Bruce Momjian wrote:
> On Tue, Jan 4, 2022 at 10:22:50PM +, Finnerty, Jim wrote:
> > I'm concerned about the maintainability impact of having 2 new
> > on-disk page formats. It's already complex enough with XIDs and
> > multixact-XIDs.
> >
> > If the
On Tue, Jan 4, 2022 at 05:49:07PM +, Finnerty, Jim wrote:
> Hi Maxim,
> I’m glad to see that you’re trying to carry the 64-bit XID work forward.
> I
> had not noticed that my earlier patch (also derived from Alexander Kortkov’s
> patch) was responded to back in September. Perhaps we
On Mon, 2022-01-03 at 16:19 +, Jacob Champion wrote:
> On Fri, 2021-12-17 at 15:40 +0900, Kyotaro Horiguchi wrote:
> >
> > + inet_net_pton_ipv4(const char *src, u_char *dst)
> > (calls inet_net_pton_ipv4_internal(src, dst, true))
> > + inet_pton_ipv4(const char *src, u_char *dst)
> > (calls
On Thu, Dec 30, 2021 at 03:15:16PM +0300, Maxim Orlov wrote:
> PFA updated working patch v6 for PG15 development cycle.
> It is based on a patch by Alexander Korotkov version 5 [5] with a few fixes,
> refactoring and was rebased to PG15.
>
> Main changes:
> - Change TransactionId to 64bit
> -
I saw one (and then went looking and found some more) enum with a
trailing comma.
These are quite rare in the PG src, so I doubt they are intentional.
PSA a patch to remove the trailing commas for all that I found.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
On Wed, Jan 05, 2022 at 02:17:11PM +0900, Michael Paquier wrote:
> On Tue, Jan 04, 2022 at 09:06:48PM -0600, Justin Pryzby wrote:
> > I think pg_get_guc_flags() may be best, but I'm interested to hear other
> > opinions.
>
> My opinion on this matter is rather close to what you have here with
>
On Tue, Jan 4, 2022 at 10:22:50PM +, Finnerty, Jim wrote:
> I'm concerned about the maintainability impact of having 2 new
> on-disk page formats. It's already complex enough with XIDs and
> multixact-XIDs.
>
> If the lack of space for the two epochs in the special data area is
> a problem
On Wed, Dec 29, 2021 at 10:40:59AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> >> Therefore, reporting the checkpoint progress in the server logs, much
> >> like [1], seems to be the best way IMO.
>
> > I find progress reporting in the logfile to generally be a terrible
> > way of doing
On 12/23/21, 3:17 AM, "Bharath Rupireddy"
wrote:
> Currently the end-of-recovery checkpoint can be much slower, impacting
> the server availability, if there are many replication slot files
> .snap or map- to be enumerated and deleted. How about skipping
> the .snap and map- file
On Wed, Jan 05, 2022 at 10:45:06AM +0530, Dilip Kumar wrote:
> On Wed, Jan 5, 2022 at 10:24 AM Bharath Rupireddy
> wrote:
> >
> > Postgres server emits a message at DEBUG1 level when it skips a
> > checkpoint. At times, developers might be surprised after figuring out
> > from server logs that
FYI - v58 is currently known to be broken due to a recent commit [1].
I plan to post a v59* later today to address this as well as other
recent review comments.
--
[1]
https://github.com/postgres/postgres/commit/6ce16088bfed97f982f66a9dc17b8364df289e4d
Kind Regards,
Peter Smith.
Fujitsu
Pushed 0001.
I had to adjust the query used in pg_dump; you changed the attribute
name in the query used for pg15, but left unchanged the one for older
branches, so pg_dump failed for all branches other than 15. Also,
psql's describe.c required a small tweak to a version number test.
Commit 6ce16088b caused me to look at pgoutput.c's handling of
cache invalidations, and I was pretty appalled by what I found.
* rel_sync_cache_relation_cb does the wrong thing when called for
a cache flush (i.e., relid == 0). Instead of invalidating all
RelationSyncCache entries as it should,
On 12/30/21, 3:52 AM, "Maxim Orlov" wrote:
> I did check the patch too and found it to be ok. Check and check-world are
> passed.
> Overall idea seems to be good in my opinion, but I'm not sure where is the
> optimal place to put the pre-allocation.
>
> On Thu, Dec 30, 2021 at 2:46 PM Pavel
On Wed, Jan 5, 2022 at 11:07 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 21.11.21 02:51, Paul A Jungwirth wrote:
> > Here are updated patches. They are rebased and clean up some of my
> > TODOs.
>
> This patch set looks very interesting. It's also very big, so it's
>
On Mon, Aug 2, 2021 at 6:38 PM Andres Freund wrote:
> I guess there's a somewhat hacky way to get somewhere without actually
> increasing the size. We could take 3 bytes from the fork number and use that
> to get to a 7 byte relfilenode portion. 7 bytes are probably enough for
> everyone.
>
>
On Sun, Jun 13, 2021 at 8:25 PM Thomas Munro wrote:
> Just as an FYI: this entry currently fails with "Timed out!" on cfbot
> because of an oversight in the master branch[1], AFAICS. It should
> pass again once that's fixed.
>
> [1]
>
> On Tue, Jan 04, 2022 at 06:02:43PM -0500, Tom Lane wrote:
> We can debate whether the rules proposed here are good for
> pg_stat_statements or not, but it seems inevitable that they will be a
> disaster for some other consumers of the query hash.
Hm, which consumers do you mean here, potential
> On 5 Jan 2022, at 02:26, Michael Paquier wrote:
>
> On Tue, Jan 04, 2022 at 06:10:07PM +0100, Erik Rijkers wrote:
>> The replacement is a ~200 euro pdf (2021). I'd be thankful if someone would
>> send the pdf to me; maybe I can update my JSON tests.
>>
>> And we should remove that entry from
On Fri, 31 Dec 2021 at 22:07, Tomas Vondra
wrote:
> The patch does something far more
> elegant - it simply uses stavalues to store an array of JSONB documents,
> each describing stats for one path extracted from the sampled documents.
Sounds good.
> I'm sure there's plenty open questions -
On Wed, 10 Nov 2021 at 03:17, Amit Kapila wrote:
>
> On Tue, Nov 9, 2021 at 5:12 AM Jeff Davis wrote:
> >
> > On Fri, 2021-11-05 at 10:00 +0530, Amit Kapila wrote:
> > > I am not talking about decoding plugin but rather decoding itself,
> > > basically, the work we do in reorderbuffer.c,
On Sat, Jan 1, 2022 at 11:07 AM Tomas Vondra
wrote:
> 0006-Add-jsonb-statistics-20211230.patch
Hi Tomas,
-CREATE OR REPLACE FUNCTION explain_jsonb(sql_query text)
+CREATE OR REPLACE FUNCTION explain_jsonb(sql_query text)
https://cirrus-ci.com/task/6405547984420864
It looks like there is a
Dag Lem writes:
> Thomas Munro writes:
>
>> On Wed, Jan 5, 2022 at 2:49 AM Dag Lem wrote:
>>> However I guess this won't make any difference wrt. actually running the
>>> tests, as long as there seems to be an encoding problem in the cfbot
>>
>> Fixed -- I told it to pull down patches as
"Daniel Westermann (DWE)" writes:
> initdb: warning: enabling "trust" authentication for local connections
> You can change this by editing pg_hba.conf or using the option -A, or
> --auth-local and --auth-host, the next time you run initdb.
> Shouldn't there be a "." after "authentication for
Andres Freund writes:
> On 2021-12-28 15:49:00 +, Jelte Fennema wrote:
>> Finally, I would love it if once these fixes are merged the would also be
>> backpatched to
>> previous versions of libpq.
> I'm not really convinced this is a good patch to backpatch. There does seem to
> be some
On Wed, Jan 5, 2022 at 2:19 PM Julien Rouhaud wrote:
>
> On Thu, Jan 6, 2022 at 12:19 AM Bruce Momjian wrote:
> >
> > On Tue, Jan 4, 2022 at 10:47:47AM -0300, Fabrízio de Royes Mello wrote:
> > >
> > >
> > > What we did was decode the 9.6 wal files and apply transactions to the
> > > old 9.2 to
Hi,
this is more a cosmetic concern, but anyway: running initdb gives this output:
...
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
initdb: warning: enabling "trust" authentication for local
Hi,
On 2021-12-28 15:49:00 +, Jelte Fennema wrote:
> The first patch is a cleaned up version of my previous patch. I think I
> addressed
> all feedback on the previous version in that patch (e.g. removed windows
> code,
> fixed formatting).
To me it seems a bit problematic to introduce a
Dag Lem writes:
> Please find attached a patch to run the previously commented-out
> UTF8-dependent tests for citext, according to best practice. For now I
> don't dare to touch the unaccent module, which seems to be UTF8-only
> anyway.
I tried this on a bunch of different locale settings and
On Tue, Jan 4, 2022 at 10:21 PM Shinya Kato
wrote:
> Thank you for the new patch!
>
> On 2021-12-15 15:40, kuroda.hay...@fujitsu.com wrote:
> > Dear Kato-san,
> >
> > Thank you for giving comments! And sorry for late reply.
> > I rebased my patches.
> >
> >> Even for local-only transaction, I
On Thu, 30 Dec 2021 at 13:19, Maxim Orlov wrote:
>
> Hi, hackers!
>
> Long time wraparound was a really big pain for highly loaded systems. One
> source of performance degradation is the need to vacuum before every
> wraparound.
> And there were several proposals to make XIDs 64-bit like [1],
Hi,
On 2021-12-29 11:31:51 -0800, Andres Freund wrote:
> That's pretty much the same - XLogInsert() can trigger an
> XLogWrite()/Flush().
>
> I think it's a complete no-go to add throttling to these places. It's quite
> possible that it'd cause new deadlocks, and it's almost guaranteed to have
>
On Thu, Jan 6, 2022 at 12:19 AM Bruce Momjian wrote:
>
> On Tue, Jan 4, 2022 at 10:47:47AM -0300, Fabrízio de Royes Mello wrote:
> >
> >
> > What we did was decode the 9.6 wal files and apply transactions to the
> > old 9.2 to keep it in sync with the new promoted version. This was our
> >
Thanks for the detailed review!
On Fri, Dec 17, 2021 at 3:04 PM Justin Pryzby wrote:
>
> On Mon, Dec 13, 2021 at 05:27:52PM -0500, Melanie Plageman wrote:
> > Done in attached v4
>
> Thanks.
>
> I think these comments can be removed from the callers:
> /* it's a simple type, so don't use
On 1/5/22 00:51, Himanshu Upadhyaya wrote:
> On Thu, Dec 9, 2021 at 7:34 PM Himanshu Upadhyaya
> wrote:
>> 3)
>> Is not that result of the two below queries should match because both are
>> trying to retrieve the information from the JSON object.
>>
>> postgres=# SELECT JSON_OBJECT('track'
On Tue, Dec 28, 2021 at 1:12 PM Jeevan Ladhe
wrote:
> Hi Tushar,
>
> You need to apply Robert's v10 version patches 0002, 0003 and 0004, before
> applying the lz4 patch(v8 version).
> Please let me know if you still face any issues.
>
Thanks, Jeevan.
I tested —server-compression option using
Japin Li writes:
> Here is a patch for POC testing.
This is certainly not right. You've made gbt_bpchar_consistent
work identically to gbt_text_consistent, but it needs to implement
a test equivalent to bpchareq, ie ignore trailing spaces in both
inputs.
The minimum-effort fix would be to
On Wed, 05 Jan 2022 at 03:19, Tom Lane wrote:
> Alexander Lakhin writes:
>> While testing the index-only scan fix, I've discovered that replacing
>> the index-only scan with the index scan changes contrib/btree_gist
>> output because index-only scan for btree_gist returns a string without
>>
On Tue, Jan 4, 2022 at 10:47:47AM -0300, Fabrízio de Royes Mello wrote:
>
> On Tue, Jan 4, 2022 at 9:22 AM Michael Paquier wrote:
> >
> > On Wed, Dec 29, 2021 at 08:50:23AM -0300, Fabrízio de Royes Mello wrote:
> > > Try this:
> > > https://github.com/michaelpq/pg_plugins/tree/main/decoder_raw
On 21.11.21 02:51, Paul A Jungwirth wrote:
Here are updated patches. They are rebased and clean up some of my
TODOs.
This patch set looks very interesting. It's also very big, so it's
difficult to see how to get a handle on it. I did a pass through it
to see if there were any obvious
On Wed, Jan 5, 2022 at 4:17 AM wrote:
> When the backend-side compression is completed, were there really be a need
> for
> client-side compression? If yes, then it seems logical to have distinct
> options
> for them and this cleanup makes sense. If not, then it seems logical to
> maintain
>
Robert Haas writes:
> Oh, well, if we have a working tar available, then it's not so bad. I
> was thinking we couldn't really count on that, especially on Windows.
I think the existing precedent is to skip the test if tar isn't there,
cf pg_basebackup/t/010_pg_basebackup.pl. But certainly the
On Mon, Dec 20, 2021 at 7:43 PM Michael Paquier wrote:
> Yeah, consistency would be good. For the client-side compression of
> LZ4, we have shaped things around the existing --compress option, and
> there is 6f164e6 that offers an API to parse that at option-level,
> meaning less custom error
On Wed, Jan 5, 2022 at 5:11 AM tushar wrote:
> One scenario where I feel error message is confusing and if it is not
> supported at all then error message need to be a little bit more clear
>
> if we use -z (or -Z ) with -t , we are getting this error
> [edb@centos7tushar bin]$ ./pg_basebackup
On Thu, 30 Dec 2021 at 16:40, Teodor Sigaev wrote:
> We are working on custom toaster for JSONB [1], because current TOAST is
> universal for any data type and because of that it has some disadvantages:
> - "one toast fits all" may be not the best solution for particular
> type or/and
BTW I think it's not great to commit with the presented split. We would
have non-trivial short-lived changes for no good reason (0002 in
particular). I think this whole series should be a single patch, with
the commit message being a fusion of messages explaining in full what
the functional
On Tuesday, December 28, 2021 11:53 AM Wang, Wei/王 威
wrote:
> On Thursday, December 16, 2021 8:51 PM osumi.takami...@fujitsu.com
> wrote:
> > Attached the updated patch v14.
>
> A comment to the timing of printing a log:
Thank you for your review !
> After the log[1] was printed, I altered
Tom Lane writes:
> Dag Lem writes:
>
>> Running "ack -l '[\x80-\xff]'" in the contrib/ directory reveals that
>> two other modules are using UTF8 characters in tests - citext and
>> unaccent.
>
> Yeah, neither of those have been upgraded to said best practice.
> (If you feel like doing the
On 03.01.22 22:50, Tom Lane wrote:
The attached proposed patch removes some ancient infrastructure for
manually testing hot standby. I doubt anyone has used this in years,
because AFAICS there is nothing here that's not done better by the
src/test/recovery TAP tests. (Or if there is, we ought
On Wed, Jan 5, 2022 at 2:45 PM Amit Kapila wrote:
>
> On Tue, Dec 28, 2021 at 6:33 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Mon, Dec 27, 2021 9:19 PM Hou Zhijie wrote:
> > > On Mon, Dec 27, 2021 9:16 PM houzj.f...@fujitsu.com
> > >
> > > wrote:
> > > > On Thur, Dec 23, 2021 4:28 PM Peter
On 1/4/22 8:07 PM, Robert Haas wrote:
Before sending an email like this, it would be a good idea to read the
documentation for the --server-compression option.
Sure, Thanks Robert.
One scenario where I feel error message is confusing and if it is not
supported at all then error message need
On Wednesday, January 5th, 2022 at 9:00 AM, Michael Paquier
wrote:
> On Mon, Jan 03, 2022 at 03:35:57PM +, gkokola...@pm.me wrote:
> > I propose to initialize streamer to NULL when declared at the top of
> > CreateBackupStreamer().
>
> Yes, that may be noisy. Done this way.
Great.
> >
On Tue, Dec 28, 2021 at 6:33 PM houzj.f...@fujitsu.com
wrote:
>
> On Mon, Dec 27, 2021 9:19 PM Hou Zhijie wrote:
> > On Mon, Dec 27, 2021 9:16 PM houzj.f...@fujitsu.com
> > wrote:
> > > On Thur, Dec 23, 2021 4:28 PM Peter Smith wrote:
> > > > Here is the v54* patch set:
> > >
> > > Attach the
On Thu, Dec 16, 2021 at 11:51:55AM +0900, Michael Paquier wrote:
> I may have missed one thing or two, but I think that's pretty much
> what we should be looking for to do the switch to TAP in terms of
> coverage.
Rebased patch to cool down the CF bot, as per the addition of
--no-sync to
(Added Jeevan in CC, for awareness)
On Mon, Jan 03, 2022 at 03:35:57PM +, gkokola...@pm.me wrote:
> I propose to initialize streamer to NULL when declared at the top of
> CreateBackupStreamer().
Yes, that may be noisy. Done this way.
> You can see that after the check_pg_config() test,
98 matches
Mail list logo
