Re: [HACKERS] Rework the way multixact truncations work

On Tue, Dec 01, 2015 at 05:07:15PM -0500, Robert Haas wrote: > I think it's weird to back a commit out only to put a bunch of very similar > stuff back in. I agree with that. If the original patches and their replacements shared 95% of diff lines in common, we wouldn't be having this

Re: [HACKERS] Remaining 9.5 open items

On 2015-12-02 08:25:13 -0800, Joshua D. Drake wrote: > A feature does not exist without documentation. Uh, you do realize there's actually documentation about RLS? The issues mentioned here are some small adjustments, not entirely new docs. -- Sent via pgsql-hackers mailing list

[HACKERS] psql ignores failure to open -o target file

I just noticed that parse_psql_options() ignores the result of setQFout(), meaning that if the argument of a -o command line option is bogus, we'll ignore the switch entirely after printing an error report. For example $ psql -o /dev/foo -c 'select 1' /dev/foo: Permission denied ?column?

Re: [HACKERS] Remaining 9.5 open items

On 12/02/2015 05:27 AM, Robert Haas wrote: On Mon, Nov 30, 2015 at 4:55 PM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: Well, it's December nearly, and we don't seem to be making much progress towards pushing out 9.5.0. I see the following items on

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

On Wed, Dec 2, 2015 at 7:45 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > Thank you for picking this up. > > At Tue, 1 Dec 2015 20:33:02 +0530, Amit Kapila wrote in > > On Mon, Nov

Re: [HACKERS] Rework the way multixact truncations work

On 2015-12-02 09:57:19 -0500, Noah Misch wrote: > On Tue, Dec 01, 2015 at 05:07:15PM -0500, Robert Haas wrote: > > I think it's weird to back a commit out only to put a bunch of very similar > > stuff back in. > > I agree with that. If the original patches and their replacements shared 95% > of

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

On Fri, Nov 27, 2015 at 2:32 AM, Amit Kapila wrote: > Okay, as discussed I have handled the case of sub-transactions without > additional shmem in the attached patch. Apart from that, I have tried > to apply this optimization for Prepared transactions as well, but as >

Re: [HACKERS] Logical replication and multimaster

On Mon, Nov 30, 2015 at 11:20 AM, Konstantin Knizhnik wrote: > We have implemented ACID multimaster based on logical replication and our > DTM (distributed transaction manager) plugin. > Good news is that it works and no inconsistency is detected. > But unfortunately it

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Tue, Dec 1, 2015 at 2:25 AM, Kyotaro HORIGUCHI wrote: > Yeah, it is actually restricted in that length. But if we allow > the buffer to store whole the qualified names, it will need 64 * > 2 + 1 +1 = 130 bytes * 10 1300 bytes for each beentry... It might > be

Re: [HACKERS] Remaining 9.5 open items

On 12/02/2015 08:39 AM, Andres Freund wrote: On 2015-12-02 08:25:13 -0800, Joshua D. Drake wrote: A feature does not exist without documentation. Uh, you do realize there's actually documentation about RLS? The issues mentioned here are some small adjustments, not entirely new docs. No I

Re: [HACKERS] Errors in our encoding conversion tables

On Fri, Nov 27, 2015 at 8:54 PM, Tatsuo Ishii wrote: > I explain why the manual editing is necessary. > > One of the most famous problems with Unicode is "wave dash" > (U+301C). According the Unicode consortium's Unicode/SJIS map, it > corresponds to 0x8160 of Shift_JIS.

Re: [HACKERS] psql: add \pset true/false

On 11/15/15 7:37 PM, Peter Eisentraut wrote: On 11/15/15 3:20 PM, Jim Nasby wrote: As to the argument about displaying a check or an X, why should that capability only exist for boolean types? For example, why not allow psql to convert a numeric value into a bar of varying sizes? I've

Re: [HACKERS] psql ignores failure to open -o target file

On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote: > On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote: > > I just noticed that parse_psql_options() ignores the result of > setQFout(), > > meaning that if the argument of a -o command line option is

Re: [HACKERS] psql ignores failure to open -o target file

"David G. Johnston" writes: > On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote: >> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote: >>> This seems surprising to me: any other program in the world would do >>> exit(1) after

Re: [HACKERS] psql ignores failure to open -o target file

I wrote: > I just noticed that parse_psql_options() ignores the result of setQFout(), > meaning that if the argument of a -o command line option is bogus, we'll > ignore the switch entirely after printing an error report. There's more silliness in the same area. \o with an invalid target spec is

Re: [HACKERS] psql ignores failure to open -o target file

On Wed, Dec 2, 2015 at 1:24 PM, Tom Lane wrote: > "David G. Johnston" writes: >> On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote: >>> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote: This seems

Re: [HACKERS] Errors in our encoding conversion tables

Robert Haas writes: > On Fri, Nov 27, 2015 at 8:54 PM, Tatsuo Ishii wrote: >> In short, there are number of reasons we cannot simply import the >> consortium's mapping regarding SJIS (and EUC_JP). > I haven't seen a response to this point, but it

Re: [HACKERS] Making the C collation less inclined to abort abbreviation

On Sun, Nov 29, 2015 at 4:02 PM, Peter Geoghegan wrote: > The C collation is treated exactly the same as other collations when > considering whether the generation of abbreviated keys for text should > continue. This doesn't make much sense. With text, the big cost that > we are

Re: [HACKERS] Using quicksort for every external sort run

On Sat, Nov 28, 2015 at 7:05 PM, Peter Geoghegan wrote: > On Sat, Nov 28, 2015 at 2:04 PM, Jeff Janes wrote: >> For me very large sorts (100,000,000 ints) with work_mem below 4MB do >> better with unpatched than with your patch series, by about 5%. Not a

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Mon, Nov 30, 2015 at 9:10 PM, Vinayak wrote: > Thanks for the v7. > Please check the comment below. > -Table name in the vacuum progress > > + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s.%s", > schemaname,relname); Uh, I hope that line doesn't appear in the

Re: [HACKERS] psql ignores failure to open -o target file

On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote: > I just noticed that parse_psql_options() ignores the result of setQFout(), > meaning that if the argument of a -o command line option is bogus, we'll > ignore the switch entirely after printing an error report. For example >

Re: [HACKERS] broken tests

Pavel Stehule wrote: > Hi > > Today I have problem with regress tests on my laptop. Maybe this is because of the libxml version? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Noah Misch wrote: > On Tue, Dec 01, 2015 at 08:11:21PM -0300, Alvaro Herrera wrote: > > Finally, I ran perltidy on all the files, which strangely changed stuff > > that I didn't expect it to change. I wonder if this is related to the > > perltidy version. > > The last pgindent run (commit

Re: [HACKERS] Logical replication and multimaster

Thank you for reply. On 12/02/2015 08:30 PM, Robert Haas wrote: Logical decoding only begins decoding a transaction once the transaction is complete. So I would guess that the sequence of operations here is something like this - correct me if I'm wrong: 1. Do the transaction. 2. PREPARE. 3.

Re: [HACKERS] Another little thing about psql wrapped expanded output

On 12/01/2015 11:20 AM, Tom Lane wrote: > Notice that the dashed lines go all the way to the right margin of my > 80-column terminal window, even though the data requires no more than > 22 columns. While this doesn't look so awful as-is, when I'm working > in a very wide window it starts to look

Re: [HACKERS] Using quicksort for every external sort run

On Wed, Dec 2, 2015 at 10:03 AM, Robert Haas wrote: >> I'm not very concerned about a regression that is only seen when >> work_mem is set below the (very conservative) postgresql.conf default >> value of 4MB when sorting 100 million integers. > > Perhaps surprisingly, I

Re: [HACKERS] proposal: function parse_ident

Hi 2015-11-17 1:49 GMT+01:00 Marko Tiikkaja : > On 9/11/15 12:25 PM, Pavel Stehule wrote: > >> new update of parse_ident function patch >> > > Nice! I've certainly wanted something like this a number of times. > > Some comments about the v2 of the patch: > >- The patch doesn't

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Vinayak wrote: > In the vacuum progress, column table_name is showing first 30 characters of > table name. > postgres=# create table test_vacuum_progress_in_postgresql(c1 int,c2 text); > postgres=# select * from pg_stat_vacuum_progress ; > -[ RECORD 1 ]---+-- > pid

Re: [HACKERS] broken tests

2015-12-02 20:08 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > Hi > > > > Today I have problem with regress tests on my laptop. > > Maybe this is because of the libxml version? 100%, same issue is with 9.4.5 After downgrade to 2.9.2 (from 2.9.3) this issue was

Re: [HACKERS] snapshot too old, configured by time

On Wed, Dec 2, 2015 at 12:39 AM, Michael Paquier wrote: > On Mon, Nov 9, 2015 at 8:07 AM, Steve Singer wrote: >> In snapmgr.c >> >> >> + * XXX: If we can trust a read of an int64 value to be atomic, we can skip >> the >> + * spinlock here. >> + */

[HACKERS] broken tests

Hi Today I have problem with regress tests on my laptop. I did fresh clone of git Is it working elsewhere? Regards Pavel regression.diffs Description: Binary data regression.out Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

[HACKERS] Postgres_FDW optimizations

Hi all, I have a question about postgres_fdw optimizations/pushdown: I have the following code running on 9.5beta2 (same format as previous/related message for consistency) CREATE EXTENSION postgres_fdw; CREATE SERVER loop foreign data wrapper postgres_fdw OPTIONS (port '5432', dbname

Re: [HACKERS] Some questions about the array.

On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev wrote: > On Tuesday 01 December 2015 08:38:21 you wrote: >> it (zero >> based indexing support) doesn't meet the standard of necessity for >> adding to the core API and as stated it's much to magical. > > We do not touch

[HACKERS] proposal: add 'waiting for replication' to pg_stat_activity.state

Hello Hackers, I recently analyzed an incident where a major lag in synchronous replication blocked a number of synchronous backends. I found myself looking at backends that, according to pg_stat_activity, were neither waiting nor idle but yet they didn't finish their work. As it turns out, the

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Dec 1, 2015 at 7:00 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > This post summarizes a few weeks of research of ANALYZE statistics > > distribution on one of our bigger production databases with some > real-world > > data and

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/12/02 1:54, Robert Haas wrote: On Fri, Nov 27, 2015 at 1:25 AM, Kouhei Kaigai wrote: Sorry, I don't understand this. In my understanding, fdw_recheck_quals can be defined for a foreign join, regardless of the join type, Yes, "can be defined", but will not be

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/12/02 14:54, Kouhei Kaigai wrote: On 2015/12/02 1:41, Robert Haas wrote: On Thu, Nov 26, 2015 at 7:59 AM, Etsuro Fujita wrote: The attached patch adds: Path *fdw_outerpath field to ForeignPath node. FDW driver can set arbitrary but one path-node here.

Re: [HACKERS] psql: add \pset true/false

Michael Paquier wrote: > So, looking at this thread, here is the current status: > - Tom Lane: -1 > - Michael Paquier: -1 > - Peter Geoghegan: +1? > - Peter Eisentraut: +1 > - the author: surely +1. > Any other opinions? Feel free to correct this list if needed, and then > let's try to

Re: [HACKERS] Parallel Seq Scan

On Wed, Dec 2, 2015 at 12:06 PM, Michael Paquier wrote: > > On Sun, Nov 22, 2015 at 3:25 PM, Amit Kapila wrote: > > On Fri, Nov 20, 2015 at 11:34 PM, Robert Haas wrote: > >> > >> On Thu, Nov 19, 2015 at 11:59 PM, Amit

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

> On Thu, Nov 26, 2015 at 5:27 AM, Kouhei Kaigai wrote: > > I'm now implementing. The above design perfectly works on ForeignScan. > > On the other hands, I'd like to have deeper consideration for CustomScan. > > > > My recent patch adds LibraryName and SymbolName on

Re: [HACKERS] El Capitan Removes OpenSSL Headers

On Tue, Dec 1, 2015 at 9:55 PM, Bruce Momjian wrote: > On Tue, Dec 1, 2015 at 06:40:09PM -0300, Alvaro Herrera wrote: >> Bruce Momjian wrote: >> >> > Do we still have licensing issues if we ship Postgres and OpenSSL >> > together? >> >> See >>

[HACKERS] find_inheritance_children() and ALTER TABLE NO INHERIT

Currently find_inheritance_children() is smart enough to skip a child table that it finds has been dropped concurrently after it gets a lock on the same. It does so by looking up the child relid in syscache. It seems it should also check if the table is still in the list of children of the parent.

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

On 2015-12-02 08:52:20 +, Kouhei Kaigai wrote: > diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c > index 26264cb..c4bb76e 100644 > --- a/src/backend/nodes/copyfuncs.c > +++ b/src/backend/nodes/copyfuncs.c > @@ -635,8 +635,12 @@ _copyWorkTableScan(const WorkTableScan

Re: [HACKERS] parallel joins, and better parallel explain

On Tue, Dec 1, 2015 at 7:21 AM, Amit Kapila wrote: > Above and changes in add_path() makes planner not to select parallel path > for seq scan where earlier it was possible. I think you want to change the > costing of parallel plans based on rows selected instead of

Re: [HACKERS] proposal: function parse_ident

On 9/15/15 11:49 PM, Pavel Stehule wrote: 1. processing user input with little bit more comfort - the user doesn't need to separate schema and table This is especially useful if you're doing anything that needs to dynamically work with different objects. I'd say about 80% of the time I'm

Fwd: [HACKERS] Another little thing about psql wrapped expanded output

Sorry, I initially responded only to Josh. Forwarding to list: On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus wrote: > On 12/01/2015 11:20 AM, Tom Lane wrote: >> Notice that the dashed lines go all the way to the right margin of my >> 80-column terminal window, even though

Re: [HACKERS] broken tests

Pavel Stehule writes: > Today I have problem with regress tests on my laptop. Looks like https://bugzilla.redhat.com/show_bug.cgi?id=1286692 regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: Fwd: [HACKERS] Another little thing about psql wrapped expanded output

Jeff Janes writes: > On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus wrote: >> If you're fixing the dashed-line code, is there a way to say that we >> never have more than a reasonable number of dashes (ideally, the width >> of the terminal) no matter how

Re: [HACKERS] proposal: add 'waiting for replication' to pg_stat_activity.state

On 3 December 2015 at 04:22, Julian Schauder wrote: > I suggest adding a new state to pg_stat_activity.state for backends that > are > waiting for their synchronous commit to be flushed on the remote host. > > Excellent idea. Anything that improves management and

Re: [HACKERS] snapshot too old, configured by time

On Thu, Dec 3, 2015 at 5:48 AM, Kevin Grittner wrote: >> There has been a review but no replies for more than 1 month. Returned >> with feedback? > > I do intend to post another version of the patch to tweak the > calculations again, after I can get a patch in to expand the > testing capabilities

Re: [HACKERS] psql: add \pset true/false

On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote: > On 11/15/15 7:37 PM, Peter Eisentraut wrote: >> >> On 11/15/15 3:20 PM, Jim Nasby wrote: >>> >>> As to the argument about displaying a check or an X, why should that >>> capability only exist for boolean types? For

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

On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova wrote: > If we don't need c4 as an index scankey, we don't need any btree opclass on > it. > But we still want to have it in covering index for queries like > > SELECT c4 FROM tbl WHERE c1=1000; // uses the

Re: [HACKERS] Logical replication and multimaster

On 1 December 2015 at 00:20, Konstantin Knizhnik wrote: > We have implemented ACID multimaster based on logical replication and our DTM (distributed transaction manager) plugin. What are you using for an output plugin and for replay? I'd really like to collaborate

Re: [HACKERS] proposal: add 'waiting for replication' to pg_stat_activity.state

On 3 December 2015 at 04:22, Julian Schauder wrote: > > I suggest adding a new state to pg_stat_activity.state for backends that > are > waiting for their synchronous commit to be flushed on the remote host. > I chose 'waiting for synchronous replication' for now. >

Re: [HACKERS] psql: add \pset true/false

Hello, At Thu, 3 Dec 2015 09:24:35 +0900, Michael Paquier wrote in > On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote: > > On 11/15/15 7:37 PM, Peter Eisentraut wrote: > > I

Re: [HACKERS] Logical replication and multimaster

On 3 December 2015 at 04:18, Konstantin Knizhnik wrote: > The problem is that transactions are delivered to replica through single > channel: logical replication slot. > And while such transaction is waiting acknowledgement from arbiter, it is > blocking replication

Re: [HACKERS] find_inheritance_children() and ALTER TABLE NO INHERIT

Amit Langote writes: > Currently find_inheritance_children() is smart enough to skip a child > table that it finds has been dropped concurrently after it gets a lock on > the same. It does so by looking up the child relid in syscache. It seems > it should also check

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

Hi Ashutosh, On 2015/12/02 20:45, Ashutosh Bapat wrote: It's been a long time since last patch on this thread was posted. I have started to work on supporting join pushdown for postgres_fdw. Thanks for the work! Generating paths A join between two foreign relations is

Re: [HACKERS] Parallel Aggregate

On 3 December 2015 at 19:24, Haribabu Kommi wrote: > On Thu, Dec 3, 2015 at 4:18 PM, David Rowley > wrote: > > > > Hi, > > > > I just wanted to cross post here to mark that I've posted an updated > patch > > for combining aggregate states:

Re: Fwd: [HACKERS] Another little thing about psql wrapped expanded output

On Wed, Dec 02, 2015 at 10:36:56PM -0500, Josh Berkus wrote: > On 12/02/2015 05:24 PM, Tom Lane wrote: > > Don't think I agree. Suppose that you have a wider-than-screen table > > and you use a pager to scroll left and right in that. If we shorten the > > dashed lines, then once you scroll to

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, At Thu, 3 Dec 2015 14:18:50 +0900, Amit Langote wrote in <565fd0ba.5020...@lab.ntt.co.jp> > On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote: > > At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera > > wrote > >> > >> Actually, do we

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Thu, Dec 3, 2015 at 6:59 AM, Alvaro Herrera wrote: > I didn't push the changed for config_default you requested a few > messages upthread; it's not clear to me how setting it to undef affects > the whole thing. If setting it to undef makes the MSVC toolchain run > the tap tests in the default

Re: [HACKERS] Logical replication and multimaster

On Dec 3, 2015, at 4:09 AM, Craig Ringer wrote: > On 1 December 2015 at 00:20, Konstantin Knizhnik > wrote: > > > We have implemented ACID multimaster based on logical replication and our > > DTM (distributed transaction manager) plugin. > > What are you using for

Re: [HACKERS] proposal: add 'waiting for replication' to pg_stat_activity.state

On 3 December 2015 at 09:32, Peter Eisentraut wrote: > On 12/2/15 7:00 PM, Craig Ringer wrote: > > I notice that you don't set the 'waiting' flag. 'waiting' is presently > > documented as: > > > >True if this backend is currently waiting on a lock > > > > ... but I'm

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera wrote in <20151202184820.GL2763@alvherre.pgsql> > Vinayak wrote: > > > In the vacuum progress, column table_name is showing first 30 characters of > > table name. > > postgres=# create table

Re: [HACKERS] Parallel Aggregate

On 20 October 2015 at 23:23, David Rowley wrote: > On 13 October 2015 at 20:57, Haribabu Kommi > wrote: > >> On Tue, Oct 13, 2015 at 5:53 PM, David Rowley >> wrote: >> > On 13 October 2015 at 17:09, Haribabu

Re: [HACKERS] Postgres_FDW optimizations

On Thu, Dec 3, 2015 at 12:55 AM, cevian wrote: > Hi all, > > I have a question about postgres_fdw optimizations/pushdown: > > I have the following code running on 9.5beta2 (same format as > previous/related message for consistency) > CREATE EXTENSION postgres_fdw; > CREATE

Re: [HACKERS] Logical replication and multimaster

On 3 December 2015 at 14:54, konstantin knizhnik wrote: > > I'd really like to collaborate using pglogical_output if at all possible. > Petr's working really hard to get the pglogical downstrem out too, with me > helping where I can. > > And where I can get

Re: Fwd: [HACKERS] Another little thing about psql wrapped expanded output

On 12/02/2015 05:24 PM, Tom Lane wrote: > Don't think I agree. Suppose that you have a wider-than-screen table > and you use a pager to scroll left and right in that. If we shorten the > dashed lines, then once you scroll to the right of wherever they stop, > you lose that visual cue separating

Re: [HACKERS] psql: add \pset true/false

On Thu, Dec 3, 2015 at 2:53 PM, Kyotaro HORIGUCHI wrote: > The attached patch adds a function to load output filter DLL. > The second file is an example filter module. The following > commandline with the file can create a test filter module. I > suppose preload

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

On Wed, Dec 2, 2015 at 8:59 PM, Robert Haas wrote: > > > I think the approach this patch takes is pretty darned strange, and > almost certainly not what we want. What you're doing here is putting > every outstanding CLOG-update request into a linked list, and then the >

Re: [HACKERS] psql: add \pset true/false

Hello, it's disappointing. At Thu, 3 Dec 2015 15:48:50 +0900, Michael Paquier wrote in > On Thu, Dec 3, 2015 at 2:53 PM, Kyotaro HORIGUCHI > wrote: > > The attached

Re: [HACKERS] Parallel Aggregate

On Thu, Dec 3, 2015 at 4:18 PM, David Rowley wrote: > > Hi, > > I just wanted to cross post here to mark that I've posted an updated patch > for combining aggregate states: >

Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code

On Thu, Dec 3, 2015 at 12:50 PM, Tom Lane wrote: > Michael Paquier writes: >> On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote: >>> BTW, not the fault of this patch in particular, but this example points >>> up the complaint I've

Re: [HACKERS] broken tests

2015-12-02 23:00 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > Today I have problem with regress tests on my laptop. > > Looks like > > https://bugzilla.redhat.com/show_bug.cgi?id=1286692 sure Pavel > > > regards, tom

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, sorry for the cloberred CC list. # I restored it manually from upthread.. At Wed, 2 Dec 2015 13:42:01 -0500, Robert Haas wrote in > On Tue, Dec 1, 2015 at 2:25 AM, Kyotaro HORIGUCHI >

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hi, On 2015/12/03 15:27, Kyotaro HORIGUCHI wrote: > At Thu, 3 Dec 2015 14:18:50 +0900, Amit Langote wrote >> On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote: >>> >>> Apart from the representation of the relation, OID would be >>> better as a field in beentry. >> >> I wonder if the field should be a

Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code

On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote: > BTW, not the fault of this patch in particular, but this example points > up the complaint I've had right along about how opaque TAP test failures > are. How did you dig down to see that error message? Well, it showed up on

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Wed, Nov 25, 2015 at 7:18 PM, Pavel Stehule wrote: > > > 2015-11-25 8:05 GMT+01:00 Haribabu Kommi : >> >> >> Thanks. Here I attached the poc patch that returns authentication method >> of the >> first matched hba entry in pg_hba.conf with the

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

2015-12-03 5:00 GMT+01:00 Haribabu Kommi : > On Wed, Nov 25, 2015 at 7:18 PM, Pavel Stehule > wrote: > > > > > > 2015-11-25 8:05 GMT+01:00 Haribabu Kommi : > >> > >> > >> Thanks. Here I attached the poc patch that

Re: [HACKERS] Combining Aggregates

On 27 July 2015 at 04:58, Heikki Linnakangas wrote: > > This patch seems sane to me, as far as it goes. However, there's no > planner or executor code to use the aggregate combining for anything. I'm > not a big fan of dead code, I'd really like to see something to use this. >

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote: > At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera > wrote >> >> Actually, do we really need to have the table name as a string at all >> here? Why not just report the table OID? Surely whoever wants to check >> the

Re: [HACKERS] find_inheritance_children() and ALTER TABLE NO INHERIT

On 2015/12/03 13:09, Tom Lane wrote: > Amit Langote writes: >> Currently find_inheritance_children() is smart enough to skip a child >> table that it finds has been dropped concurrently after it gets a lock on >> the same. It does so by looking up the child relid in

[HACKERS] W-TinyLfu for cache eviction

I've recently noticed W-TinyLfu cache admission policy (see [1]) being used for caffeine "high performance caching library for Java 8". It demonstrates high cache hit ratios (see [2]) and enables to build high-throughput caches (see caffeine in [3]) Authors explicitly allow implementations of the

Re: [HACKERS] Logical replication and multimaster

On Dec 3, 2015, at 4:18 AM, Craig Ringer wrote: > Excellent. > > It should be possible to make that a separate extension. You can use C > functions from other extensions by exposing a single pg_proc function with > 'internal' return type that populates a struct of function pointers for the >

Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code

Michael Paquier writes: > On Thu, Dec 3, 2015 at 8:38 AM, Tom Lane wrote: >> Test Summary Report >> --- >> t/001_initdb.pl (Wstat: 6400 Tests: 8 Failed: 0) >> Non-zero exit status: 25 >> Parse errors: Bad plan. You planned 14 tests but ran 8. >>

Re: [HACKERS] [COMMITTERS] pgsql: Refactor Perl test code

Michael Paquier writes: > On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote: >> BTW, not the fault of this patch in particular, but this example points >> up the complaint I've had right along about how opaque TAP test failures >> are. How did you

Re: [HACKERS] psql: add \pset true/false

Hello, the attched is an example implement of output filter dynamic loading feature of psql. At Thu, 3 Dec 2015 10:41:11 +0900, Michael Paquier wrote in > > How about plugins on psql side? Calling

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule wrote: > here is complete patch - regress tests for all supported Python branches I had a look at what changed in v10 since my last reviewed version and indeed most of it is straightforward: renames from SPIError to Error.

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2015-12-03 7:04 GMT+01:00 Catalin Iacob : > On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule > wrote: > > here is complete patch - regress tests for all supported Python branches > > I had a look at what changed in v10 since my last reviewed version

Re: [HACKERS] Postgres_FDW optimizations

On 02/12/2015 20:25, cevian wrote: > Hi all, > Hello, > I have a question about postgres_fdw optimizations/pushdown: > > I have the following code running on 9.5beta2 (same format as > previous/related message for consistency) > CREATE EXTENSION postgres_fdw; > CREATE SERVER loop foreign data

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On Mon, Nov 30, 2015 at 11:00 PM, David Rowley wrote: > There are in fact also two queries in TPC-H (Q10 and Q18) which are written > to include all of the non-aggregated column in the GROUP BY list. During a > recent test I witnessed a 50% gain in performance in Q10

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

Hi, I can't really do huge review considering I wrote half of the code, but I have couple of things I noticed. First, I wonder if it would be useful to mention somewhere, even if it's only here in the mailing list how can the protocol be extended in non-breaking way in future for

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/12/02 1:53, Robert Haas wrote: On Fri, Nov 27, 2015 at 1:33 AM, Etsuro Fujita wrote: Plan *plan = >scan.plan; @@ -3755,7 +3763,7 @@ make_foreignscan(List *qptlist, /* cost will be filled in by create_foreignscan_plan */

Re: [HACKERS] Remaining 9.5 open items

On 2015-12-02 12:25:37 +0100, Joel Jacobson wrote: > On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote: > > The significant changes are in 9.5. > > Will multixact truncations be WAL logged in 9.5? Yes. C.f. the release notes: * Rework truncation of the multixact commit

Re: [HACKERS] Getting sorted data from foreign server for merge join

Thanks Ashutosh. Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch looks good to me. On Fri, Nov 27, 2015 at 3:02 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > Thanks Rushabh for your review and comments. > > On Thu, Nov 26, 2015 at 5:39 PM, Rushabh Lathia

Re: [HACKERS] Remaining 9.5 open items

On Mon, Nov 30, 2015 at 8:43 PM, Tom Lane wrote: > * Finish multixact truncation rework > > We're not seriously going to push something this large into 9.5 at this > point, are we? I don't know all the details here, so my apologies if any of this is

Re: [HACKERS] Remaining 9.5 open items

On 2015-12-02 12:14:42 +0100, Joel Jacobson wrote: > On Mon, Nov 30, 2015 at 8:43 PM, Tom Lane wrote: > > * Finish multixact truncation rework > > > > We're not seriously going to push something this large into 9.5 at this > > point, are we? > > I don't know all the details

Re: [HACKERS] Remaining 9.5 open items

On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote: > The significant changes are in 9.5. Will multixact truncations be WAL logged in 9.5? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Remaining 9.5 open items

On Wed, Dec 2, 2015 at 12:36 PM, Andres Freund wrote: > > On 2015-12-02 12:25:37 +0100, Joel Jacobson wrote: > > On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote: > > > The significant changes are in 9.5. > > > > Will multixact truncations be WAL

  1   2   >