On Wed, 30 Jun 2021 14:35:37 +0900
Yugo NAGATA wrote:
> Hello Asif,
>
> On Tue, 29 Jun 2021 13:21:54 +
> Asif Rehman wrote:
>
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, passed
> > Implements feature: tested,
On Tue, Jun 29, 2021 at 8:56 PM Bharath Rupireddy
wrote:
>
> On Tue, Jun 29, 2021 at 4:37 PM Amit Kapila wrote:
> > Few comments:
> > ===
>
> > 2.
> > +parse_subscription_options(List *stmt_options, SubOpts *opts)
> > {
> > ListCell *lc;
> > - bool connect_given = false;
> > -
Hello Asif,
On Tue, 29 Jun 2021 13:21:54 +
Asif Rehman wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:
On Tue, Jun 29, 2021 at 9:41 PM Alvaro Herrera wrote:
>
> On 2021-Jun-29, Bharath Rupireddy wrote:
>
> > On Tue, Jun 29, 2021 at 4:37 PM Amit Kapila wrote:
> > > Few comments:
> > > ===
> > > 1.
> > > +typedef struct SubOpts
> > > +{
> > > + bits32 supported_opts; /* bitmap of
Rebased.
--
Takashi Menjo
v3-0001-Add-with-libpmem-option-for-PMEM-support.patch
Description: Binary data
v3-0002-Add-wal_pmem_map-to-GUC.patch
Description: Binary data
v3-0003-Export-InstallXLogFileSegment.patch
Description: Binary data
On 11/5/21 06:55, Zhihong Yu wrote:
On Mon, May 10, 2021 at 8:45 PM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
It seems the if statement is not needed: you can directly assign false
to subplan->async_capable.
I have completely rewritten this patch.
Main idea:
The
On Mon, Jun 28, 2021 at 01:02:37PM -0400, Andrew Dunstan wrote:
> Patch 1 adds back the '-w' flag to pg_ctl in the start() method. It's
> redundant on modern versions of Postgres but it's harmless, and helps
> with subclassing for older versions where it wasn't the default.
05cd12e applied to all
On Wed, Jun 30, 2021 at 9:29 AM Amit Kapila wrote:
>
> On Tue, Jun 29, 2021 at 12:57 PM Dilip Kumar wrote:
> >
> > On Fri, Jun 25, 2021 at 12:24 PM Amit Kapila
> > wrote:
> > >
> > > Till now, we didn't allow to stream the changes in logical replication
> > > till we receive speculative
On Tue, Jun 29, 2021 at 10:41 PM Ronan Dunklau
wrote:
> Le mardi 29 juin 2021, 10:55:59 CEST Richard Guo a écrit :
> > On Tue, Jun 29, 2021 at 3:55 PM Emre Hasegeli wrote:
> > > > Thanks for the explanation. Attached is a demo code for the hash-join
> > > > case, which is only for PoC to show
On Tue, Jun 29, 2021 at 12:57 PM Dilip Kumar wrote:
>
> On Fri, Jun 25, 2021 at 12:24 PM Amit Kapila wrote:
> >
> > Till now, we didn't allow to stream the changes in logical replication
> > till we receive speculative confirm or the next DML change record
> > after speculative inserts. The
On Tue, Jun 29, 2021 at 02:45:17PM +, gkokola...@pm.me wrote:
> The program pg_receivewal can use gzip compression to store the received WAL.
> This patch teaches it to be able to use lz4 compression if the binary is build
> using the -llz4 flag.
Nice.
> Previously, the user had to use the
On Mon, Jun 28, 2021 at 08:51:50AM -0400, Andrew Dunstan wrote:
> On 6/28/21 2:39 AM, Peter Geoghegan wrote:
> > I agree that in practice that's often fine. But my point is that there
> > is another very good reason to not increase autovacuum_freeze_max_age,
> > contrary to what the docs say
Alvaro Herrera writes:
> Ah, I nm'd all files in src/interfaces/libpq and got no hits for abort.
> But I did get one in libpgport_shlib.a:
> path_shlib.o:
> U abort
Yeah, there is one in get_progname(). But path.o shouldn't be getting
pulled into libpq ... else why aren't all
Anastasia Lubennikova писал 2021-06-30 00:49:
Hi, hackers!
Many recently discussed features can make use of an extensible storage
manager API. Namely, storage level compression and encryption [1],
[2], [3], disk quota feature [4], SLRU storage changes [5], and any
other features that may want
On Sat, Mar 27, 2021 at 11:41:07AM +0100, Laurenz Albe wrote:
> On Sat, 2021-03-27 at 00:50 -0700, Noah Misch wrote:
> > On Sat, Feb 13, 2021 at 04:56:29AM -0800, Noah Misch wrote:
> > > I'm attaching the patch for $SUBJECT, which applies atop the four patches
> > > from
> > > the two other
On Tue, Jun 29, 2021 at 11:03:30PM +0100, Simon Riggs wrote:
> PITR of Abort Prepared generates the wrong log message.
Good catch! This is wrong since 4f1b890 and 9.5, so this needs a
backpatch all the way down.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jun 29, 2021 at 09:10:30AM -0400, Greg Sabino Mullane wrote:
> Looks great, I appreciate the renaming.
Applied, then.
--
Michael
signature.asc
Description: PGP signature
At Tue, 29 Jun 2021 20:13:14 +, ahsan hadi wrote in
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:not
Ah, I nm'd all files in src/interfaces/libpq and got no hits for abort.
But I did get one in libpgport_shlib.a:
path_shlib.o:
U abort
0320 T canonicalize_path
0197 T cleanup_path
09e3 t
On 2021-Jun-29, Tom Lane wrote:
> More troublingly, fossa reports this:
>
> ! nm -A -g -u libpq.so.5.15 2>/dev/null | grep -v '_eprintf\\.o:' | grep -e
> abort -e exit
> libpq.so.5.15: U abort@@GLIBC_2.2.5
>
> Where is that coming from? hippopotamus and jay, which seem to
> be
st 30. 6. 2021 v 1:20 odesílatel Tomas Vondra
napsal:
>
>
>
> On 6/30/21 12:53 AM, Josef Šimánek wrote:
> > st 30. 6. 2021 v 0:31 odesílatel Josef Šimánek
> > napsal:
> >>
> >> Hello!
> >>
> >> Tomáš Vondra has shared a few ideas to improve BRIN index in czech
> >> PostgreSQL mail list some
On 6/30/21 12:53 AM, Josef Šimánek wrote:
st 30. 6. 2021 v 0:31 odesílatel Josef Šimánek napsal:
Hello!
Tomáš Vondra has shared a few ideas to improve BRIN index in czech
PostgreSQL mail list some time ago [1 , in czech only]. This is first
try to implement one of those ideas.
Currently
st 30. 6. 2021 v 0:31 odesílatel Josef Šimánek napsal:
>
> Hello!
>
> Tomáš Vondra has shared a few ideas to improve BRIN index in czech
> PostgreSQL mail list some time ago [1 , in czech only]. This is first
> try to implement one of those ideas.
>
> Currently BRIN index blocks HOT update even
Hello!
Tomáš Vondra has shared a few ideas to improve BRIN index in czech
PostgreSQL mail list some time ago [1 , in czech only]. This is first
try to implement one of those ideas.
Currently BRIN index blocks HOT update even it is not linked tuples
directly. I'm attaching the initial patch
PITR of Abort Prepared generates the wrong log message.
Fix attached
--
Simon Riggshttp://www.EnterpriseDB.com/
pitr_recoveryStopsBefore_AbortPrepared.v1.patch
Description: Binary data
Hi, hackers!
Many recently discussed features can make use of an extensible storage
manager API. Namely, storage level compression and encryption [1], [2], [3],
disk quota feature [4], SLRU storage changes [5], and any other features
that may want to substitute PostgreSQL storage layer with their
On Tue, Jun 29, 2021 at 4:46 PM Dean Rasheed wrote:
> On Tue, 29 Jun 2021 at 21:34, Robert Haas wrote:
> > I thought about this too, but
> > http://postgr.es/m/774767.1591985...@sss.pgh.pa.us made me think that
> > it would be an on-disk format break. Maybe it's not, though?
>
> No, because the
Robert Haas writes:
> On Tue, Jun 29, 2021 at 3:58 PM Dean Rasheed wrote:
>> When specifying NUMERIC(precision, scale) the scale is constrained to
>> the range [0, precision], which is per SQL spec. However, at least one
>> other major database vendor intentionally does not impose this
>>
Hello Tom,
The failure still represents a gcc bug, because we're using -fwrapv which
should disable that assumption.
Ok, I'll report it.
Done at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254
Fixed at r12-1916-ga96d8d67d0073a7031c0712bc3fb7759417b2125
On Tue, 29 Jun 2021 at 21:34, Robert Haas wrote:
>
> I thought about this too, but
> http://postgr.es/m/774767.1591985...@sss.pgh.pa.us made me think that
> it would be an on-disk format break. Maybe it's not, though?
>
No, because the numeric dscale remains non-negative, so there's no
change to
I wrote:
> So I pushed that, and not very surprisingly, it's run into some
> portability problems. gombessa (recent OpenBSD) reports
> ! nm -A -g -u libpq.so.5.15 2>/dev/null | grep -v '_eprintf\\.o:' | grep -e
> abort -e exit
> libpq.so.5.15:__cxa_atexit
After a few more hours, all of our
On Tue, Jun 29, 2021 at 3:58 PM Dean Rasheed wrote:
> When specifying NUMERIC(precision, scale) the scale is constrained to
> the range [0, precision], which is per SQL spec. However, at least one
> other major database vendor intentionally does not impose this
> restriction, since allowing
On 2021-Jun-29, Ranier Vilela wrote:
> On 2021-Jun-29, Alvaro Herrera wrote:
>
> >Ah, yes it does. I can reproduce this now. I thought PQconsumeInput
> >was sufficient, but it's not: you have to have the PQgetResult in there
> >too. Looking ...
>
> I think that has an oversight with a719232
>
On Thu, 2021-03-04 at 00:03 +, Jacob Champion wrote:
> Hello all,
>
> Andrew pointed out elsewhere [1] that it's pretty difficult to add new
> certificates to the test/ssl suite without blowing away the current
> state and starting over. I needed new cases for the NSS backend work,
> and ran
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
I have tested it with various object types and getting a
On 2021-Jun-29, Alvaro Herrera wrote:
>Ah, yes it does. I can reproduce this now. I thought PQconsumeInput
>was sufficient, but it's not: you have to have the PQgetResult in there
>too. Looking ...
I think that has an oversight with a719232
return false shouldn't be return 0?
regards,
Ranier
When specifying NUMERIC(precision, scale) the scale is constrained to
the range [0, precision], which is per SQL spec. However, at least one
other major database vendor intentionally does not impose this
restriction, since allowing scales outside this range can be useful.
A negative scale implies
Jacob Champion writes:
> On Tue, 2021-06-29 at 14:50 -0400, Tom Lane wrote:
>> The existing convention is to use pqexpbuffer.c, which seems strictly
>> cleaner and more robust than asprintf. In particular its behavior under
>> OOM conditions is far easier/safer to work with. Maybe we should
On Tue, 2021-06-29 at 14:50 -0400, Tom Lane wrote:
> Jacob Champion writes:
> > What would you think about a src/port of asprintf()? Maybe libpq
> > doesn't change quickly enough to worry about it, but having developers
> > revisit stack allocation for strings every time they target the libpq
> >
Jacob Champion writes:
> What would you think about a src/port of asprintf()? Maybe libpq
> doesn't change quickly enough to worry about it, but having developers
> revisit stack allocation for strings every time they target the libpq
> parts of the code seems like a recipe for security problems.
On Fri, Jun 25, 2021 at 2:56 AM Bruce Momjian wrote:
>
> On Wed, Jun 23, 2021 at 07:45:53AM -0700, Peter Geoghegan wrote:
> > On Wed, Jun 23, 2021 at 5:50 AM Simon Riggs
> > wrote:
> > > I just noticed that these commits are missing, yet are very important
> > > new features:
> > >
On Tue, 2021-06-29 at 11:48 +0500, Andrey Borodin wrote:
> > 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
On Sat, 2021-06-26 at 09:36 +0900, Michael Paquier wrote:
> On Fri, Jun 25, 2021 at 08:58:46PM +, Jacob Champion wrote:
> > On Thu, 2021-06-24 at 14:56 +0900, Michael Paquier wrote:
> > > Looking more closely at that, I actually find a bit crazy the
> > > requirement for any logging within
On Sun, 2021-06-27 at 10:43 +0900, Michael Paquier wrote:
> On Sat, Jun 26, 2021 at 01:43:50PM -0400, Tom Lane wrote:
> > BTW, so far as the original topic of this thread is concerned,
> > it sounds like Jacob's ultimate goal is to put some functionality
> > into libpq that requires JSON parsing.
On 29/6/21 20:59, Tom Lane wrote:
Andrey Lepikhov writes:
BTW, I wonder if you can't get much or all of the same effect
from "make -k check-world".
Thank you, 'make -k' is suitable solution in such situation.
--
regards,
Andrey Lepikhov
Postgres Professional
Andrey Lepikhov writes:
> 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.
I'm really skeptical that this has any positive use. It seems more
likely to
Andres Freund writes:
> On 2021-04-26 12:53:30 -0500, David Christensen wrote:
>> On Mon, Apr 26, 2021 at 12:18 PM Julien Rouhaud wrote:
>> > Using pg_stat_statements with a different query_id semantics without
>> > having to fork pg_stat_statements.
>> >
>>
>> I can see that argument for
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
shinya11.k...@nttdata.com writes:
>>I had not really looked at the patch, but if there's a cleanup portion to the
>>same
>>patch as you're adding the YB too, then maybe it's worth separating those out
>>into another patch so that the two can be considered independently.
>
> I agree with this
On 2021-Jun-29, Alvaro Herrera wrote:
> (I do see that you're doing PQisBusy that I'm not. Going to try adding
> it next.)
Ah, yes it does. I can reproduce this now. I thought PQconsumeInput
was sufficient, but it's not: you have to have the PQgetResult in there
too. Looking ...
--
Álvaro
> On 29 Jun 2021, at 18:50, Zhihong Yu wrote:
> Now that PG 15 is open for commit, do you think the patch can land ?
Adding it to the commitfest patch tracker is a good way to ensure it's not
forgotten about:
https://commitfest.postgresql.org/33/
--
Daniel Gustafsson
On Fri, May 7, 2021 at 7:42 PM Bruce Momjian wrote:
> On Fri, May 7, 2021 at 07:39:31PM -0700, Zhihong Yu wrote:
> >
> >
> > On Fri, May 7, 2021 at 7:23 PM Bruce Momjian wrote:
> >
> > On Fri, May 7, 2021 at 07:23:42PM -0700, Zhihong Yu wrote:
> > > On Tue, Apr 13, 2021 at 10:55 AM
On Tue, Jun 29, 2021 at 2:56 AM Thomas Munro wrote:
> Here's a version that includes a rather hackish test module that you
> might find useful to explore various weird effects. Testing sorting
> routines is really hard, of course... there's a zillion parameters and
> things you could do in the
Noah Misch writes:
> On Tue, Jun 29, 2021 at 01:53:42AM -0400, Tom Lane wrote:
>> Noah Misch writes:
>>> Done. This upset one buildfarm member so far:
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur=2021-06-29%2001%3A43%3A14
>> I'm too tired to look at it right now, but
On 2021-Jun-29, Bharath Rupireddy wrote:
> On Tue, Jun 29, 2021 at 4:37 PM Amit Kapila wrote:
> > Few comments:
> > ===
> > 1.
> > +typedef struct SubOpts
> > +{
> > + bits32 supported_opts; /* bitmap of supported SUBOPT_* */
> > + bits32 specified_opts; /* bitmap of user specified
On Tue, Jun 29, 2021 at 4:37 PM Amit Kapila wrote:
> Few comments:
> ===
> 1.
> +typedef struct SubOpts
> +{
> + bits32 supported_opts; /* bitmap of supported SUBOPT_* */
> + bits32 specified_opts; /* bitmap of user specified SUBOPT_* */
>
> I think it will be better to not keep
On Tue, Jun 29, 2021 at 10:45 AM Justin Pryzby wrote:
>
> We borrowed that language from the previous text:
>
> | Plannable queries (that is, SELECT, INSERT, UPDATE, and DELETE) are
> combined into a single pg_stat_statements entry whenever they have identical
> query structures according to an
On 2021-Jun-29, Boris Kolpackov wrote:
> Alvaro Herrera writes:
>
> > No luck reproducing any problems with this sequence as yet.
>
> Can you try to recreate the call flow as implemented here (it's
> pretty much plain old C if you ignore error handling):
>
Hi,
The program pg_receivewal can use gzip compression to store the received WAL.
This patch teaches it to be able to use lz4 compression if the binary is build
using the -llz4 flag.
Previously, the user had to use the option --compress with a value between [0-9]
to denote that gzip compression
Le mardi 29 juin 2021, 10:55:59 CEST Richard Guo a écrit :
> On Tue, Jun 29, 2021 at 3:55 PM Emre Hasegeli wrote:
> > > Thanks for the explanation. Attached is a demo code for the hash-join
> > > case, which is only for PoC to show how we can make it work. It's far
> > > from complete, at least
On Fri, Jun 18, 2021 at 10:06 PM Alexey Kondratov
wrote:
> On Fri, Jun 18, 2021 at 5:42 PM Andrey Borodin wrote:
> >
> > If we run 'pg_rewind --restore-target-wal' there must be restore_command in
> > config of target installation. But if the config is not within
> > $PGDATA\postgresql.conf
Hi,
Not per Coverity.
hash_choose_num_partitions function has issues.
There are at least two path calls made with used_bits = 0.
See at hashagg_spill_init.
To confirm, I run this code on cpp.sh:
int main()
{
int npartitions = 0;
int used_bits = 0;
int partition_bits = 0;
int i;
Alvaro Herrera writes:
> No luck reproducing any problems with this sequence as yet.
Can you try to recreate the call flow as implemented here (it's
pretty much plain old C if you ignore error handling):
On 2021-Jun-24, Boris Kolpackov wrote:
> I've hit another similar case except now an unexpected NULL result is
> returned in the middle of PGRES_PIPELINE_ABORTED result sequence. The
> call sequence is as follows:
>
> PQsendQueryPrepared() # INSERT #1
> PQflush()
> PQsendQueryPrepared() # INSERT
Here is an updated patch with some merge conflicts resolved, to keep it
fresh. It's still pending in the commit fest from last time.
My focus right now is to work on the "psql - add SHOW_ALL_RESULTS
option" patch (https://commitfest.postgresql.org/33/2096/) first, which
is pretty much a
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
This patch looks fine to me. master 48cb244fb9
The new status
On Tue, Jun 29, 2021 at 2:59 AM Michael Paquier wrote:
> Does that look fine to you?
>
Looks great, I appreciate the renaming.
Cheers,
Greg
On Tue, Jun 29, 2021 at 5:12 PM Masahiko Sawada wrote:
>
> Hi all,
>
> I realized that we use the magic number 10 instead of
> PG_STAT_GET_REPLICATION_SLOT_COLS in pg_stat_get_replication_slot()
> function. It seems an oversight of the original commit. Attached patch
> fixes it.
>
LGTM. I'll
On Tue, Jun 29, 2021 at 12:26 PM Amit Kapila wrote:
>
> 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
Hi all,
I realized that we use the magic number 10 instead of
PG_STAT_GET_REPLICATION_SLOT_COLS in pg_stat_get_replication_slot()
function. It seems an oversight of the original commit. Attached patch
fixes it.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
I still wasn't quite happy with the churn in the regression tests, so for
v13 I gave up on using both the existing utf8 table and my new one for the
"padded input" tests, and instead just copied the NUL byte test into the
new table. Also added a primary key to make sure the padded test won't give
Numeric x^y is supported for x < 0 if y is an integer, but this
currently fails if y is outside the range of an int32:
SELECT (-1.0) ^ 2147483647;
?column?
-
-1.
(1 row)
SELECT (-1.0) ^ 2147483648;
ERROR: cannot take logarithm of a negative number
On Mon, Jun 28, 2021 at 3:24 PM Bharath Rupireddy
wrote:
>
> 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.
>
Few comments:
===
1.
Thanks for looking!
On Mon, 28 Jun 2021 at 12:27, David Rowley wrote:
>
> Instead of adding a send/recv function, unless I'm mistaken, it should
> be possible to go the whole hog and optimizing this further by instead
> of having numericvar_send(), add:
>
> static void
On Thu, Mar 11, 2021 at 12:05 AM Jacob Champion wrote:
>
> On Tue, 2021-03-09 at 11:25 +0100, Magnus Hagander wrote:
> > I've also added some trivial tests (man that took an ungodly amount of
> > fighting perl -- it's clearly been a long time since I used perl
> > properly).
>
> Yeah. The tests
The failure still represents a gcc bug, because we're using -fwrapv which
should disable that assumption.
Ok, I'll report it.
Done at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101254
--
Fabien.
On Tue, Jun 29, 2021 at 3:55 PM Emre Hasegeli wrote:
> > Thanks for the explanation. Attached is a demo code for the hash-join
> > case, which is only for PoC to show how we can make it work. It's far
> > from complete, at least we need to adjust the cost calculation for this
> > 'right anti
On Sat, Jun 26, 2021 at 3:43 PM Amit Kapila wrote:
>
> On Fri, Jun 25, 2021 at 3:11 PM Simon Riggs
> wrote:
> >
> > On Fri, Jun 25, 2021 at 4:17 AM Amit Kapila wrote:
> > >
> > > On Fri, Jun 25, 2021 at 1:29 AM Bruce Momjian wrote:
> > > >
> > > > aOn Wed, Jun 23, 2021 at 12:56:51PM +0100,
On Tue, Jun 29, 2021 at 4:56 PM Amit Kapila wrote:
>
> 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
On Tue, Mar 9, 2021 at 11:25 AM Magnus Hagander wrote:
>
> On Sat, Mar 6, 2021 at 5:30 PM Magnus Hagander wrote:
> >
> > On Sat, Mar 6, 2021 at 4:17 PM Magnus Hagander wrote:
> > >
> > > On Fri, Mar 5, 2021 at 8:11 PM Jacob Champion
> > > wrote:
> > > >
> > > > On Fri, 2021-03-05 at 10:22
> Thanks for the explanation. Attached is a demo code for the hash-join
> case, which is only for PoC to show how we can make it work. It's far
> from complete, at least we need to adjust the cost calculation for this
> 'right anti join'.
I applied the patch and executed some queries. Hash Right
On Tue, Jun 29, 2021 at 01:53:42AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Done. This upset one buildfarm member so far:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gaur=2021-06-29%2001%3A43%3A14
>
> > I don't know what happened there. Tom, could you post a tar of the
>
On Thu, Jun 24, 2021 at 5:49 PM Tom Lane wrote:
>
> "zhangj...@fujitsu.com" writes:
> > In PostgreSQL 14, The default value of shared_buffers is 128MB, but in
> > postgresql.conf.sample, the default value of shared_buffers is 32MB.
> > I think the following changes should be made.
>
> > File:
On Fri, Jun 25, 2021 at 12:24 PM Amit Kapila wrote:
>
> Till now, we didn't allow to stream the changes in logical replication
> till we receive speculative confirm or the next DML change record
> after speculative inserts. The reason was that we never use to process
> speculative aborts but
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,
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
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
> 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
> 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.
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.
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
>
>
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
> > -
92 matches
Mail list logo
