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 succeeded.
>>>
>>> If there is max_connections exceeded, then
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 sure whether this idiom is common for
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 account prohibited, bi-direction
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 wrote:
> >> On Thu, Dec 15, 2016 at 6:47 AM, Michael Paquier
> >> wrote:
> >>> On Wed, Dec 14, 2016 at 11:34 PM, Fujii Ma
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 Masao wrote:
If we drop the "standby_list" syntax, I don't think that ne
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 backward compatibility fully for s_s_names
>> (i.e., both "standby_list" and "N (st
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 :(
>>
>> I just added a module to run "m
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 s
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 have no provision for
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 gets reused again and
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 the array position for a
socket event to 0 assumes that the socket eve
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.
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 working fix for this, and for a similar issue Robert found. I'm
>>
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 think that new parameter is
>>> necessary. We can keep s_s_names and just dro
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 *always* the
>>> first one in the list. but that can
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 support for that syntax
>> from s_s_names. This may be
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 / stored MD5
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 ma
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 change makes little sense.
>> Personally, I think this i
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 on
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
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 whitespace in the first place
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 bet
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 s
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
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
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?
Ther
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
> we should go ahead a
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 things" mode
> for Postgr
* 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:
> https://www.postgresql.org/messa
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 Eisent
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
>> wrote:
>> I would alter that slight
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, which would need to be able to report the cost
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 fetch the first N tu
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 dsa-v7.patch.
>>
>> Here's a version to go with dsa-v8.patch.
>
> Thomas has spent a f
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 forever and
I would
* 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 compatibility issue
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.
>>
>> But -- is there any
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 does not help
>>> programmer to fol
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()
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 updated version of the patch!
>
>>> +(errcode(ERRCODE_OBJE
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 'pass
* 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 pro
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 propose this patch.
>
>
* 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 down-th
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 at that a long time ago
> and deciding th
* 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 deciding that it wasn'
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.
>
ack. As I said, it's a proposal and I'm n
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 writing WAL (Acquire pin
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 code involved
has prob
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 that I'm totally unfamiliar wi
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 developers think
> > they can
* 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 convert the documentation t
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
> successfully commit; or which do no
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 make sense to strip tr
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 Hou
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: bgworker is a valuable and limited
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 provide the guarantee
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.
> >
> > Tes
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
>> that does not register
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
>> problem. Ashutosh will po
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 th
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 b
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 surreality of the universe tends towards a ma
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 som
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 Enterprise PostgreSQ
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.
>
> Oh, interesting. Just to be clear, I'm no
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
* 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 w
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 limit
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 pgsql-
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
>> than unique_constraint.
>
> I hope not; the "d
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 Sawada
>> wrote:
>> > On Mon, Dec 12, 2016 at 9:52 PM, Fujii Masao wrote:
>> >> On Mon, Dec 12, 2016 at 9:31 PM, Masahiko Sawada
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 serializable
transaction should c
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 community
> ripped out
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 which would
> have produced results equivalent to the a
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 concurrently T2
>> reads A and B and
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.
PredicateLoc
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!
>> +(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
>> + errmsg("a
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 ei
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();
catalog_ver
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() function, e.g.
>>
>> I'm pretty sure that we intentionally
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 should only care about the us
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?
You might be able to cache
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 p
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
>
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:
http://w
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 cumbersome that the scram verifiers sto
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
> FD_READ or FD_WRITE fla
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 user has a
> SCRAM
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 views and CREATE TABLE AS,
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
bui
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 WAL and
>> if we don't release the lock after writi
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 that they're scram
ve
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 regression
95 matches
Mail list logo
