Re: [HACKERS] One process per session lack of sharing

2016-07-15 11:29 GMT+02:00 : > Hi > > > Is there any plan to implement "session per thread" or "shared > sessions between thread"? > > > > I'm personally not absolutely opposed to threading, but you'll find > > it hard to convince anyone it's worth the huge

[HACKERS] Re: [HACKERS] [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

>I don't really see anything suspicious in the profile. This looks more >like a kernel scheduler issue than a postgres bottleneck one. It seems >that somehow using nonblocking IO (started in 9.5) causes scheduling >issues when pgbouncer is also local. > >Could you do perf stat -ddd -a sleep 10

Re: [HACKERS] One process per session lack of sharing

Hi Is there any plan to implement "session per thread" or "shared sessions between thread"? > I'm personally not absolutely opposed to threading, but you'll find > it hard to convince anyone it's worth the huge work required to > ensure that everything in PostgreSQL is done

Re: [HACKERS] One process per session lack of sharing

Hi > I disagree - there is lot of possible targets with much higher > benefits - columns storage, effective execution - compiled > execution, implementation of temporal databases, better support for > dynamic structures, better support for XML, JSON, integration of connection > pooling, ... Off

Re: [HACKERS] One process per session lack of sharing

On 15 July 2016 at 18:05, Pavel Stehule wrote: > There is only few use cases - mostly related to Oracle emulation when > multi threading is necessary - and few can be solved better - PLpgSQL to C > compilation and similar techniques. > > Right. If amatveev (username,

Re: [HACKERS] BUG #14245: Segfault on weird to_tsquery

The above-described topic is currently a PostgreSQL 9.6 open item. Teodor, I'm working on it now and believe that fix will be published today. since you committed the patch believed to have created it, you own this open item. If some other commit is more relevant or if this does not belong

Re: [HACKERS] One process per session lack of sharing

2016-07-15 12:20 GMT+02:00 : > Hi > > > > I disagree - there is lot of possible targets with much higher > > benefits - columns storage, effective execution - compiled > > execution, implementation of temporal databases, better support for > > dynamic structures, better support

Re: [HACKERS] Documentation fix for CREATE FUNCTION

Tom Lane wrote: > Albe Laurenz writes: >> I just noticed that the documentation for CREATE FUNCTION still mentions >> that the temporary namespace is searched for functions even though that >> has been removed with commit aa27977. > > The example you propose to correct

Re: [HACKERS] One process per session lack of sharing

On 14 July 2016 at 16:41, wrote: > Hi > > > On Tue, Jul 12, 2016 at 9:18 AM, Tom Lane wrote: > >> amatv...@bitec.ru writes: > >>> Is there any plan to implement "session per thread" or "shared > >>> sessions between thread"? > >>... > >> so > >>

Re: [HACKERS] One process per session lack of sharing

2016-07-15 13:25 GMT+02:00 : > Hi > > > > Can be nice, if we can help to all Oracle users - but it is not > > possible in this world :( - there is lot of barriers - threading is > > only one, second should be different design of PL/SQL - it is based > > on out processed, next

Re: [HACKERS] sslmode=require fallback

Magnus Hagander writes: > The entire "prefer" mode is a design flaw, that we unfortunately picked as > default mode. > ... > If you care about encryption, you should pick something else > (require/verify). If you don't care about encryption, you should pick > something else

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

On 2016/07/15 11:48, Tom Lane wrote: Etsuro Fujita writes: One thing I'm not sure about is: should we insist that a join can be pushed down only if the checkAsUser fields of the relevant RTEs are equal in the case where user mappings are meaningless to the FDW,

Re: [HACKERS] One process per session lack of sharing

2016-07-15 14:54 GMT+02:00 : > Hi > > > > but parallel processing doesn't requires threading support - see > PostgreSQL 9.6 features. > > To share dynamic execution code between threads much more easy(If > sharing this code between process is possible). > There is many

Re: [HACKERS] One process per session lack of sharing

Hi > but parallel processing doesn't requires threading support - see PostgreSQL > 9.6 features. To share dynamic execution code between threads much more easy(If sharing this code between process is possible). There is many other interaction techniques between threads which is

Re: [HACKERS] One process per session lack of sharing

Hi > This is true, only when data are immutable and in memory. Elsewhere it is > false idea. For case whenthe server works 24x7 and you need ability to fix bugs(or update) on the fly in any app code. It's usual. -- Sent via pgsql-hackers mailing list

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

On Thu, Jul 7, 2016 at 7:51 AM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> > I'm not sure how common a build without openssl is in the real world >> > though. >> > RPMs, DEBs, Windows installers etc all build with OpenSSL. But we probably

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

Etsuro Fujita writes: > On 2016/07/15 11:48, Tom Lane wrote: >> If we add a mechanism to let us know that the FDW doesn't care, we could >> relax the requirement for such cases. I don't have a strong opinion on >> whether that's worthwhile. It'd depend in part on

Re: [HACKERS] Regression tests vs existing users in an installation

Tom Lane wrote: > We've talked before about how the regression tests should be circumspect > about what role names they create/drop, so as to avoid possibly blowing > up an installation's existing users during "make installcheck". In > particular I believe there was consensus that such names

Re: [HACKERS] sslmode=require fallback

On 14.07.2016 23:34, Magnus Hagander wrote: On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane > wrote: Greg Stark > writes: > Well what's required to "configure SSL" anyways? If you don't have > verify-ca

Re: [HACKERS] One process per session lack of sharing

Hi > Can be nice, if we can help to all Oracle users - but it is not > possible in this world :( - there is lot of barriers - threading is > only one, second should be different design of PL/SQL - it is based > on out processed, next can be libraries, JAVA integration, and lot > of others. I

Re: [HACKERS] One process per session lack of sharing

Hi > If amatveev (username, unsure of full name) wants to improve > PL/PgSQL performance and the ability of a JVM to share resources > between backends, then it would be more productive to focus on that than on > threading. Note, I've statred this post with

Re: [HACKERS] pgbench - allow to store select results into variables

Hello again, I'd be okay with SELECT 1, 2 \into one two SELECT 3 \into three Here is a v2 with more or less this approach, although \into does not end the query, but applies to the current or last sql command. A query is still terminated with a ";". Now it handles things like : --

Re: [HACKERS] One process per session lack of sharing

On 15/07/2016 09:28, Craig Ringer wrote: I don't think anyone's considering moving from multi-processing to multi-threading in PostgreSQL. I really, really like the protection that the shared-nothing-by-default process model gives us, among other things. As I understand it, the main issue is

Re: [HACKERS] One process per session lack of sharing

2016-07-15 18:43 GMT+02:00 james : > On 15/07/2016 09:28, Craig Ringer wrote: > >> I don't think anyone's considering moving from multi-processing to >> multi-threading in PostgreSQL. I really, really like the protection that >> the shared-nothing-by-default process

Re: [HACKERS] \timing interval

Peter Eisentraut writes: > On 7/13/16 2:06 PM, Corey Huinker wrote: >> Time: 3601083.544 ms (1h 0m 1.084s) > That works for me, except that the abbreviation for minute is "min". Meh ... if we're using one-letter abbreviations for hour and second, using three

[HACKERS] Version number for pg_control

While researching a pgsql-general question, I noticed that commit 73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields to pg_control without bothering to touch PG_CONTROL_VERSION. Thus, PG_CONTROL_VERSION is still "942" even though the file contents are not at all compatible with

Re: [HACKERS] \timing interval

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > On 7/13/16 2:06 PM, Corey Huinker wrote: > >> Time: 3601083.544 ms (1h 0m 1.084s) > > > That works for me, except that the abbreviation for minute is "min". > > Meh ... if we're using

Re: [HACKERS] Documentation fix for CREATE FUNCTION

Albe Laurenz writes: > Tom Lane wrote: >> I believe the reason for forcing pg_temp to the back of the path is to >> prevent unqualified table names from being captured by pg_temp entries. >> This risk exists despite the rule against searching pg_temp for functions >> or

Re: [HACKERS] \timing interval

On 7/13/16 2:06 PM, Corey Huinker wrote: > Time: 71041.022 ms (1m 11.041s) > pg_sleep > -- > > (1 row) > > Time: 3601083.544 ms (1h 0m 1.084s) > pg_sleep > -- > > (1 row) That works for me, except that the abbreviation for minute is "min". -- Peter Eisentraut

Re: [HACKERS] One process per session lack of sharing

2016-07-15 19:57 GMT+02:00 Матвеев Алексей : > Hi > > >What I know about Oracle, PL/SQL, Java - all is executed as outprocess > calls. I am sure, so PL doesn't share process with SQL engine there > > You are highly not correct. > Sorry, I will answer more when i come to

Re: [HACKERS] One process per session lack of sharing

Hi >What I know about Oracle, PL/SQL, Java - all is executed as outprocess calls. >I am sure, so PL doesn't share process with SQL engine there You are highly not correct. Sorry, I will answer more when i come to work. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] sslmode=require fallback

On 07/15/2016 09:55 AM, Tom Lane wrote: I'm inclined to think that a better answer than changing libpq's behavior is to encourage DBAs to specify "hostssl" in pg_hba.conf for all external connections. Do those packagers who install dummy certificates and turn SSL on also change their

[HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

Hi, While validating my patch for http://archives.postgresql.org/message-id/20160714060607.klwgq2qr7egt3zrr%40alap3.anarazel.de I noticed that the standby's infomask still had HEAP_XMAX_INVALID set after replaying a XLOG_HEAP_LOCK record. That's bad, but not really commonly fatal, because

Re: [HACKERS] dumping database privileges broken in 9.6

* Noah Misch (n...@leadboat.com) wrote: > On Sat, Jul 09, 2016 at 12:55:33AM -0400, Stephen Frost wrote: > > * Noah Misch (n...@leadboat.com) wrote: > > > This PostgreSQL 9.6 open item is past due for your status update. Kindly > > > send > > > a status update within 24 hours, and include a date

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

I wrote: > Etsuro Fujita writes: >> Here is a patch for that redesign proposed by you; reverts commits >> fbe5a3fb73102c2cfec114a67943f4474383 and >> 5d4171d1c70edfe3e9be1de9e66603af28e3afe1, adds changes for that redesign >> to the core, and adjusts the

Re: [HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

Andres Freund wrote: > While validating my patch for > http://archives.postgresql.org/message-id/20160714060607.klwgq2qr7egt3zrr%40alap3.anarazel.de > I noticed that the standby's infomask still had HEAP_XMAX_INVALID set > after replaying a XLOG_HEAP_LOCK record. > > That's bad, but not really

Re: [HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

On 2016-07-15 17:43:44 -0400, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2016-07-15 17:23:57 -0400, Alvaro Herrera wrote: > > > > Maybe we should change fix_infomask_from_infobits() to reset > > > HEAP_XMAX_BITS | HEAP_MOVED too (and HEAP_KEYS_UPDATED I suppose), to > > > avoid doing it

Re: [HACKERS] Version number for pg_control

David Steele writes: > +1 for changing it. However, I don't think it's such a big deal since > each version since 8.3 (at least) has had a unique catalog version. > Maybe this would affect pg_controldata or other supporting utilities but > the server itself should not be

Re: [HACKERS] Version number for pg_control

On 7/15/16 6:13 PM, Alvaro Herrera wrote: > David Steele wrote: >> On 7/15/16 5:47 PM, Alvaro Herrera wrote: > >>> I can't quite make up my mind about it. It seems pointless to change >>> it now, but at the same time it seems wrong to let it continue to be >>> unchanged from 9.4. >>> >>> I

Re: [HACKERS] Version number for pg_control

Tom Lane wrote: > While researching a pgsql-general question, I noticed that commit > 73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields > to pg_control without bothering to touch PG_CONTROL_VERSION. Thus, > PG_CONTROL_VERSION is still "942" even though the file contents > are not

[HACKERS] Regression tests vs existing users in an installation

We've talked before about how the regression tests should be circumspect about what role names they create/drop, so as to avoid possibly blowing up an installation's existing users during "make installcheck". In particular I believe there was consensus that such names should begin with, or at

Re: [HACKERS] Version number for pg_control

David Steele wrote: > On 7/15/16 5:47 PM, Alvaro Herrera wrote: > > I can't quite make up my mind about it. It seems pointless to change > > it now, but at the same time it seems wrong to let it continue to be > > unchanged from 9.4. > > > > I slightly lean towards changing it in 9.6. > > +1

Re: [HACKERS] Version number for pg_control

On 7/15/16 5:47 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> While researching a pgsql-general question, I noticed that commit >> 73c986adde5d73a5e2555da9b5c8facedb146dcd added several new fields >> to pg_control without bothering to touch PG_CONTROL_VERSION. Thus, >> PG_CONTROL_VERSION is

Re: [HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

On 2016-07-15 17:23:57 -0400, Alvaro Herrera wrote: > Andres Freund wrote: > > > While validating my patch for > > http://archives.postgresql.org/message-id/20160714060607.klwgq2qr7egt3zrr%40alap3.anarazel.de > > I noticed that the standby's infomask still had HEAP_XMAX_INVALID set > > after

Re: [HACKERS] heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

Andres Freund wrote: > On 2016-07-15 17:23:57 -0400, Alvaro Herrera wrote: > > Maybe we should change fix_infomask_from_infobits() to reset > > HEAP_XMAX_BITS | HEAP_MOVED too (and HEAP_KEYS_UPDATED I suppose), to > > avoid doing it in each callsite. > > Yea, I was thinking of that as well. But

Re: [HACKERS] Version number for pg_control

I wrote: > David Steele writes: >> Maybe this would affect pg_controldata or other supporting utilities but >> the server itself should not be affected since it also checks the >> catalog version. > Right, that version number exists mostly for the benefit of pg_controldata >

Re: [HACKERS] Reviewing freeze map code

On 2016-07-14 20:53:07 -0700, Andres Freund wrote: > On 2016-07-13 23:06:07 -0700, Andres Freund wrote: > > won't enter the branch, because HEAP_XMAX_LOCK_ONLY won't be set. Which > > will leave t_ctid and HEAP_HOT_UPDATED set differently on the master and > > standby / after crash recovery.

[HACKERS] visibilitymap_clear()s in vacuumlazy.c aren't WAL logged

Hi, The $subject says it all. Am I missing something, or is that not ok? Now, these branches should never be hit, but it surely isn't good that the corruption will persist on a primary, after it's explicitly been fixed on the standby. Greetings, Andres Freund -- Sent via pgsql-hackers

Re: [HACKERS] Reviewing freeze map code

On 2016-07-13 23:06:07 -0700, Andres Freund wrote: > > + /* Clear only the all-frozen bit on visibility map if needed */ > > + if (PageIsAllVisible(BufferGetPage(buffer)) && > > + VM_ALL_FROZEN(relation, block, )) > > + { > > +

Re: [HACKERS] dumping database privileges broken in 9.6

On Sat, Jul 09, 2016 at 12:55:33AM -0400, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: > > This PostgreSQL 9.6 open item is past due for your status update. Kindly > > send > > a status update within 24 hours, and include a date for your subsequent > > status > > update.

[HACKERS] Re: Document that vacuum can't truncate if old_snapshot_threshold >= 0

On Wed, Jul 13, 2016 at 02:14:06PM -0700, Andres Freund wrote: > That appears to not be mentioned in a comment, the commit message or the > the docs. I think this definitely needs to be prominently documented. [Action required within 72 hours. This is a generic notification.] The

Re: [HACKERS] BUG #14245: Segfault on weird to_tsquery

On Tue, Jul 12, 2016 at 05:11:32PM -0400, Tom Lane wrote: > David Kellum writes: > > On Tue, Jul 12, 2016 at 12:42 PM, Tom Lane wrote: > >> Note that while crashing is certainly not good, the pre-9.6 behavior > >> can hardly be called correct either.

Re: [HACKERS] sslmode=require fallback

On Fri, Jul 15, 2016 at 5:10 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 7/13/16 4:11 PM, Robert Haas wrote: > > On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander > wrote: > >> You would think so. > >> > >> The default mode of "prefer" is ridiculous