On Fri, Oct 21, 2016 at 9:03 PM, Stephen Frost wrote:
> WARNING: The following essential packages will be removed.
> This should NOT be done unless you know exactly what you are doing!
> login
> 0 upgraded, 0 newly installed, 1 to remove and 71 not upgraded.
> After this operation, 1,212 kB disk
On Sat, Oct 22, 2016 at 9:38 AM, Tom Lane wrote:
> 1. Why are you replacing ExecOnConflictUpdate's ExecCheckHeapTupleVisible
> call with ExecCheckTIDVisible? That appears to demand a re-fetch of the
> tuple ExecOnConflictUpdate already has its hands on. Wouldn't it be
> better to just put a buff
On October 22, 2016 11:59:15 AM PDT, Tom Lane wrote:
>Alvaro Herrera writes:
>> Uh, sorry. My proposal a couple of years back was to put the
>> relfilenode, not the name. I didn't notice that it was the name
>being
>> proposed here. However, now I notice that this idea doesn't solve
>the
>>
Alvaro Herrera writes:
> Uh, sorry. My proposal a couple of years back was to put the
> relfilenode, not the name. I didn't notice that it was the name being
> proposed here. However, now I notice that this idea doesn't solve the
> problem for mapped relations.
Well, as long as a catalog looku
Tom Lane wrote:
> Alvaro Herrera writes:
> > Jim Nasby wrote:
> >> It occurs to me that it might be worth embedding the relation name in the
> >> free space of the first block. Most people would never notice the missing
> >> 64
> >> bytes, but it would be incredibly helpful in cases like this...
On 10/20/2016 04:43 PM, Robert Haas wrote:
On Tue, Oct 18, 2016 at 6:27 PM, Petr Jelinek wrote:
I agree though that the usability beyond the ReoderBuffer is limited
because everything that will want to use it for part of allocations will
get much more complicated by the fact that it will have t
Jim Nasby writes:
> On 10/21/16 7:43 PM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Agreed. The problem is how to install it without breaking pg_upgrade.
> It can't look up relation names?
It can't shove 64 bytes into a page that has < 64 bytes free space.
>> Well, that's the first problem
On 10/21/16 7:43 PM, Tom Lane wrote:
Alvaro Herrera writes:
Jim Nasby wrote:
It occurs to me that it might be worth embedding the relation name in the
free space of the first block. Most people would never notice the missing 64
bytes, but it would be incredibly helpful in cases like this...
> 11. I have reworded following comment and restructured the code that follows
> it
> in the attached patch.
> +/*
> + * Set the subquery information. If the relation performs a full outer
> + * join and if the input relations have non-NIL remote_conds, the input
> + * relations n
Peter Geoghegan writes:
> Attached is a revision of Thomas' patch to fix a related issue; it now
> also fixes this no-buffer-lock-held issue.
I think this needs more work.
1. Why are you replacing ExecOnConflictUpdate's ExecCheckHeapTupleVisible
call with ExecCheckTIDVisible? That appears to de
On 21.10.2016 22:54, Jim Nasby wrote:
On 10/21/16 2:48 PM, Sven R. Kunze wrote:
You don't need that limitation (and vacuum will be simpler) if you add
the PK as another key, akin to:
CREATE INDIRECT INDEX idx ON tab (a, b, c);
turns into
CREATE INDEX idx ON tab (a, b, c, pk);
I know I
On 10/22/16 6:58 PM, Bruce Momjian wrote:
On Sat, Oct 22, 2016 at 07:33:56AM +0900, Michael Paquier wrote:
On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
Also +1 to renaming pg_subtrans to pg_subxact.
Nice suggestion, good naming for consistency with the rest.
Agreed.
+1
--
-David
da..
On Sat, Oct 22, 2016 at 07:33:56AM +0900, Michael Paquier wrote:
> On Sat, Oct 22, 2016 at 4:29 AM, Alvaro Herrera
> wrote:
> > David Steele wrote:
> >> On 10/21/16 3:12 AM, David G. Johnston wrote:
> >>
> >> > I have no problem continuing keeping with historical precedent and
> >> > allowing mnem
I found our postgresql.conf and pg_hba.conf config files had
inconsistent comment instructions about reloading, and didn't mention
SELECT pg_reload_conf().
The attached doc patch fixes this.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterpris
brolga is still not terribly happy with this patch: it's choosing not to
push down the aggregates in one of the queries. While I failed to
duplicate that result locally, investigation suggests that brolga's result
is perfectly sane; in fact it's not very clear why we're not getting that
from multi
I just noticed that if track_commit_timestamp is enabled, the
oldestCommitTsXid and newestCommitTsXid don't persist after a server
restart, so you can't ask for the commit ts of a transaction that
committed before the last server start, although the information is
still available (unless of course
Review for postgres-fdw-more-full-join-pushdown-v6 patch.
The patch applies cleanly and regression is clean (make check in
regress directory and that in postgres_fdw).
Here are some comments.
1. Because of the following code change, for a joinrel we might end up using
attrs_used, which will be ga
On Fri, Oct 21, 2016 at 9:09 PM, Robert Haas wrote:
> On Fri, Oct 21, 2016 at 11:20 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Oct 21, 2016 at 10:47 AM, Tom Lane wrote:
dromedary seems to have found one, or at least an unstable test result.
>>
>>> OK, looking at that now. Than
On Fri, Oct 21, 2016 at 8:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Oct 21, 2016 at 10:47 AM, Tom Lane wrote:
>>> dromedary seems to have found one, or at least an unstable test result.
>
>> OK, looking at that now. Thanks.
>
> Looking at further failures, it looks like 32-bit mac
19 matches
Mail list logo
