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 after
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: po
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&dt=2021-06-29%2001%3A43%3A14
>
> > I don't know what happened there. Tom, could you post a tar of the
> 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, 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 +010
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 no
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, Simo
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 join
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 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 I'
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 numericvar_serialize(String
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.
+typede
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
beca
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
w
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/
use_constant_value
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 n
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 take
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
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 of
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 prere
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
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):
https://git.codesynthesis.com/cgit/odb/libodb-pgsql/tree/odb/pgsql/statement.cxx?h=bulk#n78
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;
f
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 pg_
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 we
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 w
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):
> https://git.codesynthesis.com/cgit/od
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 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 these
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 S
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&dt=2021-06-29%2001%3A43%3A14
>> I'm too tired to look at it right now, but reme
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 d
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 Bry
> 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 http
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 H
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 opi
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 lon
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 allowi
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
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
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 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 json
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 be
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:
> > > d9d076222f5b94
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 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:
> 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 cons
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
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
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 meaningf
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 i
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 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 scales
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 Open
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
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
https://gcc.gnu.org/git/gitweb.
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
>> restric
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 n
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
PITR of Abort Prepared generates the wrong log message.
Fix attached
--
Simon Riggshttp://www.EnterpriseDB.com/
pitr_recoveryStopsBefore_AbortPrepared.v1.patch
Description: Binary data
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 allowi
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 it
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 B
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 time
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
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 dir_strc
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 teste
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
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 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 thread
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 to
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 t
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 (actua
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 op
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 reaso
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 ho
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 confirm
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 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 async_capable
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
v3-0004-Map-WAL-segment-files-on-PMEM-as-WAL-buffe
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 support
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 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;
> > - bo
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, pass
Hi all,
jsonapi.c includes the following code bits to enforce the use of
logging:
#ifdef FRONTEND
#define check_stack_depth()
#define json_log_and_abort(...) \
do { pg_log_fatal(__VA_ARGS__); exit(1); } while(0)
#else
#define json_log_and_abort(...) elog(ERROR, __VA_ARGS__)
#endif
This has bee
On Tue, May 18, 2021 at 01:04:18PM +0200, Drouvot, Bertrand wrote:
> On 5/17/21 8:56 PM, Andres Freund wrote:
>> On 2021-05-17 20:14:40 +0200, Drouvot, Bertrand wrote:
>>> I was also wondering if:
>>>
>>> * We should keep the old behavior in case pg_resetwal -x is being used
>>> without -u?
On Tue, Jun 29, 2021 at 8:15 PM wrote:
>
> 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.
+1 for the idea
Some comments/suggestions on the patch
1.
@@
87 matches
Mail list logo
