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

On Tue, Mar 29, 2016 at 6:02 PM, Tomas Vondra wrote: > That may be easily due to differences between the CPUs and configuration. > For example the Xeon uses a way older CPU with different amounts of CPU > cache, and it's also a multi-socket system. And so on. So, having searched past threads I gu

[HACKERS] [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.

Hi Team, While I was working on constraints node in pgadmin4 I came across this scenario. Please let me know if it's correct behaviour or a bug. *Scenario:* If we create two different type of constrains (lets say primary key and foreign key) on same table with same name (lets say 'key' ) then i

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

No one should care of this but to make shure.. At Tue, 29 Mar 2016 20:12:03 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160329.201203.78219296.horiguchi.kyot...@lab.ntt.co.jp> > By the way, memory blocks that readline sees are freed by it but > blocks allocated by the additional

Re: [HACKERS] multivariate statistics v14

>> with statistics without statistics >> case10.980.01 >> case298/01/0 > > The case2 shows that functional dependencies assume that the > conditions used in queries won't be incompatible - that's something > this type of statistics can't fix. It would

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

On Tue, Mar 29, 2016 at 8:31 PM, David Steele wrote: > Hi Amit, > > On 3/22/16 3:37 AM, Michael Paquier wrote: > > Hope this brings some light in. >> > > Do you know when you'll have time to respond to Michael's last email? I've > marked this patch "waiting on author" in the meantime. > > I think

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

2016-03-30 5:43 GMT+02:00 Kyotaro HORIGUCHI : > Hello, > > At Tue, 29 Mar 2016 13:12:06 +0200, Pavel Stehule > wrote in kpzfw1+af_lutm...@mail.gmail.com> > > 2016-03-29 12:08 GMT+02:00 Kyotaro HORIGUCHI < > > > > > As mentioned before, upper-lower problem is an existing > > > > > issue. The case

Re: [HACKERS] Sequence Access Method WIP

On Tue, Mar 29, 2016 at 5:58 PM, Petr Jelinek wrote: > > On 29/03/16 22:08, Fabrízio de Royes Mello wrote: >> >> >> >> On Tue, Mar 29, 2016 at 4:59 PM, Petr Jelinek > > wrote: >> > >> > On 29/03/16 19:46, Fabrízio de Royes Mello wrotez >> >> >> >> >> >> > >> >>

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

Hello friends, A new version of my GSSAPI encryption patchset is available, both in this email and on my github: https://github.com/frozencemetery/postgres/tree/feature/gssencrypt9 This version is intended to address David's review suggestions: - The only code change (not counting SGML and comme

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

Thank you for polishing this. At Tue, 29 Mar 2016 13:31:19 -0500, Kevin Grittner wrote in > I tried to whip this into shape, but there were a few areas I > didn't feel I had the necessary understanding to feel comfortable > taking on the committer role for it. I've cleaned it up the best I > c

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

Hello, At Tue, 29 Mar 2016 13:12:06 +0200, Pavel Stehule wrote in > 2016-03-29 12:08 GMT+02:00 Kyotaro HORIGUCHI < > > > > As mentioned before, upper-lower problem is an existing > > > > issue. The case of the words in a query result list cannot be > > > > edited since it may contain words that

Re: [HACKERS] Combining Aggregates

On 26 March 2016 at 15:07, David Rowley wrote: Many thanks Robert for committing the serialize states portion. > 0005: > Haribabu's patch; no change from last time. Just in case you jump ahead. I just wanted to re-highlight something Haribabu mentioned a while ago about combining floating point

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

Peter Geoghegan writes: > Do you think it would be okay if the SQL query to detect potentially > affected indexes only considered the leading attribute? Since that's > the only attribute that could use abbreviated keys, it ought to be > safe to not require users to REINDEX indexes that happen to h

Re: [HACKERS] Relation extension scalability

On Wed, Mar 30, 2016 at 7:51 AM, Dilip Kumar wrote: > + if (lockWaiters) > + /* > + * Here we are using same freespace for all the Blocks, but that > + * is Ok, because all are newly added blocks and have same freespace > + * And even some block which we just added to FreespaceMap above, is > + *

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

On Tue, Mar 29, 2016 at 6:02 PM, Tomas Vondra wrote: > And why not? I mean, why should it be acceptable to slow down? My point was that over 80% of execution time was spent in the HashAggregate, which outputs tuples to the sort. That, and the huge i5/Xeon inconsistency (in the extent to which thi

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

On Tue, Mar 29, 2016 at 7:31 PM, Tom Lane wrote: > A corrupt index could easily fail to detect uniqueness violations (because > searches fail to find entries they should find). Not sure I believe that > it would make false reports of a uniqueness conflict that's not really > there. Sure. But loo

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

Peter Geoghegan writes: > I made a pass over this, and changed some things. I noticed it said > something about incorrect unique violations on affected systems. Is > that really possible? A corrupt index could easily fail to detect uniqueness violations (because searches fail to find entries they

Re: [HACKERS] Relation extension scalability

On Wed, Mar 30, 2016 at 7:19 AM, Robert Haas wrote: Thanks for review and better comments.. > hio.c: In function ‘RelationGetBufferForTuple’: > hio.c:231:20: error: ‘freespace’ may be used uninitialized in this > function [-Werror=uninitialized] > hio.c:185:7: note: ‘freespace’ was declared her

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

On 3/29/16 2:09 PM, Magnus Hagander wrote: > I had a chat with Heikki, and here's another suggestion: > > 1. We don't touch the current exclusive backups at all, as previously > discussed, other than deprecating their use. For backwards compat. > > 2. For new backups, we return the contents of p

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

On Tue, Mar 29, 2016 at 5:31 PM, Josh berkus wrote: > For Thursday's release, I've added a wiki page to give users more > information about the strxfrm() issue, especially since we're going to > ask them to do a bunch of REINDEXing. I made a pass over this, and changed some things. I noticed it s

[HACKERS] Re: [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

On Wed, Mar 30, 2016 at 10:47 AM, Tom Lane wrote: > Michael Paquier writes: >> On Wed, Mar 30, 2016 at 10:13 AM, Tom Lane wrote: >>> I'm inclined to just drop the out-of-range test cases. They're not that >>> useful IMO, and alternate expected-files are a real PITA for maintenance. > >> Hm. Act

Re: [HACKERS] Relation extension scalability

On Tue, Mar 29, 2016 at 1:29 PM, Dilip Kumar wrote: > Attaching new version v18 > > - Some cleanup work on v17. > - Improved UpdateFreeSpaceMap function. > - Performance and space utilization are same as V17 Looks better. Here's a v19 that I hacked on a bit. Unfortunately, one compiler I tried

Re: [HACKERS] [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

Michael Paquier writes: > On Wed, Mar 30, 2016 at 10:13 AM, Tom Lane wrote: >> I'm inclined to just drop the out-of-range test cases. They're not that >> useful IMO, and alternate expected-files are a real PITA for maintenance. > Hm. Actually, they are quite useful to check error boundaries, so

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

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 performance of reducing ppc's spinlock to 1 byte? > Cross-compiling suggest that doing so "just works". I.e. replace the > #if defined(__ppc__) typedef from an i

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan wrote: > I am currently travelling, but my intention is to deal with the remaining > patches when I'm back home this weekend, unless someone beats me to it. Cool. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL C

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Tue, Mar 29, 2016 at 5:47 PM, Thomas Munro wrote: > On Wed, Mar 30, 2016 at 6:04 AM, Robert Haas wrote: >> On Tue, Mar 29, 2016 at 3:17 AM, Michael Paquier >> wrote: >>> OK, so I am switching this patch as "Ready for committer", for 0001. >>> It is in better shape now. >> >> Well... I have a

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/29/2016 08:48 PM, Michael Paquier wrote: On Wed, Mar 30, 2016 at 12:45 AM, Robert Haas wrote: On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote: I have machine ready, waiting for animal name and secret. Great! Nice. Thanks. It will obviously fail until we push the 0002 and 0004

[HACKERS] Re: [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

On Wed, Mar 30, 2016 at 10:13 AM, Tom Lane wrote: > Michael Paquier writes: >> On Wed, Mar 30, 2016 at 6:09 AM, Tom Lane wrote: >>> Allow to_timestamp(float8) to convert float infinity to timestamp infinity. > >> Some of the tests introduced are making MSVC unhappy, because they >> depend on the

Re: [HACKERS] [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

Michael Paquier writes: > On Wed, Mar 30, 2016 at 6:09 AM, Tom Lane wrote: >> Allow to_timestamp(float8) to convert float infinity to timestamp infinity. > Some of the tests introduced are making MSVC unhappy, because they > depend on the three-digit behavior that Windows is using, leading to >

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Alvaro Herrera writes: > Tom Lane wrote: >> Anyway, as things stand, elog(ERROR) will abort the session safely but >> you won't necessarily get the kind of logging you want, so expected >> auth-failure cases should try to go the STATUS_ERROR route. > In other words, the use of palloc() and friend

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

Hi, On 03/29/2016 09:43 PM, Peter Geoghegan wrote: On Tue, Mar 29, 2016 at 9:11 AM, Robert Haas wrote: One test that kind of bothers me in particular is the "SELECT DISTINCT a FROM numeric_test ORDER BY a" test on the high_cardinality_random data set. That's a wash at most work_mem values, bu

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

On Tue, Mar 29, 2016 at 12:43 PM, Peter Geoghegan wrote: > A complete do-over from Tomas would be best, here. He has already > acknowledged that the i5 CREATE INDEX results were completely invalid. The following analysis is all based on Xeon numbers, which as I've said we should focus on pending

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Wed, Mar 30, 2016 at 12:45 AM, Robert Haas wrote: > On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote: >> I have machine ready, waiting for animal name and secret. > > Great! Nice. Thanks. >> It will obviously >> fail until we push the 0002 and 0004 though. > > I think it would be a shame

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Mar 30, 2016 at 1:23 AM, Fabien COELHO wrote: > > Hello Robert, > >>> If we don't nuke it, it'll never die. >> >> >> Hearing no objections, BOOM. > > > FIZZ! :-) > > Thanks for the commits, and apology for the portability bugs. Thanks for the additions, Fabien. This has been a long trip.

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

Hackers, For Thursday's release, I've added a wiki page to give users more information about the strxfrm() issue, especially since we're going to ask them to do a bunch of REINDEXing. Please help me improve this. Particularly, I need help on the following: * is my explanation of the issue corre

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

On 3/29/16 8:21 PM, Michael Paquier wrote: > On Wed, Mar 30, 2016 at 12:01 AM, David Steele wrote: >> Hi Amit, >> >> On 3/22/16 3:37 AM, Michael Paquier wrote: >> >>> Hope this brings some light in. >> >> >> Do you know when you'll have time to respond to Michael's last email? I've >> marked this

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

On Wed, Mar 30, 2016 at 12:01 AM, David Steele wrote: > Hi Amit, > > On 3/22/16 3:37 AM, Michael Paquier wrote: > >> Hope this brings some light in. > > > Do you know when you'll have time to respond to Michael's last email? I've > marked this patch "waiting on author" in the meantime. Shouldn't

[HACKERS] Re: [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

On Wed, Mar 30, 2016 at 6:09 AM, Tom Lane wrote: > Allow to_timestamp(float8) to convert float infinity to timestamp infinity. > > With the original SQL-function implementation, such cases failed because > we don't support infinite intervals. Converting the function to C lets > us bypass the inte

Re: [HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

On Tue, Mar 29, 2016 at 11:20 PM, Tom Lane wrote: > Christian Ullrich writes: >> * Tom Lane wrote: >>> But then, should not this code make sure that errno *always* gets set? > >> A library function that does not fail does not touch errno. > > Right, I meant "always in the error path". > >>> I'd b

Re: [HACKERS] standby_schedule

On Wed, Mar 30, 2016 at 6:44 AM, Alvaro Herrera wrote: > I think we're at a point where we can translate the tests in > src/test/regress/standby_schedule file into a PostgresNode-based test, > or remove it (probably under src/test/recovery). That way, it would get > run all the time rather than j

[HACKERS] kqueue

Hi, On the WaitEventSet thread I posted a small patch to add kqueue support[1]. Since then I peeked at how some other software[2] interacts with kqueue and discovered that there are platforms including NetBSD where kevent.udata is an intptr_t instead of a void *. Here's a version which should co

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

On 3/29/16 5:05 PM, Robbie Harwood wrote: > David Steele writes: > >> On 3/20/16 12:09 AM, Robbie Harwood wrote: >> >>> A new version of my GSSAPI encryption patchset is available >> >> Here's a more thorough review: > > Thanks for the review! To keep this a manageable size, I'm going to > trim

Re: [HACKERS] [PATCH] Remove TZ entry from postgres CLI doc page.

Matthew Somerville writes: > Please find attached a patch to the postgres command line > documentation page doc/src/sgml/ref/postgres-ref.sgml that removes the > "TZ" entry from the "Environment" section. If I've understood it > correctly, since ca4af308 TZ can be looked at when you run initdb, bu

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Tom Lane wrote: > Alvaro Herrera writes: > > So, it seems that ClientAuthentication() expects to raise ereport(FATAL) > > in case of authentication failures. But what's the code path that > > causes that to happen if a ereport(ERROR) happens in there? Because all > > that code is pretty careful

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Alvaro Herrera writes: > So, it seems that ClientAuthentication() expects to raise ereport(FATAL) > in case of authentication failures. But what's the code path that > causes that to happen if a ereport(ERROR) happens in there? Because all > that code is pretty careful to not do ereport(ERROR) d

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Wed, Mar 30, 2016 at 6:04 AM, Robert Haas wrote: > On Tue, Mar 29, 2016 at 3:17 AM, Michael Paquier > wrote: >> OK, so I am switching this patch as "Ready for committer", for 0001. >> It is in better shape now. > > Well... I have a few questions yet. > > The new argument to SyncRepWaitForLSN

[HACKERS] standby_schedule

I think we're at a point where we can translate the tests in src/test/regress/standby_schedule file into a PostgresNode-based test, or remove it (probably under src/test/recovery). That way, it would get run all the time rather than just when somebody feels like it (which is probably almost never,

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

So, it seems that ClientAuthentication() expects to raise ereport(FATAL) in case of authentication failures. But what's the code path that causes that to happen if a ereport(ERROR) happens in there? Because all that code is pretty careful to not do ereport(ERROR) directly and instead return STATU

Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

* Magnus Hagander wrote: On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote: It seems like this patch should be set "ready for committer". Can one of the reviewers do that if appropriate? I'll pick it up to do that as well as committing it. Ah, good news! I hope it's not coming too la

Re: [HACKERS] [PATCH] Supporting +-Infinity values by to_timestamp(float8)

Anastasia Lubennikova writes: > 17.03.2016 06:27, Vitaly Burovoy: >> Please find attached a new version of the patch. > I think, I should write something as a reviewer. > I read the patch again and I don't see any issues with it. > It applies to the master and works as expected. So I'll mark it a

[HACKERS] [PATCH] Remove TZ entry from postgres CLI doc page.

Hi, Please find attached a patch to the postgres command line documentation page doc/src/sgml/ref/postgres-ref.sgml that removes the "TZ" entry from the "Environment" section. If I've understood it correctly, since ca4af308 TZ can be looked at when you run initdb, but is not looked at when the ser

Re: [HACKERS] incorrect docs for pgbench / skipped transactions

Please split the patch into one part for backporting and one part for master-only and post both patches, clearly indicating which is which. Attached are the full patch for head and the backport part (the patch name ends with "backport") separated. That's not really what I wanted; the full p

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

David Steele writes: > On 3/20/16 12:09 AM, Robbie Harwood wrote: > >> A new version of my GSSAPI encryption patchset is available > > Here's a more thorough review: Thanks for the review! To keep this a manageable size, I'm going to trim pretty heavily. If I haven't replied to something, plea

Re: [HACKERS] Sequence Access Method WIP

On 29/03/16 22:08, Fabrízio de Royes Mello wrote: On Tue, Mar 29, 2016 at 4:59 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: > > On 29/03/16 19:46, Fabrízio de Royes Mello wrotez >> >> >> > >> > Hmm I am unable to reproduce this. What OS? Any special configure >> flags you use?

Re: [HACKERS] Alter or rename enum value

On 03/27/2016 10:20 AM, Tom Lane wrote: Andrew Dunstan writes: The more I think about this the more I bump up against the fact that almost anything we do might want to do to ameliorate the situation is going to be rolled back. The only approach I can think of that doesn't suffer from this is

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

Indeed. The documentation is manually edited when submitting changes so as to minimize diffs, but then it does not correspond anymore to any actual output, so it is easy to do it wrong. Well, you fixed the "latency stddev" line to the sample output too, but in my trial run that line was not di

Re: [HACKERS] raw output from copy

Andrew Dunstan writes: > The I would suggest we try to invent something for psql which does help > with it. I just don't see this as an SQL problem. There's certainly a lot to be said for that approach. I'm still not convinced that we can make COPY do this without creating compatibility issues,

Re: [HACKERS] Parallel Queries and PostGIS

On Tue, Mar 29, 2016 at 1:14 PM, 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 problematic, >>> but I just don't know why it's happen

Re: [HACKERS] Parallel Queries and PostGIS

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 problematic, >> but I just don't know why it's happening. > > What might be a good way to debug it? Is there a pie

Re: [HACKERS] Sequence Access Method WIP

On Tue, Mar 29, 2016 at 4:59 PM, Petr Jelinek wrote: > > On 29/03/16 19:46, Fabrízio de Royes Mello wrotez >> >> >> > >> > Hmm I am unable to reproduce this. What OS? Any special configure >> flags you use? >> > >> >> In my environment the error remains with your last patches. >> >> I didn't us

Re: [HACKERS] Sequence Access Method WIP

On 29/03/16 19:46, Fabrízio de Royes Mello wrotez > > Hmm I am unable to reproduce this. What OS? Any special configure flags you use? > In my environment the error remains with your last patches. I didn't use any special. ./configure --prefix=/home/fabrizio/pgsql --enable-cassert --enable

Re: [HACKERS] raw output from copy

On 03/28/2016 11:18 PM, Pavel Stehule wrote: Anyway this is certainly not committable as-is, so I'm setting it back to Waiting on Author. But the fact that both libpq and ecpg would need updates makes me question whether we can safely pretend that

Re: [HACKERS] Parallel Queries and PostGIS

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, I don't have a >> second guess, but the thing to do would be to figure out whether >> consider_parallel is false for

Re: [HACKERS] Parallel Queries and PostGIS

> First, I beg to differ with this statement: "Some of the execution > results output are wrong! " The point is that > line has loops=4, so as in any other case where loops>1, you're seeing > the number of rows divided by the number of loops. It is the > *average* number of rows that were pro

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

On Tue, Mar 29, 2016 at 9:11 AM, Robert Haas wrote: > One test that kind of bothers me in particular is the "SELECT DISTINCT > a FROM numeric_test ORDER BY a" test on the high_cardinality_random > data set. That's a wash at most work_mem values, but at 32MB it's > more than 3x slower. That's ver

Re: [HACKERS] Parallel Queries and PostGIS

On Mon, Mar 28, 2016 at 12:18 PM, Paul Ramsey wrote: > I spent some time over the weekend trying out the different modes of > parallel query (seq scan, aggregate, join) in combination with PostGIS > and have written up the results here: > > http://blog.cleverelephant.ca/2016/03/parallel-postgis.ht

Re: [HACKERS] raw output from copy

2016-03-29 20:59 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > I am writing few lines as summary: > > > 1. invention RAW_TEXT and RAW_BINARY > > 2. for RAW_BINARY: PQbinaryTuples() returns 1 and PQfformat() returns 1 > > 3.a for RAW_TEXT: PQbinaryTuples() returns 0 and PQfformat() returns 0, >

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

Fabien COELHO wrote: > > Hello, > > >>In doing this, I noticed that the latency output is wrong if you use -T > >>instead of -t; it always says the latency is zero because "duration" is > >>zero. I suppose it should be like in the attached instead. > > Indeed, I clearly overlooked option -t (tr

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

Hello, In doing this, I noticed that the latency output is wrong if you use -T instead of -t; it always says the latency is zero because "duration" is zero. I suppose it should be like in the attached instead. Indeed, I clearly overlooked option -t (transactions) which I never use. Patch a

Re: [HACKERS] Parallel Queries and PostGIS

On Mon, Mar 28, 2016 at 9:18 AM, Paul Ramsey wrote: > Parallel join would be a huge win, so some help/pointers on figuring > out why it's not coming into play when our gist operators are in > effect would be helpful. Robert, do you have any pointers on what I should look for to figure out why th

Re: [HACKERS] raw output from copy

Pavel Stehule writes: > I am writing few lines as summary: > 1. invention RAW_TEXT and RAW_BINARY > 2. for RAW_BINARY: PQbinaryTuples() returns 1 and PQfformat() returns 1 > 3.a for RAW_TEXT: PQbinaryTuples() returns 0 and PQfformat() returns 0, but > the client should to check PQcopyFormat() to

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

I tried to whip this into shape, but there were a few areas I didn't feel I had the necessary understanding to feel comfortable taking on the committer role for it. I've cleaned it up the best I could, fixing whitespace and typos, eliminating an unnecessary addition of an include, improving C comm

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-29 14:09:42 -0400, Tom Lane wrote: > Andres Freund writes: > > There's actually lbarx/stbcx - but it's not present in all ISAs. So I > > guess it's clear where to go. > > Hm. We could certainly add a configure test to see if the local assembler > knows these instructions --- but it's

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Andres Freund writes: > On 2016-03-29 13:24:40 -0400, Tom Lane wrote: >> AFAICS, lwarx/stwcx are specifically *word* wide. > There's actually lbarx/stbcx - but it's not present in all ISAs. So I > guess it's clear where to go. Hm. We could certainly add a configure test to see if the local asse

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

On Tue, Mar 29, 2016 at 6:40 PM, Magnus Hagander wrote: > > > On Tue, Mar 29, 2016 at 4:36 PM, David Steele wrote: > >> On 3/22/16 12:31 PM, Magnus Hagander wrote: >> >> On Tue, Mar 22, 2016 at 5:27 PM, David Steele >> > wrote: >>> >> > >> >>> > Adding the stop ti

Re: [HACKERS] incorrect docs for pgbench / skipped transactions

On Mon, Mar 21, 2016 at 2:32 PM, Fabien COELHO wrote: >>> Ok, I added a reference to the commitfest entry from this wiki page, and >>> a >>> note about partial 9.5 backporting. >> >> Please split the patch into one part for backporting and one part for >> master-only and post both patches, clearly

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

Alvaro Herrera wrote: > In doing this, I noticed that the latency output is wrong if you use -T > instead of -t; it always says the latency is zero because "duration" is > zero. I suppose it should be like in the attached instead. At the same > time, it says "latency average: XYZ" instead of "la

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

Fabien COELHO wrote: > > >- that it does work:-) I'm not sure what happens by the script selection > > process, it should be checked carefully because it was not designed > > with allowing a zero weight, and it may depend on its/their positions. > > It may already work, but it really needs chec

Re: [HACKERS] pgbench - show weight percent

Fabien wrote: > > This minor patch shows the expected drawing percent in multi-script reports, > next to the relative weight. Applied together with the zero weight. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Service

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-29 20:22:00 +0300, Alexander Korotkov wrote: > > > + while (true) > > > { > > > - if (buf->usage_count == 0) > > > - buf->usage_count = 1; > > > + /* spin-wait till lock is free */ > > > +

Re: [HACKERS] Sequence Access Method WIP

On Tue, Mar 29, 2016 at 2:26 PM, Petr Jelinek wrote: > > On 29/03/16 18:50, Fabrízio de Royes Mello wrote: >> >> >> >> On Tue, Mar 29, 2016 at 12:25 PM, David Steele > > wrote: >> > >> > Hi Petr, >> > >> > On 3/28/16 3:11 PM, Fabrízio de Royes Mello wrote: >> > >>

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-29 13:24:40 -0400, Tom Lane wrote: > Andres Freund writes: > > Dilip, could you test performance of reducing ppc's spinlock to 1 byte? > > Cross-compiling suggest that doing so "just works". I.e. replace the > > #if defined(__ppc__) typedef from an int to a char. > > AFAICS, lwarx/stw

Re: [HACKERS] WIP: Access method extendability

On Tue, Mar 29, 2016 at 8:29 PM, Teodor Sigaev wrote: > I incorporated your changes and did some additional refinements on top of >> them >> still. >> >> Attached is delta against v12, that should cause less issues when merging >> for >> Teodor. >> > > But last version is 13th? > > BTW, it would

Re: [HACKERS] WIP: Access method extendability

On 29/03/16 19:29, Teodor Sigaev wrote: I incorporated your changes and did some additional refinements on top of them still. Attached is delta against v12, that should cause less issues when merging for Teodor. But last version is 13th? No, 12 is last version from Alexander afaics, I named

Re: [HACKERS] Relation extension scalability

On Tue, Mar 29, 2016 at 2:09 PM, Dilip Kumar wrote: > > Attaching new version v18 - Some cleanup work on v17. - Improved *UpdateFreeSpaceMap *function. - Performance and space utilization are same as V17 -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com multi_extend_v18.pat

Re: [HACKERS] WIP: Access method extendability

I incorporated your changes and did some additional refinements on top of them still. Attached is delta against v12, that should cause less issues when merging for Teodor. But last version is 13th? BTW, it would be cool to add odcs in VII. Internals chapter, description should be similar to i

Re: [HACKERS] raw output from copy

Hi 2016-03-29 18:19 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > I tested COPY RAW on old psql clients - and it is working without any > > problem - so when the client uses same logic as psql, then it should to > > work. Sure, there can be differently implemented clients, but the COPY > > cl

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

On Mon, Mar 28, 2016 at 11:00 PM, Kouhei Kaigai wrote: >> -Original Message- >> From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas >> Sent: Tuesday, March 29, 2016 10:54 AM >> To: Kaigai Kouhei(海外 浩平) >> Cc: Petr Jelinek; pgsql-

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Andres Freund writes: > Dilip, could you test performance of reducing ppc's spinlock to 1 byte? > Cross-compiling suggest that doing so "just works". I.e. replace the > #if defined(__ppc__) typedef from an int to a char. AFAICS, lwarx/stwcx are specifically *word* wide.

[HACKERS] Pg-Logical output pkg; can't install 9.4 and 9.5 on same Wheezy box

Hackers, please see below. Posted on Admin and then General but not sure anyone of authority has noticed. Briefly, conflicting files in an include directory prevent 9.4/9.5 installed on same host instance. Thanks - Posted to Admin a few days ago... I'll try here next before going to Hac

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-29 13:09:05 -0400, Robert Haas wrote: > On Mon, Mar 28, 2016 at 9:09 AM, Andres Freund wrote: > > On 2016-03-28 11:48:46 +0530, Dilip Kumar wrote: > >> On Sun, Mar 27, 2016 at 5:48 PM, Andres Freund wrote: > >> > What's sizeof(BufferDesc) after applying these patches? It should better

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Andres Freund writes: > There's a number of cases during early startup/auth where we really > don't want client to get messages. Right, which we handle at present with ClientAuthInProgress. But I think it's worth drawing a distinction between "don't send message to client because of the state we

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Mar 28, 2016 at 9:09 AM, Andres Freund wrote: > On 2016-03-28 11:48:46 +0530, Dilip Kumar wrote: >> On Sun, Mar 27, 2016 at 5:48 PM, Andres Freund wrote: >> > What's sizeof(BufferDesc) after applying these patches? It should better >> > be <= 64... >> > >> >> It is 72. > > Ah yes, miscalc

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 2016-03-29 12:58:22 -0400, Tom Lane wrote: > Looking back at the earlier thread Andres mentioned, I see that he was > specifically on about being able to do ereport(ERROR | LOG_NO_CLIENT), > which I've got a problem with because of the point about not breaking > wire-protocol expectations. Yes.

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On Tue, Mar 29, 2016 at 12:58 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: >>> If we invent LOG_ONLY (feel free to bikeshed the name), we could later >>> redefine it as (LOG | ERR_HIDE_FROM_CLIENT), if we ever upgrade the >>> underlying implement

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Tue, Mar 29, 2016 at 3:17 AM, Michael Paquier wrote: > OK, so I am switching this patch as "Ready for committer", for 0001. > It is in better shape now. Well... I have a few questions yet. The new argument to SyncRepWaitForLSN is called "bool commit", but RecordTransactionAbortPrepared passe

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Robert Haas writes: > On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: >> If we invent LOG_ONLY (feel free to bikeshed the name), we could later >> redefine it as (LOG | ERR_HIDE_FROM_CLIENT), if we ever upgrade the >> underlying implementation to allow that. But I remain concerned about >> dea

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

Robert Haas wrote: > Yeah, I think it's dead certain that such code exists, and, ahem, not > only in our tree. I suspect that EDB is not the only organization > that has written code that involves comparing error levels. Putting > the flags in the low-order bits seems like it might be workable,

Re: [HACKERS] WIP: Access method extendability

On 29/03/16 18:25, Alvaro Herrera wrote: + /*- >+ * API for construction of generic xlog records >+ * >+ * This API allows user to construct generic xlog records which describe >+ * difference between pages in a generic w

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-03-29 12:28:40 -0400, Tom Lane wrote: >>> My proposal would be to invent a new elevel macro, maybe LOG_ONLY, >>> for this purpose. But under the hood it'd be the same as COMMERROR. > >> A couple years back I pro

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

[This is a rather informal user-review] Here are some thoughts and experiences on using the new features, I focused on testing the basic funcionality of setting password_encryption to scram and then generating some users with passwords. After that, I took a look at the documentation, s

  1   2   >