Re: [HACKERS] patch: function xmltable

2016-09-27 5:53 GMT+02:00 Craig Ringer : > On 24 September 2016 at 14:01, Pavel Stehule > wrote: > > >> Did some docs copy-editing and integrated some examples. Explained how > >> nested elements work, that multiple top level elements is an error,

Re: [HACKERS] Declarative partitioning - another take

On 2016/09/22 19:10, Ashutosh Bapat wrote: > On Thu, Sep 22, 2016 at 1:02 PM, Ashutosh Bapat > wrote: >> For list partitions, the ListInfo stores the index maps for values >> i.e. the index of the partition to which the value belongs. Those >> indexes are same as

Re: [HACKERS] Push down more full joins in postgres_fdw

On Tue, Sep 27, 2016 at 8:48 AM, Etsuro Fujita wrote: > On 2016/09/26 20:20, Ashutosh Bapat wrote: >> >> On Mon, Sep 26, 2016 at 4:06 PM, Etsuro Fujita >> wrote: >>> >>> On 2016/09/26 18:06, Ashutosh Bapat wrote: On Mon, Sep 26,

Re: [HACKERS] pageinspect: Hash index support

Peter Eisentraut wrote: > On 9/26/16 1:39 PM, Jesper Pedersen wrote: > >> - hash_metap result fields spares and mapp should be arrays of integer. > > > > B-tree and BRIN uses a 'text' field as output, so left as is. > > These fields are specific to hash, so the precedent doesn't necessarily >

Re: [HACKERS] patch: function xmltable

On 24 September 2016 at 14:01, Pavel Stehule wrote: >> Did some docs copy-editing and integrated some examples. Explained how >> nested elements work, that multiple top level elements is an error, >> etc. Explained the time-of-evaluation stuff. Pointed out that you can

Re: [HACKERS] patch: function xmltable

2016-09-27 3:34 GMT+02:00 Craig Ringer : > On 24 September 2016 at 14:01, Pavel Stehule > wrote: > > >> Did some docs copy-editing and integrated some examples. Explained how > >> nested elements work, that multiple top level elements is an error,

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/26 20:20, Ashutosh Bapat wrote: On Mon, Sep 26, 2016 at 4:06 PM, Etsuro Fujita wrote: On 2016/09/26 18:06, Ashutosh Bapat wrote: On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita wrote: ISTM that the use of the same RTI for

Re: [HACKERS] pageinspect: Hash index support

On 9/26/16 1:39 PM, Jesper Pedersen wrote: > Left as is, since BuildTupleFromCStrings() vs. xyzGetDatum() are equally > readable in this case. But, I can change the patch if needed. The point is that to use BuildTupleFromCStrings() you need to convert numbers to strings, and then they are

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Tue, Sep 27, 2016 at 11:16 AM, Peter Eisentraut wrote: > On 9/23/16 11:15 AM, Michael Paquier wrote: >>> 0002: >>> > >>> > durable_rename needs close(fd) in non-error path (compare backend code). >> Oops, leak. > > Why did you remove the errno save and

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Mon, Sep 26, 2016 at 9:22 PM, David Steele wrote: > On 9/26/16 4:54 AM, Heikki Linnakangas wrote: >> Hmm. The server could send a SCRAM challenge first, and if the client >> gives an incorrect response, or the username doesn't exist, or the >> user's password is actually

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On 9/23/16 11:15 AM, Michael Paquier wrote: >> 0002: >> > >> > durable_rename needs close(fd) in non-error path (compare backend code). > Oops, leak. Why did you remove the errno save and restore? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, Attached is v2 of the patch, updated based on the review. That means: - Better comment explaining how free chunks are tracked in Slab context. - Removed the unused SlabPointerIsValid macro. - Modified the comment before SlabChunkData, explaining how it relates to StandardChunkHeader. -

Re: [HACKERS] Stopping logical replication protocol

On 26 September 2016 at 21:52, Vladimir Gordiychuk wrote: >>You should rely on time I tests as little as possible. Some of the test >> hosts are VERY slow. If possible something deterministic should be used. > > That's why this changes difficult to verify. Maybe in that case we

[HACKERS] Detect supported SET parameters when pg_restore is run

Hackers, At work we use several major versions of PostgreSQL, and developers use non-local clusters for developing and debugging. We do dump/restore schemas/data via custom/dir formats and we have to keep several client versions for 9.2, 9.4 and 9.5 versions on local workstations because after

Re: [HACKERS] pgbench - allow to store select results into variables

On 2016/09/26 20:27, Fabien COELHO wrote: > > Hello Amit, > >>> I am marking the pgbench-into-5.patch [1] as "Ready for Committer" as I >>> have no further comments at the moment. >> >> Wait... Heikki's latest commit now requires this patch to be rebased. > > Indeed. Here is the rebased

Re: [HACKERS] patch: function xmltable

On 24 September 2016 at 14:01, Pavel Stehule wrote: >> Did some docs copy-editing and integrated some examples. Explained how >> nested elements work, that multiple top level elements is an error, >> etc. Explained the time-of-evaluation stuff. Pointed out that you can

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 21 September 2016 at 22:16, Robert Haas wrote: > On Wed, Sep 21, 2016 at 3:40 AM, Craig Ringer wrote: >> The only non-horrible one of those is IMO to just let the caller see >> an error if they lose the race. It's a function that's intended for >>

Re: [HACKERS] [COMMITTERS] pgsql: pg_ctl: Detect current standby state from pg_control

On Tue, Sep 27, 2016 at 9:45 AM, Peter Eisentraut wrote: > On 9/26/16 7:56 PM, Peter Eisentraut wrote: >> On 9/26/16 8:53 AM, Tom Lane wrote: >>> I think that it's 100% pointless for get_control_dbstate >>> to be worried about transient CRC failures. If writes

[HACKERS] Re: [COMMITTERS] pgsql: pg_ctl: Detect current standby state from pg_control

On 9/26/16 7:56 PM, Peter Eisentraut wrote: > On 9/26/16 8:53 AM, Tom Lane wrote: >> I think that it's 100% pointless for get_control_dbstate >> to be worried about transient CRC failures. If writes to pg_control >> aren't atomic then we have problems enormously larger than whether >> "pg_ctl

Re: [HACKERS] wal_segment size vs max_wal_size

On Mon, Sep 26, 2016 at 9:30 PM, Kuntal Ghosh wrote: > On Mon, Sep 26, 2016 at 5:04 PM, Amit Kapila wrote: >> >> IIRC, there is already a patch to update the minRecoveryPoint >> correctly, can you check if that solves the problem for you? >>

Re: [HACKERS] Speedup twophase transactions

On Thu, Sep 22, 2016 at 12:30 AM, Stas Kelvich wrote: > I’m not giving up yet, i’ll write them) I still have in mind several other > patches to 2pc handling in > postgres during this release cycle — logical decoding and partitioned hash > instead of > TwoPhaseState

Re: [HACKERS] VACUUM's ancillary tasks

On Tue, Sep 27, 2016 at 2:33 AM, Tom Lane wrote: > Thomas Munro writes: >> I noticed that ATExecAlterColumnType does this: >> * Drop any pg_statistic entry for the column, since it's now wrong type > >> What if there is no rewrite, because

Re: [HACKERS] Add support for restrictive RLS policies

Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > Stephen Frost wrote: > > > + > > > + If the policy is a "permissive" or "restrictive" policy. > > > Permissive > > > + policies are the default and always add visibillity- they ar "OR"d > > > +

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Sep 13, 2016 at 12:55 PM, Mithun Cy wrote: > On Thu, Sep 8, 2016 at 11:21 PM, Jesper Pedersen < > jesper.peder...@redhat.com> wrote: >> >> > For the archives, this patch conflicts with the WAL patch [1]. >> >> > [1]

Re: [HACKERS] pageinspect: Hash index support

Jeff Janes wrote: > On Tue, Sep 20, 2016 at 12:19 AM, Michael Paquier > wrote: > > > > > Note: the patch checks if a superuser is calling the new functions, > > which is a good thing. > > > > If we only have the bytea functions and the user needs to supply the raw >

Re: [HACKERS] pageinspect: Hash index support

On Tue, Sep 20, 2016 at 12:19 AM, Michael Paquier wrote: > > Note: the patch checks if a superuser is calling the new functions, > which is a good thing. > If we only have the bytea functions and the user needs to supply the raw pages themselves, rather than having

Re: [HACKERS] pgbench more operators & functions

Hello Jeevan, I did the review of your patch and here are my views on your patch. Thanks for this detailed review and debugging! Documentation: [...] it be a good idea to have a table of operators similar to that of functions. We need not have several columns here like description,

Re: [HACKERS] Add support for restrictive RLS policies

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > Stephen, the typo "awseome" in the tests is a bit distracting. Can you > please fix it? Will fix. > > Updated patch changes to using IDENT and an strcmp() (similar to > > AlterOptRoleElem and

Re: [HACKERS] Add support for restrictive RLS policies

Stephen Frost wrote: Stephen, the typo "awseome" in the tests is a bit distracting. Can you please fix it? > Updated patch changes to using IDENT and an strcmp() (similar to > AlterOptRoleElem and vacuum_option_elem) to check the results at parse-time, > and then throwing a more specific error

Re: [HACKERS] Remove superuser() checks from pgstattuple

Peter, all, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > This is now being obsoleted by the later idea of allowing base installs > from a chain of upgrade scripts. But if your upgrade scripts contain > ALTER TABLE commands, you will probably still want to write base install >

Re: [HACKERS] proposal: psql \setfileref

2016-09-26 21:47 GMT+02:00 Ryan Murphy : > > >> please, can you check attached patch? It worked in my laptop. >> >> Regards >> >> Pavel >> >> > Yes, that one applied for me without any problems. > Great, Thank you Pavel > > Thanks, > Ryan >

Re: [HACKERS] proposal: psql \setfileref

> > please, can you check attached patch? It worked in my laptop. > > Regards > > Pavel > > Yes, that one applied for me without any problems. Thanks, Ryan

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Sep 26, 2016 at 6:58 PM, Robert Haas wrote: >> That requires some kind of mutual exclusion mechanism, like an LWLock. > > No, it doesn't. Shared memory queues are single-reader, single-writer. The point is that there is a natural dependency when merging is

Re: [HACKERS] [GENERAL] inconsistent behaviour of set-returning functions in sub-query with random()

Tom van Tilburg writes: > I'm often using the WHERE clause random() > 0.5 to pick a random subset of > my data. Now I noticed that when using a set-returning function in a > sub-query, I either get the whole set or none (meaning that the WHERE > random() > 0.5 clause is

Re: [HACKERS] Add support for restrictive RLS policies

Jeevan, all, * Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote: > On Mon, Sep 12, 2016 at 7:27 AM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > > > On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane wrote: > > > > Stephen Frost

Re: [HACKERS] pageinspect: Hash index support

On Mon, Sep 26, 2016 at 10:39 AM, Jesper Pedersen < jesper.peder...@redhat.com> wrote: > Hi, > > On 09/23/2016 12:10 AM, Peter Eisentraut wrote: > >> >> > - As of very recently, we don't need to move pageinspect--1.5.sql to >> pageinspect--1.6.sql anymore. Just add pageinspect--1.5--1.6.sql. >>

Re: [HACKERS] Add support for restrictive RLS policies

Jeevan, * Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote: > I have started reviewing this patch and here are couple of points I have > observed so far: > > 1. Patch applies cleanly > 2. make / make install / initdb all good. > 3. make check (regression) FAILED. (Attached diff file for

Re: [HACKERS] proposal: psql \setfileref

Hi 2016-09-26 14:57 GMT+02:00 Ryan Murphy : > Hi Pavel, > > I just tried to apply your patch psql-setfileref-initial.patch (using git > apply) to the newest revision of postgres at the time (da6c4f6ca88) and it > failed to patch startup.c. Thinking that the patch was for

Re: [HACKERS] Showing parallel status in \df+

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Sep 26, 2016 at 10:48 AM, Stephen Frost wrote: > > I agree that "do nothing" isn't a good option. I'm not terribly > > thrilled with just putting the source code at the bottom of the \df+ > > output either, though it's at

Re: [HACKERS] Allowing GIN array_ops to work on anyarray

Enrique Meneses writes: > Great, given it does not apply to this patch, then all the other tests > passed and the change looks good. Pushed, thanks for the review! regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

> > This crashes with arrays with non-default lower bounds: > > postgres=# SELECT * FROM test_type_conversion_array_int4('[2:4]={1,2,3}'); > INFO: ([1, 2, ], ) > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 09/26/2016 07:16 PM, Tomas Vondra wrote: The averages (over the 10 runs, 5 minute each) look like this: 3.2.80 1 8 16 32 64128192 granular-locking1567 12146 26341 44188

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sat, Sep 24, 2016 at 9:07 AM, Peter Geoghegan wrote: > On Thu, Sep 22, 2016 at 8:57 PM, Robert Haas wrote: >> On Thu, Sep 22, 2016 at 3:51 PM, Heikki Linnakangas wrote: >>> It'd be good if you could overlap the final merges in the

Re: [HACKERS] [PATCH] pgpassfile connection option

On Thu, Sep 22, 2016 at 11:34 AM, Julian Markwort wrote: > I haven't really thought about this as I had been asked to make this work as > an additional option to the connection parameters... > Now that I've looked at it - there is really only the benefit of saving

Re: [HACKERS] pageinspect: Hash index support

On 09/23/2016 01:56 AM, Amit Kapila wrote: While looking at patch, I noticed below code which seems somewhat problematic: + stat->max_avail = BLCKSZ - (BLCKSZ - phdr->pd_special + SizeOfPageHeaderData); + + /* page type (flags) */ + if (opaque->hasho_flag & LH_META_PAGE) + stat->type = 'm'; +

Re: [HACKERS] pageinspect: Hash index support

Hi, On 09/23/2016 12:10 AM, Peter Eisentraut wrote: On 9/21/16 9:30 AM, Jesper Pedersen wrote: Attached is v5, which add basic page verification. There are still some things that I found that appear to follow the old style (btree) conventions instead the new style (brin, gin) conventions. -

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Sep 23, 2016 at 9:20 AM, Amit Kapila wrote: > On Fri, Sep 23, 2016 at 6:50 AM, Robert Haas wrote: >> On Thu, Sep 22, 2016 at 7:44 PM, Tomas Vondra >> wrote: >>> I don't dare to suggest rejecting the patch, but

Re: [HACKERS] Showing parallel status in \df+

On Mon, Sep 26, 2016 at 10:48 AM, Stephen Frost wrote: > I agree that "do nothing" isn't a good option. I'm not terribly > thrilled with just putting the source code at the bottom of the \df+ > output either, though it's at least slightly less ridiculous than trying > to put

Re: [HACKERS] proposal: psql \setfileref

2016-09-26 14:57 GMT+02:00 Ryan Murphy : > Hi Pavel, > > I just tried to apply your patch psql-setfileref-initial.patch (using git > apply) to the newest revision of postgres at the time (da6c4f6ca88) and it > failed to patch startup.c. Thinking that the patch was for some

Re: [HACKERS] temporary table vs array performance

2016-09-26 17:39 GMT+02:00 dby...@163.com : > test: > create type h3 as (id int,name char(10)); > > CREATE or replace FUNCTION proc17() > RETURNS SETOF h3 AS $$ > DECLARE > v_rec h3; > BEGIN > create temp table abc(id int,name varchar) on commit drop; > insert into abc

Re: [HACKERS] Allowing GIN array_ops to work on anyarray

Great, given it does not apply to this patch, then all the other tests passed and the change looks good. Thank you, Enrique On Mon, Sep 26, 2016 at 6:27 AM Tom Lane wrote: > Enrique Meneses writes: > > I was not sure what "Spec compliant means"... so

Re: [HACKERS] temporary table vs array performance

Its considered bad form to post to multiple lists. Please pick the most relevant one - in this case I'd suggest -general. On Mon, Sep 26, 2016 at 8:39 AM, dby...@163.com wrote: > > Array is not convenient to use in function, whether > there are other methods can be replaced

[HACKERS] temporary table vs array performance

test: create type h3 as (id int,name char(10)); CREATE or replace FUNCTION proc17() RETURNS SETOF h3 AS $$ DECLARE v_rec h3; BEGIN create temp table abc(id int,name varchar) on commit drop; insert into abc select 1,'lw'; insert into abc select 2,'lw2'; for v_rec in select * from abc loop

Re: [HACKERS] WIP: Covering + unique indexes.

24.09.2016 15:36, Amit Kapila: On Wed, Sep 21, 2016 at 6:51 PM, Anastasia Lubennikova wrote: 20.09.2016 08:21, Amit Kapila: On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova wrote: 28.08.2016 09:13, Amit Kapila: The problem

Re: [HACKERS] Showing parallel status in \df+

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Pavel Stehule writes: > > 2016-09-23 7:22 GMT+02:00 Rushabh Lathia : > >> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote: > >>> If it's unreadable in \df+, how would \df++ make that

Re: [HACKERS] Showing parallel status in \df+

Pavel Stehule writes: > 2016-09-23 7:22 GMT+02:00 Rushabh Lathia : >> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote: >>> If it's unreadable in \df+, how would \df++ make that any better? >> Eventhough source code as part

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

"Tsunakawa, Takayuki" writes: >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas >> I think that we shouldn't start changing things based on guesses about what >> the problem is, even if they're fairly smart guesses. The thing to do would >>

Re: [HACKERS] Small race in pg_xlogdump --follow

Magnus Hagander writes: > Oh, right, at the very last loop. I've never seen it need more than 1 loop > so I didn't manage to hit that codepath :) But yeah, saving errno and > restoring it on the other side of pg_usleep is probably a good idea. Right. On a larger scale ---

Re: [HACKERS] Stopping logical replication protocol

>You should rely on time I tests as little as possible. Some of the test hosts are VERY slow. If possible something deterministic should be used. That's why this changes difficult to verify. Maybe in that case we should write benchmark but not integration test? In that case we can say, before

Re: [HACKERS] Small race in pg_xlogdump --follow

On Mon, Sep 26, 2016 at 3:44 PM, Tom Lane wrote: > Magnus Hagander writes: > > Attached patch puts a retry loop around opening the file that retries > for 5 > > seconds (which is excessive, but should be safe) in case the file is > > missing (and still

Re: [HACKERS] pgbench more operators & functions

On Sat, Jul 9, 2016 at 12:14 PM, Fabien COELHO wrote: > >> Here is a simple patch which adds a bunch of operators (bitwise: & | ^ ~, >> comparisons: =/== <>/!= < <= > >=, logical: and/&& or/|| xor/^^ not/!) and >> functions (exp ln if) to pgbench. I've tried to be pg's SQL

Re: [HACKERS] Small race in pg_xlogdump --follow

Magnus Hagander writes: > Attached patch puts a retry loop around opening the file that retries for 5 > seconds (which is excessive, but should be safe) in case the file is > missing (and still fails out for other error messages of course). > Comments? The patch assumes

[HACKERS] Small race in pg_xlogdump --follow

When using pg_xlogdump in --follow mode, there is what I believe is a small race condition when files are switched. If pg_xlogdump detects then end of one file (by looking at the record) it will immediately try to open the following file. If that file has not yet been created, it will fail with

Re: [HACKERS] VACUUM's ancillary tasks

Thomas Munro writes: > I noticed that ATExecAlterColumnType does this: > * Drop any pg_statistic entry for the column, since it's now wrong type > What if there is no rewrite, because the type is binary compatible > (ATColumnChangeRequiresRewrite returns

Re: [HACKERS] Allowing GIN array_ops to work on anyarray

Enrique Meneses writes: > I was not sure what "Spec compliant means"... so I did not select as tested > or passed. What should I do to validate that this change is "Spec compliant"? It's irrelevant to this patch, AFAICS. The SQL standard doesn't discuss indexes at all,

Re: [HACKERS] Allowing GIN array_ops to work on anyarray

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed I built and installed (make world / make install-world) github

Re: [HACKERS] Allowing GIN array_ops to work on anyarray

I was not sure what "Spec compliant means"... so I did not select as tested or passed. What should I do to validate that this change is "Spec compliant"? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] proposal: psql \setfileref

Hi Pavel, I just tried to apply your patch psql-setfileref-initial.patch (using git apply) to the newest revision of postgres at the time (da6c4f6ca88) and it failed to patch startup.c. Thinking that the patch was for some previous revision, I then checked out d062245b5, which was from

Re: [HACKERS] Aggregate Push Down - Performing aggregation on foreign server

This patch will need some changes to conversion_error_callback(). That function reports an error in case there was an error converting the result obtained from the foreign server into an internal datum e.g. when the string returned by the foreign server is not acceptable by local input function

Re: [HACKERS] wal_segment size vs max_wal_size

On Mon, Sep 26, 2016 at 5:04 PM, Amit Kapila wrote: > > IIRC, there is already a patch to update the minRecoveryPoint > correctly, can you check if that solves the problem for you? > > [1] - >

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 9/26/16 4:54 AM, Heikki Linnakangas wrote: > On 09/26/2016 09:02 AM, Michael Paquier wrote: >> On Mon, Sep 26, 2016 at 2:15 AM, David Steele >> wrote: >>> However, it doesn't look like they can be used in conjunction since the >>> pg_hba.conf entry must specify either m5

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Mon, Sep 26, 2016 at 5:25 PM, Masahiko Sawada wrote: > On Mon, Sep 26, 2016 at 7:28 PM, Ashutosh Bapat > wrote: >> My original patch added code to manage the files for 2 phase >> transactions opened by the local server on the remote

Re: [HACKERS] Add support for restrictive RLS policies

Hi, I have started reviewing this patch and here are couple of points I have observed so far: 1. Patch applies cleanly 2. make / make install / initdb all good. 3. make check (regression) FAILED. (Attached diff file for reference). Please have a look over failures. Meanwhile I will go ahead

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Mon, Sep 26, 2016 at 7:28 PM, Ashutosh Bapat wrote: > My original patch added code to manage the files for 2 phase > transactions opened by the local server on the remote servers. This > code was mostly inspired from the code in twophase.c which manages the >

Re: [HACKERS] Add support for restrictive RLS policies

On Mon, Sep 12, 2016 at 7:27 AM, Stephen Frost wrote: > Robert, > > * Robert Haas (robertmh...@gmail.com) wrote: > > On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane wrote: > > > Stephen Frost writes: > > >> * Alvaro Herrera

Re: [HACKERS] wal_segment size vs max_wal_size

On Mon, Sep 26, 2016 at 4:00 PM, Kuntal Ghosh wrote: > On Wed, Sep 21, 2016 at 8:33 PM, Peter Eisentraut > wrote: >> There is apparently some misbehavior if max_wal_size is less than 5 * >> wal_segment_size. >> > >> This should

Re: [HACKERS] pgbench - allow to store select results into variables

Hello Amit, I am marking the pgbench-into-5.patch [1] as "Ready for Committer" as I have no further comments at the moment. Wait... Heikki's latest commit now requires this patch to be rebased. Indeed. Here is the rebased version, which still get through my various tests. -- Fabien.diff

Re: [HACKERS] Push down more full joins in postgres_fdw

On Mon, Sep 26, 2016 at 4:06 PM, Etsuro Fujita wrote: > On 2016/09/26 18:06, Ashutosh Bapat wrote: >> >> On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita >> wrote: > > >>> ISTM that the use of the same RTI for subqueries in multi-levels in

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/26 18:06, Ashutosh Bapat wrote: On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita wrote: ISTM that the use of the same RTI for subqueries in multi-levels in a remote SQL makes the SQL a bit difficult to read. How about using the position of the join rel

Re: [HACKERS] wal_segment size vs max_wal_size

On Wed, Sep 21, 2016 at 8:33 PM, Peter Eisentraut wrote: > There is apparently some misbehavior if max_wal_size is less than 5 * > wal_segment_size. > > For example, if you build with --with-wal-segsize=64, then the recovery > test fails unless you set

Re: [HACKERS] Transactions involving multiple postgres foreign servers

My original patch added code to manage the files for 2 phase transactions opened by the local server on the remote servers. This code was mostly inspired from the code in twophase.c which manages the file for prepared transactions. The logic to manage 2PC files has changed since [1] and has been

Re: [HACKERS] Push down more full joins in postgres_fdw

On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita wrote: > On 2016/09/15 15:29, Ashutosh Bapat wrote: >> >> On Wed, Sep 14, 2016 at 8:52 PM, Robert Haas >> wrote: > > >>> I'm not sure why it wouldn't work >>> to just use the lowest RTI involved in

Re: [HACKERS] Aggregate Push Down - Performing aggregation on foreign server

Thanks Jeevan for working on the comments. > > 3. classifyConditions() assumes list expressions of type RestrictInfo. But > HAVING clause expressions (and JOIN conditions) are plain expressions. Do > you mean we should modify the classifyConditions()? If yes, then I think it > should be done as a

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 09/26/2016 09:02 AM, Michael Paquier wrote: On Mon, Sep 26, 2016 at 2:15 AM, David Steele wrote: However, it doesn't look like they can be used in conjunction since the pg_hba.conf entry must specify either m5 or scram (though the database can easily contain a mixture).

Re: [HACKERS] pgbench - allow to store select results into variables

On 2016/09/26 16:12, Amit Langote wrote: > I am marking the pgbench-into-5.patch [1] as "Ready for Committer" as I > have no further comments at the moment. Wait... Heikki's latest commit now requires this patch to be rebased. commit 12788ae49e1933f463bc59a6efe46c4a01701b76 Author: Heikki

Re: [HACKERS] WAL logging problem in 9.4.3?

Hello, I return to this before my things:) Though I haven't played with the patch yet.. At Fri, 29 Jul 2016 16:54:42 +0900, Michael Paquier wrote in > > Well, not that soon at the end, but I am back

Re: [HACKERS] pgbench - minor fix for meta command only scripts

On 09/24/2016 12:45 PM, Fabien COELHO wrote: Although I cannot be absolutely sure that the refactoring does not introduce any new bug, I'm convinced that it will be much easier to find them:-) :-) Attached are some small changes to your version: I have added the sleep_until fix. I have

Re: [HACKERS] Declarative partitioning - another take

Hi Ashutosh, On 2016/09/22 14:42, Ashutosh Bapat wrote: > Hi Amit, > Following sequence of DDLs gets an error > -- > -- multi-leveled partitions > -- > CREATE TABLE prt1_l (a int, b int, c varchar) PARTITION BY RANGE(a); > CREATE TABLE prt1_l_p1 PARTITION OF prt1_l FOR VALUES START (0) END >

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

On 2016/09/21 0:40, Robert Haas wrote: On Fri, Jul 1, 2016 at 3:10 AM, Etsuro Fujita wrote: On 2016/04/14 4:57, Robert Haas wrote: 1. For a regular FDW scan, zero the xmin, xmax, and cid of the tuple before returning it from postgres_fdw, so that we don't expose

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/15 15:29, Ashutosh Bapat wrote: On Wed, Sep 14, 2016 at 8:52 PM, Robert Haas wrote: I'm not sure why it wouldn't work to just use the lowest RTI involved in the join, though; the others won't appear anywhere else at that query level. So +1 for using the

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/13 14:17, Ashutosh Bapat wrote: But another concern about the approach of generating an subselect alias for a path, if needed, at the path creation time would be that the path might be rejected by add_path, which would result in totally wasting cycles for generating

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On 2016/09/07 10:54, vinayak wrote: Thanks for the clarification. I had added pg_fdw_xact_resolver() to resolve any transactions which can not be resolved immediately after they were prepared. There was a comment from Kevin (IIRC) that leaving transactions unresolved on the foreign server

Re: [HACKERS] pgbench - allow to store select results into variables

Hi Fabien, I am marking the pgbench-into-5.patch [1] as "Ready for Committer" as I have no further comments at the moment. Thanks, Amit [1] https://www.postgresql.org/message-id/alpine.DEB.2.20.1609130730380.10870%40lancre -- Sent via pgsql-hackers mailing list

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

On Sat, Sep 24, 2016 at 3:26 AM, David Steele wrote: > On 9/12/16 2:50 PM, Peter Eisentraut wrote: >> The comments on excludeDirContents are somewhat imprecise. For >> example, none of those directories are actually removed or recreated >> on startup, only the contents are.

Re: [HACKERS] Refactoring of heapam code.

On Tue, Sep 6, 2016 at 8:39 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 06.09.2016 07:44, Pavan Deolasee: > > > I don't know what to do with the CF entry itself. I could change the > status to "waiting on author" but then the design draft may not get enough > attention. So

Re: [HACKERS] Tracking wait event for latches

On Mon, Sep 26, 2016 at 1:46 PM, Thomas Munro wrote: > If the class really is strictly implied by the WaitEventIdentifier, > then do we really need to supply it everywhere when calling the > various wait functions? That's going to be quite a few functions: >