On Sat, Jun 26, 2021 at 06:11:26PM -0500, Justin Pryzby wrote:
> Curious. I found that before a4d75c86bf, there was an issue without the
> "extra" patches.
Is this issue different than the XID problem not matching when using
wal_level = minimal in test 011_crash_recovery.pl? I am not sure to
und
On Sat, Jun 26, 2021 at 05:29:29PM -0400, Tom Lane wrote:
> I'll stick this into the CF list to see if the cfbot agrees that
> it finds the abort() problems...
The CF Bot is finding those problems.
> +# Check for functions that libpq must not call.
> +# (If nm doesn't exist or doesn't work on shl
On Mon, Jun 28, 2021 at 04:36:42PM +0900, Michael Paquier wrote:
> Is this issue different than the XID problem not matching when using
> wal_level = minimal in test 011_crash_recovery.pl? I am not sure to
> understand if you are
(This paragraph has been cut in half)
referring to a different pro
> 28 июня 2021 г., в 12:36, Michael Paquier написал(а):
>
> Removing "allows_streaming => 1" in 011_crash_recovery.pl is enough to
> make the test fail on HEAD. And the test fails equally without or
> without any changes related to wal_compression, so adding or removing
> options to wal_compr
Hello Tom,
moonjelly just reported an interesting failure [1].
I noticed. I was planning to have a look at it, thanks for digging!
It seems that with the latest bleeding-edge gcc, this code is
misoptimized:
else if (imax - imin < 0 || (imax - imin) + 1 < 0)
+# Check for functions that libpq must not call.
+# (If nm doesn't exist or doesn't work on shlibs, this test will silently
+# do nothing, which is fine.)
+.PHONY: check-libpq-refs
+check-libpq-refs: $(shlib)
+ @! nm -A -g -u $< 2>/dev/null | grep -e abort -e exit
"abort" and "exit" cou
On 2019-11-29 05:32, Michael Paquier wrote:
These comments are unanswered for more than 2 months, so I am marking
this entry as returned with feedback.
I'd like to revive this patch. To make further work easier, attaching a
rebased version of the latest patch by Alexander.
As for having yet
On Tue, Jun 22, 2021 at 9:18 AM osumi.takami...@fujitsu.com
wrote:
>
> On Tuesday, June 22, 2021 11:08 AM Japin Li wrote:
> > > Your patch appears to be on the lines we discussed but I would prefer
> > > to get it done after Beta2 as this is just a minor code improvement.
> > > Can you please sen
On Mon, Jun 28, 2021 at 5:36 AM Peter Geoghegan wrote:
>
> The wraparound failsafe mechanism added by commit 1e55e7d1 had minimal
> documentation -- just a basic description of how the GUCs work. I
> think that it certainly merits some discussion under "25.1. Routine
> Vacuuming" -- more specifica
I found a couple of places where numeric multiplication suffers from
overflow errors for inputs that aren't necessarily very large in
magnitude.
The first is with the numeric * operator, which attempts to always
produce the exact result, even though the numeric type has a maximum
of 16383 digits a
On Mon, Jun 21, 2021 at 4:40 PM houzj.f...@fujitsu.com
wrote:
>
> To be honest, I didn't find a cheap way to invalidate partitioned table's
> parallel safety automatically.
>
I also don't see the feasibility for doing parallelism checks for
partitioned tables both because it is expensive due to
t
On Fri, Jun 18, 2021 at 6:35 PM Bharath Rupireddy
wrote:
> > PSA v5 patch set.
>
> PSA v6 patch set rebased onto the latest master.
PSA v7 patch set rebased onto the latest master.
With Regards,
Bharath Rupireddy.
v7-0001-Refactor-parse_subscription_options.patch
Description: Binary data
v7-
Hi!
From: Zhihong Yu
Sent: Saturday, June 26, 2021 20:32
Subject: Re: Rename of triggers for partitioned tables
> Hi, Arne:
> It seems the patch no longer applies cleanly on master branch.
> Do you mind updating the patch ?
>
> Thanks
Thank you for having a look! Please let me know if the attach
> On 18 May 2021, at 15:50, Heikki Linnakangas wrote:
> The reason is that if you specify multiple --rmgr options, only the last one
> takes effect.
That's in line with how options are handled for most binaries, so this will go
against that. That being said, I don't think thats a problem here
Em dom., 27 de jun. de 2021 às 21:18, Peter Smith
escreveu:
> On Fri, Jun 25, 2021 at 11:55 PM Ranier Vilela
> wrote:
> >
> >
> >
> https://github.com/postgres/postgres/commit/3af10943ce21450e299b3915b9cad47cd90369e9
> > fixes some issues with subscriptioncmds.c, but IMHO still lack this
> issue
Em seg., 28 de jun. de 2021 às 00:29, Michael Paquier
escreveu:
> On Mon, Jun 28, 2021 at 10:17:55AM +1000, Peter Smith wrote:
> > IIUC for the case ALTER_SUBSCRIPTION_DROP_PUBLICATION it looks like
> > the uninitialized copy_data local stack var would remain uninitialized
> > (undefined) still a
On Mon, 28 Jun 2021 at 21:16, Dean Rasheed wrote:
> So the second patch fixes this by adding new numericvar_send/recv()
> functions capable of sending the full precision NumericVar's from each
> worker, without rounding. The first test case in this patch is an
> example that would round the wrong
On Mon, 28 Jun 2021 at 21:59, Peter Eisentraut
wrote:
>
> There are certain parts of code that laboriously initialize every field
> of a struct to (some spelling of) zero, even though the whole struct was
> just zeroed (by makeNode() or memset()) a few lines earlier. Besides
> being redundant, I
On Sat, 26 Jun 2021 at 16:41, Justin Pryzby wrote:
>
> On Thu, Jun 24, 2021 at 10:27:06AM +1200, David Rowley wrote:
> > I think the reasons for doing operations directly on partitions are
> > being reduced with each release. What operations do people really
> > need to do on partitions now? TRUN
> On 28 Jun 2021, at 11:59, Peter Eisentraut
> wrote:
>
> There are certain parts of code that laboriously initialize every field of a
> struct to (some spelling of) zero, even though the whole struct was just
> zeroed (by makeNode() or memset()) a few lines earlier. Besides being
> redundan
On Mon, 28 Jun 2021 at 15:59, Amit Langote wrote:
>
> On Fri, Jun 25, 2021 at 10:26 AM David Rowley wrote:
> > I wonder, since we can't delay taking locks until after run-time
> > pruning due to being unable to invalidate cached plans, maybe instead
> > we could tag on any PartitionPruneInfo onto
Here's the diff from a pgindent run. The results look kosher to me - I
had to do a little surgery on queryjumble.h due to it having an unused
typedef.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
On 6/28/21 2:39 AM, Peter Geoghegan wrote:
> On Sun, Jun 27, 2021 at 4:23 PM Andrew Dunstan wrote:
>
>> In practical terms, there is an awful lot of head room between the
>> default for autovacuum_freeze_max_age and any danger of major
>> anti-wraparound measures. Say you increase it to 1bn fro
On Tue, 29 Jun 2021 at 00:29, Andrew Dunstan wrote:
> Here's the diff from a pgindent run.
--- a/src/backend/commands/policy.c
+++ b/src/backend/commands/policy.c
@@ -587,65 +587,65 @@ RemoveRoleFromObjectPolicy(Oid roleid, Oid
classid, Oid policy_id)
/* If any roles remain, update the policy e
Alvaro Herrera writes:
> I forgot to mention:
>
> > + /* XXX useless without a flush ...? */
> > + pqFlush(conn);
> > +
> > + return 1;
> > +}
>
> I'm not sure if it's a good idea for PQrequestFlush to itself flush
> libpq's buffer. We can just document that PQflush is required ...
> opi
I happened to spot the below call in src/bin/pg_basebackup/streamutil.c which
has an unbounded %s in the format.
/* fetch xlog value and unit from the result */
if (sscanf(PQgetvalue(res, 0, 0), "%d%s", &xlog_val, xlog_unit) != 2)
There is no risk of overflow as the unit is defined to be
On 6/28/21 8:52 AM, David Rowley wrote:
> On Tue, 29 Jun 2021 at 00:29, Andrew Dunstan wrote:
>> Here's the diff from a pgindent run.
> --- a/src/backend/commands/policy.c
> +++ b/src/backend/commands/policy.c
> @@ -587,65 +587,65 @@ RemoveRoleFromObjectPolicy(Oid roleid, Oid
> classid, Oid poli
On Mon, 2021-06-28 at 23:46 +1200, David Rowley wrote:
> On Sat, 26 Jun 2021 at 16:41, Justin Pryzby wrote:
> > On Thu, Jun 24, 2021 at 10:27:06AM +1200, David Rowley wrote:
> > > I think the reasons for doing operations directly on partitions are
> > > being reduced with each release. What opera
Michael Paquier writes:
> On Sat, Jun 26, 2021 at 05:29:29PM -0400, Tom Lane wrote:
>> I'll stick this into the CF list to see if the cfbot agrees that
>> it finds the abort() problems...
> The CF Bot is finding those problems.
>> +# Check for functions that libpq must not call.
>> +# (If nm doe
Fabien COELHO writes:
> A possible trick is to add ccp flags such as: -Dexit=exit_BAD
> -Dabort=abort_BAD.
Not really going to work, at least not without a lot of fragile
kluges, because the main problem here is to prevent libpq from
*indirectly* calling those functions via stuff it imports from
Daniel Gustafsson writes:
> I happened to spot the below call in src/bin/pg_basebackup/streamutil.c which
> has an unbounded %s in the format.
> /* fetch xlog value and unit from the result */
> if (sscanf(PQgetvalue(res, 0, 0), "%d%s", &xlog_val, xlog_unit) != 2)
> There is no risk of o
Le 27/06/2021 à 17:14, Tom Lane a écrit :
Julien Rouhaud writes:
On Sun, Jun 27, 2021 at 10:34:52AM -0400, Tom Lane wrote:
It's not very hard to imagine someday moving view
expansion into the planner on efficiency grounds, leaving the rewriter
handling only the rare uses of INSERT/UPDATE/DELET
On 6/28/21 8:29 AM, Andrew Dunstan wrote:
> Here's the diff from a pgindent run. The results look kosher to me - I
> had to do a little surgery on queryjumble.h due to it having an unused
> typedef.
>
>
This time run against the right branch ..
cheers
andrew
--
Andrew Dunstan
EDB: https://w
Peter Eisentraut writes:
> There are certain parts of code that laboriously initialize every field
> of a struct to (some spelling of) zero, even though the whole struct was
> just zeroed (by makeNode() or memset()) a few lines earlier.
FWIW, I think that it's an intentional style choice to exp
Andrew Dunstan writes:
> On 6/28/21 8:52 AM, David Rowley wrote:
>> I wasn't too sure about the status of this one. Michael did mention it
>> in [1], but Tom mentioned that was on purpose to ease backpatching.
>> I'm not too clear on if Tom intended it should stay unindented until
>> "rewriting th
I wrote:
> Andrew Dunstan writes:
>> I'll let Tom speak for himself, but I somewhat doubt he meant the code
>> to stay badly indented for more than a short period of time.
> I did not. If you can give me an hour or so, I'll get the patch
> I previously proposed [1] committed, and then this issue
> On 28 Jun 2021, at 16:02, Tom Lane wrote:
> Ugh. Shouldn't we instead modify the format to read not more than
> two characters? Even if this is safe on non-malicious input, it
> doesn't seem like good style.
No disagreement, I was only basing it on what is in the tree. I would propose
that
On 6/28/21 10:44 AM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan writes:
>>> I'll let Tom speak for himself, but I somewhat doubt he meant the code
>>> to stay badly indented for more than a short period of time.
>> I did not. If you can give me an hour or so, I'll get the patch
>> I previousl
On Thu, Jun 24, 2021 at 12:04 PM Michael Paquier wrote:
>
> On Tue, Apr 20, 2021 at 07:36:39AM +0530, Bharath Rupireddy wrote:
> > I'm attaching 3 patches that replace pg_usleep with WaitLatch: 0001 in
> > lazy_truncate_heap, 0002 in do_pg_stop_backup and 0003 for Pre and
> > Post Auth Delay. Regr
Andrew Dunstan writes:
> On 6/28/21 10:44 AM, Tom Lane wrote:
>> Wait ... I did already, at 5a0f1c8c0. Are you sure you were indenting
>> current HEAD?
> No, see revised patch. I posted at 10.13
Right, new version looks better.
regards, tom lane
Bharath Rupireddy writes:
> On Thu, Jun 24, 2021 at 12:04 PM Michael Paquier wrote:
>> On top of that, not reacting on signals can be
>> interesting to keep as a behavior for developers?
> Yeah, it can be useful at times as it enables debugging even when the
> postmaster dies.
Dunno ... I canno
On 6/27/21 10:55 AM, Andrew Dunstan wrote:
> I am planning on forking the tree so we can start adding developments
> for Postgres 15 in the upcoming commitfest. This will be done tomorrow,
> June 28, late morning US East coast time. I will be following the
> procedures laid out in src/tools/RELEA
> On Jun 27, 2021, at 3:41 AM, Andrey Borodin wrote:
>
> And here's what I've come up with.
I have not tested the patch yet, but here are some quick review comments:
> #define PGLZ_HISTORY_SIZE 0x0fff - 1 /* to avoid compare in iteration
> */
...
> static PGLZ_HistEntry hist_entries
> On Jun 28, 2021, at 9:05 AM, Mark Dilger wrote:
>
> Is it worth sharting a static inline function that uses your optimization in
> other places?
s/sharting/sharing/
> How confident are you that your optimization really helps?
By which I mean, is the optimization worth the extra branch
Thanks for the feedback Gilles!
On Mon, Jun 28, 2021 at 04:06:54PM +0200, Gilles Darold wrote:
>
> If we could at least call get_query_def()through an extension if we didn't
> have a functionit would be ideal for DBAs.I agree this is unusual but when
> it does happen to you being able to call get
Fabien COELHO writes:
>> I suggest applying the attached in branches that have the required
>> functions.
> The proposed patch does fix the issue in pgbench TAP test. I'd suggest to
> add unlikely() on all these conditions, as already done elsewhere. See
> attached version.
Done that way, tho
On 2021-Jun-28, Daniel Gustafsson wrote:
> I happened to spot the below call in src/bin/pg_basebackup/streamutil.c which
> has an unbounded %s in the format.
>
> /* fetch xlog value and unit from the result */
> if (sscanf(PQgetvalue(res, 0, 0), "%d%s", &xlog_val, xlog_unit) != 2)
>
> Th
On 4/24/21 3:14 PM, Alvaro Herrera wrote:
> On 2021-Apr-24, Andrew Dunstan wrote:
>
>> I would like to undertake some housekeeping on PostgresNode.pm.
>>
>> 1. OO modules in perl typically don't export anything. We should remove
>> the export settings. That would mean that clients would have to ca
Andrew Dunstan writes:
> This has been completed.
Doesn't look like the buildfarm has heard of REL_14_STABLE yet?
regards, tom lane
On 6/28/21 1:04 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> This has been completed.
> Doesn't look like the buildfarm has heard of REL_14_STABLE yet?
>
>
Will do shortly. On at least one occasion we've been caught by updating
it before the new branch had reached mi
Le 28/06/2021 à 18:41, Julien Rouhaud a écrit :
> Thanks for the feedback Gilles!
>
> On Mon, Jun 28, 2021 at 04:06:54PM +0200, Gilles Darold wrote:
>> If we could at least call get_query_def()through an extension if we didn't
>> have a functionit would be ideal for DBAs.I agree this is unusual but
On Wed, Jun 16, 2021 at 1:55 AM Thomas Munro wrote:
[v2 patch]
Hi Thomas,
I plan to do some performance testing with VACUUM, ANALYZE etc soon, to see
if I can detect any significant differences.
I did a quick check of the MacOS/clang binary size (no debug symbols):
master:8108408
0001-0009
I wrote:
>> Not real sure what to do about PGTHREAD_ERROR.
> I wonder if we shouldn't simply nuke that macro and change the
> call sites into "Assert(false)".
After further study this still seems like the best available choice.
We do not have the option to make either default_threadlock() or
pq_l
On Mon, Jun 28, 2021 at 11:45 AM Arne Roland wrote:
> Hi,
>
> *From:* Zhihong Yu
> *Sent:* Monday, June 28, 2021 15:28
> *Subject:* Re: Rename of triggers for partitioned tables
>
> > -void *arg)
> > +callbackForRenameTrigger(char *relname, Oid relid)
> >
> > Sinc
The README for pg_indent says:
./configure # "make" will not work in an unconfigured tree
cd src/include/catalog
make reformat-dat-files
cd ../../..
This looks like a case of using a sledgehammer to crack a nut.
I did this, which amounts to the same thing and is faster:
Andrew Dunstan writes:
> The README for pg_indent says:
> ./configure # "make" will not work in an unconfigured tree
> cd src/include/catalog
> make reformat-dat-files
> cd ../../..
> This looks like a case of using a sledgehammer to crack a nut.
> I did this, which amounts
On Sun, 27 Jun 2021, Tom Lane wrote:
You should let the server infer its type, instead, which it can easily
do from context in this example. That is, pass zero as the type OID, or
leave out the paramTypes
Ah, thank you, that works brilliantly. Sorry for the noise!
-E
> On 28 Jun 2021, at 21:15, Tom Lane wrote:
> I wrote:
>>> Not real sure what to do about PGTHREAD_ERROR.
>
>> I wonder if we shouldn't simply nuke that macro and change the
>> call sites into "Assert(false)".
>
> After further study this still seems like the best available choice.
While this
I wrote:
> This relies on "nm" being able to work on shlibs, which it's not
> required to by POSIX. However, it seems to behave as desired even
> on my oldest dinosaurs. In any case, if "nm" doesn't work then
> we'll just not detect such problems on that platform, which should
> be OK as long as
On Sun, Jun 27, 2021 at 11:08 PM Peter Geoghegan wrote:
> > That said, the relevant table is the active "alarms" table, and it would've
> > gotten plenty of DML with no issue for months running v13.
>
> It might not have been visibly broken without assertions enabled,
> though. I sprinkled nbtdedu
Here I'm just reviewing a couple items in the Sorting section:
https://wiki.postgresql.org/wiki/Todo#Sorting
- Consider whether duplicate keys should be sorted by block/offset
https://www.postgresql.org/message-id/flat/23321.1205726381%40sss.pgh.pa.us
It's moot since we started requiring tid as
On Tue, 2021-04-20 at 14:19 -0700, SATYANARAYANA NARLAPURAM wrote:
> One idea here is to make the backend ignore query
> cancellation/backend termination while waiting for the synchronous
> commit ACK. This way client never reads the data that was never
> flushed remotely. The problem with this app
On Mon, Jun 28, 2021 at 01:42:25PM -0700, Peter Geoghegan wrote:
> On Sun, Jun 27, 2021 at 11:08 PM Peter Geoghegan wrote:
> > > That said, the relevant table is the active "alarms" table, and it
> > > would've
> > > gotten plenty of DML with no issue for months running v13.
> >
> > It might not
Hi John,
On Tue, Jun 29, 2021 at 7:13 AM John Naylor
wrote:
> I plan to do some performance testing with VACUUM, ANALYZE etc soon, to see
> if I can detect any significant differences.
Thanks!
> I did a quick check of the MacOS/clang binary size (no debug symbols):
>
> master:8108408
> 000
On Fri, Jun 25, 2021 at 06:04:56PM -0500, Justin Pryzby wrote:
> > Require custom server variable names to use only character which are valid
> > for unquoted SQL identifiers (Tom Lane)
>
> characters plural (since 69a58bfe4)
Fixed.
> > This is similar to how Unicode can be specified in literal
I spotted a mistake in v3: I didn't rename ST_COMPARE_TYPE to
ST_COMPARE_RET_TYPE in the 0009 patch (well, I did, but forgot to
commit before I ran git format-patch). I won't send another tarball
just for that, but will correct it next time.
On Wed, Apr 21, 2021 at 10:40:07AM -0500, Justin Pryzby wrote:
> On Thu, Apr 22, 2021 at 12:13:17AM +0900, Fujii Masao wrote:
> > On 2021/04/21 23:53, Justin Pryzby wrote:
> > > Or:
> > >
> > > Enabling this parameter may incur a noticeable performance
> > > penalty,
> > > especia
On Mon, Jun 28, 2021 at 09:01:40PM -0400, Bruce Momjian wrote:
> On Fri, Jun 25, 2021 at 06:04:56PM -0500, Justin Pryzby wrote:
> > > The postgres_fdw supports these type of scans if async_capable is set.
> > this type
> > remove "The" ?
>
> New text is:
>
> linkend="postgres-fdw">po
On Tue, Jun 29, 2021 at 10:09 AM Justin Pryzby wrote:
>
> Checking back - here's the latest patch.
>
> diff --git a/doc/src/sgml/pgstatstatements.sgml
> b/doc/src/sgml/pgstatstatements.sgml
> index 930081c429..9e98472c5c 100644
> --- a/doc/src/sgml/pgstatstatements.sgml
> +++ b/doc/src/sgml/pgsta
On Tue, Jun 29, 2021 at 10:29:43AM +0800, Julien Rouhaud wrote:
> On Tue, Jun 29, 2021 at 10:09 AM Justin Pryzby wrote:
>
> Is "identical structure" really accurate here? For instance a multi
> tenant application could rely on the search_path and only use
> unqualified relation name. So while t
On Mon, Jun 28, 2021 at 11:02 AM vignesh C wrote:
>
> On Mon, Jun 7, 2021 at 2:38 PM Amit Kapila wrote:
> >
> > On Thu, Jun 3, 2021 at 10:39 PM Tom Lane wrote:
> > >
>
> Attached patch has the documentation changes for the back-branches. As
> there is no specific reason for this, I have just men
On Friday, June 25, 2021 2:25 AM vignesh C wrote:
>
> Thanks for reporting these warnings, I have fixed this in the v8 patch
> attached at [1].
> [1] - https://www.postgresql.org/message-
> id/CALDaNm044P_cds1OxZvFse5rE_qQfhbUg5MdtMgsa7t_bZGJdw%40mail.
> gmail.com
>
Thanks for your patch. The wa
On Tue, Jun 22, 2021 at 09:11:26AM +0900, Michael Paquier wrote:
> What about the following error then? Say:
> "image at %X/%X compressed with LZ4 not supported by build, block
> %d".
>
>> Also, maybe %s can be inlined to lz4 in this case.
>
> I think that's a remnant of the zstd part of the pat
Laurenz,
Thanks for your comments. Sorry it's taken me so long to get back to you.
Commenting inline below on anything I think needs comment; other proposed
changes look good.
On Sun, 30 May 2021 at 19:20, Laurenz Albe wrote:
> + always use linkend="xfunc-sleeping-interrupts-blocking">Postgr
On Sat, 20 Mar 2021 at 03:46, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Mar 19, 2021 at 3:25 PM Tom Lane wrote:
> >> I'm not very comfortable about the idea of having the postmaster set
> >> child processes' latches ... that doesn't sound terribly safe from the
> >> standpoint of not al
On Sun, May 02, 2021 at 10:57:47PM -0700, Noah Misch wrote:
> On Sat, May 01, 2021 at 09:43:36AM -0700, Zhihong Yu wrote:
> > On Sat, May 1, 2021 at 8:16 AM Asif Rehman wrote:
> > > The new status of this patch is: Ready for Committer
> I'll push this when v15 branches.
Done. This upset one bui
On Mon, 1 Feb 2021 at 18:42, Craig Ringer
wrote:
> On Sun, 24 Jan 2021 at 09:12, Andres Freund wrote:
>
>> Hi,
>>
>> On 2021-01-19 14:16:07 +0800, Craig Ringer wrote:
>> > AFAICS it'd be necessary to expand PROCLOG to expose this in shmem.
>> > Probably by adding a small bitfield where bit 0 is
Noah Misch writes:
> Done. This upset one buildfarm member so far:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur&dt=2021-06-29%2001%3A43%3A14
> I don't know what happened there. Tom, could you post a tar of the
> src/bin/pg_dump/tmp_check/tmp_test_* directory after a failed "ma
On Thu, 6 May 2021 at 19:40, Amit Kapila wrote:
> On Thu, May 6, 2021 at 9:54 AM Craig Ringer wrote:
> >
> At the least it'd be helpful to have pg_stat_replication (or a new
> related auxiliary view like pg_stat_logical_decoding) show
> >
> > - walsender total bytes sent this session
> > - numb
On 21.06.21 13:53, John Naylor wrote:
> This patch changes places like this
>
> DECLARE_UNIQUE_INDEX_PKEY(pg_aggregate_fnoid_index, 2650, on
> pg_aggregate using btree(aggfnoid oid_ops));
> #define AggregateFnoidIndexId 2650
>
> to this
>
> DECLARE_UNIQUE_INDEX_PKEY(pg_aggregate_fnoid_i
Hi,
I want to add the '--ignore-errors' option into the pg_regress module.
I understand it can't be used in the regression or TAP tests. But such
option is useful to test a custom extension. A custom extension couldn't
pass all check-world tests and will be stopped at the end of first stage.
M
> 29 июня 2021 г., в 08:41, Michael Paquier написал(а):
>
> Now that v15 is open for business, I have looked again at this stuff
> this morning and committed the LZ4 part
That's great, thanks Michael!
Best regards, Andrey Borodin.
> 29 июня 2021 г., в 03:56, Jeff Davis написал(а):
>
> The patch may be somewhat controversial, so I'll wait for feedback
> before documenting it properly.
The patch seems similar to [0]. But I like your wording :)
I'd be happy if we go with any version of these idea.
Best regards, Andrey Bo
On Wed, Jun 23, 2021 at 4:10 PM Ajin Cherian wrote:
>
The first two patches look mostly good to me. I have combined them
into one and made some minor changes. (a) Removed opt_two_phase and
related code from repl_gram.y as that is not required for this version
of the patch. (b) made some changes i
On Tue, Jun 29, 2021 at 1:11 PM Thomas Munro wrote:
> I spotted a mistake in v3: I didn't rename ST_COMPARE_TYPE to
> ST_COMPARE_RET_TYPE in the 0009 patch (well, I did, but forgot to
> commit before I ran git format-patch). I won't send another tarball
> just for that, but will correct it next t
On Wed, Jun 23, 2021 at 09:39:37AM +0900, Michael Paquier wrote:
> Perhaps you are right to keep it simple. If people would like to
> document that more precisely, it could always be changed if
> necessary. What you have here sounds pretty much right to me.
So, I was looking at this one today, a
86 matches
Mail list logo
