On 10 October 2015 20:45, Amit Kapila Wrote:
>> I observed one strange behavior today that if postmaster process gets
>> crashed/killed, then it kill all background processes but not the client
>> backend process.
> This is a known behaviour and there was some discussion on this
> topic [1] pre
On Sat, Oct 10, 2015 at 12:32 PM, Peter Geoghegan wrote:
> I noticed that there is still one comment that I really should have
> removed as part of this work.
I also noticed that I failed to reset the last_returned strcoll()
cache variable as part of an abbreviation call, despite the fact that
ta
Hi, Alvaro!
On Tue, May 12, 2015 at 9:13 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > 2009/12/30 Teodor Sigaev :
> > > Sync with current CVS
> >
> > I have reviewed this patch and it looks good to me. The only
> > substantive question I have is why gist_point_consistent() uses a
> > diffe
Hi, Stefan!
On Sun, Oct 11, 2015 at 10:00 PM, Stefan Keller wrote:
> Pls. don't misunderstand my questions: They are directed to get an
> even more useful spatial data handling of PostgreSQL. I'm working with
> PostGIS since years and are interested in any work regarding spatial
> types...
>
> C
> This was already fixed for GiST.
> See following discussion
> http://www.postgresql.org/message-id/capphfdvgticgniaj88vchzhboxjobuhjlm6c09q_op_u9eo...@mail.gmail.com
> and commit
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3c29b196b0ce46662cb9bb7a1f91079fbacbcabb
> "Consis
On Mon, Oct 12, 2015 at 12:47 PM, Emre Hasegeli wrote:
> > This was already fixed for GiST.
> > See following discussion
> >
> http://www.postgresql.org/message-id/capphfdvgticgniaj88vchzhboxjobuhjlm6c09q_op_u9eo...@mail.gmail.com
> > and commit
> >
> http://git.postgresql.org/gitweb/?p=postgresq
On Mon, Oct 12, 2015 at 2:55 PM, Amit Kapila wrote:
> On Sun, Oct 11, 2015 at 9:12 PM, Tom Lane wrote:
> I could easily reproduce the issue if logging collector is on and even if
> we try to increase the loop count or sleep time in PGSharedMemoryCreate(),
> it doesn't change the situation as the
On 2015-10-12 11:25:35 +0530, Amit Kapila wrote:
> /*
> + * Close the shared memory handle as the syslogger doesn't need to
> + * attach to it. For EXEC_BACKEND case, the shared memory handle
> + * is inherited by all postmaster child processes irrespective of
> + * wheth
On Mon, Oct 12, 2015 at 12:25 PM, Andres Freund wrote:
> On 2015-10-12 11:25:35 +0530, Amit Kapila wrote:
> > /*
> > + * Close the shared memory handle as the syslogger doesn't need to
> > + * attach to it. For EXEC_BACKEND case, the shared memory handle
> > + * is inherited
>> Pls. don't misunderstand my questions: They are directed to get an
>> even more useful spatial data handling of PostgreSQL. I'm working with
>> PostGIS since years and are interested in any work regarding spatial
>> types...
>>
>> Can anyone report use cases or applications of these built-in geo
On Mon, Oct 12, 2015 at 3:45 PM, Michael Paquier
wrote:
>
> On Mon, Oct 12, 2015 at 2:55 PM, Amit Kapila
wrote:
> > On Sun, Oct 11, 2015 at 9:12 PM, Tom Lane wrote:
> > I could easily reproduce the issue if logging collector is on and even
if
> > we try to increase the loop count or sleep time i
On Mon, Oct 12, 2015 at 11:51 AM, Haribabu Kommi
wrote:
>
> On Mon, Oct 5, 2015 at 11:20 PM, Amit Kapila
wrote:
> > For now, I have fixed this by not preserving the startblock incase of
rescan
> > for parallel scan. Note that, I have created a separate patch
> > (parallel_seqscan_heaprescan_v1.pa
On Sat, Oct 10, 2015 at 3:10 AM, Robbie Harwood wrote:
> Michael Paquier writes:
>>> On 2015-07-02 14:22:13 -0400, Robbie Harwood wrote:
>>> [Andres' comments]
>>
>> Here are some comments on top of what Andres has mentioned.
>>
>> --- a/configure.in
>> +++ b/configure.in
>> @@ -636,6 +636,7 @@ PGA
On Mon, Oct 12, 2015 at 7:26 PM, Magnus Hagander wrote:
>
>
> On Mon, Oct 12, 2015 at 12:25 PM, Andres Freund wrote:
>>
>> On 2015-10-12 11:25:35 +0530, Amit Kapila wrote:
>> > /*
>> > + * Close the shared memory handle as the syslogger doesn't need to
>> > + * attach to it. For
On 2015-10-12 21:38:12 +0900, Michael Paquier wrote:
> >> It feels wrong to do this in syslogger.c - I mean it's not the only
> >> process that's not attached to shared memory. Sure, the others get
> >> killed, but nonetheless...
> >
> >
> > +1. It feels like we're setting our selves up for repeati
Hello, Amit!
On Пн, 2015-10-12 at 11:25 +0530, Amit Kapila wrote:
> On Sun, Oct 11, 2015 at 9:12 PM, Tom Lane wrote:
> >
> > Magnus Hagander writes:
> > > On Sun, Oct 11, 2015 at 5:22 PM, Tom Lane
> wrote:
> > >> I'm a bit suspicious that we may have leaked a handle to the
> shared
> > >> memory
On Mon, Oct 12, 2015 at 4:42 PM, Dmitry Vasilyev
wrote:
> Hello, Amit!
>
> On Пн, 2015-10-12 at 11:25 +0530, Amit Kapila wrote:
>
> On Sun, Oct 11, 2015 at 9:12 PM, Tom Lane wrote:
> >
> > Magnus Hagander writes:
> > > On Sun, Oct 11, 2015 at 5:22 PM, Tom Lane wrote:
> > >> I'm a bit suspiciou
Andres Freund writes:
> On 2015-10-12 21:38:12 +0900, Michael Paquier wrote:
>> Actually, doesn't this apply as well to the archiver and the pgstat
>> collector?
> As mentioned above? The difference is that the archiver et al get killed
> by postmaster during a PANIC restart thus don't present th
Oleg Bartunov writes:
> Assuming the problem will be fixed, should we release Beta2 soon ?
This bug has existed since we had native Windows support. It's entirely
immaterial for beta purposes, and I have a hard time thinking it's
critical enough to justify a short release cycle for the back bran
On 2015-10-12 10:04:55 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-10-12 21:38:12 +0900, Michael Paquier wrote:
> >> Actually, doesn't this apply as well to the archiver and the pgstat
> >> collector?
>
> > As mentioned above? The difference is that the archiver et al get killed
>
Andres Freund writes:
> Right. But that doesn't mean it's right to call PGSharedMemoryDetach()
> without other changes as done in Michael's proposed patch? That'll do an
> UnmapViewOfFile() which'll fail because nothing i mapped, but still not
> close UsedShmemSegID?
Ah, right, I'd not noticed th
I wrote:
> Andres Freund writes:
>> Right. But that doesn't mean it's right to call PGSharedMemoryDetach()
>> without other changes as done in Michael's proposed patch? That'll do an
>> UnmapViewOfFile() which'll fail because nothing i mapped, but still not
>> close UsedShmemSegID?
> Ah, right, I
On Mon, Oct 12, 2015 at 8:10 PM, Tom Lane wrote:
>
> I wrote:
> > Andres Freund writes:
> >> Right. But that doesn't mean it's right to call PGSharedMemoryDetach()
> >> without other changes as done in Michael's proposed patch? That'll do
an
> >> UnmapViewOfFile() which'll fail because nothing i
I wrote:
> Actually, now that I look at it, it's even more obvious that this is the
> wrong thing because *all the subprocess types in question already call
> PGSharedMemoryDetach*.
Ah, scratch that: in most of them, the call is in #ifndef EXEC_BACKEND
stanzas. The exception is bgworker start for
On 10/11/15 6:55 AM, Jinyu wrote:
Are there other solutions to improve the concurency of vacuum
full/cluster and select statement on the same relation?
ISTM that if we were going to put effort into this it makes more sense
to pull pg_repack into core. BTW, it's approach to this is to summarily
On Sun, Oct 11, 2015 at 7:56 PM, Noah Misch wrote:
> I see no mention in this thread of varatt_indirect, but I anticipated
> datumSerialize() reacting to it the same way datumCopy() reacts. If
> datumSerialize() can get away without doing so, why is that?
Good point. I don't think it can. Atta
Wheter it would be a problem to set additional item (rhost) before
pam_authentication function in backend/libpq/auth.c?
It is very useful because you can restrict access to given ip address like
in mysql.
And this actually utilized in pam-pgsql, wich cannot be used because rhost
item is empty.
Tha
On Mon, Oct 12, 2015 at 12:47 AM, Peter Geoghegan wrote:
> I also noticed that I failed to reset the last_returned strcoll()
> cache variable as part of an abbreviation call, despite the fact that
> tapesort may freely interleave conversions with comparisons, while
> reusing buf1 and buf2 both as
Hi Alexander
Thanks for your succinct reply.
Actually I considered contributing myself for the first time to
PostgreSQL and/or PostGIS.
So, concluding from your explanations there's no big use case behind
build-in geometric types except serving as reference implementation?
I'm still torn over this
I wrote:
> This is kind of a mess :-(. But it does look like what we want is
> for SubPostmasterMain to do more than nothing when it chooses not to
> reattach. Probably that should include resetting UsedShmemSegAddr to
> NULL, as well as closing the handle.
After poking around a bit more, I prop
Hello Tom!
On Пн, 2015-10-12 at 16:35 -0400, Tom Lane wrote:
> I wrote:
> > This is kind of a mess :-(. But it does look like what we want is
> > for SubPostmasterMain to do more than nothing when it chooses not
> > to
> > reattach. Probably that should include resetting UsedShmemSegAddr
> > to
>
Michael Paquier writes:
>> On Wed, Oct 7, 2015 at 11:52 PM, Tom Lane wrote:
>>> I think there is still room to salvage something without fully rewriting
>>> the postmaster invocation logic to avoid using CMD, because it's still
>>> true that checking whether the CMD process is still there should
On Fri, Oct 9, 2015 at 8:02 AM, YUriy Zhuravlev
wrote:
> We were some of the issues associated with the behavior of arrays.
> 1. We would like to implement arrays negative indices (from the end) like in
> Python or Ruby: arr[-2] or arr[1: -1]
> but as an array can be indexed in the negative area
On Fri, Oct 9, 2015 at 4:38 PM, Amir Rohan wrote:
> It does catch bad syntax, but in most cases all you get is
> "The setting could not be applied". that's not great for enums
> or a float instead of an int. I guess a future version will fix that
> (or not).
I expect we would consider patches to
On Mon, Oct 12, 2015 at 3:31 PM, Peter Geoghegan wrote:
> On Mon, Oct 12, 2015 at 12:47 AM, Peter Geoghegan wrote:
>> I also noticed that I failed to reset the last_returned strcoll()
>> cache variable as part of an abbreviation call, despite the fact that
>> tapesort may freely interleave conver
On Tue, Oct 6, 2015 at 2:33 PM, Nathan Wagner wrote:
> Two, I think any attempt to tell the developers and committers that they
> need to change their workflow to adapt to some system is bound to fail,
> so, I have asked, just what changed would you all be willing to actually
> *do*? Tom Lane is
On Fri, Oct 9, 2015 at 10:16 PM, Noah Misch wrote:
> On Fri, Oct 09, 2015 at 03:14:26PM -0400, Robert Haas wrote:
>> On Thu, Oct 8, 2015 at 11:26 PM, Noah Misch wrote:
>> >> In particular, magically
>> >> substituting 127.0.0.1 for 0.0.0.0 seems utterly without principle.
>> >
>> > Binding a list
On Mon, Oct 12, 2015 at 07:37:42PM -0400, Robert Haas wrote:
> On Fri, Oct 9, 2015 at 10:16 PM, Noah Misch wrote:
> > On Fri, Oct 09, 2015 at 03:14:26PM -0400, Robert Haas wrote:
> >> On Thu, Oct 8, 2015 at 11:26 PM, Noah Misch wrote:
> >> >> In particular, magically
> >> >> substituting 127.0.0.
On Mon, Oct 12, 2015 at 4:15 PM, Robert Haas wrote:
> In this case, I think
> the best thing for me to do right now is wait to commit anything
> further until you have had a chance to go over this and come up with a
> fix or set of fixes that you think are completely, 100% ready to go;
> or else u
On 10/13/2015 02:02 AM, Robert Haas wrote:
> On Fri, Oct 9, 2015 at 4:38 PM, Amir Rohan wrote:
>> It does catch bad syntax, but in most cases all you get is
>> "The setting could not be applied". that's not great for enums
>> or a float instead of an int. I guess a future version will fix that
>>
Robert Haas writes:
> On Fri, Oct 9, 2015 at 10:16 PM, Noah Misch wrote:
>> The listening side is in good shape today. This thread is about the address
>> that pg_ctl uses in PQping("host=..."). Listening on 0.0.0.0 is portable.
>> PQping("host='0.0.0.0'") relies on non-portable semantics in th
On Sun, Oct 11, 2015 at 10:07 PM, Haribabu Kommi
wrote:
> Parallel aggregate is the feature doing the aggregation job parallel
> with the help of Gather and
> partial seq scan nodes. The following is the basic overview of the
> parallel aggregate changes.
>
> Decision phase:
>
> Based on the follo
On Tue, Oct 13, 2015 at 8:35 AM, Tom Lane wrote:
> Cause TestLib.pm to define $windows_os in all branches.
>
> Back-port of a part of commit 690ed2b76ab91eb79ea04ee2bfbdc8a2693f2a37 that
> I'd depended on without realizing that it was only added recently. Since
> it seems entirely likely that oth
On Tue, Oct 13, 2015 at 8:36 AM, Robert Haas wrote:
> 1. I'm not the only one doing it - i.e. at least 3 or 4
> moderately-frequent committers are all doing it consistently and all
> using the same format. If Tom buys into it, that's a big plus.
>
> 2. Adding the necessary metadata to a commit can
On Mon, Oct 12, 2015 at 08:07:37PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Oct 9, 2015 at 10:16 PM, Noah Misch wrote:
> >> The listening side is in good shape today. This thread is about the
> >> address
> >> that pg_ctl uses in PQping("host=..."). Listening on 0.0.0.0 is port
Michael Paquier writes:
> On Tue, Oct 13, 2015 at 8:35 AM, Tom Lane wrote:
>> Cause TestLib.pm to define $windows_os in all branches.
>>
>> Back-port of a part of commit 690ed2b76ab91eb79ea04ee2bfbdc8a2693f2a37 that
>> I'd depended on without realizing that it was only added recently. Since
>>
Michael Paquier writes:
> On Tue, Oct 13, 2015 at 8:36 AM, Robert Haas wrote:
>> 3. Adding the metadata doesn't cause lines > 70 characters. I am not
>> a fan of the "Discussion: Message-ID-Here" format which some
>> committers have begun using, sometimes with just the message ID and
>> sometimes
On Tue, Oct 13, 2015 at 11:31 AM, Tom Lane wrote:
> Hmm, well, why wasn't that back-patched? We expect these tests to run
> on Windows don't we?
The message related to this particular commit is here:
http://www.postgresql.org/message-id/55b90161.5090...@iki.fi
I recall that we discussed about bac
On Tue, Oct 13, 2015 at 12:14 PM, Robert Haas wrote:
> On Sun, Oct 11, 2015 at 10:07 PM, Haribabu Kommi
> wrote:
>> Parallel aggregate is the feature doing the aggregation job parallel
>> with the help of Gather and
>> partial seq scan nodes. The following is the basic overview of the
>> parallel
Hi Team,
Would like to propose a new DIAGNOSTICS attribute, which returns the no.of
rows got skipped during the FOR UPDATE SKIP LOCKED;
Using this attribute, we can have more control on parallel operations like,
IF SKIPPED_ROW_COUNT =0 THEN
<>
ELSE
<>
END IF;
Kindly let me know your inputs/sugg
dinesh kumar writes:
> Would like to propose a new DIAGNOSTICS attribute, which returns the no.of
> rows got skipped during the FOR UPDATE SKIP LOCKED;
I'm concerned that there may not be any implementation-independent
definition of this. That is, the query plan might or might not reject
rows be
On Mon, Oct 12, 2015 at 9:38 PM, Tom Lane wrote:
> dinesh kumar writes:
> > Would like to propose a new DIAGNOSTICS attribute, which returns the
> no.of
> > rows got skipped during the FOR UPDATE SKIP LOCKED;
>
> I'm concerned that there may not be any implementation-independent
> definition of
On Tue, Oct 13, 2015 at 7:41 AM, Tom Lane wrote:
> So there's still something to be desired on Windows; but it's still
> better than before in that we can reliably detect child process exit
> instead of having to use the five-second heuristic. And of course on
> Unix this is way better than befor
On Mon, Oct 12, 2015 at 5:15 PM, Amit Kapila
wrote:
>
>
> Right, it should initialize parallel scan properly even for
non-synchronized
> scans. Fixed the issue in attached patch. Rebased heap rescan is
> attached as well.
>
Attached is rebased patch for partial seqscan support. The major
chang
On 13 October 2015 at 17:09, Haribabu Kommi
wrote:
> On Tue, Oct 13, 2015 at 12:14 PM, Robert Haas
> wrote:
> > Also, I think the path for parallel aggregation should probably be
> > something like FinalizeAgg -> Gather -> PartialAgg -> some partial
> > path here. I'm not clear whether that is
55 matches
Mail list logo
