On Sun, Feb 19, 2017 at 10:11 PM, Robert Haas wrote:
> On Thu, Feb 16, 2017 at 6:41 PM, Kuntal Ghosh
> wrote:
> > On Thu, Feb 16, 2017 at 5:47 PM, Rafia Sabih
> > wrote:
> >> Other that that I updated some comments and other cleanup things. Please
> >> find the attached patch for the revised ve
I noticed while researching bug #14555 that fd.c contains two separate
cases like
vfdP->seekPos = lseek(vfdP->fd, (off_t) 0, SEEK_CUR);
Assert(vfdP->seekPos != (off_t) -1);
This seems, um, unwise. It might somehow fail to fail in production
builds, because elsewhere it's assumed
On Sun, Feb 19, 2017 at 2:33 PM, Robert Haas wrote:
> On Fri, Feb 17, 2017 at 11:44 AM, Ashutosh Bapat
> wrote:
>> That's true for a partitioned table, but not necessarily for every
>> append relation. Amit's patch is generic for all append relations. If
>> the child plans are joins or subquery s
On Mon, Feb 20, 2017 at 11:35 AM, Jim Nasby wrote:
> On 2/19/17 7:56 PM, Masahiko Sawada wrote:
>>
>> The half-dead pages are never cleaned up if the ratio of pages
>> containing garbage is always lower than threshold. Also in gin index
>> the pending list is never cleared, which become big proble
On Thu, Feb 16, 2017 at 10:55 AM, Michael Paquier
wrote:
> It is possible to get a test easily in this area by abusing of the
> fact that multiple -d switches defined in psql make it use only the
> last value. By looking at psql() in PostgresNode.pm you would see what
> I mean as -d is defined by
On Sun, Feb 19, 2017 at 10:07 PM, Michael Paquier
wrote:
> There is something that I think is still unwelcome in this patch: the
> interface in pg_hba.conf. I mentioned that in the previous thread but
> now if you want to match a user and a database with a scram password
> you need to do that with
Thanks Amit for raising this point. I was not at all aware of mark/restore.
I tried to come up with the case, but haven't found such case.
For now here is the patch with comment update.
Thanks,
On Sun, Feb 19, 2017 at 7:30 PM, Amit Kapila
wrote:
> On Sun, Feb 19, 2017 at 2:22 PM, Robert Haas
On 2017-02-19 10:49:29 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane wrote:
> >> Thoughts? Should we double down on trying to make this work according
> >> to the "all integer timestamps" protocol specs, or cut our losses and
> >> change the specs?
>
Yes, it seems the pg_stat_sql function can fit the individual need of
collecting tags of query. However the new function can not return other values
of query at the same time, such as block number info, run time and so on.
Returning these values at the same time are very important.
So I thin
On Sun, Feb 19, 2017 at 10:34 PM, Robert Haas wrote:
> Yeah, but it looks like ExecReScanGather gets rid of the workers, but
> reuses the existing DSM. I'm not quite sure what happens to the DSA.
> It looks like it probably just hangs around from the previous
> iteration, which means that any all
101 - 110 of 110 matches
Mail list logo