On Sat, Jul 10, 2021 at 2:50 PM John Naylor
wrote:
> On Thu, Apr 22, 2021 at 8:01 AM Simon Riggs
> wrote:
> >
> > 897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
> > level for CHECK constraints when allowing them to be NOT VALID.
> >
> > This is simple and safe, since check co
On 5/7/21 23:15, Zhihong Yu wrote:
On Mon, Jul 5, 2021 at 2:57 AM Andrey Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
+ * Can't imagine situation when join relation already
exists. But in
+ * the 'partition_join' regression test it happens.
+ * It may be a
On Wednesday, July 14, 2021 9:30 PM Ajin Cherian wrote:
> I've had to rebase the patch after a recent commit by Amit Kapila of
> supporting
> two-phase commits in pub-sub [1].
> Also I've modified the patch to also skip replicating empty prepared
> transactions. Do let me know if you have any com
On Tue, 13 Jul 2021 at 01:15, John Naylor wrote:
> > It seems like it would be easy to have pg_utf8_verify_one in my proposed
> > pg_utf8.h header and replace the body of pg_utf8_verifychar with it.
>
> 0001: I went ahead and tried this for v15, and also attempted some clean-up:
>
> - Rename pg_u
At Wed, 14 Jul 2021 19:55:18 +0900, Michael Paquier wrote
in
> On Fri, Jul 09, 2021 at 09:00:31PM +0900, Kyotaro Horiguchi wrote:
> > Mmm. Ok, I distributed the mother regression test into each version.
>
> Thanks, my apologies for the late reply. It took me some time to
> analyze the whole.
.
At Thu, 15 Jul 2021 00:39:52 +0500, Ibrar Ahmed wrote
in
> On Wed, Jun 30, 2021 at 12:54 PM Kyotaro Horiguchi
> wrote:
> > Maybe I will rebase it soon.
> >
> > Yes, rebase is required, therefore I am changing the status to "Waiting On
> Author"
> http://cfbot.cputube.org/patch_33_2113.log
Gah.
On Thu, Jul 15, 2021 at 7:37 AM Amit Kapila wrote:
>
> On Wed, Jul 14, 2021 at 10:55 PM Euler Taveira wrote:
> >
> > On Wed, Jul 14, 2021, at 12:08 PM, Tomas Vondra wrote:
> >
> > Yeah, but AFAIK that's needed only when replicating DELETEs, so perhaps
> > we could ignore this for subscriptions wi
Hi, tom
Thanks for your reply.
>Hmmm, yeah, I think you're right. It probably doesn't make a big difference
>in the real world --- anyone who's dependent on the performance of 2PC
>rollbaxks is Doing It Wrong.
> But we'd have already done LocalExecuteInvalidationMessage when getting out
> of
Em qua., 14 de jul. de 2021 às 22:22, David Rowley
escreveu:
> On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
> >
> > Em qua., 14 de jul. de 2021 às 21:21, David Rowley
> escreveu:
> >> But, in v8 there is no additional branch, so no branch to mispredict.
> >> I don't really see how your ex
On July 15, 2021 5:35 AM Daniel Gustafsson wrote:
> > On 14 Jul 2021, at 10:54, houzj.f...@fujitsu.com wrote:
>
> > Since PQfnumber() is not a cheap function, I think we'd better invoke
> > PQfnumber() out of the loop like the attatched patch.
>
> Looks good on a quick readthrough, and I didn't
On 2021/07/15 11:21, Michael Paquier wrote:
On Wed, Jul 14, 2021 at 11:38:59PM +0530, Bharath Rupireddy wrote:
It looks like the commit d75288fb [1] added an unnecessary
Assert(PgArchPID == 0); in PostmasterStateMachine as the if block code
gets hit only when PgArchPID == 0. PSA small patch.
On Sat, Jul 10, 2021 at 3:36 AM Tomas Vondra
wrote:
>
> But I think removing one of the snapshots (as the v2 does it) is rather
> strange too. I very much doubt having both the transaction and active
> snapshots in the parallel worker is not intentional, and Pavel may very
> well be right this bre
On Wed, Jul 14, 2021 at 02:02:18PM -0400, Tom Lane wrote:
>
> Hm. I guess this point (i.e. that the Param substitution should result
> in the identical plan tree as writing a literal constant would have)
> has some force. I still feel like your application is pretty shaky,
> but I don't really h
On Wed, Jul 14, 2021 at 11:38:59PM +0530, Bharath Rupireddy wrote:
> It looks like the commit d75288fb [1] added an unnecessary
> Assert(PgArchPID == 0); in PostmasterStateMachine as the if block code
> gets hit only when PgArchPID == 0. PSA small patch.
Agreed that there is no need to keep that a
Hi,
Thomas^WA bad person recently nerdsniped me (with the help of an accidental use
of an SSL connection in a benchmark leading to poor results) into checking what
would be needed to benefit from SSL/TLS hardware acceleration (available with
suitable hardware, OS support (linux and freebsd) and op
On Wed, Jul 14, 2021 at 10:55 PM Euler Taveira wrote:
>
> On Wed, Jul 14, 2021, at 12:08 PM, Tomas Vondra wrote:
>
> Yeah, but AFAIK that's needed only when replicating DELETEs, so perhaps
> we could ignore this for subscriptions without DELETE.
>
> ... and UPDATE. It seems we have a consensus to
On Wed, Jul 14, 2021 at 8:43 PM Alvaro Herrera wrote:
>
> On 2021-Jul-14, Tomas Vondra wrote:
>
> > The other question is when to check/enforce this. I guess we'll have to do
> > that during decoding, not just when the publication is being created,
> > because the user can do ALTER TABLE later.
>
Hi,
On 2021-07-14 17:42:10 -0400, Tom Lane wrote:
> I think the main reason that the previous patch went nowhere was general
> resistance to making developers install something as complicated as
> libclang --- that could be a big lift on non-mainstream platforms.
I'm still not particularly convin
On Thu, 15 Jul 2021 at 12:30, Ranier Vilela wrote:
>
> Em qua., 14 de jul. de 2021 às 21:21, David Rowley
> escreveu:
>> But, in v8 there is no additional branch, so no branch to mispredict.
>> I don't really see how your explanation fits.
>
> In v8 the branch occurs at :
> + if (ExecGetResultTy
Em qua., 14 de jul. de 2021 às 21:21, David Rowley
escreveu:
> On Thu, 15 Jul 2021 at 12:10, Ranier Vilela wrote:
> >
> > Em qua., 14 de jul. de 2021 às 20:43, David Rowley
> escreveu:
> >>
> >> On Thu, 15 Jul 2021 at 05:55, Ranier Vilela
> wrote:
> >> > I repeated (3 times) the benchmark with
On Thu, 15 Jul 2021 at 12:10, Ranier Vilela wrote:
>
> Em qua., 14 de jul. de 2021 às 20:43, David Rowley
> escreveu:
>>
>> On Thu, 15 Jul 2021 at 05:55, Ranier Vilela wrote:
>> > I repeated (3 times) the benchmark with v8 here,
>> > and the results were not good.
>>
>> Do you have any good the
Em qua., 14 de jul. de 2021 às 20:43, David Rowley
escreveu:
> On Thu, 15 Jul 2021 at 05:55, Ranier Vilela wrote:
> > I repeated (3 times) the benchmark with v8 here,
> > and the results were not good.
>
> Do you have any good theories on why the additional branching that's
> done in v7b vs v8 m
Looking over the tests added by your (Justin's) patch, there was a
problem checking for non-existance of the CREATE TRIGGER line: it
doesn't work to use "like => {}" (empty), you need to use
"unlike => { everything }". So your test was not catching the fact that
we were, in fact, emitting the unde
On Thu, 15 Jul 2021 at 05:55, Ranier Vilela wrote:
> I repeated (3 times) the benchmark with v8 here,
> and the results were not good.
Do you have any good theories on why the additional branching that's
done in v7b vs v8 might cause it to run faster?
David
On Wed, Jul 14, 2021 at 6:14 AM David Rowley wrote:
> It would be good to get a 2nd opinion about this idea. Also, more
> benchmark results with v6 and v8 would be good too.
I tested this on an older Xeon, gcc 8.4 (here median of each test, full
results attached):
test HEAD v6 v8
Test1 588 10
Isaac Morland writes:
> I've attached a patch for this. Turns out there was a comment in the source
> explaining that there is no interval_abs because it's not clear what to
> return; but I think it's clear that if i is an interval the larger of i and
> -i should be considered to be the absolute v
Bharath Rupireddy writes:
> While working on [1], I got to know that there is a new GUC
> debug_invalidate_system_caches_always that has been introduced in v14.
> It can be used to switch off cache invalidation in
> CLOBBER_CACHE_ALWAYS builds which makes cache sensitive tests stable.
> Using this
Andres Freund writes:
> On 2021-06-08 19:45:58 +0200, Peter Eisentraut wrote:
>> On 08.06.21 15:40, David Rowley wrote:
>>> It's almost 2 years ago now, but I'm wondering if you saw what Andres
>>> proposed in [1]?
>> That project was technologically impressive, but it seemed to have
>> significa
> On 14 Jul 2021, at 10:54, houzj.f...@fujitsu.com wrote:
> Since PQfnumber() is not a cheap function, I think we'd better invoke
> PQfnumber() out of the loop like the attatched patch.
Looks good on a quick readthrough, and I didn't see any other similar codepaths
in pg_dump on top of what you'v
On 7/13/21 2:10 AM, Craig Ringer wrote:
>
>
> If you don't have the toolchain installed, you can install Chocolatey
> (there's a one-liner on their website) then:
>
> choco install -y visualstudio2019buildtools
>
> choco install -y visualstudio2019-vc++ --packageparameters "--add
> Micros
On Wed, Jul 14, 2021 at 3:34 PM Tom Lane wrote:
> Hm, I'm not following? setup_depend runs in initdb, that is on the
> client side. It can't invoke backend-internal functions any other
> way than via SQL, AFAICS.
Ah, brainfade on my part.
I was also curious about the test case where Andres fi
Dave Cramer writes:
> On Wed, 14 Jul 2021 at 15:09, David G. Johnston
> wrote:
>> "Install ... files used by the old cluster" (which must be binary
>> compatible with the new cluster as noted elsewhere on that page) supports
>> the claim that it is the old cluster's version that is going to resul
On Wed, Jun 30, 2021 at 12:54 PM Kyotaro Horiguchi
wrote:
> At Fri, 09 Apr 2021 09:36:59 +0900 (JST), Kyotaro Horiguchi <
> horikyota@gmail.com> wrote in
> > I'm surprised to see this pushed this soon. Thanks for pushing this!
>
> Then this has been reverted. I'm not sure how to check for th
Zhihong Yu writes:
> On Wed, Jul 14, 2021 at 10:17 AM Tom Lane wrote:
>> There's really very little point in adding such code. Our memory
>> context mechanisms take care of minor leaks like this, with less
>> code and fewer cycles expended than explicit pfree calls require.
>> It's worth trying
On Wed, Jul 14, 2021 at 6:51 PM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
>
> On 05.01.21 22:40, Paul Martinez wrote:
> > I've created a patch to better support referential integrity constraints
> when
> > using composite primary and foreign keys. This patch allows creating a
>
John Naylor writes:
> On Thu, May 27, 2021 at 6:53 PM Tom Lane wrote:
>> Attached is a rebase over a4390abec.
> Looks good to me overall, I just had a couple questions/comments:
Thanks for looking!
> isObjectPinned and isSharedObjectPinned are now thin wrappers around
> IsPinnedObject. Is keep
On Wed, Jul 14, 2021 at 12:21 PM Dave Cramer wrote:
>
> On Wed, 14 Jul 2021 at 15:09, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>>
>> Something like, "... because the installed extensions will be copied from
>> the old cluster during the upgrade."
>>
>
> This is still rather opaq
Gilles Darold writes:
> I have renamed the patch and the title of this proposal registered in
> the commitfest "Xact/SubXact event callback at command start" to reflect
> the last changes that do not include new hooks anymore.
Hmm, it doesn't seem like this has addressed my concern at all.
The
On Wed, 14 Jul 2021 at 15:09, David G. Johnston
wrote:
> On Wed, Jul 14, 2021 at 11:59 AM Dave Cramer wrote:
>
>>
>>
>> On Wed, 14 Jul 2021 at 14:47, David G. Johnston <
>> david.g.johns...@gmail.com> wrote:
>>
>>> On Wednesday, July 14, 2021, Dave Cramer wrote:
>>>
Notice the up
On Wed, Jul 14, 2021 at 1:41 AM Tom Lane wrote:
> Ibrar Ahmed writes:
> > The patch is failing the regression, @Tom Lane can
> you
> > please take a look at that.
>
> Seems to just need an update of the expected-file to account for test
> cases added recently. (I take no position on whether th
On Wed, Jul 14, 2021 at 11:59 AM Dave Cramer wrote:
>
>
> On Wed, 14 Jul 2021 at 14:47, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Wednesday, July 14, 2021, Dave Cramer wrote:
>>
>>>
>>>
>>> Notice the upgraded version is 1.5 and the new version is 1.8
>>>
>>> I would think
On Wed, 14 Jul 2021 at 14:47, David G. Johnston
wrote:
> On Wednesday, July 14, 2021, Dave Cramer wrote:
>
>>
>>
>> Notice the upgraded version is 1.5 and the new version is 1.8
>>
>> I would think somewhere in the upgrade of the schema there should have
>> been a create extension pg_stat_statem
On Wednesday, July 14, 2021, Dave Cramer wrote:
>
>
> Notice the upgraded version is 1.5 and the new version is 1.8
>
> I would think somewhere in the upgrade of the schema there should have
> been a create extension pg_stat_statements ?
>
That would be a faulty assumption. Modules do not get u
Upgrading from
10.5 to 13.3 using pg_upgrade -k
The following is the result of an upgrade
select * from pg_extension ;
oid | extname | extowner | extnamespace | extrelocatable |
extversion | extconfig | extcondition
---++--+--+
On Wed, Jul 14, 2021 at 11:02 AM Alvaro Herrera
wrote:
> On 2020-Oct-27, Justin Pryzby wrote:
>
> > I think either way could be ok - if you assume that the trigger was
> disabled
> > with ONLY, then it'd make sense to restore it with ONLY, but I think
> it's at
> > least as common to ALTER TABLE
On Wed, Jul 14, 2021, at 8:21 AM, Greg Nancarrow wrote:
> Some minor v19 patch review points you might consider for your next
> patch version:
Greg, thanks for another review. I agree with all of these changes. It will be
in the next patch.
--
Euler Taveira
EDB https://www.enterprisedb.com/
On Wed, Jul 14, 2021 at 10:17 AM Tom Lane wrote:
> Zhihong Yu writes:
> > I was looking at fmgr_internal_validator().
> > It seems prosrc is only used internally.
> > The patch frees the C string prosrc points to, prior to returning.
>
> There's really very little point in adding such code. Our
On Mon, 2021-07-12 at 18:28 +0200, Magnus Hagander wrote:
> Yeah, I have no problem being stricter than necessary, unless that
> actually causes any interop problems. It's a lot worse to not be
> strict enough..
Agreed. Haven't heard back from the HAProxy mailing list yet, so
staying strict seems
Hi,
It looks like the commit d75288fb [1] added an unnecessary
Assert(PgArchPID == 0); in PostmasterStateMachine as the if block code
gets hit only when PgArchPID == 0. PSA small patch.
[1]
commit d75288fb27b8fe0a926aaab7d75816f091ecdc27
Author: Fujii Masao
Date: Mon Mar 15 13:13:14 2021 +0900
Julien Rouhaud writes:
> On Tue, Jul 13, 2021 at 07:01:24PM -0400, Tom Lane wrote:
>> So I'm not really convinced that there's a fully-baked use case
>> here, and would like more detail about how you hope to use the
>> location value.
> As I said I have no doubt that there are other cases which a
On 2020-Oct-27, Justin Pryzby wrote:
> I think either way could be ok - if you assume that the trigger was disabled
> with ONLY, then it'd make sense to restore it with ONLY, but I think it's at
> least as common to ALTER TABLE [*]. It might look weird to the user if they
> used ALTER TABLE ONLY
On Thu, May 27, 2021 at 6:53 PM Tom Lane wrote:
> Attached is a rebase over a4390abec.
Looks good to me overall, I just had a couple questions/comments:
isObjectPinned and isSharedObjectPinned are now thin wrappers around
IsPinnedObject. Is keeping those functions a matter of future-proofing in
Em qua., 14 de jul. de 2021 às 07:14, David Rowley
escreveu:
> On Tue, 13 Jul 2021 at 15:15, David Rowley wrote:
> > In theory, we likely could get rid of the small regression by having
> > two versions of ExecSort() and setting the correct one during
> > ExecInitSort() by setting the function p
"liuhuail...@fujitsu.com" writes:
> So, I think we needn't send SI messags when rollbacking the two-phase
> transaction.
> Or Does it has something special because of two-phase transaction?
Hmmm, yeah, I think you're right. It probably doesn't make a big
difference in the real world --- anyone
On Wed, Jul 14, 2021, at 12:08 PM, Tomas Vondra wrote:
> Yeah, but AFAIK that's needed only when replicating DELETEs, so perhaps
> we could ignore this for subscriptions without DELETE.
... and UPDATE. It seems we have a consensus to use old row in the row filter
for UPDATEs. I think you meant pub
Zhihong Yu writes:
> I was looking at fmgr_internal_validator().
> It seems prosrc is only used internally.
> The patch frees the C string prosrc points to, prior to returning.
There's really very little point in adding such code. Our memory
context mechanisms take care of minor leaks like this,
Hi,
I was looking at fmgr_internal_validator().
It seems prosrc is only used internally.
The patch frees the C string prosrc points to, prior to returning.
Please take a look.
Thanks
free-c-str.patch
Description: Binary data
I wrote:
> Interesting question, so I took a look:
> https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c#n593
> case 's':
> a = arg.p ? arg.p : "(null)";
BTW, the adjacent code shows that musl is also supporting glibc's
"%m" extension, so I imagi
On Wed, Jul 14, 2021, at 11:48 AM, Dilip Kumar wrote:
> On Wed, Jul 14, 2021 at 8:04 PM Tomas Vondra
> wrote:
> >
>
> > Perhaps the best way forward is to stick to the approach that INSERT
> > uses new, DELETE uses old and UPDATE works as DELETE+INSERT (probably),
> > and leave anything fancier (
Peter Eisentraut writes:
> In this particular case, I would for example be quite curious how those
> alternative minimal C libraries such as musl-libc handle this.
Interesting question, so I took a look:
https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.c#n593
cas
On Thu, Apr 8, 2021 at 11:40 PM Simon Riggs wrote:
>
> On Thu, 8 Apr 2021 at 18:15, Alvaro Herrera wrote:
> >
> > On 2021-Apr-08, Simon Riggs wrote:
> >
> > > On Thu, 8 Apr 2021 at 16:58, David Steele wrote:
> >
> > > > It's not clear to me which patch is which, so perhaps move one CF entry
> >
On Sat, Jun 26, 2021 at 2:52 AM Bruce Momjian wrote:
>
> On Wed, May 26, 2021 at 05:02:01PM -0400, Bruce Momjian wrote:
> > For these reasons, if we decide to go in the direction of using a
> > non-LSN nonce, I no longer plan to continue working on this feature. I
> > would rather work on things t
On 2021-Jul-14, vignesh C wrote:
> The patch does not apply on Head anymore, could you rebase and post a
> patch. I'm changing the status to "Waiting for Author".
BTW I gave a look at this patch in the March commitfest and concluded it
still requires some major surgery that I didn't have time for
On Wed, Mar 10, 2021 at 1:49 PM yuzuko wrote:
>
> Hello,
>
> I thought about this suggestion again.
>
> Amit's patch suggested in the thread [1] can eliminate SPI plans from
> INSERT/UPDATE triggers, so our memory pressure issue would be solved.
> But as far as I can see that thread, Amit's patch
On Mon, Apr 19, 2021 at 5:18 PM David Rowley wrote:
>
> On Wed, 3 Mar 2021 at 22:37, David Rowley wrote:
> > I've attached a rebased patch.
>
> I've rebased this again.
>
> I also moved away from using hash tables for storing references and
> libraries. I was having some problems getting psql to
On Wed, Apr 7, 2021 at 5:23 PM Michael Banck wrote:
>
> Hi,
>
> Am Dienstag, den 06.04.2021, 15:37 +0200 schrieb Michael Banck:
> > Am Montag, den 05.04.2021, 14:33 -0400 schrieb Stephen Frost:
> > > Should drop the 'DEFAULT_' to match the others since the rename to
> > > 'predefined' roles went i
On Thu, Jul 8, 2021 at 10:22 AM Zhihong Yu wrote:
>
>
> On Wed, Jun 30, 2021 at 9:35 AM Bruce Momjian wrote:
>
>> On Tue, Jun 29, 2021 at 06:49:45PM +0200, Daniel Gustafsson wrote:
>> > > On 29 Jun 2021, at 18:50, Zhihong Yu wrote:
>> >
>> > > Now that PG 15 is open for commit, do you think the
On Thu, Mar 4, 2021 at 9:51 AM Andy Fan wrote:
>
>
>>
>> I have implemented a new one, which only handles 1 level of partitioned
>> table, and
>> only 1 partition key. and only handle the eq operators like partkey = $1 /
>> partkey in ($1, $2)
>> / parkey = $1 or partkey = $2; The patch works
On Mon, May 17, 2021 at 10:08 AM Yugo NAGATA wrote:
>
> On Fri, 7 May 2021 14:14:16 +0900
> Yugo NAGATA wrote:
>
> > On Mon, 26 Apr 2021 16:03:48 +0900
> > Yugo NAGATA wrote:
> >
> > > On Mon, 26 Apr 2021 15:46:21 +0900
> > > Yugo NAGATA wrote:
> > >
> > > > On Tue, 20 Apr 2021 09:51:34 +0900
>
On Tue, Mar 30, 2021 at 2:14 AM Mark Rofail wrote:
>
> Hey Alvaro
>
>> Yes, we should do that.
>
> I have attached v12 with more tests in “ src/test/regress/sql/gin.sql”
>
> Changelog:
> - v12 (compatible with current master 2021/03/29, commit
> 6d7a6feac48b1970c4cd127ee65d4c487acbb5e9)
> * a
On Wed, Oct 28, 2020 at 6:14 AM Justin Pryzby wrote:
>
> Forking this thread, since the existing CFs have been closed.
> https://www.postgresql.org/message-id/flat/20200914143102.GX18552%40telsasoft.com#58b1056488451f8594b0f0ba40996afd
>
> On Mon, Sep 14, 2020 at 09:31:03AM -0500, Justin Pryzby wr
On Wed, Mar 31, 2021 at 7:28 PM Denis Hirn wrote:
>
> Sorry, I didn't append the patch properly.
The patch does not apply on Head anymore, could you rebase and post a
patch. I'm changing the status to "Waiting for Author".
Regards,
Vignesh
On Wed, Jul 14, 2021 at 6:31 PM Daniil Zakhlystov
wrote:
>
> **sorry for the noise, but I need to re-send the message because one of the
> recipients is blocked on the pgsql-hackers for some reason**
>
> Hi!
>
> Done, the patch should apply to the current master now.
>
> Actually, I have an almos
> On Jul 14, 2021, at 7:57 AM, Mark Dilger wrote:
>
> so no valid toast pointer should contain a va_rawsize field greater than
> MaxAllocSize
... nor should any valid toast pointer contain a va_extinfo field encoding a
va_extsize greater than va_rawsize - VARHDRSZ.
Violations of either of
On Wed, Jul 14, 2021 at 8:26 AM Heikki Linnakangas wrote:
> Thanks for having a look!
>
> On 14/07/2021 18:18, Zhihong Yu wrote:
> > For the loop over the hash:
> >
> > + for (int idx = 0; idx < capacity; idx++)
> > {
> > - if (olditemsarr[i] != resarr->invalidval)
> > -
Thanks for having a look!
On 14/07/2021 18:18, Zhihong Yu wrote:
For the loop over the hash:
+ for (int idx = 0; idx < capacity; idx++)
{
- if (olditemsarr[i] != resarr->invalidval)
- ResourceArrayAdd(resarr, olditemsarr[i]);
+ while (owner->hash
On Wed, Jul 14, 2021 at 08:54:32AM +, houzj.f...@fujitsu.com wrote:
> Since PQfnumber() is not a cheap function, I think we'd better invoke
> PQfnumber() out of the loop like the attatched patch.
+1
Please add to the next CF
--
Justin
On Wed, Jul 14, 2021 at 7:40 AM Heikki Linnakangas wrote:
> On 14/07/2021 17:07, Alvaro Herrera wrote:
> > On 2021-Jul-14, vignesh C wrote:
> >
> >> On Tue, Mar 9, 2021 at 6:10 PM Heikki Linnakangas
> wrote:
> >
> >>> Here you go.
> >>
> >> The patch does not apply on Head anymore, could you reb
On 2021-Jul-14, Tomas Vondra wrote:
> On 7/14/21 4:52 PM, Alvaro Herrera wrote:
> > In any case, it seems to me that the condition expression should be
> > scanned to see which columns are used in Vars (pull_varattnos?), and
> > verify if those columns are in the REPLICA IDENTITY; and if they are
On 7/14/21 4:52 PM, Alvaro Herrera wrote:
On 2021-Jul-14, Tomas Vondra wrote:
The way I'm thinking about this is that for INSERT and DELETE it's clear
which row version should be used (because there's just one). And for UPDATE
we could see that as DELETE + INSERT, and apply the same rule to
On 14/07/2021 15:12, vignesh C wrote:
On Sat, Jan 23, 2021 at 3:49 AM Heikki Linnakangas wrote:
Here's an updated version that fixes one bug:
The CFBot was reporting a failure on the FreeBSD system [1]. It turned
out to be an out-of-memory issue caused by an underflow bug in the
calculation of
On 2021-Jul-14, Kyotaro Horiguchi wrote:
> > > pg_log_error("extra_float_digits must be in range
> > > -15..3");
> > > exit_nicely(1);
> >
> > Should we take this occasion to reduce the burden of translators and
> > reword that as "%s must be in range %d
> On Jul 14, 2021, at 3:33 AM, Heikki Linnakangas wrote:
>
>> +/* The largest valid toast va_rawsize */
>> +#define VARLENA_SIZE_LIMIT 0x3FFF
>> +
>
> Hmm, a toasted datum cannot be larger than MaxAllocSize, because it's
> reconstituted in a palloc'd datum, right?
No datum size exceeds
On 7/14/21 4:48 PM, Dilip Kumar wrote:
On Wed, Jul 14, 2021 at 8:04 PM Tomas Vondra
wrote:
Perhaps the best way forward is to stick to the approach that INSERT
uses new, DELETE uses old and UPDATE works as DELETE+INSERT (probably),
and leave anything fancier (like being able to reference
On 2021-Jul-14, Tomas Vondra wrote:
> The way I'm thinking about this is that for INSERT and DELETE it's clear
> which row version should be used (because there's just one). And for UPDATE
> we could see that as DELETE + INSERT, and apply the same rule to each
> action.
>
> On the other hand, I c
On Wed, Jul 14, 2021 at 8:04 PM Tomas Vondra
wrote:
>
> Perhaps the best way forward is to stick to the approach that INSERT
> uses new, DELETE uses old and UPDATE works as DELETE+INSERT (probably),
> and leave anything fancier (like being able to reference both versions
> of the row) for a futur
On 14/07/2021 17:07, Alvaro Herrera wrote:
On 2021-Jul-14, vignesh C wrote:
On Tue, Mar 9, 2021 at 6:10 PM Heikki Linnakangas wrote:
Here you go.
The patch does not apply on Head anymore, could you rebase and post a
patch. I'm changing the status to "Waiting for Author".
Support for hma
On 7/14/21 2:50 PM, Amit Kapila wrote:
On Wed, Jul 14, 2021 at 3:58 PM Tomas Vondra
wrote:
On 7/14/21 7:39 AM, Amit Kapila wrote:
On Wed, Jul 14, 2021 at 6:28 AM Euler Taveira wrote:
On Tue, Jul 13, 2021, at 6:06 PM, Alvaro Herrera wrote:
1. if you use REPLICA IDENTITY FULL, then the expr
On 7/14/21 4:01 PM, Alvaro Herrera wrote:
On 2021-Jul-14, Dilip Kumar wrote:
I think for insert we are only allowing those rows to replicate which
are matching filter conditions, so if we updating any row then also we
should maintain that sanity right? That means at least on the NEW rows
we
‐‐‐ Original Message ‐‐‐
On Wednesday, July 14th, 2021 at 04:17, Michael Paquier
wrote:
> On Tue, Jul 13, 2021 at 11:16:06AM +, gkokola...@pm.me wrote:
> > Agreed. For the record that is why I said v6 :)
> Okay, thanks.
Please find v6 attached.
Cheers,
//Georgios
>
On 2021-Jul-14, vignesh C wrote:
> On Tue, Mar 9, 2021 at 6:10 PM Heikki Linnakangas wrote:
> > Here you go.
>
> The patch does not apply on Head anymore, could you rebase and post a
> patch. I'm changing the status to "Waiting for Author".
Support for hmac was added by e6bdfd9700eb so the reb
On Mon, Jul 12, 2021 at 8:46 AM John Naylor
wrote:
>
> On Tue, Jun 8, 2021 at 10:50 PM Michael Paquier
wrote:
> >
> > At first glance, this looked to me like breaking something just for
> > sake of breaking it, but removing the rel argument could be helpful
> > to simplify any external code calli
On 2021-Jul-14, Dilip Kumar wrote:
> I think for insert we are only allowing those rows to replicate which
> are matching filter conditions, so if we updating any row then also we
> should maintain that sanity right? That means at least on the NEW rows
> we should apply the filter, IMHO. Said tha
On Tue, Jun 22, 2021 at 1:37 PM Michael Paquier wrote:
>
> On Tue, Jun 22, 2021 at 11:05:22AM +0530, Dilip Kumar wrote:
> > IMHO there is certainly a use case, basically, if we compress the data
> > so that we can avoid storing it externally. Now suppose for some
> > data, with default LZ4 compre
On 05.01.21 22:40, Paul Martinez wrote:
I've created a patch to better support referential integrity constraints when
using composite primary and foreign keys. This patch allows creating a foreign
key using the syntax:
FOREIGN KEY (tenant_id, fk_id) REFERENCES fktable ON DELETE SET NULL (fk
Hi,
I have renamed the patch and the title of this proposal registered in
the commitfest "Xact/SubXact event callback at command start" to reflect
the last changes that do not include new hooks anymore.
Here is the new description corresponding to the current patch.
This patch allow to ex
Wednesday, July 14, 2021 6:17 PM vignesh C wrote:
> On Tue, Jul 13, 2021 at 12:06 PM tanghy.f...@fujitsu.com
> wrote:
> >
> > On Monday, July 12, 2021 5:36 PM vignesh C wrote:
> > >
> > > Thanks for reporting this issue, this issue is fixed in the v10
> > > patch attached at [1].
> > > [1] - htt
On Wed, Jul 14, 2021 at 3:58 PM Tomas Vondra
wrote:
>
> On 7/14/21 7:39 AM, Amit Kapila wrote:
> > On Wed, Jul 14, 2021 at 6:28 AM Euler Taveira wrote:
> >>
> >> On Tue, Jul 13, 2021, at 6:06 PM, Alvaro Herrera wrote:
> >>
> >> 1. if you use REPLICA IDENTITY FULL, then the expressions would work
On Wed, Jun 16, 2021 at 9:24 AM Thomas Munro wrote:
> No change yet, just posting a rebase to keep cfbot happy.
>
>
Hi, Thomas
I think that the proposed feature is pretty cool not only because it fixes
some old issues with lseek() performance and reliability, but also because
it opens the door t
On Thu, May 27, 2021 at 8:58 PM vignesh C wrote:
> Thanks for the updated patch, few comments:
> 1) I'm not sure if we could add some tests for skip empty
> transactions, if possible add a few tests.
>
Added a few tests for prepared transactions as well as the existing
test in 020_messages.pl als
1 - 100 of 134 matches
Mail list logo
