At Fri, 15 Apr 2016 14:45:33 +0900, Michael Paquier
wrote in
> Hi all,
> (Windows-only be careful)
>
> Horiguchi-san has mentioned yesterday
> (http://www.postgresql.org/message-id/20160414.172539.34325458.horiguchi.kyot...@lab.ntt.co.jp)
> that we are missing a couple of modes in vcregress.pl
On Fri, Apr 15, 2016 at 7:45 AM, Michael Paquier
wrote:
> Hi all,
> (Windows-only be careful)
>
> Horiguchi-san has mentioned yesterday
> (
> http://www.postgresql.org/message-id/20160414.172539.34325458.horiguchi.kyot...@lab.ntt.co.jp
> )
> that we are missing a couple of modes in vcregress.pl i
On Fri, Apr 15, 2016 at 10:03 AM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> At Fri, 15 Apr 2016 14:45:33 +0900, Michael Paquier <
> michael.paqu...@gmail.com> wrote in tcufg+dgy_gqcypre5d6...@mail.gmail.com>
> > Hi all,
> > (Windows-only be careful)
> >
> > Horiguchi-san has m
On Fri, Apr 15, 2016 at 3:00 PM, Kyotaro HORIGUCHI
wrote:
> At Fri, 15 Apr 2016 08:52:56 +0530, Amit Kapila
> wrote in
>> On Thu, Apr 14, 2016 at 1:10 PM, Masahiko Sawada
>> wrote:
>> >
>> > On Thu, Apr 14, 2016 at 1:11 PM, Kyotaro HORIGUCHI
>> > wrote:
>> > > At Thu, 14 Apr 2016 12:42:06 +09
With the new set of patches, I am getting following warnings but no
compilation failures. Patches apply smoothly.
partition.c:1216:21: warning: variable ‘form’ set but not used
[-Wunused-but-set-variable]
partition.c:1637:20: warning: variable ‘form’ set but not used
[-Wunused-but-set-variable]
Fo
With the new set of patches, I am getting following warnings but no
compilation failures. Patches apply smoothly.
partition.c:1216:21: warning: variable ‘form’ set but not used
[-Wunused-but-set-variable]
partition.c:1637:20: warning: variable ‘form’ set but not used
[-Wunused-but-set-variable]
Fo
The documentation says that the default value is 128Kb on Linux, but the
code says it's 256Kb.
Not sure which one is correct, but the other one should be updated :) I'm
guessing it's a copy/paste mistake in the docs, but since I'm not sure I'm
not just pushing a fix.
--
Magnus Hagander
Me: htt
On 2016/04/14 13:04, Robert Haas wrote:
On Wed, Apr 13, 2016 at 11:21 PM, Etsuro Fujita
wrote:
2. When a join is pushed down, deparse system columns using something
like "CASE WHEN r1.* IS NOT NULL THEN 0 END", except for the table OID
column, which gets deparsed with the table OID in place of
On 2016/04/15 14:31, Michael Paquier wrote:
On Thu, Apr 14, 2016 at 10:44 AM, Etsuro Fujita
wrote:
On 2016/04/13 21:50, Michael Paquier wrote:
On Wed, Apr 13, 2016 at 9:46 PM, Robert Haas
wrote:
On Tue, Apr 12, 2016 at 10:24 PM, Etsuro Fujita
wrote:
How about we encapsulate the while (PQi
pg_get_functiondef(oid) does not return the PARALLEL indicators.
Attached a small patch to have pg_get_functiondef actually add these
indicators, using commit 7aea8e4f2 (pg_dump.c) as a guide.
The logic is the same as with the volatility: we only append non-default
indicators.
Feike Steenbergen
On 2016/04/14 15:20, Ashutosh Bapat wrote:
On Thu, Apr 14, 2016 at 8:42 AM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
As you mentioned, we could
support FULL JOIN fully, by encapsulating a joining relation with
conditions into a subquery. And ISTM that it is relati
On Fri, Apr 15, 2016 at 5:07 PM, Magnus Hagander wrote:
> Applied with only very small changes - you had trailing slashes on src/bin
> and contrib, but not on src/test/modules. I added it to modules, to make it
> consistent. And I removed the "driver" from ECPG, because I'm pretty sure
> that's no
On Fri, Apr 15, 2016 at 8:48 PM, Feike Steenbergen
wrote:
> pg_get_functiondef(oid) does not return the PARALLEL indicators.
>
> Attached a small patch to have pg_get_functiondef actually add these
> indicators, using commit 7aea8e4f2 (pg_dump.c) as a guide.
>
> The logic is the same as with the v
On Fri, Apr 15, 2016 at 8:25 PM, Etsuro Fujita
wrote:
> How about doing something similar for PQprepare/PQexecPrepared in
> postgresExecForeignInsert, postgresExecForeignUpdate, and
> postgresExecForeignDelete?
Yes, I hesitated to touch those, but they are good candidates for this
new interface,
David Rowley writes:
> On 15 April 2016 at 13:43, David Rowley wrote:
>> The attached patch just disallows any index containing a system
>> column, apart from OID.
> Seems I only did half the job as I forgot to think to check for system
> columns that are hidden away inside expressions or predic
I've been annoyed one time too many by the fact that matview.sql
creates, and leaves around, tables and views with such generic
names as "t" and "tv". Unless someone's really attached to that,
I'd like to rename those objects to begin with, say, "mvtest".
regards, tom lane
On 2016-04-15 11:49:27 -0400, Tom Lane wrote:
> I think what we should do with this is split it into two patches, one
> to fix ALTER REPLICA IDENTITY's crash (which we'd back-patch to 9.4)
> and one to forbid indexes on system columns (which IMO should be HEAD
> only). The first of those should be
On Wed, Apr 13, 2016 at 2:21 PM, Julien Rouhaud
wrote:
>> I think we should go with "Workers Planned" and "Workers Launched",
>> capitalized exactly that way, and lose "Number Of".
>
> Fixed
>
>> I would be inclined to view this as a reasonable 9.6 cleanup of
>> parallel query, but other people ma
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 13, 2016 at 6:53 PM, Stephen Frost wrote:
> > Requiring that SET ROLE be allowed will mean that many more paths must
> > be checked and adjusted, such as in all of the CreateObject statements
> > and potentionally many other paths
No objection here.
I can do that if you would rather.
Kevin Grittner
On Fri, Apr 15, 2016 at 10:52 AM, Tom Lane wrote:
> I've been annoyed one time too many by the fact that matview.sql
> creates, and leaves around, tables and views with such generic
> names as "t" and "tv". Unless someone's
Kevin Grittner writes:
> On Fri, Apr 15, 2016 at 10:52 AM, Tom Lane wrote:
>> I've been annoyed one time too many by the fact that matview.sql
>> creates, and leaves around, tables and views with such generic
>> names as "t" and "tv". Unless someone's really attached to that,
>> I'd like to rena
On Thu, Apr 14, 2016 at 7:49 AM, Ashutosh Bapat
wrote:
> BTW, I noticed that we are deparsing whole-row reference as ROW(list of
> columns from local definition of foreign table), which has the same problem
> with outer joins. It won't be NULL when the rest of the row from that
> relation is NULL
On Wed, Apr 13, 2016 at 11:03 PM, David Rowley
wrote:
> There's 2 problems:
>
> 1)
>
> I recently noticed that EXPLAIN VERBOSE is a bit bogus when it comes
> to parallel aggregates with FILTER (WHERE ...) clauses.
>
> We get;
>
> Output: pg_catalog.sum((sum(num) FILTER (WHERE (num > 0 FILTER
>
On Fri, Apr 15, 2016 at 9:39 PM, Robert Haas wrote:
> On Thu, Apr 14, 2016 at 7:49 AM, Ashutosh Bapat
> wrote:
> > BTW, I noticed that we are deparsing whole-row reference as ROW(list of
> > columns from local definition of foreign table), which has the same
> problem
> > with outer joins. It wo
Alvaro's recommendation, to let the cleaner off the hook once it
passes the page which was the tail page at the time it started, would
prevent any process from getting pinned down indefinitely, but would
Added, see attached patch (based on v3.1)
If there is no objections I will aplly it at mondea
On Fri, Apr 15, 2016 at 8:56 AM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Wed, Apr 13, 2016 at 6:53 PM, Stephen Frost
> wrote:
> > > Requiring that SET ROLE be allowed will mean that many more paths must
> > > be checked and adjusted, such as in all
Robert Haas writes:
> I definitely agree that the current output is messed up, but I'm not
> sure your proposed output is much better. I wonder if it shouldn't
> say something like:
> Output: serialfn(transfn(args))
> for the partial aggregate and
> Output: finalfn(combinefn(deserialfn(args)))
>
On Fri, Apr 15, 2016 at 12:16 PM, Ashutosh Bapat
wrote:
> The testcases had tableoid::regclass which outputs the foreign table's local
> name, which won't change across runs. Isn't that so?
[rhaas pgsql]$ grep 16444 ~/Downloads/postgres-fdw-syscol-zap-ab.patch
+ Remote SQL: SELECT r1.c1,
On Fri, Apr 15, 2016 at 5:46 AM, Ashutosh Bapat
wrote:
> Retaining the partition hierarchy would help to push-down join across
> partition hierarchy effectively.
-1. You don't get to insert cruft into the final plan for the
convenience of the optimizer. I think the AppendPath needs to be
annota
On Fri, Apr 15, 2016 at 10:17 PM, Robert Haas wrote:
> On Fri, Apr 15, 2016 at 12:16 PM, Ashutosh Bapat
> wrote:
> > The testcases had tableoid::regclass which outputs the foreign table's
> local
> > name, which won't change across runs. Isn't that so?
>
> [rhaas pgsql]$ grep 16444 ~/Downloads/p
On Thu, Apr 14, 2016 at 12:11 PM, Andres Freund wrote:
> On 2016-04-14 11:50:58 -0400, Robert Haas wrote:
>> On Wed, Apr 13, 2016 at 9:58 PM, Andres Freund wrote:
>> > We've recently discussed a very similar issue around
>> > http://www.postgresql.org/message-id/20160227002958.peftvmcx4dxwe...@al
On 2016-04-15 13:07:19 -0400, Robert Haas wrote:
> On Thu, Apr 14, 2016 at 12:11 PM, Andres Freund wrote:
> > On 2016-04-14 11:50:58 -0400, Robert Haas wrote:
> >> On Wed, Apr 13, 2016 at 9:58 PM, Andres Freund wrote:
> >> > We've recently discussed a very similar issue around
> >> > http://www.p
Robert Haas writes:
> On Thu, Apr 14, 2016 at 12:11 PM, Andres Freund wrote:
>> The easiest way to achieve that seems to be to just assign an xid if
>> that's the case; while it's not necessarily safe/efficient to do so at
>> the point the invalidation message was queued, I think it should be saf
On Thu, Apr 14, 2016 at 1:39 AM, Abhijit Menon-Sen wrote:
> At 2016-04-12 09:00:57 -0400, robertmh...@gmail.com wrote:
>>
>> On Mon, Apr 11, 2016 at 1:17 PM, Andres Freund wrote:
>> >
>> > 3) Actually handle the case of the last open segment not being
>> >RELSEG_SIZE properly in _mdfd_getseg(
On Fri, Apr 15, 2016 at 1:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 14, 2016 at 12:11 PM, Andres Freund wrote:
>>> The easiest way to achieve that seems to be to just assign an xid if
>>> that's the case; while it's not necessarily safe/efficient to do so at
>>> the point the i
On Fri, Apr 8, 2016 at 5:48 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 01/22/2016 03:46 PM, Tom Lane wrote:
>>> Add trigonometric functions that work in degrees.
>
>> I have a host here that is having regression test failures from this commit:
>
>> --- src/test/regress/expected/float8.o
Andres Freund writes:
> On 2016-04-15 11:49:27 -0400, Tom Lane wrote:
>> I think what we should do with this is split it into two patches, one
>> to fix ALTER REPLICA IDENTITY's crash (which we'd back-patch to 9.4)
>> and one to forbid indexes on system columns (which IMO should be HEAD
>> only).
On Thu, Apr 14, 2016 at 1:01 PM, Andres Freund wrote:
> On 2016-04-14 13:16:20 +0200, Andreas Karlsson wrote:
>> I am personally not a fan of the pg_get_Xdef() functions due to their heavy
>> reliance on the syscache which feels rather unsafe in combination with
>> concurrent DDL.
>
> I'm not sure
Robert Haas writes:
> On Thu, Apr 14, 2016 at 1:01 PM, Andres Freund wrote:
>> I'm not sure I find that convincing: The state portrayed by the syscache
>> is th state COPY/SELECT et al will be using. I think the angle to
>> attack this is rather to allow blocking 'globally visible' DDL
>> effici
On 2016-04-15 13:44:27 -0400, Robert Haas wrote:
> On Fri, Apr 15, 2016 at 1:12 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Thu, Apr 14, 2016 at 12:11 PM, Andres Freund wrote:
> >>> The easiest way to achieve that seems to be to just assign an xid if
> >>> that's the case; while it's not
On 15 April 2016 at 18:44, Robert Haas wrote:
> On Fri, Apr 15, 2016 at 1:12 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Thu, Apr 14, 2016 at 12:11 PM, Andres Freund
> wrote:
> >>> The easiest way to achieve that seems to be to just assign an xid if
> >>> that's the case; while it's no
On 2016-04-15 19:59:06 +0100, Simon Riggs wrote:
> For me, the issue is that we need to do something to catch bugs. The
> existing code does not have any test at all to check whether we are doing
> the wrong thing - it just lets the wrong thing happen.
But sending the message, without assigning an
Stephen Frost wrote:
> Add new catalog called pg_init_privs
>
> This new catalog holds the privileges which the system was
> initialized with at initdb time, along with any permissions set
> by extensions at CREATE EXTENSION time. This allows pg_dump
> (and any other similar use-cases) to detect
On 15 April 2016 at 20:01, Andres Freund wrote:
> On 2016-04-15 19:59:06 +0100, Simon Riggs wrote:
> > For me, the issue is that we need to do something to catch bugs. The
> > existing code does not have any test at all to check whether we are doing
> > the wrong thing - it just lets the wrong th
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > Add new catalog called pg_init_privs
> >
> > This new catalog holds the privileges which the system was
> > initialized with at initdb time, along with any permissions set
> > by extensions at CREATE EXTENSION t
Stephen Frost wrote:
> Alvaro,
> Will take a look at this, though I'm just about to commit a fix that's
> probably related (and addresses Pavel's issue). Basically, for reasons
> unknown, I was calling systable_endscan() immediately after
> systable_getnext(), which doesn't work when you want to
Simon Riggs writes:
> In my understanding we have two choices for this bug
> 1) assign an xid so it forces sending a message (message plus xid)
> 2) send a message without assigning an xid (message only)
> (1) seems like it is worse for backpatching, IMHO, though I am willing to
> hear other tho
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > Alvaro,
>
> > Will take a look at this, though I'm just about to commit a fix that's
> > probably related (and addresses Pavel's issue). Basically, for reasons
> > unknown, I was calling systable_endscan() immediately a
On 4/14/16 10:02 PM, Robert Haas wrote:
As previously threatened, I have written some user documentation for
parallel query. I put it up here:
Yay! Definitely needed to be written. :)
There should be a section that summarizes the parallel machinery. I
think the most important points are that
On 2016-04-15 15:26:17 -0400, Tom Lane wrote:
> I think the bottom line is that we misdesigned the WAL representation
> by assuming that this sort of info could always be piggybacked on a
> transaction commit record. It's time to fix that.
I think we got to piggyback it onto a commit record, as l
Andres Freund wrote:
> On 2016-04-15 15:26:17 -0400, Tom Lane wrote:
> > I think the bottom line is that we misdesigned the WAL representation
> > by assuming that this sort of info could always be piggybacked on a
> > transaction commit record. It's time to fix that.
>
> I think we got to piggyb
Andres Freund writes:
> On 2016-04-15 15:26:17 -0400, Tom Lane wrote:
>> I think the bottom line is that we misdesigned the WAL representation
>> by assuming that this sort of info could always be piggybacked on a
>> transaction commit record. It's time to fix that.
> I think we got to piggyback
Stephen Frost wrote:
> Here's the latest message ID on the thread he started.
>
> cafj8prb_8wggxg1ekgfdq_g_c1p1ilc_j9m3jflfmld2vxt...@mail.gmail.com
>
> Pretty sure it's the same issue. Going through testing now and will
> push the fix very shortly.
May I suggest adding the extension I showed
Alvaro,
On Friday, April 15, 2016, Alvaro Herrera wrote:
> Stephen Frost wrote:
>
> > Here's the latest message ID on the thread he started.
> >
> > cafj8prb_8wggxg1ekgfdq_g_c1p1ilc_j9m3jflfmld2vxt...@mail.gmail.com
>
> >
> > Pretty sure it's the same issue. Going through testing now and will
Please bear with a neophyte question ...
I am tempted to apply HeapTupleGetDatum to a tuple retrieved from
the syscache (as I already have code for processing a tuple presented
as a Datum).
But I see a comment on HeapTupleHeaderGetDatum: "This must *not* get
applied to an on-disk tuple; the tuple
Chapman Flack wrote:
> I am tempted to apply HeapTupleGetDatum to a tuple retrieved from
> the syscache (as I already have code for processing a tuple presented
> as a Datum).
>
> But I see a comment on HeapTupleHeaderGetDatum: "This must *not* get
> applied to an on-disk tuple; the tuple should
Chapman Flack writes:
> I am tempted to apply HeapTupleGetDatum to a tuple retrieved from
> the syscache (as I already have code for processing a tuple presented
> as a Datum).
> But I see a comment on HeapTupleHeaderGetDatum: "This must *not* get
> applied to an on-disk tuple; the tuple should b
On 04/15/16 18:03, Alvaro Herrera wrote:
> I suppose you could create a copy of the tuple (SysCacheSearchCopy) and
> use that for HeapTupleGetDatum. The problem with the syscache tuple is
> that it can go away as soon as you do the ReleaseSysCache -- it lives in
> shared_buffers memory, so when i
Chapman Flack writes:
> On 04/15/16 18:13, Tom Lane wrote:
>> You could use heap_copy_tuple_as_datum().
> Thanks, that looks like what the doctor ordered.
> For pre-9.4, would the equivalent be basically
> heap_form_tuple applied to the results of heap_deform_tuple ?
You could do that, or you c
On Fri, Apr 15, 2016 at 9:46 PM, Michael Paquier
wrote:
> On Fri, Apr 15, 2016 at 8:25 PM, Etsuro Fujita
> wrote:
>> How about doing something similar for PQprepare/PQexecPrepared in
>> postgresExecForeignInsert, postgresExecForeignUpdate, and
>> postgresExecForeignDelete?
>
> Yes, I hesitated to
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2016-04-14 14:26 GMT+02:00 Stephen Frost :
> >
> > * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > > I am trying to prepare orafce for PostgreSQL 9.6.
> > >
> > > I can successfully compile this extension, but the statement CREATE
> >
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > Alvaro,
>
> > Will take a look at this, though I'm just about to commit a fix that's
> > probably related (and addresses Pavel's issue). Basically, for reasons
> > unknown, I was calling systable_endscan() immediately a
2016-04-16 4:12 GMT+02:00 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > 2016-04-14 14:26 GMT+02:00 Stephen Frost :
> > >
> > > * Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > > > I am trying to prepare orafce for PostgreSQL 9.6.
> > > >
> > > > I can succes
63 matches
Mail list logo
