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
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 !=
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
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
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
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
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
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
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
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
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
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 =
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
>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()
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
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
Hello Peter,
The original stylesheets explicitly go out of their way to do it that way.
We can easily fix that by removing that special case. See attached patch.
That patch only fixes it for the header. To fix it for the footer as well,
we'd first need to import the navfooter template to
The original stylesheets explicitly go out of their way to do it that
way.
Can we find any evidence of the reasoning? As you say, that clearly was
an intentional choice.
Given the code, my guess would be the well-intentioned but misplaced
desire to avoid a redundancy, i.e. two links
* First patch reworks time measurements in pgbench.
* Second patch adds a barrier before starting the bench
It applies on top of the previous one. The initial imbalance due to
thread creation times is smoothed.
The usecs patch fails to apply to HEAD, can you please submit a rebased version
On Wed, Jul 1, 2020 at 8:44 PM Alvaro Herrera wrote:
>
> On 2020-Jul-01, Amit Kapila wrote:
>
> > Okay, but do we think it is better to display this in
> > pg_replication_slots or some new view like pg_stat_*_slots as being
> > discussed in [1]? It should not happen that we later decide to move
24 matches
Mail list logo
