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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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 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
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
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
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 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
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
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
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
>
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
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
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
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.
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 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
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
"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 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
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, 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 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)
> *
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
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
> >
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
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
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
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
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 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
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
> 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
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
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
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
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
>
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
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
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
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
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
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
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.
>
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.
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
>
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
>>
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
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
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 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
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
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
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
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
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.
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
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
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
2021年7月14日(水) 14:43 Ian Lawrence Barwick :
>
> Hi
>
> The description for "pg_database" [1] mentions the function
> "pg_encoding_to_char()", but this is not described anywhere in the docs. Given
> that that it (and the corresponding "pg_char_to_encoding()") have been around
> since 7.0 [2], it's
On 13.07.21 20:26, Tom Lane wrote:
Did you see my followup? The vast majority of live systems do not do
that, so we are accomplishing nothing of value by insisting it's a
crash-worthy bug.
But there are no guarantees that that will be maintained in the future.
In the past, it has often come
On Mon, Jul 12, 2021 at 9:14 AM Peter Smith wrote:
>
> On Sun, Jul 11, 2021 at 8:20 PM Amit Kapila wrote:
> >
> > On Fri, Jul 9, 2021 at 4:43 AM Peter Smith wrote:
> > >
> > > > The patch looks good to me, I don't have any comments.
> > >
> > > I tried the v95-0001 patch.
> > >
> > > - The
> On 14 Jul 2021, at 02:19, Alvaro Herrera wrote:
> Personally, I like the simplicity of the function call in those places,
+1
--
Daniel Gustafsson https://vmware.com/
> 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 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
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
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)
> > -
> 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 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
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 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
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
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
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
On Wed, Jul 14, 2021 at 12:45 AM Tomas Vondra
wrote:
>
> On 7/13/21 12:57 PM, Amit Kapila wrote:
> > On Tue, Jul 13, 2021 at 10:24 AM Amit Kapila
> > wrote:
>
> > I think the problem described by Petr[1] is also possible today if the
> > user drops the publication and there is a corresponding
On Mon, Jul 12, 2021 at 8:52 PM Amit Kapila wrote:
>
> On Mon, Jul 12, 2021 at 11:13 AM Masahiko Sawada
> wrote:
> >
> > On Mon, Jul 12, 2021 at 1:15 PM Amit Kapila wrote:
> > >
> > > On Mon, Jul 12, 2021 at 9:37 AM Alexey Lesovsky
> > > wrote:
> > > >
> > > > On Mon, Jul 12, 2021 at 8:36 AM
On Wed, Jul 14, 2021 at 4:23 PM Amit Kapila wrote:
>
> On Mon, Jul 12, 2021 at 9:14 AM Peter Smith wrote:
> >
> > On Sun, Jul 11, 2021 at 8:20 PM Amit Kapila wrote:
> > >
> > > On Fri, Jul 9, 2021 at 4:43 AM Peter Smith wrote:
> > > >
> > > > > The patch looks good to me, I don't have any
On Wed, Jul 14, 2021 at 6:36 AM Peter Eisentraut
wrote:
>
> On 13.07.21 10:58, Magnus Hagander wrote:
> > Maybe "each distinct database id, each distinct user id, each distinct
> > query id, and whether it is a top level statement or not"?
> >
> > Or maybe "each distinct combination of database
Hi all.
I've come up with a proof-of-concept patch using the delegation/proxy approach.
Let's say we have two DB, one for FDW and one for the real server. When client
connects to FDW server using kerberos authentication, we can obtain a "proxy"
credential and store it in the global variable
On 7/14/21 2:18 AM, Stephen Frost wrote:
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
On 2021-Jul-13, Stephen Frost wrote:
The simplest possible format isn't going to work with all the different
pg_dump options and it still isn't going to be 'simple' since it needs
to work
@@ -30,6 +30,9 @@ PG_FUNCTION_INFO_V1(verify_heapam);
/* The number of columns in tuples returned by verify_heapam */
#define HEAPCHECK_RELATION_COLS 4
+/* The largest valid toast va_rawsize */
+#define VARLENA_SIZE_LIMIT 0x3FFF
+
Hmm, a toasted datum cannot be larger than
On Tue, Jul 13, 2021 at 2:22 PM Greg Nancarrow wrote:
>
> On Mon, Jul 12, 2021 at 7:24 PM vignesh C wrote:
> >
> >
> > Thanks for reporting this issue. I felt this issue is the same as the
issue which Hou San had reported. This issue is fixed in the v10 patch
attached at [1].
> > [1] -
On Tue, Jul 13, 2021 at 1:14 PM r.takahash...@fujitsu.com
wrote:
>
> Hi Sawada-san,
>
>
> Thank you for your reply.
>
> > Not sure but it might be possible to keep holding an xlogreader for
> > reading PREPARE WAL records even after the transaction commit. But I
> > wonder how much open() for wal
Hi,
When reviewing some pg_dump related code, I found some existsing code
(getTableAttrs() and dumpEnumType()) invoke PQfnumber() repeatedly which seems
unnecessary.
Example
-
for (int j = 0; j < ntups; j++)
{
if (j + 1 !=
On Tue, Jul 13, 2021 at 07:01:24PM -0400, Tom Lane wrote:
>
> I thought for a bit about also having evaluate_expr() inject the
> exprLocation(expr) into its result Const, but in this example
> that would likely result in having the 43 labeled with the offset
> of the $1 (given exprLocation's
On 13/07/2021 14:52, Aleksander Alekseev 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:tested, passed
The patch
1 - 100 of 134 matches
Mail list logo
