Re: [HACKERS] background sessions

On Thu, Dec 15, 2016 at 12:24 PM, Andrew Borodin wrote: > 2016-12-15 0:30 GMT+05:00 Peter Eisentraut : > TryBeginSession()? What exactly would that do? >>> Return status (success\failure) and session object, if a function

Re: [HACKERS] background sessions

2016-12-15 0:30 GMT+05:00 Peter Eisentraut : TryBeginSession()? >>> >>> What exactly would that do? >> Return status (success\failure) and session object, if a function succeeded. >> >> If there is max_connections exceeded, then (false,null). >> >> I'm not

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

On Tue, Dec 13, 2016 at 2:44 PM, Michael Paquier wrote: > SASLPrep is defined here: > https://tools.ietf.org/html/rfc4013 > And stringprep is here: > https://tools.ietf.org/html/rfc3454 > So that's roughly applying a conversion from the mapping table, taking > into

Re: [HACKERS] Quorum commit for multiple synchronous replication.

At Thu, 15 Dec 2016 14:20:53 +0900, Masahiko Sawada wrote in > On Thu, Dec 15, 2016 at 11:23 AM, Michael Paquier > wrote: > > On Thu, Dec 15, 2016 at 11:04 AM, Fujii Masao

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Dec 15, 2016 at 11:23 AM, Michael Paquier wrote: > On Thu, Dec 15, 2016 at 11:04 AM, Fujii Masao wrote: >> On Thu, Dec 15, 2016 at 6:47 AM, Michael Paquier >> wrote: >>> On Wed, Dec 14, 2016 at 11:34 PM, Fujii

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Dec 15, 2016 at 7:53 AM, Michael Paquier wrote: > On Thu, Dec 15, 2016 at 11:04 AM, Fujii Masao wrote: >> On Thu, Dec 15, 2016 at 6:47 AM, Michael Paquier >> wrote: > >> So I'd like to propose to keep the

Re: [HACKERS] Broken SSL tests in master

On Tue, Dec 13, 2016 at 10:07 PM, Robert Haas wrote: > On Mon, Dec 12, 2016 at 1:34 AM, Heikki Linnakangas wrote: >> On 12/01/2016 09:45 PM, Andres Freund wrote: >>> >>> And nobody has added a buildfarm module to run it manually on their >>> servers either

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi, On 2016-12-12 16:46:38 +0900, Michael Paquier wrote: > Ashutosh, could you try it and see if it improves things? So what's the theory of why this triggers pldebugger hangs, but apparently causes not many other problems? I tried to skim pldebugger code, but it's state isn't very condusive to

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On Wed, Dec 14, 2016 at 10:08 PM, Andres Freund wrote: > On 2016-12-14 22:00:45 -0500, Robert Haas wrote: >> I took a look at Andres's patches today and saw that they can't really >> be applied as-is, because they "temporarily" change the master's >> ParallelWorkerNumber but

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Tue, Dec 13, 2016 at 11:19 AM, Andres Freund wrote: > On 2016-12-12 16:46:38 +0900, Michael Paquier wrote: >> OK, I think that I have spotted an issue after additional read of the >> code. When a WSA event is used for read/write activity on a socket, >> the same WSA event

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Thu, Dec 15, 2016 at 7:48 AM, Michael Paquier wrote: > On Thu, Dec 15, 2016 at 1:18 AM, Robert Haas wrote: >> On Wed, Dec 14, 2016 at 5:35 AM, Ashutosh Sharma >> wrote: I have just read the patch, and hardcoding

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On 2016-12-14 22:00:45 -0500, Robert Haas wrote: > I took a look at Andres's patches today and saw that they can't really > be applied as-is, because they "temporarily" change the master's > ParallelWorkerNumber but have no provision for restoring it after an > ERROR. Yea, that's not quite right.

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On Thu, Dec 8, 2016 at 5:23 PM, Robert Haas wrote: > On Wed, Nov 23, 2016 at 3:33 AM, Andres Freund wrote: >> On 2016-11-18 08:00:40 -0500, Robert Haas wrote: >>> On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund wrote: >>> > I've a

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Dec 15, 2016 at 11:04 AM, Fujii Masao wrote: > On Thu, Dec 15, 2016 at 6:47 AM, Michael Paquier > wrote: >> On Wed, Dec 14, 2016 at 11:34 PM, Fujii Masao wrote: >>> If we drop the "standby_list" syntax, I don't

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Thu, Dec 15, 2016 at 1:18 AM, Robert Haas wrote: > On Wed, Dec 14, 2016 at 5:35 AM, Ashutosh Sharma > wrote: >>> I have just read the patch, and hardcoding the array position for a >>> socket event to 0 assumes that the socket event will be

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Dec 15, 2016 at 6:47 AM, Michael Paquier wrote: > On Wed, Dec 14, 2016 at 11:34 PM, Fujii Masao wrote: >> If we drop the "standby_list" syntax, I don't think that new parameter is >> necessary. We can keep s_s_names and just drop the

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On Wed, Dec 14, 2016 at 8:33 PM, Heikki Linnakangas wrote: > But, a password stored in plaintext works with either MD5 or SCRAM, or any > future authentication mechanism. So as soon as we have SCRAM authentication, > it becomes somewhat useful again. > > In a nutshell: > > auth /

Re: [HACKERS] Proposal for changes to recovery.conf API

On Wed, Dec 14, 2016 at 02:29:07PM -0800, Josh Berkus wrote: > On 12/14/2016 08:06 AM, Bruce Momjian wrote: > > On Fri, Dec 9, 2016 at 09:46:44AM +0900, Michael Paquier wrote: > My own take on it is that the release notes are already a massive > amount of work, and putting duplicative

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Dec 15, 2016 at 1:20 AM, Vladimir Rusinov wrote: > > On Wed, Dec 14, 2016 at 4:07 PM, Peter Eisentraut > wrote: > Others will follow later in separate patches. Or is it preferred to have one > huge patch submitted? Please yes. One

Re: [HACKERS] Make pg_basebackup -x stream the default

Summary === Thank you for submission! I think it needs a bit more work to be even better. Please deal with '-x' argument and with wording in documentation. I'll set status to 'waiting on author' now. Submission review == Patch is in correct format. Patch applies cleanly

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

On 12/14/16 5:12 PM, Stephen Frost wrote: > For my 2c, at least, because we're going to be constantly fighting with > the trailing whitespace in those examples. If you forget to s/ the docs aren't going to build and it's going to be extremely obvious > that you need to do something. Not that I'm

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

On Wed, Dec 14, 2016 at 9:37 PM, Stephen Frost wrote: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > On 12/14/16 12:03 PM, Stephen Frost wrote: > > > If we do want to change that, perhaps we should also change psql to not > > > output the trailing

Re: [HACKERS] Proposal for changes to recovery.conf API

On 12/14/2016 08:06 AM, Bruce Momjian wrote: > On Fri, Dec 9, 2016 at 09:46:44AM +0900, Michael Paquier wrote: My own take on it is that the release notes are already a massive amount of work, and putting duplicative material in a bunch of other places isn't going to make things

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Tom Lane wrote: > > > Thinking about this, I'm wondering what is the connection between > > what psql does and what should be in the SGML (or XML) docs, anyway. > > Nobody says boo when we have to do s/ > to put it in the docs; why is

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

Tom Lane wrote: > Thinking about this, I'm wondering what is the connection between > what psql does and what should be in the SGML (or XML) docs, anyway. > Nobody says boo when we have to do s/ to put it in the docs; why is stripping trailing whitespace a bigger > issue? Why do we need to put

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > The real problem here, IMO, is the break in expected regression outputs. > The previous thread mainly discussed that in terms of its impact on > third-party tests using pg_regress, but for our own purposes it would be > just as nasty to need to adjust

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

On 12/14/16 4:51 PM, Tom Lane wrote: > Thinking about this, I'm wondering what is the connection between > what psql does and what should be in the SGML (or XML) docs, anyway. > Nobody says boo when we have to do s/ to put it in the docs; why is stripping trailing whitespace a bigger > issue?

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

Stephen Frost writes: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> Previous discussion: >> https://www.postgresql.org/message-id/flat/1285093687.5468.18.camel%40vanquo.pezone.net > Thanks for that, but, frankly, it seems like most were in agreement that >

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Dec 14, 2016 at 11:34 PM, Fujii Masao wrote: > If we drop the "standby_list" syntax, I don't think that new parameter is > necessary. We can keep s_s_names and just drop the support for that syntax > from s_s_names. This may be ok if we're really in "break all the

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 12/14/16 12:03 PM, Stephen Frost wrote: > > If we do want to change that, perhaps we should also change psql to not > > output the trailing whitespace in the first place..? > > Previous discussion: >

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

On 12/14/16 12:03 PM, Stephen Frost wrote: > If we do want to change that, perhaps we should also change psql to not > output the trailing whitespace in the first place..? Previous discussion: https://www.postgresql.org/message-id/flat/1285093687.5468.18.camel%40vanquo.pezone.net -- Peter

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

On Wed, Dec 14, 2016 at 11:12 AM, Ian Jackson wrote: > Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: > Retry on constraint violation [and 2 more messages] [and 1 more messages]"): >> On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson

Re: [HACKERS] Linear vs. nonlinear planner cost estimates

Robert Haas writes: > On Wed, Dec 14, 2016 at 2:12 PM, Tom Lane wrote: >> I don't have a concrete proposal right now about how to fix this. The >> most expansive response would be to decorate every path with an explicitly >> nonlinear cost function,

Re: [HACKERS] Linear vs. nonlinear planner cost estimates

On Wed, Dec 14, 2016 at 2:12 PM, Tom Lane wrote: > I don't have a concrete proposal right now about how to fix this. The > most expansive response would be to decorate every path with an explicitly > nonlinear cost function, which would need to be able to report the cost > to

Re: [HACKERS] Creating a DSA area to provide work space for parallel execution

On Mon, Dec 5, 2016 at 3:12 PM, Robert Haas wrote: > On Thu, Dec 1, 2016 at 6:35 AM, Thomas Munro > wrote: >> On Sat, Nov 26, 2016 at 1:55 AM, Thomas Munro >> wrote: >>> Here's a new version to apply on top of

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 12/14/2016 11:41 AM, Stephen Frost wrote: * Heikki Linnakangas (hlinn...@iki.fi) wrote: On 14 December 2016 20:12:05 EET, Bruce Momjian wrote: On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote: Storing plaintext passwords has been bad form for just about

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

* Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 14 December 2016 20:12:05 EET, Bruce Momjian wrote: > >On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote: > >> I would so like to just drop support for plain passwords completely > >:) But > >> there's a backwards

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 14 December 2016 20:12:05 EET, Bruce Momjian wrote: >On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote: >> I would so like to just drop support for plain passwords completely >:) But >> there's a backwards compatibility issue to think about of course. >> >>

Re: [HACKERS] background sessions

On 12/14/16 11:33 AM, Andrew Borodin wrote: > 2016-12-14 20:45 GMT+05:00 Peter Eisentraut > : >> On 12/11/16 5:38 AM, Andrew Borodin wrote: >>> 2. From my point of view the interface of the feature is the strong >>> point here (compared to pg_background). But it

[HACKERS] Linear vs. nonlinear planner cost estimates

I've been looking into the problem reported here: https://www.postgresql.org/message-id/CAOfJSTwzQ7Fx6Yjeg9mFkMsM5OVKPoa=egkhcegdkr1twg8...@mail.gmail.com I can reproduce similar misbehavior with this test case: create table updates as select (-log(random()) * 10)::int as driver_id, now()

Re: [HACKERS] Re: [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

On Wed, Dec 14, 2016 at 11:10 PM, Fujii Masao wrote: > On Tue, Dec 13, 2016 at 10:24 PM, Michael Paquier > wrote: >> On Tue, Dec 13, 2016 at 12:49 PM, Fujii Masao wrote: >> >> Thanks for the review. > > Thanks for the

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On Wed, Dec 14, 2016 at 11:27:15AM +0100, Magnus Hagander wrote: > I would so like to just drop support for plain passwords completely :) But > there's a backwards compatibility issue to think about of course. > > But -- is there any actual usecase for them anymore? I thought we recommended

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

* Vladimir Rusinov (vrusi...@google.com) wrote: > I'm not sure if it makes sense to merge just these, as it will not help > people with whitespace-eating editors. I think we've established that it's going to be quite a while before we will reach a point where whitespace-eating editors aren't a

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

On Wed, Dec 14, 2016 at 5:41 PM, Stephen Frost wrote: > > They are considered bad practice in many style guides and many editors > > configured to stip them on every save. > > > > Such editors will produce spurious diffs when editing the documentation. > > > > Therefore, I

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

* Vladimir Rusinov (vrusi...@google.com) wrote: > They are considered bad practice in many style guides and many editors > configured to stip them on every save. > > Such editors will produce spurious diffs when editing the documentation. > > Therefore, I propose this patch. As mentioned

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

On Wed, Dec 14, 2016 at 5:14 PM, Tom Lane wrote: > Stephen Frost writes: > > If we do want to change that, perhaps we should also change psql to not > > output the trailing whitespace in the first place..? > > Yeah, maybe. I seem to recall having looked

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > If we do want to change that, perhaps we should also change psql to not > > output the trailing whitespace in the first place..? > > Yeah, maybe. I seem to recall having looked at that a long time ago > and

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

On Wed, Dec 14, 2016 at 4:50 PM, Tom Lane wrote: > Vladimir Rusinov writes: > > Therefore, I propose this patch. > > Right now is a really bad time to do that; what it will mostly accomplish > is to break back-patching of doc fixes for little benefit. >

Re: [HACKERS] Hash Indexes

On Wed, Dec 14, 2016 at 4:27 AM, Amit Kapila wrote: >> It's not required for enabling WAL. You don't *have* to release and >> reacquire the buffer lock; in fact, that just adds overhead. > > If we don't release the lock, then it will break the general coding > pattern of

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

Stephen Frost writes: > If we do want to change that, perhaps we should also change psql to not > output the trailing whitespace in the first place..? Yeah, maybe. I seem to recall having looked at that a long time ago and deciding that it wasn't worth the trouble, but the

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

On Wed, Dec 14, 2016 at 11:20 AM, Ian Jackson wrote: >> I'm not sure Ian is intentionally taking that position. Not all of us >> are as familiar with the ramifications of every serializability >> behavior we may want as you are. > > Indeed. I think it's fair to say

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]"): > On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson > wrote: > > > Let me try to summarise my understanding of what the

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Vladimir Rusinov writes: > > Therefore, I propose this patch. > > Right now is a really bad time to do that; what it will mostly accomplish > is to break back-patching of doc fixes for little benefit. > > There is work afoot to

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

On Wed, Dec 14, 2016 at 10:20 AM, Ian Jackson wrote: > Let me try to summarise my understanding of what the developers think > they can and intend to promise, about SERIALIZABLE transactions: > > There is a consistent serialisation of all transactions which >

Re: [HACKERS] [PATCH] Remove trailing whitespaces from documentation

Vladimir Rusinov writes: > Therefore, I propose this patch. Right now is a really bad time to do that; what it will mostly accomplish is to break back-patching of doc fixes for little benefit. There is work afoot to convert the documentation to xml. If that succeeds, it'd

[HACKERS] [PATCH] Remove trailing whitespaces from documentation

They are considered bad practice in many style guides and many editors configured to stip them on every save. Such editors will produce spurious diffs when editing the documentation. Therefore, I propose this patch. -- Vladimir Rusinov Storage SRE, Google Ireland Google Ireland Ltd.,Gordon

Re: [HACKERS] background sessions

2016-12-14 20:45 GMT+05:00 Peter Eisentraut : > On 12/11/16 5:38 AM, Andrew Borodin wrote: >> 2. From my point of view the interface of the feature is the strong >> point here (compared to pg_background). But it does not help >> programmer to follow good practice:

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

Robert Haas writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]"): > On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote: > > considered. Essentially, the position Ian has been taking is that > > PostgreSQL should

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Wed, Dec 14, 2016 at 4:07 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/13/16 12:47 PM, Vladimir Rusinov wrote: > > Based on discussion in > > https://www.postgresql.org/message-id/CAE1wr-w% > 3DLE1cK5uG_rmAh-VBxc4_Bnw-gAE3qSqL-%3DtWwvLvjQ%40mail.gmail.com. > > > >

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 14, 2016 at 5:35 AM, Ashutosh Sharma wrote: >> I have just read the patch, and hardcoding the array position for a >> socket event to 0 assumes that the socket event will be *always* the >> first one in the list. but that cannot be true all the time, any code >>

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 14, 2016 at 2:34 AM, Ashutosh Sharma wrote: >> Okay, but I think we need to re-enable the existing event handle for >> required event (FD_READ) by using WSAEventSelect() to make it work >> sanely. We have tried something on those lines and it resolved the >>

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 12/13/16 12:47 PM, Vladimir Rusinov wrote: > Based on discussion in > https://www.postgresql.org/message-id/CAE1wr-w%3DLE1cK5uG_rmAh-VBxc4_Bnw-gAE3qSqL-%3DtWwvLvjQ%40mail.gmail.com. > > Tested via regression tests. > To be applied in master only and to be included in 10.0. I don't think

Re: [HACKERS] Proposal for changes to recovery.conf API

On Fri, Dec 9, 2016 at 09:46:44AM +0900, Michael Paquier wrote: > >> My own take on it is that the release notes are already a massive > >> amount of work, and putting duplicative material in a bunch of other > >> places isn't going to make things better, it'll just increase the > >> maintenance

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

Kevin Grittner writes: > On Wed, Dec 14, 2016 at 8:16 AM, Dagfinn Ilmari Mannsåker > wrote: > >> Attached is a patch > > Please add this to the open CommitFest to ensure that it is reviewed. Done. https://commitfest.postgresql.org/12/910/ -- "The

Re: [HACKERS] background sessions

On 12/11/16 5:38 AM, Andrew Borodin wrote: > 2. From my point of view the interface of the feature is the strong > point here (compared to pg_background). But it does not help > programmer to follow good practice: bgworker is a valuable and limited > resource, may be we could start session with

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

On Wed, Dec 14, 2016 at 8:16 AM, Dagfinn Ilmari Mannsåker wrote: > Attached is a patch Please add this to the open CommitFest to ensure that it is reviewed. http://commitfest.postgresql.org/action/commitfest_view/open -- Kevin Grittner EDB: http://www.enterprisedb.com The

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]

On Wed, Dec 14, 2016 at 8:38 AM, Robert Haas wrote: > On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote: >> Predicate locks >> from reads within subtransactions are not discarded, even if the >> work of the subtransaction is otherwise discarded. > >

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 12/5/16 12:17 AM, Michael Paquier wrote: > OK, here is attached what I had in mind as reload-ssl-v08-02.patch for > reference. This applies on top of the main patch > reload-ssl-v08-01.patch that is the same version as v7 with the issues > I reported previously as addressed. LoadedSSL is mapped

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 12/14/16 5:15 AM, Michael Paquier wrote: > > I would be tempted to suggest adding the verifier type as a new column > > of pg_authid > > Yes please. This discussion seems to continue to come up and I don't entirely understand why

Re: [HACKERS] Declarative partitioning - another take

Hi Amit, On 12/13/2016 09:45 AM, Amit Langote wrote: On 2016/12/13 0:17, Tomas Vondra wrote: On 12/12/2016 07:37 AM, Amit Langote wrote: Hi Tomas, On 2016/12/12 10:02, Tomas Vondra wrote: 2) I'm wondering whether having 'table' in the catalog name (and also in the new relkind) is too

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 12/14/16 5:15 AM, Michael Paquier wrote: > I would be tempted to suggest adding the verifier type as a new column > of pg_authid Yes please. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]

On Wed, Dec 14, 2016 at 9:40 AM, Kevin Grittner wrote: > On Wed, Dec 14, 2016 at 8:27 AM, Robert Haas wrote: >> But even after that fix, at the least, you'll still be able to >> demonstrate the same problem by trapping serialization_failure rather >>

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Tue, Dec 13, 2016 at 5:06 PM, Kyotaro HORIGUCHI wrote: > At Tue, 13 Dec 2016 08:46:06 +0530, Amit Kapila > wrote in >> On Mon, Dec 12, 2016 at 9:54 PM, Masahiko

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]

On Wed, Dec 14, 2016 at 8:27 AM, Robert Haas wrote: > But even after that fix, at the least, you'll still be able to > demonstrate the same problem by trapping serialization_failure rather > than unique_constraint. I hope not; the "doomed" flag associated with a

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]

Thanks for the reply. On Wed, Dec 14, 2016 at 9:26 AM, Kevin Grittner wrote: > considered. Essentially, the position Ian has been taking is that > PostgreSQL should provide the guarantee of (2) above. As far as I > can see, that would require using S2PL -- something the

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]

On Wed, Dec 14, 2016 at 12:44 AM, Robert Haas wrote: > On Tue, Dec 13, 2016 at 1:00 PM, Ian Jackson > wrote: > Saying that a set of transactions are serializable is equivalent to > the statement that there is some serial order of execution

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]

On Wed, Dec 14, 2016 at 9:05 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> I have not read any database literature on the interaction of >> serializability with subtransactions. This seems very thorny. >> Suppose T1 reads A and B and updates A -> A' while

[HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

Hi hackers, I have a workload using SSI that causes a lot of tuple predicate to be promoted to page locks. This causes a lot of spurious serialisability errors, since the promotion happens at once three tuples on a page are locked, and the affected tables have 30-90 tuples per page.

Re: [HACKERS] Re: [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

On Tue, Dec 13, 2016 at 10:24 PM, Michael Paquier wrote: > On Tue, Dec 13, 2016 at 12:49 PM, Fujii Masao wrote: > > Thanks for the review. Thanks for the updated version of the patch! >> +

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages]

Robert Haas wrote: > I have not read any database literature on the interaction of > serializability with subtransactions. This seems very thorny. > Suppose T1 reads A and B and updates A -> A' while concurrently T2 > reads A and B and updates B -> B'. This is obviously not > serializable; if

Re: [HACKERS] pg_catversion builtin function

On 12/14/2016 08:52 AM, Robert Haas wrote: But I understand your concern, so "Rejected" is ok under https://commitfest.postgresql.org/12/906/ I have a better reason for rejecting this patch: we already have this feature. rhaas=# select catalog_version_no from pg_control_system();

Re: [HACKERS] pg_catversion builtin function

On Wed, Dec 14, 2016 at 8:32 AM, Jesper Pedersen wrote: > On 12/13/2016 10:33 AM, Tom Lane wrote: >> Jesper Pedersen writes: >>> Attached is a new builtin function that exposes the CATALOG_VERSION_NO >>> constant under the pg_catversion()

Re: [HACKERS] pg_catversion builtin function

On 12/13/2016 10:33 AM, Tom Lane wrote: Jesper Pedersen writes: Attached is a new builtin function that exposes the CATALOG_VERSION_NO constant under the pg_catversion() function, e.g. I'm pretty sure that we intentionally didn't expose that, reasoning that users

Re: [HACKERS] Declarative partitioning - another take

Hi, On 13.12.2016 21:10, Robert Haas wrote: On Tue, Dec 13, 2016 at 12:22 PM, Ildar Musin wrote: We've noticed that PartitionDispatch object is built on every INSERT query and that it could create unnecessary overhead. Wouldn't it be better to keep it in relcache?

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 12/14/2016 12:27 PM, Magnus Hagander wrote: I would so like to just drop support for plain passwords completely :) But there's a backwards compatibility issue to think about of course. But -- is there any actual usecase for them anymore? Hmm. At the moment, I don't think there is. But, a

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi Micheal,, > I have just read the patch, and hardcoding the array position for a > socket event to 0 assumes that the socket event will be *always* the > first one in the list. but that cannot be true all the time, any code > that does not register the socket event as the first one in the list

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 12/14/2016 12:15 PM, Michael Paquier wrote: This work is definitely something that should be done before anything else. Need a patch or are you on it? I'm on it.. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On Wed, Dec 14, 2016 at 9:51 AM, Heikki Linnakangas wrote: > On 12/09/2016 10:19 AM, Michael Paquier wrote: > >> On Fri, Dec 9, 2016 at 5:11 PM, Heikki Linnakangas >> wrote: >> >>> Couple of things I should write down before I forget: >>> >>> 1. It's a bit

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 14, 2016 at 5:38 PM, Ashutosh Sharma wrote: >> What I think you want to do is modify the flag events associated to >> the socket read/write event to be updated in WaitEventAdjustWin32(), > > Well, this does not work as the following if check does not allow the >

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On Wed, Dec 14, 2016 at 5:51 PM, Heikki Linnakangas wrote: > The tip of the work branch can now do SCRAM authentication, when a user has > a plaintext password in pg_authid.rolpassword. The reverse doesn't work, > however: you cannot do plain "password" authentication, when the

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Wed, Dec 14, 2016 at 7:02 PM, Rahila Syed wrote: >>There is a similar code pattern for materialized views, see >>create_ctas_nodata() where the attribute list is built > create_ctas_nodata() is for creation of materialized views WITH NO DATA. > For other materialized

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

Hello, Thank you for comments. >There is a similar code pattern for materialized views, see >create_ctas_nodata() where the attribute list is built create_ctas_nodata() is for creation of materialized views WITH NO DATA. For other materialized views and CREATE TABLE AS, column definitions are

Re: [HACKERS] Hash Indexes

On Tue, Dec 13, 2016 at 11:30 PM, Robert Haas wrote: > On Mon, Dec 12, 2016 at 9:21 PM, Amit Kapila wrote: >> The reason is to make the operations consistent in master and standby. >> In WAL patch, for clearing the SPLIT_CLEANUP flag, we write a

pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 12/09/2016 10:19 AM, Michael Paquier wrote: On Fri, Dec 9, 2016 at 5:11 PM, Heikki Linnakangas wrote: Couple of things I should write down before I forget: 1. It's a bit cumbersome that the scram verifiers stored in pg_authid.rolpassword don't have any clear indication

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi Micheal, > I bet that this patch breaks many things for any non-WIN32 platform. It seems to me like you have already identified some issues when testing. If yes, could please share it. I have tested my patch on CentOS-7 and Windows-7 machines and have found no issues. I ran all the