Hi!
On Fri, Jul 3, 2020 at 12:29 AM Konstantin Knizhnik
wrote:
> Did you read this thread:
> https://www.postgresql.org/message-id/flat/78aadf6b-86d4-21b9-9c2a-51f1efb8a499%40postgrespro.ru
> I have proposed a patch for supporting time travel (AS OF) queries.
> But I didn't fill a big interest to
On Wed, 7 Aug 2019 at 02:49, Konstantin Knizhnik
wrote:
>
> Hi, Li
>
> Thank you very much for reporting the problem.
>
> On 07.08.2019 7:21, Li Japin wrote:
> > I inspect the code, and find the following code in DefineRelation function:
> >
> > if (stmt->relation->relpersistence != RELPERSISTENCE
On Tue, Jun 30, 2020 at 2:53 PM Georgios wrote:
>
>
> As promised, I gladly ament upon your request. Also included a fix for
> a minor oversight in tests, they should now be stable. Finally in this
> version, I extended a bit the logic to only include the access method column
> if the relations di
On Sat, Jul 4, 2020 at 12:32 PM Amit Kapila wrote:
>
> On Fri, Jul 3, 2020 at 5:18 PM Masahiko Sawada
> wrote:
> >
> > On Fri, 3 Jul 2020 at 17:07, vignesh C wrote:
> > >
> > > Hi,
> > >
> > > While checking through the code I found that some of the function
> > > parameters in reorderbuffer &
On Sat, 2020-07-04 at 14:49 +0530, Amit Kapila wrote:
> > We don't even have a user report yet of a
> > regression compared to PG 12, or one that can't be fixed by
> > increasing
> > work_mem.
> >
>
> Yeah, this is exactly the same point I have raised above. I feel we
> should wait before design
On Tue, Jun 2, 2020 at 2:06 AM David Zhang wrote:
>
> On 2020-05-06 10:45 p.m., Michael Paquier wrote:
> > On Wed, May 06, 2020 at 12:17:03AM +0200, Juan José Santamaría Flecha
> wrote:
> >> Please forgive me if I am being too nitpicky, but I find the comments a
> >> little too verbose, a usage f
On 7/4/20 1:10 PM, Joe Conway wrote:
> On 7/4/20 12:52 PM, Tom Lane wrote:
>> Justin Pryzby writes:
>>> But I noticed that cfbot is now populating with failures like:
>>
>>> genfile.c: In function ‘read_binary_file’:
>>> genfile.c:192:5: error: ignoring return value of ‘fread’, declared with
>>>
On 7/4/20 12:52 PM, Tom Lane wrote:
> Justin Pryzby writes:
>> But I noticed that cfbot is now populating with failures like:
>
>> genfile.c: In function ‘read_binary_file’:
>> genfile.c:192:5: error: ignoring return value of ‘fread’, declared with
>> attribute warn_unused_result [-Werror=unused
Justin Pryzby writes:
> But I noticed that cfbot is now populating with failures like:
> genfile.c: In function ‘read_binary_file’:
> genfile.c:192:5: error: ignoring return value of ‘fread’, declared with
> attribute warn_unused_result [-Werror=unused-result]
> fread(rbuf, 1, 1, file);
>
Hi Joe
Thanks for addressing this.
But I noticed that cfbot is now populating with failures like:
https://travis-ci.org/github/postgresql-cfbot/postgresql/builds/704898559
genfile.c: In function ‘read_binary_file’:
genfile.c:192:5: error: ignoring return value of ‘fread’, declared with
attribut
Hello Andrey
>> I have researched your patch which is so great, in the patch only data
>> out of 'global_snapshot_defer_time' can be vacuum, and it keep dead
>> tuple even if no snapshot import at all,right?
>>
>> I am thanking about a way if we can start remain dead tuple just before
>> we impor
Peter Eisentraut writes:
> Do people prefer a typedef or just writing it out, like it's done in the
> Python code?
I'm for a typedef. There is *nothing* readable about "(void (*) (void))",
and the fact that it's theoretically incorrect for the purpose doesn't
exactly aid intelligibility either.
On 7/2/20 6:29 PM, Tom Lane wrote:
> Joe Conway writes:
>> On 7/2/20 5:37 PM, Tom Lane wrote:
>>> I still can't get excited about contorting the code to remove that
>>> issue.
>
>> It doesn't seem much worse than the oom test that was there before -- see
>> attached.
>
> Personally I would not
On 2020-07-03 18:18, Tom Lane wrote:
Andrew Dunstan writes:
On 7/2/20 10:01 AM, Tom Lane wrote:
Yeah. We *must not* simply give up on extensibility and decide that
every interesting feature has to be in core. I don't have any great
ideas about how we grow the wider Postgres development commu
On Thu, Jul 2, 2020 at 1:31 PM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
>
>
> Thanks! Yes, I'm working on this patch while considering to send the
> stats to stats collector.
>
> I've attached PoC patch that implements a simple approach. I'd like to
> discuss how we collect the re
On Sun, Jun 28, 2020 at 11:18 PM Mark Dilger
wrote:
>
>
>
> > On Jun 28, 2020, at 9:05 AM, Dilip Kumar wrote:
> >
> > Some more comments on v9_0001.
> > 1.
> > + LWLockAcquire(XidGenLock, LW_SHARED);
> > + nextFullXid = ShmemVariableCache->nextFullXid;
> > + ctx.oldestValidXid = ShmemVariableCach
On 2020-07-03 16:40, Tom Lane wrote:
Given that gcc explicitly documents "void (*) (void)" as being what
to use, they're going to have a hard time changing their minds about
that ... and gcc is dominant enough in this space that I suppose
other compilers would have to be compatible with it. So e
>Thanks. Movead, please note that the patch is waiting on author?
>Could you send an update if you think that those changes make sense?
I make a patch as Michael Paquier described that use a new function to
return transactionid and origin, and I add a origin version to
pg_last_committed_xact() t
On Fri, Jul 3, 2020 at 7:38 PM Bruce Momjian wrote:
>
> On Thu, Jul 2, 2020 at 08:35:40PM -0700, Peter Geoghegan wrote:
> > But the problem isn't really the hashaggs-that-spill patch itself.
> > Rather, the problem is the way that work_mem is supposed to behave in
> > general, and the impact that
On Fri, Jul 3, 2020 at 5:18 PM Masahiko Sawada
wrote:
>
> On Fri, 3 Jul 2020 at 17:07, vignesh C wrote:
> >
> > Hi,
> >
> > While checking through the code I found that some of the function
> > parameters in reorderbuffer & vacuumlazy are not used. I felt this
> > could be removed. I'm not sure
20 matches
Mail list logo
