On Tue, Jun 21, 2016 at 9:21 AM, Andres Freund wrote:
>
> On 2016-06-21 08:59:13 +0530, Amit Kapila wrote:
> > Can we consider to use some strategy to avoid deadlocks without
releasing
> > the lock on old page? Consider if we could have a mechanism such that
> > RelationGetBufferForTuple() will e
On Tue, Jun 21, 2016 at 9:16 AM, Thomas Munro
wrote:
>
> On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila
wrote:
> > Some others ways could be:
> >
> > Before releasing the lock on buffer containing old tuple, clear the VM
and
> > visibility info from page and WAL log it. I think this could impact
>
On Tue, Jun 21, 2016 at 9:08 AM, Thomas Munro
wrote:
>
> On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila
wrote:
> > On Tue, Jun 21, 2016 at 1:03 AM, Andres Freund
wrote:
> >> Well, I think generally nobody seriously looked at actually refactoring
> >> heap_update(), even though that'd be a good ide
Hi all,
While auditing the code, I got surprised that there are a couple of
code paths that do nothing for this error handling:
- pg_regress and isolationtester use malloc extensively, in case of
failure those would just crash crash. I think that it matters for
buildfarm members that are under mem
On Tue, Jun 21, 2016 at 1:24 AM, Robert Haas wrote:
>
> On Mon, Jun 20, 2016 at 1:13 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote:
> >>> Personally, I'm +1 for such tinkering if it makes the feature either
more
> >>> controllable or more unde
On 2016-06-21 08:59:13 +0530, Amit Kapila wrote:
> Can we consider to use some strategy to avoid deadlocks without releasing
> the lock on old page? Consider if we could have a mechanism such that
> RelationGetBufferForTuple() will ensure that it always returns a new buffer
> which has targetblock
On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila wrote:
> Some others ways could be:
>
> Before releasing the lock on buffer containing old tuple, clear the VM and
> visibility info from page and WAL log it. I think this could impact
> performance depending on how frequently we need to perform this a
On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila wrote:
> On Tue, Jun 21, 2016 at 1:03 AM, Andres Freund wrote:
>> Well, I think generally nobody seriously looked at actually refactoring
>> heap_update(), even though that'd be a good idea. But in this instance,
>> the problem seems relatively fundam
On Tue, Jun 21, 2016 at 12:06 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 6/20/16 10:29 PM, Tom Lane wrote:
>>> What I would want to know is whether this specific change is actually a
>>> good idea. In particular, I'm concerned about the possible security
>>> implications of exposing pr
On Tue, Jun 21, 2016 at 1:03 AM, Andres Freund wrote:
>
> On 2016-06-15 08:56:52 -0400, Robert Haas wrote:
> > Yikes: heap_update() sets the tuple's XMAX, CMAX, infomask, infomask2,
> > and CTID without logging anything or clearing the all-visible flag and
> > then releases the lock on the heap pa
Peter Eisentraut writes:
> On 6/19/16 5:55 PM, Tom Lane wrote:
>> Depending on what the percentage actually is, maybe we could treat
>> this like the "random" test, and allow a failure to be disregarded
>> overall? But that doesn't seem very nice either, in view of our
>> increasing reliance on a
On 6/19/16 5:55 PM, Tom Lane wrote:
Depending on what the percentage actually is, maybe we could treat
this like the "random" test, and allow a failure to be disregarded
overall? But that doesn't seem very nice either, in view of our
increasing reliance on automated testing. If "random" were fa
Peter Eisentraut writes:
> On 6/20/16 10:29 PM, Tom Lane wrote:
>> What I would want to know is whether this specific change is actually a
>> good idea. In particular, I'm concerned about the possible security
>> implications of exposing primary_conninfo --- might it not contain a
>> password, fo
Peter Geoghegan writes:
> On Wed, May 18, 2016 at 3:40 AM, Robert Haas wrote:
>> What I'm tempted to do is trying to document that, as a point of
>> policy, parallel query in 9.6 uses up to (workers + 1) times the
>> resources that a single session might use. That includes not only CPU
>> but al
On 6/20/16 10:29 PM, Tom Lane wrote:
What I would want to know is whether this specific change is actually a
good idea. In particular, I'm concerned about the possible security
implications of exposing primary_conninfo --- might it not contain a
password, for example?
That would have been my o
Michael Paquier writes:
> On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote:
>> What I would want to know is whether this specific change is actually a
>> good idea. In particular, I'm concerned about the possible security
>> implications of exposing primary_conninfo --- might it not contain a
>>
On Tue, Jun 21, 2016 at 11:29 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote:
>>> Even there seems to be ongoing discussions on changing version number
>>> while in the beta period (and which definitely requires initdb). Why
>>> not changing
Michael Paquier writes:
> On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote:
>> Even there seems to be ongoing discussions on changing version number
>> while in the beta period (and which definitely requires initdb). Why
>> not changing system catalog during beta?:-)
> I am not directly again
Alvaro Herrera writes:
> Tom Lane wrote:
>> This seems like pretty good evidence that we should remove the "ignored"
>> marking for the random test, and maybe remove that functionality from
>> pg_regress altogether. We could probably adjust the test to decrease
>> its risk-of-failure by another f
On Tue, May 24, 2016 at 09:23:27AM -0500, Jim Nasby wrote:
> On 5/16/16 2:36 AM, Bruce Momjian wrote:
> >Right. I am thinking of writing some docs about how to avoid downtime
> >for upgrades of various types.
>
> If there's some magic sauce to shrink pg_upgrade downtime to near 0 I think
> folks
On Fri, May 20, 2016 at 07:40:53PM -0400, Robert Haas wrote:
> On Mon, May 16, 2016 at 3:36 AM, Bruce Momjian wrote:
> > On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote:
> >> 2) There's no ability at all to revert, other than restore a backup. That
> >> means if you pull the trigger and
On Tue, Jun 21, 2016 at 9:58 AM, Tatsuo Ishii wrote:
>>> Thanks, this looks good. Could you please add it to the next commitfest
>>> so that it doesn't get lost and also so I can do an official review of it?
>>
>> Yes, I just did that. That's too late for 9.6 anyway with beta2 close by.
>
> Even
>> Thanks, this looks good. Could you please add it to the next commitfest
>> so that it doesn't get lost and also so I can do an official review of it?
>
> Yes, I just did that. That's too late for 9.6 anyway with beta2 close by.
Even there seems to be ongoing discussions on changing version nu
On Mon, Jun 20, 2016 at 11:26 PM, Vik Fearing wrote:
> On 19/06/16 13:02, Michael Paquier wrote:
>> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote:
>>> On 19/06/16 12:28, Michael Paquier wrote:
On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
Or in short the attached.
>>>
>>> The co
On Mon, Jun 20, 2016 at 5:47 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:52 PM, David G. Johnston
> wrote:
> > Internal or external I do think the number and type of flags described
> here,
> > for the purposes described, seems undesirable from an architectural
> > standpoint.
>
> Well, t
Tom Lane wrote:
> This seems like pretty good evidence that we should remove the "ignored"
> marking for the random test, and maybe remove that functionality from
> pg_regress altogether. We could probably adjust the test to decrease
> its risk-of-failure by another factor of ten or so, if anyone
On Fri, Jun 17, 2016 at 3:36 PM, Noah Misch wrote:
> I agree the non-atomic, unlogged change is a problem. A related threat
> doesn't require a torn page:
>
> AssignTransactionId() xid=123
> heapam.c:3931 HeapTupleHeaderSetXmax(oldtup.t_data, 123);
> some ERROR before heap_update() finishes
I wrote:
> Depending on what the percentage actually is, maybe we could treat
> this like the "random" test, and allow a failure to be disregarded
> overall? But that doesn't seem very nice either, in view of our
> increasing reliance on automated testing. If "random" were failing
> 90% of the ti
On Wed, May 18, 2016 at 3:40 AM, Robert Haas wrote:
> What I'm tempted to do is trying to document that, as a point of
> policy, parallel query in 9.6 uses up to (workers + 1) times the
> resources that a single session might use. That includes not only CPU
> but also things like work_mem and tem
On Mon, Jun 20, 2016 at 05:11:17PM -0400, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane wrote:
> > No, the argument for it was that we'd no longer have to have the annual
> > discussions about "is it 10.0 yet?".
>
> WHAT annual argument? Did anyone even argue that any 9.x releas
On Mon, May 16, 2016 at 10:16:48AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 5/16/16 9:53 AM, Greg Stark wrote:
> >> I thought the idea was that Berkeley tossed an source tree over the
> >> wall with no version number and then the first five releases were
> >> Postgres95 0.x, Postgr
On 2016-06-20 17:55:19 -0400, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:24 PM, Andres Freund wrote:
> > On 2016-06-20 16:10:23 -0400, Robert Haas wrote:
> >> What exactly is the point of all of that already_marked stuff?
> >
> > Preventing the old tuple from being locked/updated by another ba
On Mon, Jun 20, 2016 at 4:24 PM, Andres Freund wrote:
> On 2016-06-20 16:10:23 -0400, Robert Haas wrote:
>> What exactly is the point of all of that already_marked stuff?
>
> Preventing the old tuple from being locked/updated by another backend,
> while unlocking the buffer.
>
>> I
>> mean, suppos
On Mon, Jun 20, 2016 at 5:36 PM, David G. Johnston
wrote:
>> Yeah, no kidding. We had a perfectly good consensus to keep this at
>> 9.6 on pgsql-advocacy, and then later we had a revised consensus to
>> retitle it to 10.0,
>
> If -advocacy had changed their mind before beta1 was tagged this may h
On Mon, Jun 20, 2016 at 4:52 PM, David G. Johnston
wrote:
> Internal or external I do think the number and type of flags described here,
> for the purposes described, seems undesirable from an architectural
> standpoint.
Well, that seems like a bold statement to me, because I think that one
reall
On Mon, Jun 20, 2016 at 5:08 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake
> wrote:
> > Or we could adopt the very reasonable and practical policy of:
> >
> > The current versioning scheme isn't broke, so we aren't going to fix it.
>
> Yeah, no kidding. We had a perf
On 06/20/2016 02:14 PM, Merlin Moncure wrote:
On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas wrote:
On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake wrote:
Or we could adopt the very reasonable and practical policy of:
The current versioning scheme isn't broke, so we aren't going to fix it.
On Mon, Jun 20, 2016 at 4:57 PM, Tom Lane wrote:
> Andres Freund writes:
>> I also don't see why it's a good idea to have knowledge about how to
>> truncate the visibility map outside of visibilitymap.c. Having that in a
>> contrib module just seems like a modularity violation.
>
> That seems lik
On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake
> wrote:
>> Or we could adopt the very reasonable and practical policy of:
>>
>> The current versioning scheme isn't broke, so we aren't going to fix it.
>
> The idea that this discussion is no
On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane wrote:
> No, the argument for it was that we'd no longer have to have the annual
> discussions about "is it 10.0 yet?".
WHAT annual argument? Did anyone even argue that any 9.x release
prior to 9.6 deserved to be called 10.0? Maybe somebody suggested
th
On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake wrote:
> Or we could adopt the very reasonable and practical policy of:
>
> The current versioning scheme isn't broke, so we aren't going to fix it.
Yeah, no kidding. We had a perfectly good consensus to keep this at
9.6 on pgsql-advocacy, and the
Andres Freund writes:
> I also don't see why it's a good idea to have knowledge about how to
> truncate the visibility map outside of visibilitymap.c. Having that in a
> contrib module just seems like a modularity violation.
That seems like a pretty good argument.
regards
Alvaro Herrera writes:
> Tom Lane wrote:
>> If we were going to do it like that, I would argue for "every ten years
>> like clockwork", e.g. 10.0.x is next after 9.9.x. But in point of fact,
>> Robert, you already made your case for that approach and nobody else
>> cared for it.
> I voted for th
On Mon, Jun 20, 2016 at 4:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>> wrote:
>>> 10.x is the desired output.
>
>> 10.x is the output that some people desire. A significant number of
>> people, including me, would prefer to stick with the
On 06/20/2016 01:41 PM, Alvaro Herrera wrote:
Tom Lane wrote:
Robert Haas writes:
On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
wrote:
If we were going to do it like that, I would argue for "every ten years
like clockwork", e.g. 10.0.x is next after 9.9.x. But in point of fact,
Rober
On Mon, Jun 20, 2016 at 4:03 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 3:29 PM, David G. Johnston
> wrote:
> > The entire theory here looks whacked - and seems to fall into the "GUCs
> > controlling results" bucket of undesirable things.
>
> As far as I can see, this entire email is total
On 2016-06-18 11:56:51 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Sat, Jun 18, 2016 at 6:53 AM, Robert Haas wrote:
> >> Andres, do you want to explain the nature of your concern further?
>
> > I am not in his mind, but my guess is that contrib modules are
> > sometimes used as templ
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> > wrote:
> >> 10.x is the desired output.
>
> > 10.x is the output that some people desire. A significant number of
> > people, including me, would prefer to stick with the current
> > three-part vers
On Mon, Jun 20, 2016 at 4:14 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> wrote:
> > 10.x is the desired output.
>
> 10.x is the output that some people desire. A significant number of
> people, including me, would prefer to stick with the current
> three-part v
On 2016-06-20 16:10:23 -0400, Robert Haas wrote:
> What exactly is the point of all of that already_marked stuff?
Preventing the old tuple from being locked/updated by another backend,
while unlocking the buffer.
> I
> mean, suppose we just don't do any of that before we go off to do
> toast_ins
Robert Haas writes:
> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> wrote:
>> 10.x is the desired output.
> 10.x is the output that some people desire. A significant number of
> people, including me, would prefer to stick with the current
> three-part versioning scheme, possibly with som
On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
wrote:
> 10.x is the desired output.
10.x is the output that some people desire. A significant number of
people, including me, would prefer to stick with the current
three-part versioning scheme, possibly with some change to the
algorithm for bu
On Mon, Jun 20, 2016 at 3:33 PM, Andres Freund wrote:
>> I'm not sure what to do about this: this part of the heap_update()
>> logic has been like this forever, and I assume that if it were easy to
>> refactor this away, somebody would have done it by now.
>
> Well, I think generally nobody seriou
> On Jun 20, 2016, at 1:00 PM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger wrote:
>
> > Do you have a problem with the human form and machine forms of the version
> > number being different in this respect? I don't - for me the decision of a
> > choice for t
On Mon, Jun 20, 2016 at 3:29 PM, David G. Johnston
wrote:
> The entire theory here looks whacked - and seems to fall into the "GUCs
> controlling results" bucket of undesirable things.
As far as I can see, this entire email is totally wrong and off-base,
because the whole thing seems to be writte
On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger
wrote:
>
> > Do you have a problem with the human form and machine forms of the
> version number being different in this respect? I don't - for me the
> decision of a choice for the human form is not influenced by the fact the
> machine form has 6 dig
On Mon, Jun 20, 2016 at 1:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote:
>>> Personally, I'm +1 for such tinkering if it makes the feature either more
>>> controllable or more understandable. After reading the comments at the
>>> head of nodeGa
On Mon, Jun 20, 2016 at 3:07 PM, Gražvydas Valeika
wrote:
> Hi,
>
> I recently bumped into http://semver.org/
>
> It can be interesting to participants of this discussion.
>
> Especially motivation for minor version (middle number).
>
>
While we appreciate the comment this is third (maybe forth)
On 2016-06-15 08:56:52 -0400, Robert Haas wrote:
> Yikes: heap_update() sets the tuple's XMAX, CMAX, infomask, infomask2,
> and CTID without logging anything or clearing the all-visible flag and
> then releases the lock on the heap page to go do some more work that
> might even ERROR out. Only if
On Mon, Jun 20, 2016 at 12:06 PM, Robert Haas wrote:
> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote:
> >> although I fear we
> >> might be getting to a level of tinkering with parallel query that
> >> starts to look more like feature development.
> >
> > Personally, I'm +1 for such tinkering
Andreas Seltenreich writes:
> Just had a parallel worker of a memory-starved instance of sqlsmith
> crash. plpgsql_extra_checks_check_hook forgot to check the result of
> its malloc call here:
Good catch, will fix. Thanks!
regards, tom lane
--
Sent via pgsql-hackers
> On Jun 20, 2016, at 11:30 AM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger wrote:
>
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake
> > wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >>> Now maybe you have some other idea in mind, but I do
Just had a parallel worker of a memory-starved instance of sqlsmith
crash. plpgsql_extra_checks_check_hook forgot to check the result of
its malloc call here:
Core was generated by `postgres: bgworker: parallel worker for PID 5905
'.
Program terminated with signal SIGSEGV, Seg
Hi,
I recently bumped into http://semver.org/
It can be interesting to participants of this discussion.
Especially motivation for minor version (middle number).
Best,
Grazvydas
On Mon, Jun 20, 2016 at 9:30 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Jun 20, 2016 at
On 19/06/16 13:02, Michael Paquier wrote:
> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote:
>> On 19/06/16 12:28, Michael Paquier wrote:
>>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
>>> Or in short the attached.
>>
>> The code looks good to me but why no documentation?
>
> Because tha
On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake
> wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >>> Now maybe you have some other idea in mind, but I don't quite
> >>> understand what it is.
> >>
> >> I do, indeed, and her
On Mon, Jun 20, 2016 at 1:48 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 9:38 AM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> >
> > On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger
> wrote:
> >
> > > On Jun 20, 2016, at 8:53 AM, Mark Dilger
> wrote:
> > >
> > >
> > > This is no
> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake wrote:
>
> On 06/20/2016 10:45 AM, Mark Dilger wrote:
>
>>> Now maybe you have some other idea in mind, but I don't quite
>>> understand what it is.
>>
>> I do, indeed, and here it is:
>>
>> When considering whether to *back port* a change, we t
Mark Dilger wrote:
> When considering whether to *back port* a change, we typically do so
> on the basis that bug fixes are back ported, features are not. In my
> proposed versioning scheme, you could back port any feature that is
> compatible with the old version, and bump the middle number to a
> On Jun 20, 2016, at 9:38 AM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger wrote:
>
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger wrote:
> >
> >
> > This is not a plea for keeping the three part versioning system. It's just
> > a plea not to have a 2 part ver
> On Jun 20, 2016, at 9:43 AM, Robert Haas wrote:
>
> On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger wrote:
>>> In practical effect that is exactly what your proposal does. You just feel
>>> better because you defined when B is allowed to change even though it never
>>> should happen based up
Robert Haas writes:
> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote:
>> Personally, I'm +1 for such tinkering if it makes the feature either more
>> controllable or more understandable. After reading the comments at the
>> head of nodeGather.c, though, I don't think that single_copy is either
I have just noticed that when I added the pager_min_lines psetting to
psql in 9.5, I omitted to add it to the relevant piece of
tab-complete.c. If no-one objects I propose to remedy that shortly and
backpatch it.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Tomas Vondra writes:
> On 06/18/2016 06:52 PM, Tom Lane wrote:
>> I concur, actually, but I feel that it's out of scope for this
>> particular patch, which is only trying to replace the functionality
>> that was committed previously. If you want to come up with a patch on
>> top of this that adds
On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger wrote:
>> In practical effect that is exactly what your proposal does. You just feel
>> better because you defined when B is allowed to change even though it never
>> should happen based upon our project policy. And any rare exception can
>> justi
Tomas Vondra writes:
> OK, thanks. The one thing we haven't done is testing the performance, to
> see how this fares. So I've repeated the tests I've done on the original
> version of the patch here
Hmm. I'm not that excited about these results, for a couple of reasons:
* AFAICS, all the numb
On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger
> wrote:
> >
> >
> > This is not a plea for keeping the three part versioning system. It's
> just
> > a plea not to have a 2 part versioning system masquerading as a three
> > part versioning sys
> On Jun 20, 2016, at 8:53 AM, Mark Dilger wrote:
>
>
> This is not a plea for keeping the three part versioning system. It's just
> a plea not to have a 2 part versioning system masquerading as a three
> part versioning system, or vice versa.
To clarify my concern, I never want to have to w
>
> In practical effect that is exactly what your proposal does. You just feel
> better because you defined when B is allowed to change even though it never
> should happen based upon our project policy. And any rare exception can
> justifiably be called a bug fix because, face it, it would o
On Mon, Jun 20, 2016 at 1:26 AM, Amit Kapila wrote:
> I have done analysis on this and didn't found any use case where passing
> CURSOR_OPT_PARALLEL_OK in exec_stmt_execsql() can help in parallelizing the
> queries. Basically, there seems to be three ways in which function
> exec_stmt_execsql can
On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote:
>> although I fear we
>> might be getting to a level of tinkering with parallel query that
>> starts to look more like feature development.
>
> Personally, I'm +1 for such tinkering if it makes the feature either more
> controllable or more underst
On Monday, June 20, 2016, Mark Dilger wrote:
>
> > On Jun 18, 2016, at 5:48 PM, Josh Berkus > wrote:
> >
> > On 06/16/2016 11:01 PM, Craig Ringer wrote:
> >>
> >> I thought about raising this, but I think in the end it's replacing one
> >> confusing and weird versioning scheme for another confus
> On Jun 18, 2016, at 5:48 PM, Josh Berkus wrote:
>
> On 06/16/2016 11:01 PM, Craig Ringer wrote:
>>
>> I thought about raising this, but I think in the end it's replacing one
>> confusing and weird versioning scheme for another confusing and weird
>> versioning scheme.
>>
>> It does have the
Teodor Sigaev writes:
>> We're really quickly running out of time to get this done before
>> beta2. Please don't commit anything that's going to break the tree
>> because we only have about 72 hours before the wrap, but if it's
>> correct then it should go in.
> Isn't late now? Or wait to beta2
We're really quickly running out of time to get this done before
beta2. Please don't commit anything that's going to break the tree
because we only have about 72 hours before the wrap, but if it's
correct then it should go in.
Isn't late now? Or wait to beta2 is out?
--
Teodor Sigaev
On 13.06.2016 18:52, amul sul wrote:
Hi,
It's look like bug in to_timestamp() function when format string has more
whitespaces compare to input string, see below:
Ex.1: Two white spaces before HH24 whereas one before input time string
postgres=# SELECT TO_TIMESTAMP('2016-06-13 15:43:36', 'YY
On 20.06.2016 16:36, Tom Lane wrote:
Robert Haas writes:
On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote:
I think a space in the format string should skip a whitespace
character in the input string, but not a non-whitespace character.
It's my understanding that these functions exist in n
On 19/06/16 13:02, Michael Paquier wrote:
> On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote:
>> On 19/06/16 12:28, Michael Paquier wrote:
>>> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier
>>> Or in short the attached.
>>
>> The code looks good to me but why no documentation?
>
> Because tha
Tom Lane wrote:
> I don't necessarily have an opinion yet. I would like to see more than
> just an unsupported assertion about what Oracle's behavior is. Also,
> how should FM mode affect this?
I can supply what Oracle 12.1 does:
SQL> SELECT to_timestamp('2016-06-13 15:43:36', ' /MM/DD HH24
Robert Haas writes:
> On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote:
>> I think a space in the format string should skip a whitespace
>> character in the input string, but not a non-whitespace character.
>> It's my understanding that these functions exist in no small part for
>> compatibili
On Thu, Jun 16, 2016 at 8:20 AM, Robert Haas wrote:
>
> On Wed, Jun 15, 2016 at 10:48 PM, Amit Kapila
wrote:
> > exec_stmt_execsql() is used to execute SQL statements insider plpgsql
which
> > includes dml statements as well, so probably you wanted to play safe by
not
> > allowing parallel option
On Mon, Jun 20, 2016 at 8:19 AM, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas
> wrote:
> > On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote:
> >> amul sul writes:
> >>> It's look like bug in to_timestamp() function when format string has
> more whitespaces compare to inpu
On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote:
>> amul sul writes:
>>> It's look like bug in to_timestamp() function when format string has more
>>> whitespaces compare to input string, see below:
>>
>> No, I think this is a case of "inp
Thank you for useful suggestions. PFA patch, I have tried to cover all the
points mentioned.
Regards,
Muhammad Asif Naeem
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 not a good idea to skip trunca
On 20 June 2016 at 19:06, David Rowley wrote:
> On 18 June 2016 at 05:45, Tom Lane wrote:
>> A possible solution is to give deserialize an extra dummy argument, along
>> the lines of "deserialize(bytea, internal) returns internal", thereby
>> ensuring it can't be called in any non-system-originat
On 20/04/16 23:44, Tom Lane wrote:
Over in <17456.1460832...@sss.pgh.pa.us> I speculated about whether
we should be enforcing that WAL insertion happen only inside critical
sections. We don't currently, and a survey of the backend says that
there are quite a few calls that aren't inside critical
Hi,
Here is a small patch to remove an unnecessary return from
deparseFromExprForRel in contrib/postgres_fdw/deparse.c.
Best regards,
Etsuro Fujita
pg-fdw-deparse-cleanup.patch
Description: application/download
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
I ran tpc-h's queries on this version and it's successful.
The error is fixed.
commit 705ad7f3b523acae0ddfdebd270b7048b2bb8029
Author: Tom Lane
Date: Sun Jun 19 13:11:40 2016 -0400
Regards,
Tatsuro Yamada
NTT OSS Center
On 2016/06/18 1:26, Robert Haas wrote:
On Fri, Jun 17, 2016 at 9:
On 2016/06/17 21:45, Robert Haas wrote:
On Thu, Jun 16, 2016 at 10:44 PM, Etsuro Fujita
wrote:
On 2016/06/16 22:00, Robert Haas wrote:
On Thu, Jun 16, 2016 at 7:05 AM, Etsuro Fujita
wrote:
ISTM that a robuster solution to this is to push down the ft1-ft2-ft3
join
with the PHV by extending d
On 18 June 2016 at 09:29, Tom Lane wrote:
> So at this point my proposal is:
>
> 1. Add an OID-list field to Aggref holding the data types of the
> user-supplied arguments. This can be filled in parse analysis since it
> won't change thereafter. Replace calls to get_aggregate_argtypes() with
> u
1 - 100 of 105 matches
Mail list logo
