Re: [HACKERS] [POC] FETCH limited by bytes.

Hello, > > > @@ -915,6 +933,23 @@ postgresBeginForeignScan(ForeignScanState *node, > > int eflags) ... > > > + def = get_option(table->options, "fetch_size"); > > > I don't think it's a good idea to make such checks at runtime - and > > either way it's somethign that should be reported back u

Re: [HACKERS] BRIN INDEX value

> On 9/4/2015 2:04 PM, Tatsuo Ishii wrote: >>> One thing I imagine we could do is to change the signature of >>> summrize_range() to also include heapNumBlks which its (only) caller >>> brinsummarize() already computes. It will look like: >>> >>> static void summarize_range(IndexInfo *indexInfo, Br

Re: [HACKERS] pageinspect patch, for showing tuple data

On Wed, Sep 2, 2015 at 6:58 PM, Nikolay Shaplov wrote: > В письме от 3 августа 2015 15:35:23 пользователь Alvaro Herrera написал: > > Nikolay Shaplov wrote: > > > This patch adds several new functions, available from SQL queries. All > > > these functions are based on heap_page_items, but accept

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Sep 4, 2015 at 10:35 AM, Fujii Masao wrote: > On Fri, Sep 4, 2015 at 2:23 AM, Masahiko Sawada wrote: >> On Thu, Aug 27, 2015 at 1:54 AM, Masahiko Sawada >> wrote: >>> On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera >>> wrote: Jim Nasby wrote: > I think things like pagein

Re: [HACKERS] Declarative partitioning

Sorry about the long delay in replying, to this message or the others posted in the last few days. I should have notified in advance of my vacation with rather limited Internet access. On 2015-08-26 PM 11:00, Simon Riggs wrote: > On 18 August 2015 at 11:30, Amit Langote > >> 3. Multi-level part

Re: [HACKERS] Allow replication roles to use file access functions

On Thu, Sep 3, 2015 at 9:53 PM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Thu, Sep 3, 2015 at 11:20 AM, Stephen Frost wrote: >> >> Not only, +clog, configuration files, etc. >> > >> > Configuration files? Perhaps you could elaborate? >> >> Sure. Sorry for b

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

Hello, Thank you for registering this to CF-Sep. I missed the regtration window.. It ended earlier than usual.. Most troubles have gone and I'll be back next week. > The work to be left is eliminating double-format of Command > struct. This is done as the additional fourth patch, not merged into

Re: [HACKERS] BRIN INDEX value

On 9/4/2015 2:04 PM, Tatsuo Ishii wrote: >> One thing I imagine we could do is to change the signature of >> summrize_range() to also include heapNumBlks which its (only) caller >> brinsummarize() already computes. It will look like: >> >> static void summarize_range(IndexInfo *indexInfo, BrinBuild

Re: [HACKERS] BRIN INDEX value

> One thing I imagine we could do is to change the signature of > summrize_range() to also include heapNumBlks which its (only) caller > brinsummarize() already computes. It will look like: > > static void summarize_range(IndexInfo *indexInfo, BrinBuildState *state, >

Re: [HACKERS] BRIN INDEX value

On 9/4/2015 1:33 PM, Tatsuo Ishii wrote: >> Ah, it did cross my mind to the fix it in brin.c but was not sure. I did >> it that way in the attached patch. > > Amit, > > I have looked into your patch and am a little bit worried because it > calls RelationGetNumberOfBlocks() which is an expensive f

Re: [HACKERS] BRIN INDEX value

> On 9/4/2015 8:28 AM, Tatsuo Ishii wrote: >>> >>> Attached hack fixes the symptom but perhaps not the correct fix for this. >> >> Why can't we fix summarize_range() in brin.c: >> >> IndexBuildHeapRangeScan(heapRel, state->bs_irel, indexInfo, false, true, >>

Re: [HACKERS] proposal: function parse_ident

2015-09-03 13:11 GMT+02:00 Andres Freund : > On 2015-08-23 17:46:36 +0200, Pavel Stehule wrote: > > here is the patch > > > > It is really trivial - all heavy work was done done before. > > This seems to entirely disregard the comments in > http://archives.postgresql.org/message-id/29030.144003015

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-04 5:50 GMT+02:00 Shulgin, Oleksandr : > On Sep 3, 2015 10:14 PM, "Pavel Stehule" wrote: > >>> > >>> Please find attached a v3. > >>> > >>> It uses a shared memory queue and also has the ability to capture > plans nested deeply in the call stack. Not sure about using the executor > hook,

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On Sep 3, 2015 7:30 PM, "Robert Haas" wrote: > > All of these objections seem pretty thin to me. I'd accept any of > them as a reason for preferring one alternative over another, but I > don't accept that the presence of a few problems of this magnitude > means we should give up on the feature.

Re: [HACKERS] BRIN INDEX value

On 9/4/2015 12:01 PM, Alvaro Herrera wrote: > Amit Langote wrote: >> On 9/4/2015 9:22 AM, Tatsuo Ishii wrote: >>> >>> 3) I wonder if other index type is suffered by this type of bug. >>> >> >> About 3, it seems unlikely. Both the IndexBuildHeapRangeScan() and >> heap_setscanlimits() were introduced

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Fri, Sep 4, 2015 at 12:04 PM, Tom Lane wrote: > I wrote: > > Hmm. I am not feeling especially comfortable about this: it's not clear > > that there's anything preventing a suspended portal from containing a > > dangerous reference. However, a quick trial did not show that it was > > possible

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

Robert Haas writes: > On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane wrote: >> Offhand I think that the >> most likely way to build that text will be to examine the query's jointree >> to see where c,d,e appear in it. But in any case, that's a separate issue >> and I fail to see how plopping the join

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Sep 3, 2015 10:14 PM, "Pavel Stehule" wrote: >>> >>> Please find attached a v3. >>> >>> It uses a shared memory queue and also has the ability to capture plans nested deeply in the call stack. Not sure about using the executor hook, since this is not an extension... >>> >>> The LWLock is used

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

I wrote: > Hmm. I am not feeling especially comfortable about this: it's not clear > that there's anything preventing a suspended portal from containing a > dangerous reference. However, a quick trial did not show that it was > possible to break it --- in the cases I tried, we detected that a cac

Re: [HACKERS] BRIN INDEX value

Amit Langote wrote: > On 9/4/2015 9:22 AM, Tatsuo Ishii wrote: > >> > >> In this case, scan->rs_startblock is 384 set by IndexBuildHeapRangeScan() > >> using heap_setscanlimits(). One can imagine how the above heap finish > >> criteria might not work as expected. > > > > What scares me is: > > >

Re: [HACKERS] Freeze avoidance of very large table.

Bruce Momjian wrote: > On Thu, Sep 3, 2015 at 11:37:09PM +0200, Petr Jelinek wrote: > > >I don't understand. I'm just proposing that the source code for the > > >extension to live in src/extensions/, and have the shared library > > >installed by toplevel make install; I'm not suggesting that the

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

Michael Paquier writes: > On Fri, Sep 4, 2015 at 9:57 AM, Tom Lane wrote: >> On reflection I think that the tracking of activeSubid in my patch is >> probably overkill if we're attacking it this way. We can just have >> AtSubAbort_Portals fail any ACTIVE portal regardless of subxact level, >> wh

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Sep 4, 2015 at 2:23 AM, Masahiko Sawada wrote: > On Thu, Aug 27, 2015 at 1:54 AM, Masahiko Sawada > wrote: >> On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera >> wrote: >>> Jim Nasby wrote: >>> I think things like pageinspect are very different; I really can't see any use for

Re: [HACKERS] BRIN INDEX value

On 9/4/2015 8:28 AM, Tatsuo Ishii wrote: >> >> Attached hack fixes the symptom but perhaps not the correct fix for this. > > Why can't we fix summarize_range() in brin.c: > > IndexBuildHeapRangeScan(heapRel, state->bs_irel, indexInfo, false, true, >

Re: [HACKERS] Reduce ProcArrayLock contention

On Thu, Sep 3, 2015 at 11:07 PM, Robert Haas wrote: > On Tue, Aug 25, 2015 at 7:51 AM, Amit Kapila > wrote: > > [ new patch ] > > Andres pinged me about this patch today. It contained a couple of > very strange whitespace anomalies, but otherwise looked OK to me, so I > committed it with after

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Fri, Sep 4, 2015 at 9:57 AM, Tom Lane wrote: > On reflection I think that the tracking of activeSubid in my patch is > probably overkill if we're attacking it this way. We can just have > AtSubAbort_Portals fail any ACTIVE portal regardless of subxact level, > which is pretty analogous to wha

Re: [HACKERS] BRIN INDEX value

On 9/4/2015 9:22 AM, Tatsuo Ishii wrote: >> >> In this case, scan->rs_startblock is 384 set by IndexBuildHeapRangeScan() >> using heap_setscanlimits(). One can imagine how the above heap finish >> criteria might not work as expected. > > What scares me is: > > 1) the bug will not be found unless

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

Michael Paquier writes: > On Fri, Sep 4, 2015 at 6:51 AM, Tom Lane wrote: >> Ideas? > Yes. This diff on top of your patch: > @@ -922,8 +922,7 @@ AtSubAbort_Portals(SubTransactionId mySubid, > * must be forced into FAILED state, for > the same reasons >

Re: [HACKERS] Is this a bug?

On Fri, Sep 4, 2015 at 3:52 AM, Alvaro Herrera wrote: > Robert Haas wrote: > > On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera > > wrote: > > > Fabrízio de Royes Mello wrote: > > > > > >> Why this patch was reverted one day after applied [1]? I didn't see > any > > >> discussion around it. > > >

Re: [HACKERS] Freeze avoidance of very large table.

On 04/09/15 12:11, Bruce Momjian wrote: On Thu, Sep 3, 2015 at 11:37:09PM +0200, Petr Jelinek wrote: I don't understand. I'm just proposing that the source code for the extension to live in src/extensions/, and have the shared library installed by toplevel make install; I'm not suggesting that

Re: [HACKERS] Memory prefetching while sequentially fetching from SortTuple array, tuplestore

On 3 September 2015 at 16:50, Peter Geoghegan wrote: > On Wed, Sep 2, 2015 at 9:43 PM, David Rowley > wrote: > > Peter, would you be able to share the test case which you saw the speedup > > on. So far I've been unable to see much of an improvement. > > The case I tested was an internal sort CRE

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Fri, Sep 4, 2015 at 6:51 AM, Tom Lane wrote: > I experimented with the attached patch. It seems to work to stop the > crash Michael exhibited (I've not tried to duplicate Jim's original > example, though). However, it also causes a regression test failure, > because transactions.sql does thi

Re: [HACKERS] BRIN INDEX value

> The summarization during VACUUM invokes IndexBuildHeapRangeScan() which is > passed scanStartBlock and scanNumBlocks. If scanStartBlock + scanNumBlocks >> heapTotalBlocks, further down the line, heapgettup() may start returning > tuples from the beginning given the following code in it: > > pa

Re: [HACKERS] Freeze avoidance of very large table.

On 09/03/2015 05:11 PM, Bruce Momjian wrote: > On Thu, Sep 3, 2015 at 11:37:09PM +0200, Petr Jelinek wrote: >>> I don't understand. I'm just proposing that the source code for the >>> extension to live in src/extensions/, and have the shared library >>> installed by toplevel make install; I'm not

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Sep 3, 2015 at 11:37:09PM +0200, Petr Jelinek wrote: > >I don't understand. I'm just proposing that the source code for the > >extension to live in src/extensions/, and have the shared library > >installed by toplevel make install; I'm not suggesting that the > >extension is installed aut

Re: [HACKERS] [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace

On Thu, Sep 3, 2015 at 01:03:30PM +0200, Andres Freund wrote: > Hi Bruce, > > Are you actually waiting for review in this thread? Or is the CF entry > more of a reminder? Oh, I have a commit-fest entry for this? Well, whoever did that was doing the right thing so things are not forgotten. Yeah

Re: [HACKERS] BRIN INDEX value

> The summarization during VACUUM invokes IndexBuildHeapRangeScan() which is > passed scanStartBlock and scanNumBlocks. If scanStartBlock + scanNumBlocks >> heapTotalBlocks, further down the line, heapgettup() may start returning > tuples from the beginning given the following code in it: > > pa

[HACKERS] Small patch to fix an O(N^2) problem in foreign keys

Attached is a small patch and a script to reproduce the issue. The problem is a cache introduced in commit 45ba4247 that improves foreign key lookups during bulk updates when the FK value does not change. When restoring a schema dump from a database with many (say 100,000) foreign keys, this c

Re: [HACKERS] [POC] FETCH limited by bytes.

On Wed, Sep 2, 2015 at 9:08 AM, Andres Freund wrote: > On 2015-02-27 13:50:22 -0500, Corey Huinker wrote: > > +static DefElem* > > +get_option(List *options, char *optname) > > +{ > > + ListCell *lc; > > + > > + foreach(lc, options) > > + { > > + DefElem *def = (DefElem *)

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

I wrote: > I'm inclined to think that the only real fix for this type of problem > is that at subtransaction abort, we have to prevent further execution > of any Portals that have executed at all within the subxact (ie force > them into PORTAL_FAILED state and clean out their resources, see > MarkP

Re: [HACKERS] Freeze avoidance of very large table.

On 2015-09-03 20:26, Alvaro Herrera wrote: Robert Haas wrote: On Thu, Aug 20, 2015 at 10:46 AM, Alvaro Herrera wrote: I don't think that necessarily means it must continue to be in contrib. Quite the contrary, I think it is a tool critical enough that it should not be relegated to be a secon

Re: [HACKERS] strange test in psql:startup.c

On Wed, Aug 26, 2015 at 8:18 AM, Pavel Stehule wrote: > if (options.single_txn && options.action != ACT_FILE && > options.action == ACT_NOTHING) > { > fprintf(stderr, _("%s: -1 can only be used in > non-interactive mode\n"), pset.progname); > exit(EX

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

Tom Lane wrote: > Andrew Dunstan writes: > > There is no equivalent of execl, nor a cmd.exe exquivalent of the > > shell's exec. But surely the equivalent of the fork/execl you're doing > > here would be a simple CreateProcess(). I don't see why you need a shell > > in the middle on Windows at

Re: [HACKERS] Autonomous Transaction is back

On Sat, Aug 22, 2015 at 2:23 AM, Noah Misch wrote: >> > Can you get away with only looking at tuples though? For example, >> > what about advisory locks? Table locks? >> >> Well, that's an interesting question. Can we get away with regarding >> those things as non-conflicting, as between the pa

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-03 22:06 GMT+02:00 Pavel Stehule : > Hi > > > > > 2015-09-03 18:30 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> On Wed, Sep 2, 2015 at 3:07 PM, Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de> wrote: >> >>> On Wed, Sep 2, 2015 at 3:04 PM, Pavel Stehule >>> wro

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

Andrew Dunstan writes: > There is no equivalent of execl, nor a cmd.exe exquivalent of the > shell's exec. But surely the equivalent of the fork/execl you're doing > here would be a simple CreateProcess(). I don't see why you need a shell > in the middle on Windows at all. The problem is to ge

Re: [HACKERS] On-demand running query plans using auto_explain and signals

Hi 2015-09-03 18:30 GMT+02:00 Shulgin, Oleksandr : > On Wed, Sep 2, 2015 at 3:07 PM, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > >> On Wed, Sep 2, 2015 at 3:04 PM, Pavel Stehule >> wrote: >>> >>> Well, maybe I'm missing something, but sh_mq_create() will just over

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

On 09/03/2015 03:31 PM, Tom Lane wrote: I wrote: Andres Freund writes: I'don't like adding a couple seconds of test runtime for the benefit of very slow platforms. Me either. This is the first time I've seen an indication that the start_postmaster change mentioned in the comment is actuall

Re: [HACKERS] PG_CATCH used without PG_RETHROW

Greg Stark writes: > My understanding is that PG_TRY/PG_CATCH doesn't save enough state to > avoid rethrowing errors and if you want to actually continue the > transaction you must use a subtransaction. As a result I was under the > impression it was mandatory to PG_RETHROW as a result. > If that

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

I wrote: > Andres Freund writes: >> I'don't like adding a couple seconds of test runtime for the benefit of >> very slow platforms. > Me either. This is the first time I've seen an indication that the > start_postmaster change mentioned in the comment is actually important > for production use,

[HACKERS] PG_CATCH used without PG_RETHROW

My understanding is that PG_TRY/PG_CATCH doesn't save enough state to avoid rethrowing errors and if you want to actually continue the transaction you must use a subtransaction. As a result I was under the impression it was mandatory to PG_RETHROW as a result. If that's the case then I think I jus

Re: [HACKERS] Is this a bug?

Robert Haas wrote: > On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera > wrote: > > Fabrízio de Royes Mello wrote: > > > >> Why this patch was reverted one day after applied [1]? I didn't see any > >> discussion around it. > > > > Contributors whose patches are getting committed should really subscr

Re: [HACKERS] [PROPOSAL] Inputs on forcing VACUUM VERBOSE to write timestamp

On Thu, Sep 3, 2015 at 9:18 AM, Andres Freund wrote: > Hi, > > On 2015-09-03 21:45:52 +0530, dinesh kumar wrote: > > Forcing VACUUM VERBOSE to write timestamp, for each "INFO" entry. This > was > > raised already in this > > < > http://www.postgresql.org/message-id/20031110162349.65542.qm...@web2

Re: [HACKERS] Is this a bug?

On Wed, Aug 26, 2015 at 3:31 PM, Alvaro Herrera wrote: > Fabrízio de Royes Mello wrote: > >> Why this patch was reverted one day after applied [1]? I didn't see any >> discussion around it. > > Contributors whose patches are getting committed should really subscribe > to pgsql-committers. I would

Re: [HACKERS] September 2015 Commitfest

On 09/03/2015 03:06 PM, Andres Freund wrote: Hi, Two days ago the September Commitfest started. I'm going to be your host^W commitfest manager this time round. To start off I went through all entries and tried to make sure their state is accurate. Right now we have: Needs review: 47

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Sep 3, 2015 at 2:26 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Thu, Aug 20, 2015 at 10:46 AM, Alvaro Herrera >> wrote: > >> > I don't think that necessarily means it must continue to be in contrib. >> > Quite the contrary, I think it is a tool critical enough that it should >> >

Re: [HACKERS] Freeze avoidance of very large table.

Robert Haas wrote: > On Thu, Aug 20, 2015 at 10:46 AM, Alvaro Herrera > wrote: > > I don't think that necessarily means it must continue to be in contrib. > > Quite the contrary, I think it is a tool critical enough that it should > > not be relegated to be a second-class citizen as it is now (le

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

Michael Paquier writes: > Finally I have been able to crack down the problem, and it can be > reproduced with the following test case for example: Hm. It looks like the problem is that we're executing the function within the Portal created for cursor "h", and that Portal is older than the subtra

Re: [HACKERS] FSM versus GIN pending list bloat

On Thu, Sep 3, 2015 at 3:57 AM, Robert Haas wrote: > On Mon, Aug 10, 2015 at 1:16 PM, Jeff Janes wrote: >> I have a simple test case that inserts an array of 101 md5 digests into each >> row. With 10_000 of these rows inserted into an already indexed table, I >> get 40MB for the table and 80MB f

Re: [HACKERS] Potential GIN vacuum bug

On Mon, Aug 31, 2015 at 12:10 AM, Jeff Janes wrote: > On Sun, Aug 30, 2015 at 3:57 PM, Tom Lane wrote: > >> Jeff Janes writes: >> > On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane wrote: >> > > But we would still have to deal with the >> > fact that unconditional acquire attempt by the backends wil

Re: [HACKERS] Reduce ProcArrayLock contention

On Tue, Aug 25, 2015 at 7:51 AM, Amit Kapila wrote: > [ new patch ] Andres pinged me about this patch today. It contained a couple of very strange whitespace anomalies, but otherwise looked OK to me, so I committed it with after fixing those issues and tweaking the comments a bit. Hopefully we

Re: [HACKERS] pgbench stats per script & other stuff

I've left out: - removing -N/-S upward compatibility shorthands but I will not cry if they are removed I see no particular merit to breaking backward compatibility here. I agree, but I would not fight for this. I think there is a good argument *NOT* to add more if new builtin scripts ar

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Aug 20, 2015 at 10:46 AM, Alvaro Herrera wrote: > Jim Nasby wrote: >> I think things like pageinspect are very different; I really can't see any >> use for those beyond debugging (and debugging by an expert at that). > > I don't think that necessarily means it must continue to be in contri

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On Thu, Sep 3, 2015 at 12:57 PM, Shulgin, Oleksandr wrote: > On Thu, Sep 3, 2015 at 6:02 PM, Robert Haas wrote: >> Maybe someday we should have all that, but I think for right now >> that's complicating things unnecessarily. I think the best proposal >> so far is to allow the host=X option to be

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Aug 27, 2015 at 1:54 AM, Masahiko Sawada wrote: > On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera > wrote: >> Jim Nasby wrote: >> >>> I think things like pageinspect are very different; I really can't see any >>> use for those beyond debugging (and debugging by an expert at that). >> >>

Re: [HACKERS] Horizontal scalability/sharding

On 09/03/2015 03:57 AM, Bruce Momjian wrote: >> > >> > Yes, the logical replication has similar syncrep properties as the >> > binary one (feedback works same way). Oh? What does UDR/BDR currently support for sync? > Yes, I assumed that. Logical replication uses WAL, so if you are > synchronou

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Shulgin, Oleksandr wrote: > > > > Alternatively, change the rules for parsing the existing host=X > > > parameter so that we split it on some separator that isn't a valid > > > hostname character, and then strip off an optional :port syntax from

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On 3 September 2015 at 12:57, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote > > On Thu, Sep 3, 2015 at 6:02 PM, Robert Haas wrote: >> >> >> Maybe someday we should have all that, but I think for right now >> that's complicating things unnecessarily. I think the best proposal >> so far

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

* Robert Haas (robertmh...@gmail.com) wrote: > Alternatively, change the rules for parsing the existing host=X > parameter so that we split it on some separator that isn't a valid > hostname character, and then strip off an optional :port syntax from > each entry; that value, if present, overrides

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

Shulgin, Oleksandr wrote: > > Alternatively, change the rules for parsing the existing host=X > > parameter so that we split it on some separator that isn't a valid > > hostname character, and then strip off an optional :port syntax from > > each entry; that value, if present, overrides port=X for

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On Thu, Sep 3, 2015 at 6:02 PM, Robert Haas wrote: > > Maybe someday we should have all that, but I think for right now > that's complicating things unnecessarily. I think the best proposal > so far is to allow the host=X option to be repeated multiple times. > If you repeat the host=X option N

Re: [HACKERS] [PROPOSAL] Inputs on forcing VACUUM VERBOSE to write timestamp

On Thu, Sep 3, 2015 at 9:48 PM, Andres Freund wrote: > Hi, > > On 2015-09-03 21:45:52 +0530, dinesh kumar wrote: > > Forcing VACUUM VERBOSE to write timestamp, for each "INFO" entry. This > was > > raised already in this > > < > http://www.postgresql.org/message-id/20031110162349.65542.qm...@web2

Re: [HACKERS] Performance improvement for joins where outer side is unique

On Tue, Aug 25, 2015 at 1:25 AM, David Rowley wrote: > If that's the case then why do we not enable verbose for all of the non-text > outputs? > It seems strange to start making exceptions on a case-by-case basis. +1. FORMAT and VERBOSE are separate options, and each one should control what the

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Wed, Sep 2, 2015 at 3:07 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Wed, Sep 2, 2015 at 3:04 PM, Pavel Stehule > wrote: >> >> >>> Well, maybe I'm missing something, but sh_mq_create() will just >>> overwrite the contents of the struct, so it doesn't care about >>> sende

Re: [HACKERS] [PROPOSAL] Inputs on forcing VACUUM VERBOSE to write timestamp

Hi, On 2015-09-03 21:45:52 +0530, dinesh kumar wrote: > Forcing VACUUM VERBOSE to write timestamp, for each "INFO" entry. This was > raised already in this > > thread, and wanted to discuss it again. I didn't

[HACKERS] [PROPOSAL] Inputs on forcing VACUUM VERBOSE to write timestamp

Hi All, Greetings for the day. Would like to know your inputs/suggestions on below proposal. Kindly let me know, if it's already taken care. *Proposal* Forcing VACUUM VERBOSE to write timestamp, for each "INFO" entry. This was raised already in this

Re: [HACKERS] Horizontal scalability/sharding

On 2015-09-03 12:10:08 -0400, Robert Haas wrote: > On Thu, Sep 3, 2015 at 6:57 AM, Bruce Momjian wrote: > > Yes, I assumed that. Logical replication uses WAL, so if you are > > synchronous with WAL, logical replication is synchronous too. However, > > of course, it is synchronous in being durabl

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

Robert Haas wrote: > Alternatively, change the rules for parsing the existing host=X > parameter so that we split it on some separator that isn't a valid > hostname character, and then strip off an optional :port syntax from > each entry; that value, if present, overrides port=X for that entry. :

Re: [HACKERS] Horizontal scalability/sharding

On Thu, Sep 3, 2015 at 6:57 AM, Bruce Momjian wrote: > Yes, I assumed that. Logical replication uses WAL, so if you are > synchronous with WAL, logical replication is synchronous too. However, > of course, it is synchronous in being durable, not synchronous in terms > of applying the WAL. This

Re: [HACKERS] pgbench stats per script & other stuff

On Thu, Sep 3, 2015 at 3:26 AM, Fabien COELHO wrote: > I've left out: > - removing -N/-S upward compatibility shorthands >but I will not cry if they are removed I see no particular merit to breaking backward compatibility here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The E

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On Thu, Sep 3, 2015 at 11:42 AM, Stephen Frost wrote: >> > I believe that having a floating IP for the master is much more practical >> > approach and it doesn't require any patch to libpq or modification of the >> > client connection settings. >> >> I think that's a great approach if all the mach

Re: [HACKERS] Too many duplicated condition query return wrong value

On Thu, Sep 3, 2015 at 5:14 AM, Atsushi Yoshida wrote: > Hi. > > I cought a strange result. > I execute such query. > > > SELECT "attend"."lid", "attend"."status" FROM "attend" WHERE > "attend"."sid" = 325 AND "attend"."lid" IN ('ABF0010', 'ABF0010', > 'ABF0010', 'ABF0010', 'ABF0010', 'ABF0010',

Re: [HACKERS] Can pg_dump make use of CURRENT/SESSION_USER

On Thu, Sep 3, 2015 at 8:16 AM, Andres Freund wrote: > > On 2015-08-25 22:01:51 +0900, Michael Paquier wrote: > > Seeing no activity in the last couple of months for this patch that > > had reviews, it is now marked as returned with feedback. > > Fabrizio, you after the above moved the patch to ne

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Sep 3, 2015 at 4:00 AM, Shulgin, Oleksandr > wrote: > > I believe that having a floating IP for the master is much more practical > > approach and it doesn't require any patch to libpq or modification of the > > client connection settings. >

Re: [HACKERS] [PROPOSAL] Effective storage of duplicates in B-tree index.

01.09.2015 21:23, Peter Geoghegan: On Mon, Aug 31, 2015 at 12:41 AM, Anastasia Lubennikova wrote: Now new B-tree index tuple must be inserted for each table row that we index. It can possibly cause page split. Because of MVCC even unique index could contain duplicates. Storing duplicates in p

Re: Hooking at standard_join_search (Was: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual)

On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 2, 2015 at 10:30 AM, Tom Lane wrote: >>> But if you have in mind that typical FDWs would actually create join paths >>> at that point, consider that >>> >>> 1. The FDW would have to find all the combinations of

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On Thu, Sep 3, 2015 at 3:56 PM, Robert Haas wrote: > On Thu, Sep 3, 2015 at 4:00 AM, Shulgin, Oleksandr > wrote: >> I believe that having a floating IP for the master is much more practical >> approach and it doesn't require any patch to libpq or modification of the >> client connection settings.

Re: [HACKERS] Proposal: Implement failover on libpq connect level.

On Thu, Sep 3, 2015 at 4:00 AM, Shulgin, Oleksandr wrote: > I believe that having a floating IP for the master is much more practical > approach and it doesn't require any patch to libpq or modification of the > client connection settings. I think that's a great approach if all the machines are o

[HACKERS] Too many duplicated condition query return wrong value

Hi. I cought a strange result. I execute such query. > SELECT "attend"."lid", "attend"."status" FROM "attend" WHERE "attend"."sid" = > 325 AND "attend"."lid" IN ('ABF0010', 'ABF0010', 'ABF0010', 'ABF0010', > 'ABF0010', 'ABF0010', 'ABF0010', 'ABF0010', 'ABF0010', 'ABF0010', 'ABF0010', > 'ABF001

Re: [HACKERS] Horizontal scalability/sharding

On Thu, Sep 3, 2015 at 03:40:40PM +0200, Tomas Vondra wrote: > Not really, the idea is that you don't need to create the replica > immediately. The system recognizes that primary shard location is > unavailable and redirects the tasks to the "replicas." So the time > to recreate the failed node is

Re: [HACKERS] Horizontal scalability/sharding

Josh Berkus wrote: >>> You'd also need a way to let the connection nodes know when a replica >>> has fallen behind so that they can be taken out of >>> load-balancing/sharding for read queries. For the synchronous model, >>> that would be "fallen behind at all"; for asynchronous it would be >>>

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Thu, Sep 3, 2015 at 1:46 AM, Jim Nasby wrote: > The double set of exceptions seems to be critical; if instead of calling > tf.get(invoice) (which recursively does tf.get(customer)) I define the > cursor to call tf.get(customer) directly there's no assert. Finally I have been able to crack down

Re: [HACKERS] Horizontal scalability/sharding

Hi, On 09/03/2015 05:02 AM, Amit Kapila wrote: On Thu, Sep 3, 2015 at 8:28 AM, Bruce Momjian mailto:br...@momjian.us>> wrote: > > On Wed, Sep 2, 2015 at 07:50:25PM -0700, Joshua Drake wrote: > > >Can you explain why logical replication is better than binary > > >replication for this use-cas

Re: [HACKERS] [PATCH] Microvacuum for gist.

Hi, I don't know too much about gist, but did a quick read through. Mostly spotting some stylistic issues. Please fix those making it easier for the next reviewer. Thank you for review! All mentioned issues are fixed. -- Anastasia Lubennikova Postgres Professional:http://www.postgrespro.com T

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> , On Wed, Aug 26, 2015 at 4:05 AM, Kouhei Kaigai wrote: > >> On 2015/08/26 16:07, Kouhei Kaigai wrote: > >> I wrote: > >> >> Maybe I'm missing something, but why do we need such a flexiblity for > >> >> the columnar-stores? > >> > >> > Even if we enforce them a new interface specification comfor

Re: [HACKERS] Allow a per-tablespace effective_io_concurrency setting

On Wed, Sep 2, 2015 at 5:38 PM, Andres Freund wrote: > If you additionally take into account hardware realities where you have > multiple platters, multiple spindles, command queueing etc, that's even > more true. A single rotation of a single platter with command queuing > can often read several

[HACKERS] September 2015 Commitfest

Hi, Two days ago the September Commitfest started. I'm going to be your host^W commitfest manager this time round. To start off I went through all entries and tried to make sure their state is accurate. Right now we have: Needs review: 47 Waiting on Author: 24 Ready for Committer:

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 3 September 2015 at 22:17, Andres Freund wrote: > On 2015-09-03 16:28:40 +1200, David Rowley wrote: > > I experimented with finding the fastest way to convert an int to a string > > at the weekend, I did happen to be testing with int64's but likely int32 > > will be the same. > > > > This is t

Re: [HACKERS] [DOCS] max_worker_processes on the standby

On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas wrote: > On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera > wrote: >>> I think it's totally reasonable for the standby to follow the master's >>> behavior rather than the config file. That should be documented, but >>> otherwise, no problem. If it wer

Re: [HACKERS] Allow replication roles to use file access functions

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Sep 3, 2015 at 11:20 AM, Stephen Frost wrote: > >> Not only, +clog, configuration files, etc. > > > > Configuration files? Perhaps you could elaborate? > > Sure. Sorry for being unclear. It copies everything that is not a > relation f

  1   2   >