On Sun, Mar 13, 2016 at 12:40 AM, Tom Lane wrote:
> In short: we've already been over this territory, at length,
> and I am not excited by people trying to bikeshed it again
> after the fact, especially when no new arguments are being
> presented. Can we call the discussion closed, please?
Close
Robert Haas writes:
> You could also argue that's a compatibility break, because people may
> have logic that assumes that a wait is always a heavyweight lock wait.
> If we keep the column but change the meaning, people who need to
> update their scripts may fail to notice. Hard breaks aren't tha
On Fri, Mar 11, 2016 at 6:31 PM, Jim Nasby wrote:
> On 3/10/16 8:36 PM, Robert Haas wrote:
>> 1. We make it true only for heavyweight lock waits, and false for
>> other kinds of waits. That's pretty strange.
>> 2. We make it true for all kinds of waits that we now know how to
>> report. That sti
On Sat, Mar 12, 2016 at 5:01 AM, Jim Nasby wrote:
>
> On 3/10/16 8:36 PM, Robert Haas wrote:
>>
>> 1. We make it true only for heavyweight lock waits, and false for
>> other kinds of waits. That's pretty strange.
>> 2. We make it true for all kinds of waits that we now know how to
>> report. Tha
On Sat, Mar 12, 2016 at 6:31 AM, Jim Nasby wrote:
> On 3/10/16 8:36 PM, Robert Haas wrote:
>>
>> 1. We make it true only for heavyweight lock waits, and false for
>> other kinds of waits. That's pretty strange.
>> 2. We make it true for all kinds of waits that we now know how to
>> report. That
On 3/10/16 8:36 PM, Robert Haas wrote:
1. We make it true only for heavyweight lock waits, and false for
other kinds of waits. That's pretty strange.
2. We make it true for all kinds of waits that we now know how to
report. That still breaks compatibility.
I would absolutely vote for 2 here.
2016-03-11 23:22 GMT+01:00 Joel Jacobson :
> On Sat, Mar 12, 2016 at 5:09 AM, Pavel Stehule
> wrote:
> >> What we need is more input on proposed changes from other companies
> >> who are also heavy users of PL/pgSQL.
> >>
> >> Only then can we move forward. It's like Robert is saying, there is a
On Sat, Mar 12, 2016 at 5:09 AM, Pavel Stehule wrote:
>> What we need is more input on proposed changes from other companies
>> who are also heavy users of PL/pgSQL.
>>
>> Only then can we move forward. It's like Robert is saying, there is a
>> risk for bikeshedding here,
>> we must widen our pers
2016-03-11 22:48 GMT+01:00 Joel Jacobson :
> On Sat, Mar 12, 2016 at 4:41 AM, Pavel Stehule
> wrote:
> > I afraid so you try to look on your use case as global/generic issue. The
> > PL/SQL, ADA. PL/pgSQL are verbose languages, and too shortcuts does the
> > languages dirty. In this point we have
On Sat, Mar 12, 2016 at 4:48 AM, Joel Jacobson wrote:
> neither you nor me have nothing to add.
Correction: neither you nor me have anything to add.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
On Sat, Mar 12, 2016 at 4:41 AM, Pavel Stehule wrote:
> I afraid so you try to look on your use case as global/generic issue. The
> PL/SQL, ADA. PL/pgSQL are verbose languages, and too shortcuts does the
> languages dirty. In this point we have different opinion.
>
> I proposed some enhanced PLpgS
2016-03-11 22:32 GMT+01:00 Joel Jacobson :
> On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas
> wrote:
> >
> > I don't think my experience in this area is as deep as you seem to
> > think. I can tell you that most of the requests EnterpriseDB gets for
> > PL/pgsql enhancements involve wanting it to
2016-03-11 22:08 GMT+01:00 Robert Haas :
> On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson wrote:
> > On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas
> wrote:
> >> I'm not direly opposed to most of what's on that page,
> >> but I'm not excited about most of it, either.
> >
> > May I ask, what impro
On Sat, Mar 12, 2016 at 4:08 AM, Robert Haas wrote:
>
> I don't think my experience in this area is as deep as you seem to
> think. I can tell you that most of the requests EnterpriseDB gets for
> PL/pgsql enhancements involve wanting it to be more like Oracle's
> PL/SQL, which of course has very
On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson wrote:
> On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote:
>> I'm not direly opposed to most of what's on that page,
>> but I'm not excited about most of it, either.
>
> May I ask, what improvements of PL/pgSQL would you personally be most
> excit
On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote:
> I'm not direly opposed to most of what's on that page,
> but I'm not excited about most of it, either.
May I ask, what improvements of PL/pgSQL would you personally be most
excited about,
if you or someone else would have unlimited resources
>
> Yes, I think we use this rubric quite often, and I agree it's a good one.
>
> > Trying to e.g. select a different number of columns into a different
> > number of variables in a PL/pgSQL function doesn't throw an error.
> > Bad. :(
>
> Yeah, I'm sympathetic to that request. That seems like poo
2016-03-11 0:17 GMT+01:00 Tom Lane :
> Robert Haas writes:
> > Or ... maybe this is intentional behavior? Now that I think about it,
> > doesn't each backend cache this info the first time its transaction
> > reads the data?
>
> Your view of pg_stat_activity is supposed to hold still within a
>
On Thu, Mar 10, 2016 at 10:49 PM, Joel Jacobson wrote:
> On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote:
>> Well, this was discussed. If we keep the Boolean "waiting" column, then
>> either:
>
> Oh, sorry for missing out on that discussion.
>
>> 1. We make it true only for heavyweight lock
On Fri, Mar 11, 2016 at 9:19 AM, Joel Jacobson wrote:
>
> On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas
wrote:
> > Well, this was discussed. If we keep the Boolean "waiting" column,
then either:
>
> Oh, sorry for missing out on that discussion.
>
> > 1. We make it true only for heavyweight lock w
On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote:
> Well, this was discussed. If we keep the Boolean "waiting" column, then
> either:
Oh, sorry for missing out on that discussion.
> 1. We make it true only for heavyweight lock waits, and false for
> other kinds of waits. That's pretty stran
On Thu, Mar 10, 2016 at 8:31 PM, Joel Jacobson wrote:
> This is an excellent feature, thanks!
> But can we please keep the old boolean waiting column?
> I see no reason to break backward-compatibility. Or maybe I'm missing
> something.
Well, this was discussed. If we keep the Boolean "waiting"
This is an excellent feature, thanks!
But can we please keep the old boolean waiting column?
I see no reason to break backward-compatibility. Or maybe I'm missing something.
I just had to commit this to make our system run locally on 9.6:
commit 2e189f85fa56724bec5c5cab2fcf0d2f3a4ce22a
Author: Jo
Robert Haas writes:
> Or ... maybe this is intentional behavior? Now that I think about it,
> doesn't each backend cache this info the first time its transaction
> reads the data?
Your view of pg_stat_activity is supposed to hold still within a
transaction, yes. Otherwise it'd be really painful
On Thu, Mar 10, 2016 at 5:07 PM, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 5:05 PM, Robert Haas wrote:
>> On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule
>> wrote:
>>> Maybe it be clear from attached text file
>>
>> Uh, yikes, that looks messed up, but I wouldn't have thought this
>> commit w
On Thu, Mar 10, 2016 at 5:05 PM, Robert Haas wrote:
> On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule
> wrote:
>> Maybe it be clear from attached text file
>
> Uh, yikes, that looks messed up, but I wouldn't have thought this
> commit would have changed anything there one way or the other. The
>
On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule wrote:
> Maybe it be clear from attached text file
Uh, yikes, that looks messed up, but I wouldn't have thought this
commit would have changed anything there one way or the other. The
current query is reported by pgstat_report_activity(), which I di
2016-03-10 22:24 GMT+01:00 Robert Haas :
>
> rhaas=# select query, state, wait_event, wait_event_type from
> pg_stat_activity;
> query
> | state | wait_event | wait_event_type
>
> -+
On Thu, Mar 10, 2016 at 3:44 PM, Pavel Stehule wrote:
> I am trying to test this feature, and there I see not actual data. Maybe
> this behave is not related to this patch:
>
> create table foo(a int);
> insert into foo values(10);
>
> session one:
>
> begin; select * from foo for update;
>
> sess
29 matches
Mail list logo