[HACKERS] EPQ recheck across HashJoin, what does it actuall check?

Folks, Could you correct me if I misunderstand the execution path. We may have the following example. Query try to get row level locking on the table 't1' that is under the 'Hash' node. postgres=# EXPLAIN postgres-# SELECT * FROM t0 NATURAL JOIN t1 WHERE ax between 10 and 30 FOR UPDATE OF t1;

Re: [HACKERS] Re: [COMMITTERS] pgsql: Enable logical slots to follow timeline switches

On 1 April 2016 at 12:47, Craig Ringer wrote: > I'll prep a follow-up patch. > > Done and attached. Note that I can't use PG_GETARG_TRANSACTIONID directly since it's a macro defined only in xid.c . It didn't seem worth extracting it and moving it to postgres.h (where the

Re: [HACKERS] [PATCH v10] GSSAPI encryption support

On Fri, Apr 1, 2016 at 12:31 PM, Robbie Harwood wrote: > - Fixed Windows build. Thanks to Michael for patches. This looks fine. I am not seeing build failures now. > - Fixed buffering of large replies on the serverside. This should fix > the traceback that was being

Re: [HACKERS] Timeline following for logical slots

On 31 March 2016 at 16:09, Andres Freund wrote: > > This gives us an option for failover of logical replication in 9.6, even > if > > it's a bit cumbersome and complex for the client, in case failover slots > > don't make the cut. And, of course, it's a pre-req for failover

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

On Fri, Apr 1, 2016 at 12:48 PM, Tom Lane wrote: > I thought about this patch a bit more... > > When I first looked at the patch, I didn't believe that it worked at > all: it failed to return a PGRES_COPY_XXX result to the application, > and yet nonetheless switched libpq's

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Sat, Mar 19, 2016 at 5:45 PM, Magnus Hagander wrote: > On Wed, Mar 2, 2016 at 6:49 PM, Marco Nenciarini < > marco.nenciar...@2ndquadrant.it> wrote: > >> >> I've attached an updated patch, which is rebased on current master and > includes the oid fix. > > + Finish

Re: [HACKERS] Re: [COMMITTERS] pgsql: Enable logical slots to follow timeline switches

On 1 April 2016 at 11:13, Petr Jelinek wrote: > > The function does following: > TransactionId new_xmin = (TransactionId) PG_GETARG_INT64(1); > This should be reasonable enough though; down-casting it will discard the high bits but that's fine when we know there's nothing

Re: [HACKERS] Incorrect format in error message

David Rowley writes: > The attached fixes an error message which is incorrectly using an > unsigned format specifier instead of a signed one. I think that's the tip of the iceberg :-(. For starters, the code allows ObjectIdAttributeNumber without regard for the

Re: [HACKERS] Parallel Queries and PostGIS

On 30 March 2016 at 09:14, Robert Haas wrote: > On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey > wrote: >>> I have no idea why the cost adjustments that you need are different >>> for the scan case and the aggregate case. That does seem

Re: [HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

On Apr 1, 2016 02:57, "Karl O. Pinc" wrote: > > I assume there are no questions about supporting a > similar functionality only without PQsetSingleRowMode, > as follows: Sorry, but I don't see what is your actual question here? Both code examples are going to compile and work,

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2016-04-01 4:52 GMT+02:00 Kyotaro HORIGUCHI : > At Thu, 31 Mar 2016 11:22:20 +0200, Pavel Stehule > wrote in < > cafj8prd7vadunoiapb8exwc+c5ccis-rj2dphvzcwzkgxjb...@mail.gmail.com> > > 2016-03-30 10:34 GMT+02:00 Kyotaro HORIGUCHI < > >

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

I thought about this patch a bit more... When I first looked at the patch, I didn't believe that it worked at all: it failed to return a PGRES_COPY_XXX result to the application, and yet nonetheless switched libpq's asyncStatus to PGASYNC_COPY_XXX? Wouldn't things be hopelessly confused? I tried

Re: [HACKERS] Parallel Queries and PostGIS

On Fri, Apr 1, 2016 at 12:49 AM, Paul Ramsey wrote: > > On Tue, Mar 29, 2016 at 12:51 PM, Paul Ramsey wrote: > > On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey wrote: > > > >>> On the join case, I wonder if it's

Re: [HACKERS] [PATCH v10] GSSAPI encryption support

Hello friends, Here is another version of GSSAPI encryption support, both on this email and on my github: https://github.com/frozencemetery/postgres/tree/feature/gssencrypt10 This version is intended to address Michael's review: - Fixed Windows build. Thanks to Michael for patches. - Fixed

Re: [HACKERS] Re: [COMMITTERS] pgsql: Enable logical slots to follow timeline switches

On 01/04/16 03:49, Alvaro Herrera wrote: > Moving thread to -hackers, CC'ing Craig. > > Michael Paquier wrote: > >> hamster complains here: >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster=2016-03-31%2016%3A00%3A06 >> [...] >> # Copying slots to replica >>

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Thu, Mar 31, 2016 at 5:49 PM, Magnus Hagander wrote: > On Thu, Mar 31, 2016 at 4:00 AM, David Steele wrote: > So maybe we should at least start that way. And just document that > clearly, and then use the patch that we have right now? > > Except we

Re: [HACKERS] So, can we stop supporting Windows native now?

On Fri, Apr 1, 2016 at 11:44 AM, Alvaro Herrera wrote: > The huge_pages feature is fairly new, and as I recall the intention is > that other operating systems will be supported as we get patches for it. BTW about other operating systems: It looks like FreeBSD is

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

At Thu, 31 Mar 2016 11:22:20 +0200, Pavel Stehule wrote in > 2016-03-30 10:34 GMT+02:00 Kyotaro HORIGUCHI < > horiguchi.kyot...@lab.ntt.co.jp>: > > > Hi, > > > > At Wed, 30 Mar 2016 09:23:49 +0200,

Re: [HACKERS] PATCH: index-only scans with partial indexes

At Thu, 31 Mar 2016 14:51:02 -0400, Tom Lane wrote in <19589.1459450...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Thank you for the comment. The new version is attached. > > Committed with rather heavy editorialization and a batch of

[HACKERS] Re: [COMMITTERS] pgsql: Enable logical slots to follow timeline switches

Moving thread to -hackers, CC'ing Craig. Michael Paquier wrote: > hamster complains here: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamster=2016-03-31%2016%3A00%3A06 > [...] > # Copying slots to replica > after_basebackup|test_decoding||547|0/560|0/598 > # Copying slot >

Re: [HACKERS] So, can we stop supporting Windows native now?

On Fri, Apr 1, 2016 at 11:44 AM, Alvaro Herrera wrote: > Thomas Munro wrote: >> On Fri, Apr 1, 2016 at 2:53 AM, Andrew Dunstan wrote: >> > It would also be nice to find out why we can't usefully scale shared >> > buffers >> > higher like we can on

[HACKERS] Incorrect format in error message

The attached fixes an error message which is incorrectly using an unsigned format specifier instead of a signed one. # create table t (); # create unique index t_idx on t (ctid); # alter table t replica identity using index t_idx; ERROR: internal column 4294967295 in unique index "t_idx" I was

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

Aleksander Alekseev writes: > +1, same here. Lets see whats committer's opinion. I fooled around with this patch quite a bit but could not bring myself to pull the trigger, because I think it fundamentally breaks applications that follow the "repeat PQgetResult until

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

On Fri, Apr 1, 2016 at 4:14 AM, Alvaro Herrera wrote: > Noah Misch wrote: > >> The above-described topic is currently a PostgreSQL 9.6 open item. Alvaro, >> since you committed the patch believed to have created it, you own this open >> item. > > That's correct. Since

[HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

Hi, Bruce Momjian suggested I write and ask about using libpq to submit multiple SQL statements to the backend, and then get results for each of the submitted statements, row-by-row without server-side caching of the results. Bruce wrote: > I think this would be good > to post to hackers to get

Re: [HACKERS] So, can we stop supporting Windows native now?

On Fri, Apr 1, 2016 at 9:05 AM, Craig Ringer wrote: > I completely agree there. I wrote some documentation on how to make project > files to build extensions, but it'd be nice to *generate* them instead, like > we do for in-tree builds. Yes, I maintain some code that

Re: [HACKERS] Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.

On Thu, Mar 31, 2016 at 04:48:26PM +0900, Masahiko Sawada wrote: > On Thu, Mar 31, 2016 at 2:02 PM, Noah Misch wrote: > > On Thu, Mar 10, 2016 at 01:04:11AM +0900, Masahiko Sawada wrote: > >> As a result of looked into code around the recvoery, ISTM that the > >> cause is

Re: [HACKERS] So, can we stop supporting Windows native now?

On 31 March 2016 at 21:53, Andrew Dunstan wrote: > > The worst thing about developing from my POV isn't something that actually > affects core developers so much, namely the lack of a nice MSVC equivalent > of PGXS. > I completely agree there. I wrote some documentation on

Re: [HACKERS] [PATCH v9] GSSAPI encryption support

On Fri, Apr 1, 2016 at 6:10 AM, Tom Lane wrote: > If that's what it is, it seems fairly broken to have it connected up to a > GUC variable. Especially one that's USERSET; some people will wonder why > frobbing it with SET does nothing, and others will bitch that they think >

Re: [HACKERS] Correction for replication slot creation error message in 9.6

On Thu, Mar 31, 2016 at 11:18 PM, Alvaro Herrera wrote: > Andres Freund wrote: >> On 2016-03-31 10:15:21 +0900, Ian Barwick wrote: > >> > Patch changes the error message to: >> > >> > ERROR: replication slots can only be used if wal_level is "replica" or >> >

Re: [HACKERS] So, can we stop supporting Windows native now?

Thomas Munro wrote: > On Fri, Apr 1, 2016 at 2:53 AM, Andrew Dunstan wrote: > > It would also be nice to find out why we can't usefully scale shared buffers > > higher like we can on *nix. > > Has anyone ever looked into whether asking for SEC_LARGE_PAGES would > help with

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

On March 31, 2016 11:13:46 PM GMT+02:00, Jesper Pedersen wrote: >I can do a USE_CONTENT_LOCK run on 0003 if it is something for 9.6. Yes please. I think the lock variant is realistic, the lockless did isn't. -- Sent from my Android device with K-9 Mail. Please

Re: [HACKERS] Draft release notes for next week's releases

On Thu, Mar 31, 2016 at 2:59 PM, Tom Lane wrote: > Well, too late for 9.5.2 anyway. It still makes sense to correct that > text for future releases. I'm inclined to wait a little bit though and > see what other improvements become apparent. For instance, I think the > point

Re: [HACKERS] Draft release notes for next week's releases

Peter Geoghegan writes: > I just noticed that the release notes mention char(n) as affected. > That's not actually true, because char(n) SortSupport only came in > 9.6. The Wiki page now shows this, which may be the most important > place, but ideally we'd fix this in the release

Re: [HACKERS] Draft release notes for next week's releases

On Sat, Mar 26, 2016 at 4:34 PM, Tom Lane wrote: > Probably the most discussion-worthy item is whether we can say > anything more about the strxfrm mess. Should we make a wiki > page about that and have the release note item link to it? I just noticed that the release notes

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

Hi, On 03/30/2016 07:09 PM, Andres Freund wrote: Yes. That looks good. My testing shows that increasing the number of buffers can increase both throughput and reduce latency variance. The former is a smaller effect with one of the discussed patches applied, the latter seems to actually increase

Re: [HACKERS] [PATCH v9] GSSAPI encryption support

Robbie Harwood writes: >>> + { >>> + {"gss_encrypt", PGC_USERSET, CONN_AUTH_SECURITY, >>> +gettext_noop("Require encryption for all GSSAPI connections."), >>> +NULL, >>> +GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE >>> + }, >>> +

Re: [HACKERS] improving GROUP BY estimation

Alvaro Herrera writes: > Tom Lane wrote: >> See "Approximating block accesses in database organizations", S. B. Yao, >> Communications of the ACM, Volume 20 Issue 4, April 1977 Pages 260-261 > That sounds nice all right, but I'm not sure it's actually helpful, > because

Re: [HACKERS] improving GROUP BY estimation

Dean Rasheed writes: > Yeah, that makes sense. In fact, if we only apply the adjustment when > reldistinct > 0 and rel->rows < rel->tuples, and rewrite the first > argument to pow() as (rel->tuples - rel->rows) / rel->tuples, then it > is guaranteed to be non-negative.

Re: [HACKERS] improving GROUP BY estimation

Dean Rasheed writes: > On 31 March 2016 at 21:40, Tom Lane wrote: >> Let's use something like this: >> See "Approximating block accesses in database organizations", S. B. Yao, >> Communications of the ACM, Volume 20 Issue 4, April 1977 Pages 260-261

Re: [HACKERS] [PATCH v9] GSSAPI encryption support

Alvaro Herrera writes: > Robbie Harwood wrote: >> Michael Paquier writes: > >> > + iov[0].iov_base = lenbuf; >> > + iov[0].iov_len = 4; >> > + iov[1].iov_base = output.value; >> > + iov[1].iov_len = output.length; >> > + >> > + ret

Re: [HACKERS] improving GROUP BY estimation

Tom Lane wrote: > > The article text refers to this 1977 S. B. Yao paper "Approximating > > block accesses in database organizations" which doesn't appear to be > > available online, except behind ACM's paywall at > > http://dl.acm.org/citation.cfm?id=359475 > > Well, a CACM citation is

Re: [HACKERS] improving GROUP BY estimation

On 31 March 2016 at 21:40, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Another minor gripe is the use of a random URL as justification. This >>> code will still be around when that URL exists nowhere but the Wayback >>> Machine.

Re: [HACKERS] improving GROUP BY estimation

On 31 March 2016 at 20:18, Tom Lane wrote: > Also, I wonder if it'd be a good idea to provide a guard against division > by zero --- we know rel->tuples > 0 at this point, but I'm less sure that > reldistinct can't be zero. In the same vein, I'm worried about the first >

Re: [HACKERS] improving GROUP BY estimation

Alvaro Herrera writes: > Tom Lane wrote: >> Another minor gripe is the use of a random URL as justification. This >> code will still be around when that URL exists nowhere but the Wayback >> Machine. Can't we find a more formal citation to use? > The article text

Re: [HACKERS] So, can we stop supporting Windows native now?

On Fri, Apr 1, 2016 at 2:53 AM, Andrew Dunstan wrote: > It would also be nice to find out why we can't usefully scale shared buffers > higher like we can on *nix. Has anyone ever looked into whether asking for SEC_LARGE_PAGES would help with that? I noticed that another

Re: [HACKERS] Please correct/improve wiki page about abbreviated keys bug

On Wed, Mar 30, 2016 at 6:23 PM, Josh berkus wrote: > Based on that concept, I wrote a query which is now on the wiki page. > Please fix it if it's not showing what we want it to show. Sorry, I got caught up with something last night. I did this this morning Pacific time.

Re: [HACKERS] improving GROUP BY estimation

Tom Lane wrote: > Another minor gripe is the use of a random URL as justification. This > code will still be around when that URL exists nowhere but the Wayback > Machine. Can't we find a more formal citation to use? The article text refers to this 1977 S. B. Yao paper "Approximating block

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Thu, Mar 31, 2016 at 8:21 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > > I think these changes worth running benchmark again. I'm going to run it > on 4x18 Intel. > The results are following. clients master v3 v5 v9 1 11671 12507 12679 12408 2

Re: [HACKERS] [PATCH v9] GSSAPI encryption support

Robbie Harwood wrote: > Michael Paquier writes: > > + iov[0].iov_base = lenbuf; > > + iov[0].iov_len = 4; > > + iov[1].iov_base = output.value; > > + iov[1].iov_len = output.length; > > + > > + ret = writev(port->sock, iov, 2); > > > > writev and iovec are

Re: [HACKERS] Parallel Queries and PostGIS

On Tue, Mar 29, 2016 at 12:51 PM, Paul Ramsey wrote: > On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey > wrote: > >>> On the join case, I wonder if it's possible that _st_intersects is not >>> marked parallel-safe? If that's not the problem,

Re: [HACKERS] improving GROUP BY estimation

Dean Rasheed writes: > On 30 March 2016 at 14:03, Tomas Vondra wrote: >> Attached is v4 of the patch > Thanks, I think this is good to go, except that I think we need to use > pow() rather than powl() because AIUI powl() is new to C99, and

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

Noah Misch wrote: > The above-described topic is currently a PostgreSQL 9.6 open item. Alvaro, > since you committed the patch believed to have created it, you own this open > item. That's correct. Since we already had a patch available, I pushed it. I'll wait for a few days before marking the

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

Michael Paquier wrote: > Actually, the attached is better. This one relies on time() to perform > the delay checks, and takes care of things even for slow machines. Thanks, pushed with some minor adjustments. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development,

Re: [HACKERS] PATCH: index-only scans with partial indexes

Kyotaro HORIGUCHI writes: > Thank you for the comment. The new version is attached. Committed with rather heavy editorialization and a batch of regression test cases. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] improving GROUP BY estimation

On 30 March 2016 at 14:03, Tomas Vondra wrote: > Attached is v4 of the patch Thanks, I think this is good to go, except that I think we need to use pow() rather than powl() because AIUI powl() is new to C99, and so won't necessarily be available on all supported

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

What led you to choose the ? operator for the FOLLOWED BY semantics? It doesn't seem a terribly natural choice -- most other things seems to use ? as some sort of wildcard. What about something like "...", so you would do SELECT q @@ to_tsquery('fatal ... error'); and SELECT q @@ (tsquery

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

Hi Teodor, I've looked through your version and made a few adjustments. > Pls, remove tsquery_setweight from patch because it's not a part of phrase > search and it isn't mentioned in docs. Please, make a separate patch for it. I've removed tsquery_setweight as you requested. I'm going to add

Re: [HACKERS] WIP: Access method extendability

On 03/31/16 17:29, Alexander Korotkov wrote: > New revision of patches is attached. > 1) API of generic xlog was changed: now there is no static variables, >GenericXLogStart() returns palloc'd struct. Attached are two trivial documentation editing fixes for this, as an incremental patch.

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Thu, Mar 31, 2016 at 7:14 PM, Andres Freund wrote: > > +/* > > + * The following two macros are aimed to simplify buffer state > modification > > + * in CAS loop. It's assumed that variable "uint32 state" is defined > outside > > + * of this loop. It should be used as

Re: [HACKERS] [PATCH v9] GSSAPI encryption support

Michael Paquier writes: > On Thu, Mar 31, 2016 at 2:14 PM, Michael Paquier > wrote: >> On Wed, Mar 30, 2016 at 1:01 PM, Robbie Harwood wrote: >>> A new version of my GSSAPI encryption patchset is available, both in >>>

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

Looking at patch, I'm inlined to commit it in current commitfest, it looks workable and too many people desire it. I've did some changes, mostly in formatting and comments. Patch makes some user-visible changes: 1 change order for tsquery. Assume, it's acceptable, only a few users store

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi, > +/* > + * The following two macros are aimed to simplify buffer state modification > + * in CAS loop. It's assumed that variable "uint32 state" is defined outside > + * of this loop. It should be used as following: > + * > + * BEGIN_BUFSTATE_CAS_LOOP(bufHdr); > + * modifications of state

[HACKERS] Re: [PATH] Jsonb, insert a new value into an array at arbitrary position

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 have reviewed this patch. It applies cleanly at the top of

Re: [HACKERS] So, can we stop supporting Windows native now?

On 03/30/2016 09:17 PM, Tom Lane wrote: > Craig Ringer writes: >> On 31 March 2016 at 07:49, Josh berkus wrote: >>> So, can we stop supporting Windows native now? > >> Why would we want to? > >> The cost is small. > > Surely you jest. Windows is the

Re: [HACKERS] So, can we stop supporting Windows native now?

On 03/31/2016 06:53 AM, Andrew Dunstan wrote: > The worst thing about developing from my POV isn't something that > actually affects core developers so much, namely the lack of a nice MSVC > equivalent of PGXS. Bingo! +1 -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure

Re: [HACKERS] [PATCH] we have added support for box type in SP-GiST index

> Thank you, pushed Thank you for working on this. I noticed that have overlooked this: static RectBox * -initRectBox() +initRectBox(void) { -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi! On Thu, Mar 31, 2016 at 4:59 PM, Amit Kapila wrote: > On Tue, Mar 29, 2016 at 10:52 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> Hi, Andres! >> >> Please, find next revision of patch in attachment. >> >> > Couple of minor comments: > > + * The

Re: [HACKERS] WIP: Access method extendability

Hi! New revision of patches is attached. Changes are following: 1) API of generic xlog was changed: now there is no static variables, GenericXLogStart() returns palloc'd struct. 2) Generic xlog use elog instead ereport since it reports internal errors which shouldn't happen normally. 3) Error

Re: [HACKERS] Correction for replication slot creation error message in 9.6

Andres Freund wrote: > On 2016-03-31 10:15:21 +0900, Ian Barwick wrote: > > Patch changes the error message to: > > > > ERROR: replication slots can only be used if wal_level is "replica" or > > "logical" > > > > Explicitly naming the valid WAL levels matches the wording in the wal_level >

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Andres Freund writes: > Oh. I confused my approaches. I was thinking about going for 2): >> 2) Replace the lwlock spinlock by a bit in LWLock->state. That'd avoid >> embedding the spinlock, and actually might allow to avoid one atomic >> op in a number of cases. > precisely

Re: [HACKERS] Performance degradation in commit 6150a1b0

Robert Haas writes: > On Thu, Mar 31, 2016 at 6:45 AM, Andres Freund wrote: >> On 2016-03-31 06:43:19 -0400, Robert Haas wrote: >>> To which proposal are you referring? >> 1) in >>

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Mar 29, 2016 at 10:52 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Hi, Andres! > > Please, find next revision of patch in attachment. > > Couple of minor comments: + * The following two macroses is macroses right word to be used here? + * of this loop. It should be

Re: [HACKERS] So, can we stop supporting Windows native now?

On 03/31/2016 06:38 AM, Andres Freund wrote: On 2016-03-31 13:30:58 +0300, Yury Zhuravlev wrote: Craig Ringer wrote: Yeah, you're right. He's not the only one either. I was reacting to the original post, and TBH didn't think it through. The commit logs suggest there's a decent amount of

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

On Wed, Mar 30, 2016 at 9:19 PM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> Just a note: I began looking at the tests, but finished looking at the >> patch entirely at the end by curiosity. Regarding the integration of >> this patch for 9.6, I think that bumping

Re: [HACKERS] Relation extension scalability

On Thu, Mar 31, 2016 at 4:28 PM, Robert Haas wrote: > Yeah, kind of. But obviously if we could make the limit smaller > without hurting performance, that would be better. > > Per my note yesterday about performance degradation with parallel > COPY, I wasn't able to

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 31 March 2016 at 17:31, Vitaly Burovoy wrote: > it is logical to insert new value if "before", then current value, then new > value if "after". > Oh, I see now. There is a slightly different logic: `v` is a current value and `newval` is a new value. So basically we

Re: [HACKERS] PATCH: index-only scans with partial indexes

Thank you for the comment. The new version is attached. Some issues has not been addressed but the rest will be addresses in the next version. At Thu, 31 Mar 2016 08:42:50 +0200, Tomas Vondra wrote in <90d885f2-e5ce-6668-226f-c817154e4...@2ndquadrant.com> > On

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

On 2016-03-31 17:52:12 +0530, Amit Kapila wrote: > On Thu, Mar 31, 2016 at 3:48 PM, Andres Freund wrote: > > > > On 2016-03-31 15:07:22 +0530, Amit Kapila wrote: > > > On Thu, Mar 31, 2016 at 4:39 AM, Andres Freund > wrote: > > > > > > > > On 2016-03-28

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-31 12:58:55 +0200, Andres Freund wrote: > On 2016-03-31 06:54:02 -0400, Robert Haas wrote: > > On Wed, Mar 30, 2016 at 3:16 AM, Andres Freund wrote: > > > Yea, as Tom pointed out that's not going to work. I'll try to write a > > > patch for approach 1). > > > >

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

On Thu, Mar 31, 2016 at 3:48 PM, Andres Freund wrote: > > On 2016-03-31 15:07:22 +0530, Amit Kapila wrote: > > On Thu, Mar 31, 2016 at 4:39 AM, Andres Freund wrote: > > > > > > On 2016-03-28 22:50:49 +0530, Amit Kapila wrote: > > > > On Fri, Sep 11, 2015

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Thu, Mar 31, 2016 at 2:19 PM, Magnus Hagander wrote: > On Thu, Mar 31, 2016 at 4:00 AM, David Steele wrote: > >> On 3/30/16 4:18 AM, Magnus Hagander wrote: >> > >> > On Wed, Mar 30, 2016 at 4:10 AM, David Steele > >

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On Thu, Mar 31, 2016 at 4:00 AM, David Steele wrote: > On 3/30/16 4:18 AM, Magnus Hagander wrote: > > > > On Wed, Mar 30, 2016 at 4:10 AM, David Steele > > wrote: > > > > This certainly looks like it would work but it

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 3/30/16, Dmitry Dolgov <9erthali...@gmail.com> wrote: > On 31 March 2016 at 05:04, Vitaly Burovoy wrote: >> The documentation changes still has to be fixed. > Thanks for help. Looks like I'm not so good at text formulation. Fixed. Never mind. I'm also not so good at

Re: [HACKERS] Relation extension scalability

On Thu, Mar 31, 2016 at 4:28 PM, Robert Haas wrote: > On Thu, Mar 31, 2016 at 12:59 AM, Dilip Kumar > wrote: > > On Tue, Mar 29, 2016 at 10:08 AM, Amit Kapila > > wrote: > >> Yes, that makes sense. One more point is that

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-31 06:54:02 -0400, Robert Haas wrote: > On Wed, Mar 30, 2016 at 3:16 AM, Andres Freund wrote: > > Yea, as Tom pointed out that's not going to work. I'll try to write a > > patch for approach 1). > > Does this mean that any platform that wants to perform well will

Re: [HACKERS] Relation extension scalability

On Thu, Mar 31, 2016 at 12:59 AM, Dilip Kumar wrote: > On Tue, Mar 29, 2016 at 10:08 AM, Amit Kapila > wrote: >> Yes, that makes sense. One more point is that if the reason for v13 >> giving better performance is extra blocks (which we believe in

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Wed, Mar 30, 2016 at 3:16 AM, Andres Freund wrote: > On 2016-03-30 07:13:16 +0530, Dilip Kumar wrote: >> On Tue, Mar 29, 2016 at 10:43 PM, Andres Freund wrote: >> >> > My gut feeling is that we should do both 1) and 2). >> > >> > Dilip, could you test

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Thu, Mar 31, 2016 at 6:45 AM, Andres Freund wrote: > On 2016-03-31 06:43:19 -0400, Robert Haas wrote: >> On Thu, Mar 31, 2016 at 3:51 AM, Andres Freund wrote: >> >>My attribution above was incorrect. Robert Haas is the committer and >> >>owner of >>

Re: [HACKERS] Performance degradation in commit 6150a1b0

On 2016-03-31 06:43:19 -0400, Robert Haas wrote: > On Thu, Mar 31, 2016 at 3:51 AM, Andres Freund wrote: > >>My attribution above was incorrect. Robert Haas is the committer and > >>owner of > >>this one. I apologize. > > > > Fine in this case I guess. I've posted a proposal

Re: [HACKERS] Performance degradation in commit 6150a1b0

On Thu, Mar 31, 2016 at 3:51 AM, Andres Freund wrote: >>My attribution above was incorrect. Robert Haas is the committer and >>owner of >>this one. I apologize. > > Fine in this case I guess. I've posted a proposal nearby either way, it > appears to be a !x86 problem. To

Re: [HACKERS] So, can we stop supporting Windows native now?

On 2016-03-31 13:30:58 +0300, Yury Zhuravlev wrote: > Craig Ringer wrote: > >Yeah, you're right. He's not the only one either. > > > >I was reacting to the original post, and TBH didn't think it through. The > >commit logs suggest there's a decent amount of work that goes in, and I'm > >sure a lot

Re: [HACKERS] So, can we stop supporting Windows native now?

Craig Ringer wrote: Yeah, you're right. He's not the only one either. I was reacting to the original post, and TBH didn't think it through. The commit logs suggest there's a decent amount of work that goes in, and I'm sure a lot of it isn't visible when just looking for 'windows', 'win32',

Re: [HACKERS] So, can we stop supporting Windows native now?

On 31 March 2016 at 16:20, Andres Freund wrote: > On 2016-03-31 09:04:35 +0800, Craig Ringer wrote: > > The cost is small. > > First off I agree we don't want to drop proper windows support. > > But I think "the cost is small" is a pretty bad mischaracterization. I > don't do

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

On 2016-03-31 15:07:22 +0530, Amit Kapila wrote: > On Thu, Mar 31, 2016 at 4:39 AM, Andres Freund wrote: > > > > On 2016-03-28 22:50:49 +0530, Amit Kapila wrote: > > > On Fri, Sep 11, 2015 at 8:01 PM, Amit Kapila > > > wrote: > > > > > > > > Amit,

Re: [HACKERS] Small patch: --disable-setproctitle flag

On 2016-03-31 13:06:05 +0300, Aleksander Alekseev wrote: > Hello > > Recently I discovered that renaming processes using setproctitle() call > on BSD systems may sometimes cause problems. For instance there is > currently a bug in all versions of LLDB which makes it impossible to > debug a

[HACKERS] Small patch: --disable-setproctitle flag

Hello Recently I discovered that renaming processes using setproctitle() call on BSD systems may sometimes cause problems. For instance there is currently a bug in all versions of LLDB which makes it impossible to debug a process that called setproctitle():

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

On Thu, Mar 31, 2016 at 4:39 AM, Andres Freund wrote: > > On 2016-03-28 22:50:49 +0530, Amit Kapila wrote: > > On Fri, Sep 11, 2015 at 8:01 PM, Amit Kapila > > wrote: > > > > > Amit, could you run benchmarks on your bigger hardware? Both with >

[HACKERS] standalone backend PANICs during recovery

While investigating a problem on a streaming hot standby instance at a customer site, i got the following when using a standalone backend: PANIC: btree_xlog_delete_get_latestRemovedXid: cannot operate with inconsistent data CONTEXT: xlog redo delete: index 1663/65588/65625; iblk 11, heap

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2016-03-30 10:34 GMT+02:00 Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp>: > Hi, > > At Wed, 30 Mar 2016 09:23:49 +0200, Pavel Stehule > wrote in < > cafj8prbvka6ng4jwz2qmro7inudfjws5w0+demvgzznuf-h...@mail.gmail.com> > > Hi > > > > ... > > >> =# alter table if > >

  1   2   >