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

On Apr 8, 2016 1:13 AM, "Tom Lane" wrote: > > Magnus Hagander writes: > > On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote: > >> Magnus, do you intend to commit the patch before the feature freeze? > > > It's on my list of things

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 11:43 PM, Fujii Masao wrote: > On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier > wrote: >> On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier >> wrote: >>> Here are few things I have noticed: >>> +

Re: [HACKERS] Choosing parallel_degree

On Wed, Apr 6, 2016 at 10:49 PM, Julien Rouhaud wrote: > > On 06/04/2016 07:38, Amit Kapila wrote: > > On Tue, Apr 5, 2016 at 11:55 PM, Julien Rouhaud > >> > >> In alter_table.sgml, I didn't comment the lock level needed to modify > >> parallel_degree since it requires

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Tue, Apr 05, 2016 at 03:22:03PM +0900, Etsuro Fujita wrote: > On 2016/04/04 20:35, Michael Paquier wrote: > >On Mon, Apr 4, 2016 at 7:49 PM, Etsuro Fujita > > wrote: > >>Here is a patch to fix this issue. As proposed by Michael, I modified > >>execute_dml_stmt so

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Apr 8, 2016 at 12:55 PM, Thomas Munro wrote: > On Wed, Apr 6, 2016 at 8:23 PM, Fujii Masao wrote: >> >> Okay, I pushed the patch! >> Many thanks to all involved in the development of this feature! > > > Hi, > > I spotted a couple of

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 8:23 PM, Fujii Masao wrote: > > Okay, I pushed the patch! > Many thanks to all involved in the development of this feature! > Hi, I spotted a couple of places in the documentation that still implied there was only one synchronous standby. Please

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

On Thu, Apr 7, 2016 at 11:10 AM, Robert Haas wrote: > I prefer units of tuples, with the GUC itself therefore being > unitless. I suggest we call the parameter replacement_sort_threshold > and document that (1) the ideal value may depend on the amount of CPU > cache

Re: [HACKERS] Timeline following for logical slots

On 7 April 2016 at 23:32, Robert Haas wrote: > > Yeah. I understand the reasons for that decision. Per an earlier reply I > > think we can avoid making them WAL-logged so they can be used on standbys > > and still achieve usable failover support on physical replicas. > >

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

On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote: > Robbie Harwood writes: >> Tom Lane writes: >>> Wait a second. So the initial connection-request packet is necessarily >>> unencrypted under this scheme? > >> Yes, by necessity. The

Re: [HACKERS] Fix for OpenSSL error queue bug

On Fri, Apr 8, 2016 at 10:23 AM, Peter Eisentraut wrote: > On 04/07/2016 03:47 AM, Michael Paquier wrote: >> >> I have looked at this patch. Do we need to worry as well about >> SSL_shutdown in disconnection code path? I believe that we don't care >> much if an error happens at

Re: [HACKERS] Fix for OpenSSL error queue bug

On Thu, Apr 7, 2016 at 6:08 PM, Peter Eisentraut wrote: > I wish we could avoid the huge, repeated comment blocks. Perhaps we could > put them at the top of the files once? I'm fine with that. Do you want to take care of that, or should I? > Also, why do you write 0UL instead

Re: [HACKERS] Fix for OpenSSL error queue bug

On 04/07/2016 03:47 AM, Michael Paquier wrote: I have looked at this patch. Do we need to worry as well about SSL_shutdown in disconnection code path? I believe that we don't care much if an error happens at this point but we surely should consume any error generated because the SSL context is

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

On Fri, Apr 8, 2016 at 9:29 AM, Andrew Dunstan wrote: > Not out of the woods yet. Attached is what I got from VS2015 on a fresh W10 > VM, with Michael's patch 0002 and 0004 applied. Interesting, I have no idea what we are doing differently, and seeing those errors it seems

Re: [HACKERS] Fix for OpenSSL error queue bug

On 03/14/2016 09:44 PM, Peter Geoghegan wrote: On Mon, Mar 14, 2016 at 4:11 PM, Peter Geoghegan wrote: Yes, with one small difference: I wouldn't be calling ERR_get_error() in the common case where SSL_get_error() returns SSL_ERROR_NONE, on the theory that skipping that case

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

On Thu, Apr 7, 2016 at 4:33 PM, Tom Lane wrote: > Jeff Janes writes: >> To summarize the behavior change: > >> In the released code, an inserting backend that violates the pending >> list limit will try to clean the list, even if it is already being >>

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

On 04/06/2016 04:50 PM, Andrew Dunstan wrote: On 03/29/2016 09:38 PM, Robert Haas wrote: 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

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

I wrote: > Alvaro Herrera writes: >> FWIW the feature freeze rules state that it is allowed for a committer >> to request an extension to the feature freeze date for individual >> patches: >>

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

Jeff Janes writes: > To summarize the behavior change: > In the released code, an inserting backend that violates the pending > list limit will try to clean the list, even if it is already being > cleaned. It won't accomplish anything useful, but will go through the >

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

Magnus Hagander writes: > On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote: >> Magnus, do you intend to commit the patch before the feature freeze? > It's on my list of things to work on this weekend, yeah. But the stated feature freeze deadline is

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

On Thu, Apr 7, 2016 at 3:56 PM, Kevin Grittner wrote: >> Unfortunately, this does stop recycling from >> happening early for B-Tree pages, even though that's probably safe in >> principle. This is probably not so bad -- it just needs to be >> considered when reviewing this

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Daniel Verite wrote: > > * In the "if (cont.cells[idx] != NULL && cont.cells[idx][0] != '\0')" > > block (line 497 in the attached), can't we do the same thing by using > > psprintf? > > In that block, we can't pass a cell contents as a valist and be done with > that cell, because duplicates of

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

On Mon, Apr 4, 2016 at 9:15 PM, Peter Geoghegan wrote: > The patch does this: > >> --- a/src/backend/access/heap/pruneheap.c >> +++ b/src/backend/access/heap/pruneheap.c >> @@ -92,12 +92,21 @@ heap_page_prune_opt(Relation relation, Buffer buffer) >> * need to use the

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

On Sun, Apr 3, 2016 at 4:09 PM, Jeff Janes wrote: > On Wed, Mar 30, 2016 at 12:34 PM, Kevin Grittner wrote: >> On Sat, Mar 19, 2016 at 1:27 AM, Jeff Janes wrote: >>> I set the value to 1min. >>> >>> I set up a test like this: >>>

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

Jeff Janes wrote: > The proposed change removes that throttle, so that inserters will > immediately see there is already a cleaner and just go back about > their business. Due to that, unthrottled backends could add to the > pending list faster than the cleaner can clean it, leading to >

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

On Thu, Apr 7, 2016 at 11:10 AM, Robert Haas wrote: > I prefer units of tuples, with the GUC itself therefore being > unitless. I suggest we call the parameter replacement_sort_threshold > and document that (1) the ideal value may depend on the amount of CPU > cache

Re: [HACKERS] GIN data corruption bug(s) in 9.6devel

On Wed, Apr 6, 2016 at 9:52 AM, Teodor Sigaev wrote: > I'm inclining to push v3.1 as one of two winners by size/performance and, > unlike to pending lock patch, it doesn't change an internal logic of lock > machinery. This restricts the memory used by ordinary backends when

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On Thu, Apr 7, 2016 at 1:26 PM, Alvaro Herrera wrote: > I wonder if the business of appending values of multiple columns > separated with spaces is doing us any good. Why not require that > there's a single column in the cell? If the user wants to put things >

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: > Daniel Verite wrote: > > > * A few examples in docs. The psql manpage should have at least two new > > > examples showing the crosstab features, one with the simplest case you > > > can think of, and another one showing all the features. > > > > Added that in the

Re: [HACKERS] Default Roles

On 04/07/2016 09:50 PM, Stephen Frost wrote: Robert, José, I've rebased this on top of master and added a few additional checks and regression tests. Applies and compiles cleanly, of course. Passes all 164 tests, too. - make installcheck-world ok - interdiff checked, nothing very surprising

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

I wonder if the business of appending values of multiple columns separated with spaces is doing us any good. Why not require that there's a single column in the cell? If the user wants to put things together, they can use format() or just || the fields together. What benefit is there to the '

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

On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote: > > * 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

Re: [HACKERS] Default Roles

Robert, José, I've rebased this on top of master and added a few additional checks and regression tests. I'm planning to continue going over the patch tomorrow morning with plans to push this before the feature freeze deadline. Thanks! Stephen From a0724d91ffd1a93034d5b5d5df2b4ff54339d763 Mon

[HACKERS] if (!superuser) checks

All, Andres, Now that we have begun removing the if (!superuser) checks and instead relying on the GRANT system to determine who is allowed to call certain functions, it's time to consider functions beyond the initial set. In particular, the pg_logical_* functions have superuser checks and those

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Daniel Verite wrote: > > regression=# select * from pg_class \crosstabview relnatts > > \crosstabview: missing second argument > > regression-# > > Fixed. This was modelled after the behavior of: > select 1 \badcommand > but I've changed to mimic what happens with: > select 1 \g

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

Alvaro Herrera writes: > Tom Lane wrote: >> I don't know if you have time to look at this now --- my clock says it's >> already Friday morning in New Zealand. > FWIW the feature freeze rules state that it is allowed for a committer > to request an extension to the

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. Magnus, do you intend

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

* Petr Jelinek wrote: On 07/04/16 00:50, Michael Paquier wrote: On Thu, Apr 7, 2016 at 7:44 AM, Michael Paquier wrote: On Thu, Apr 7, 2016 at 6:11 AM, Petr Jelinek wrote: On 06/04/16 22:50, Andrew Dunstan wrote: * VS2015 appears to

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

Tom Lane wrote: > Anyway, while refactoring the make_join_rel/add_paths_to_joinrel division > of labor wouldn't be such a big deal in itself, I don't want to commit a > change to JoinType only to undo it later; that would be too much churn. > So I think we need to resolve this question before we

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

David Rowley writes: > [ unique_joins_2016-04-07.patch ] Just had a thought about this, which should have crystallized a long time ago perhaps. Where I'd originally imagined you were going with this idea is to do what the thread title actually says, and check for

Re: [HACKERS] Timeline following for logical slots

On 07/04/16 17:32, Robert Haas wrote: Second, I'm not sure whether it was a good design decision to make logical slots a special kind of object that sit off to the side, neither configuration (like postgresql.conf) nor WAL-protected data (like pg_clog and the data files themselves), but it was

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

On Thu, Apr 7, 2016 at 11:05 AM, Robert Haas wrote: > I spent some time today reading through the new 0001 and in general I > think it looks pretty good. Cool. > 1. Changing cost_sort to consider disk access as 90% sequential, 10% > random rather than 75% sequential, 25%

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

On Thu, Apr 7, 2016 at 1:17 PM, Peter Geoghegan wrote: >> I certainly agree that GUCs that aren't easy to tune are bad. I'm >> wondering whether the fact that this one is hard to tune is something >> that can be fixed. The comments about "padding" - a term I don't >> like,

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

On Mon, Mar 21, 2016 at 2:01 AM, Peter Geoghegan wrote: > On Thu, Mar 17, 2016 at 1:13 PM, Robert Haas wrote: >> OK, I have now committed 0001 > > I attach a revision of the external quicksort patch and supplementary > small patches, rebased on top of the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

Peter Eisentraut writes: > On 04/04/2016 09:20 PM, Michael Paquier wrote: >> Likely an oversight not tracked by the buildfarm. What are you using here? > It should be a rather unspectactular Debian system. I have tried a > bunch of different compilers and optimization options,

Re: [HACKERS] Proposal: Generic WAL logical messages

On 07/04/16 12:26, Andres Freund wrote: Hi, On 2016-04-06 20:03:20 +0200, Petr Jelinek wrote: Attached patch adds filtering of both database and origin. Added tests with slightly less hardcoding than what you proposed above. Not a fan of creating & dropping another database - that's really

[HACKERS] Re: [COMMITTERS] pgsql: In pg_dump, include pg_catalog and extension ACLs, if changed

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > It'd be possible to fix (1) by adding "drop if exists", but I think the > whole thing is wrongheaded due to (2). Perhaps the needs of the test > could be met by granting/revoking some rights explicitly to current_user > (ie, the test superuser)?

Re: [HACKERS] [COMMITTERS] pgsql: In pg_dump, include pg_catalog and extension ACLs, if changed

Stephen Frost writes: > In pg_dump, include pg_catalog and extension ACLs, if changed This patch added a regression test step that creates some roles and doesn't drop them again. This is unacceptable, because (1) it breaks the ability to do "make installcheck" more than

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

On Thu, Apr 7, 2016 at 6:55 AM, Robert Haas wrote: >> In reality there will be multiple processes running at the same time (e.g >> backends when running parallel query), significantly reducing the amount of >> cache per process, making the replacement sort inefficient and

Re: [HACKERS] Why the "UPDATE tab SET tab.col" is invalid?

"postgres_sure" writes: > I found "Do not include the table's name in the specification of a target > column > — for example, UPDATE tab SET tab.col = 1 is invalid." in > the documentation. > Some people usually like to update table by alias. They want

Re: [HACKERS] Why the "UPDATE tab SET tab.col" is invalid?

On 7 April 2016 at 16:45, Tom Lane wrote: > Don't know which version of the SQL spec you're looking at, It was the draft 95 version, cos (being text file) it's easiest to read :). I'll learn my lesson next time and expand the 2008 one. > but SQL:2008 has > > ::= > UPDATE

Re: [HACKERS] pg_ctl promote wait

On 04/07/2016 01:22 AM, Michael Paquier wrote: On Wed, Mar 23, 2016 at 1:47 AM, David Steele wrote: On 3/16/16 12:19 PM, David Steele wrote: Hi Peter, On 3/9/16 3:08 PM, Michael Paquier wrote: Here are some comments about 0002 <...> I think that we had better do

Re: [HACKERS] [CommitFest App] Feature request -- review e-mail additions

Magnus Hagander wrote: > On Wed, Mar 30, 2016 at 7:47 PM, Alvaro Herrera > wrote: > > > José Luis Tallón wrote: > > > > > Just wanted to suggest two minor mods to the review e-mails > > > auto-generated by the app: > > > > > > * Prepend a [review] tag to the e-mail

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Thu, Apr 7, 2016 at 8:49 AM, Thomas Munro wrote: > Here is a version that includes an attempt to describe the > situation in the documentation. Pushed with minor adjustments to the docs. Mostly I thought your new text was more appropriate as just another

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

06.04.2016 23:52, Peter Geoghegan: On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote: Personally, I like documenting assertions, and will sometimes write assertions that the compiler could easily optimize away. Maybe going *that* far is more a matter of personal style, but

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

On 04/04/2016 09:20 PM, Michael Paquier wrote: Likely an oversight not tracked by the buildfarm. What are you using here? It should be a rather unspectactular Debian system. I have tried a bunch of different compilers and optimization options, without success. I'll keep looking. -- Sent

Re: [HACKERS] pgbench randomness initialization

Fabien COELHO wrote: > While testing it I had a funny pattern, something like: > > pgbench --random-seed=123 -M prepared -T 3 -P 1 -S > 1.0: 600 tps > 2.0: 600 tps > 3.0: 600 tps The output should include the random seed used, whether it was passed with --random-seed, environment

Re: [HACKERS] Why the "UPDATE tab SET tab.col" is invalid?

Geoff Winkless writes: > I grabbed the wrong section of the doc; I should of course have pasted > the searched version: > ::= > UPDATE > SET > [ WHERE ] > My point is still the same though :) Don't know which version of the

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

On Mon, Apr 4, 2016 at 8:38 PM, Peter Geoghegan wrote: > On Sun, Apr 3, 2016 at 2:09 PM, Jeff Janes wrote: >> Also, HOT-cleanup should stop the bloat increase once the snapshot >> crosses the old_snapshot_threshold without even needing to wait until >> the

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Alvaro Herrera wrote: Thanks for looking into that patch! > regression=# select * from pg_class \crosstabview relnatts > \crosstabview: missing second argument > regression-# Fixed. This was modelled after the behavior of: select 1 \badcommand but I've changed to mimic what happens

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

On Thu, Apr 7, 2016 at 6:48 PM, Andres Freund wrote: > > On 2016-04-07 18:40:14 +0530, Amit Kapila wrote: > > This is the data with -b tpcb-like@1 with 20-min run for each version and I > > could see almost similar results as the data posted in previous e-mail. > > > > Client

Re: [HACKERS] Timeline following for logical slots

On Tue, Apr 5, 2016 at 10:34 PM, Craig Ringer wrote: >> Right, but right now you probably *aren't* do doing any kind of >> logical decoding from a master server to a standby, because there's >> squat in the core distribution that could make use of that capability. >> So you

Re: [HACKERS] Why the "UPDATE tab SET tab.col" is invalid?

On 7 April 2016 at 15:51, I wrote: > ::= > UPDATE > SET > WHERE CURRENT OF I grabbed the wrong section of the doc; I should of course have pasted the searched version: ::= UPDATE SET [ WHERE ]

Re: [HACKERS] Why the "UPDATE tab SET tab.col" is invalid?

On 7 April 2016 at 14:48, Merlin Moncure wrote: > > On Thu, Apr 7, 2016 at 4:39 AM, postgres_sure wrote: > > Hi, > > > > I found "Do not include the table's name in the specification of a target > > column > > — for example, UPDATE tab

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

David Rowley writes: > I've attached an updated patch which introduces JOIN_INNER_UNIQUE and > JOIN_LEFT_UNIQUE. So unique inner joins no longer borrow JOIN_SEMI. OK. > In EXPLAIN, I named these new join types "Unique Inner" and "Unique > Left". Hm. I'm back to

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier wrote: > On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier > wrote: >> Here are few things I have noticed: >> + for (i = 0; i < max_wal_senders; i++) >> + { >> + walsnd = >walsnds[i]; >>

Re: [HACKERS] pgbench randomness initialization

It means that you can't separate between OS caused, and pgbench order caused performance differences. I'm not objecting to adding an option for this; but I think Fabien is right that it shouldn't be the default. Yep. Andres, attached is a simple POC with an option & environment variable

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

Sorry for not responding to this thread again sooner. I was on vacation Thursday-Sunday, and have been playing catch-up since then. On Sun, Apr 3, 2016 at 8:24 AM, Tomas Vondra wrote: > Secondly, master is faster only if there's enough on-CPU cache for the >

Re: [HACKERS] pgbench randomness initialization

On 2016-04-07 09:46:27 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote: > >> So I have no mathematical doubt that changing the seed is the right default > >> setting, thus I think that the current behavior is fine. However

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

On Wed, Apr 6, 2016 at 5:15 PM, Jim Nasby wrote: > On 4/6/16 11:06 AM, Robert Haas wrote: >> This is too late for 9.6 at this point and certainly requires >> discussion anyway, so please add it to the next CommitFest. > > If the goal here is to free up space via

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Thu, Apr 7, 2016 at 4:41 PM, Andres Freund wrote: > On 2016-03-31 20:21:02 +0300, Alexander Korotkov wrote: > > ! BEGIN_BUFSTATE_CAS_LOOP(bufHdr); > > > > ! Assert(BUF_STATE_GET_REFCOUNT(state) > 0); > > ! wasDirty = (state & BM_DIRTY) ? true : false; > > !

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Thu, Apr 7, 2016 at 10:42 PM, Kevin Grittner wrote: > On Thu, Apr 7, 2016 at 3:26 AM, Simon Riggs wrote: > >> We agree its a bug, so the deadline doesn't need to constrain us. > > I'm not sure there is consensus across the community on that. > >> I

Re: [HACKERS] Why the "UPDATE tab SET tab.col" is invalid?

On Thu, Apr 7, 2016 at 4:39 AM, postgres_sure wrote: > Hi, > > I found "Do not include the table's name in the specification of a target > column > — for example, UPDATE tab SET tab.col = 1 is invalid." in > the documentation. > > Some people usually like

Re: [HACKERS] pgbench randomness initialization

Andres Freund writes: > On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote: >> So I have no mathematical doubt that changing the seed is the right default >> setting, thus I think that the current behavior is fine. However I'm okay if >> someone wants to control the randomness

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-31 20:21:02 +0300, Alexander Korotkov wrote: > ! BEGIN_BUFSTATE_CAS_LOOP(bufHdr); > > ! Assert(BUF_STATE_GET_REFCOUNT(state) > 0); > ! wasDirty = (state & BM_DIRTY) ? true : false; > ! state |= BM_DIRTY | BM_JUST_DIRTIED; > ! if (state == oldstate) > !

Re: [HACKERS] pgbench randomness initialization

On Thu, Apr 7, 2016 at 9:15 AM, Andres Freund wrote: > It's not about "covering it up"; it's about actually being able to take > action based on benchmark results, and about practically being able to > run benchmarks. The argument above means essentially that we need to run >

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

On 2016-04-07 18:40:14 +0530, Amit Kapila wrote: > On Thu, Apr 7, 2016 at 10:16 AM, Andres Freund wrote: > > > > Hi, > > > > On 2016-04-07 09:14:00 +0530, Amit Kapila wrote: > > > On Sat, Apr 2, 2016 at 5:25 PM, Amit Kapila > wrote: > > > I have ran

Re: [HACKERS] pgbench randomness initialization

On 2016-04-07 08:58:16 -0400, Robert Haas wrote: > On Thu, Apr 7, 2016 at 5:56 AM, Fabien COELHO wrote: > > I think that it depends on what you want, which may vary: > > > > (1) "exactly" reproducible runs, but one run may hit a particular > > steady state not

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

On Thu, Apr 7, 2016 at 10:16 AM, Andres Freund wrote: > > Hi, > > On 2016-04-07 09:14:00 +0530, Amit Kapila wrote: > > On Sat, Apr 2, 2016 at 5:25 PM, Amit Kapila wrote: > > I have ran exactly same test on intel x86 m/c and the results are as below: >

Re: [HACKERS] pgbench randomness initialization

On Thu, Apr 7, 2016 at 5:56 AM, Fabien COELHO wrote: > I think that it depends on what you want, which may vary: > > (1) "exactly" reproducible runs, but one run may hit a particular > steady state not representative of what happens in general. > > (2) runs which

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

On 7 April 2016 at 12:23, Simon Riggs wrote: > For 0002 > For find_best_foreign_key_quals() how can this ever match 2 FKs with different keys? The fkrel references the foreignrel, which has a single PK. How can the FK have a different number of columns to the PK?

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

Hi, On 04/07/2016 01:23 PM, Simon Riggs wrote: On 7 April 2016 at 00:15, Tomas Vondra > wrote: Right. Fixed. 0001 committed. I added comments and a fastpath when no triggers are present. For 0002, I would be more

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 7:29 PM, Amit Kapila wrote: > On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote > wrote: >> >> On 2016/04/07 15:26, Fujii Masao wrote: >> > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila >> > wrote:

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

On 7 April 2016 at 00:15, Tomas Vondra wrote: > Right. Fixed. 0001 committed. I added comments and a fastpath when no triggers are present. For 0002, I would be more comfortable adding enable_fk_plans = on (true) | off even if we decided to remove that

Re: [HACKERS] pgbench randomness initialization

Hello Andres, If you run the test for longer... Or explicitly iterate over IVs. At the very least we need to make pgbench output the IV used, to have some chance of repeating tests. Note that I'm not against providing a way to repeat tests "exactly", and I have suggested two means:

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Thu, Apr 7, 2016 at 3:26 AM, Simon Riggs wrote: > We agree its a bug, so the deadline doesn't need to constrain us. I'm not sure there is consensus across the community on that. > I suggest we should apply what we have then fix the rest later > when we work out how.

Re: [HACKERS] pgbench randomness initialization

On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote: > > >> (2) runs which really vary from one to the next, so as > >> to have an idea about how much it may vary, what is the > >> performance stability. > > > >I don't think this POV makes all that much sense. If you do something >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote wrote: > > On 2016/04/07 15:26, Fujii Masao wrote: > > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila wrote: > >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote: > >>>

Re: [HACKERS] pgbench randomness initialization

(2) runs which really vary from one to the next, so as to have an idea about how much it may vary, what is the performance stability. I don't think this POV makes all that much sense. If you do something non-comparable, then the results aren't, uh, comparable. Which also means

Re: [HACKERS] Proposal: Generic WAL logical messages

Hi, On 2016-04-06 20:03:20 +0200, Petr Jelinek wrote: > Attached patch adds filtering of both database and origin. Added tests with > slightly less hardcoding than what you proposed above. Not a fan of creating & dropping another database - that's really rather expensive. And we're in a target

Re: [HACKERS] pgbench randomness initialization

On 2016-04-07 11:56:12 +0200, Fabien COELHO wrote: > (2) runs which really vary from one to the next, so as > to have an idea about how much it may vary, what is the > performance stability. I don't think this POV makes all that much sense. If you do something non-comparable, then the

Re: [HACKERS] pgbench randomness initialization

Hello Andres, et al I was wondering why it's a good idea for pgbench to do INSTR_TIME_SET_CURRENT(start_time); srandom((unsigned int) INSTR_TIME_GET_MICROSEC(start_time)); to initialize randomness and then for (i = 0; i < nthreads; i++)

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Hi, On 2016-04-06 21:58:50 -0400, Robert Haas wrote: > I spent a lot of time testing things on power2 today Thanks for that! > It's fairly mysterious to me why there is so much jitter in the > results on this machine. By doing prewarming in a consistent fashion, > we make sure that every disk

[HACKERS] pgbench randomness initialization

Hi, pondering http://archives.postgresql.org/message-id/CA%2BTgmoZJdA6K7-17K4A48rVB0UPR98HVuaNcfNNLrGsdb1uChg%40mail.gmail.com et al I was wondering why it's a good idea for pgbench to do INSTR_TIME_SET_CURRENT(start_time); srandom((unsigned int)

[HACKERS] Why the "UPDATE tab SET tab.col" is invalid?

Hi, I found "Do not include the table's name in the specification of a target column — for example, UPDATE tab SET tab.col = 1 is invalid." in the documentation. Some people usually like to update table by alias. They want to add this feature. So I get the source in the

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

On Thu, Apr 7, 2016 at 2:15 AM, Jim Nasby wrote: > On 4/6/16 11:06 AM, Robert Haas wrote: > >> This is too late for 9.6 at this point and certainly requires >> discussion anyway, so please add it to the next CommitFest. >> > > If the goal here is to free up space via

Re: [HACKERS] Truncating/vacuuming relations on full tablespaces

Thank you Robert. Sure, I will add the updated patch on the next CommitFest with all the suggested changes. On Wed, Apr 6, 2016 at 9:06 PM, Robert Haas wrote: > On Wed, Apr 6, 2016 at 3:32 AM, Asif Naeem wrote: > >> Oh, I see. I think it's probably

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On 7 April 2016 at 08:55, Michael Paquier wrote: > On Sun, Mar 27, 2016 at 8:15 AM, Thomas Munro > wrote: > > Realistically I'm not going to have a solution to the third problem > > before the 31st. > > Ping. > We agree its a bug, so

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2016/04/07 15:26, Fujii Masao wrote: > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila wrote: >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote: >>> Yes if the variable that we'd like to pass to a backend is BOOL, INT, >>> REAL, STRING or ENUM.

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Sun, Mar 27, 2016 at 8:15 AM, Thomas Munro wrote: > Realistically I'm not going to have a solution to the third problem > before the 31st. Ping. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Fix for OpenSSL error queue bug

On Sun, Mar 27, 2016 at 9:01 AM, Tom Lane wrote: > Peter Geoghegan writes: >> Will this make it into the next point release? I was rather hoping it would. > > I dunno. I certainly haven't reviewed it carefully enough to commit it. > Perhaps Peter has, but

  1   2   >