Re: [HACKERS] SEGFAULT in CREATE EXTENSION related pg_init_privs

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

Re: [HACKERS] [COMMITTERS] pgsql: Add new catalog called pg_init_privs

* 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

Re: [HACKERS] SEGFAULT in CREATE EXTENSION related pg_init_privs

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

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

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,

Re: [HACKERS] Is a syscache tuple more like an on-disk tuple or a freshly made one?

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

Re: [HACKERS] Is a syscache tuple more like an on-disk tuple or a freshly made one?

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

Re: [HACKERS] Is a syscache tuple more like an on-disk tuple or a freshly made one?

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

Re: [HACKERS] Is a syscache tuple more like an on-disk tuple or a freshly made one?

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

[HACKERS] Is a syscache tuple more like an on-disk tuple or a freshly made one?

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

Re: [HACKERS] [COMMITTERS] pgsql: Add new catalog called pg_init_privs

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

Re: [HACKERS] [COMMITTERS] pgsql: Add new catalog called pg_init_privs

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] more parallel query documentation

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

Re: [HACKERS] [COMMITTERS] pgsql: Add new catalog called pg_init_privs

* 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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] [COMMITTERS] pgsql: Add new catalog called pg_init_privs

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

Re: [HACKERS] [COMMITTERS] pgsql: Add new catalog called pg_init_privs

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] [COMMITTERS] pgsql: Add new catalog called pg_init_privs

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] Refactor pg_dump as a library?

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] Refactor pg_dump as a library?

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

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

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: > >>

Re: [HACKERS] Disallow unique index on system columns

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

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 >>

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

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 >> >

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

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.

Re: [HACKERS] Declarative partitioning

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

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

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 +

Re: [HACKERS] EXPLAIN VERBOSE with parallel Aggregate

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:

Re: [HACKERS] SET ROLE and reserved roles

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 > > >

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

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

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

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),

Re: [HACKERS] EXPLAIN VERBOSE with parallel Aggregate

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)

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

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

Re: [HACKERS] Unreasonably generic names in matview.sql

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

Re: [HACKERS] Unreasonably generic names in matview.sql

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

Re: [HACKERS] SET ROLE and reserved roles

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

Re: [HACKERS] Choosing parallel_degree

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 >>

Re: [HACKERS] Disallow unique index on system columns

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

[HACKERS] Unreasonably generic names in matview.sql

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

Re: [HACKERS] Disallow unique index on system columns

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

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

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

Re: [HACKERS] Parallel indicators not written by pg_get_functiondef

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

Re: [HACKERS] Rework help interface of vcregress.pl

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

Re: [HACKERS] Postgres_fdw join pushdown - INNER - FULL OUTER join combination generating wrong result

On 2016/04/14 15:20, Ashutosh Bapat wrote: On Thu, Apr 14, 2016 at 8:42 AM, Etsuro Fujita > wrote: As you mentioned, we could support FULL JOIN fully, by encapsulating a joining relation with conditions into a

[HACKERS] Parallel indicators not written by pg_get_functiondef

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

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

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

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

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

[HACKERS] checkpoint_flush_after documentation inconsistency

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:

Re: [HACKERS] Declarative partitioning

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]

Re: [HACKERS] Declarative partitioning

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]

Re: [HACKERS] Support for N synchronous standby servers - take 2

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

Re: [HACKERS] Rework help interface of vcregress.pl

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

Re: [HACKERS] Rework help interface of 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

Re: [HACKERS] Rework help interface of vcregress.pl

At Fri, 15 Apr 2016 14:45:33 +0900, Michael Paquier wrote in > Hi all, > (Windows-only be careful) > > Horiguchi-san has mentioned yesterday >

Re: [HACKERS] Support for N synchronous standby servers - take 2

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 >