Re: [HACKERS] Dangling Client Backend Process

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]

Re: [HACKERS] More work on SortSupport for text - strcoll() and strxfrm() caching

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,

Re: [HACKERS] point_ops for GiST

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

Re: [HACKERS] point_ops for GiST

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 > > >

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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 > >

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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 > + *

Re: [HACKERS] point_ops for GiST

>> 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

Re: [HACKERS] point_ops for GiST

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

Re: [HACKERS] point_ops for GiST

> 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 >

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Parallel Seq Scan

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.patch) for support of rescan (for parallel

Re: [HACKERS] Improve the concurency of vacuum full table and select statement on the same relation

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

Re: [HACKERS] Parallel Seq Scan

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

[HACKERS] pam auth - add rhost item

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.

Re: [HACKERS] Parallel Seq Scan

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] [PATCH v1] GSSAPI encryption support

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 @@

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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,

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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 > >>

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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,

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] point_ops for GiST

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

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] More work on SortSupport for text - strcoll() and strxfrm() caching

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

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

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

Re: [HACKERS] More work on SortSupport for text - strcoll() and strxfrm() caching

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%

Re: [HACKERS] Some questions about the array.

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

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

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,

Re: [HACKERS] Postgres service stops when I kill client backend on Windows

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

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

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

Re: [HACKERS] Parallel Aggregate

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

Re: [HACKERS] [COMMITTERS] pgsql: Cause TestLib.pm to define $windows_os in all branches.

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

Re: [HACKERS] More work on SortSupport for text - strcoll() and strxfrm() caching

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 >>

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

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

Re: [HACKERS] Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

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

Re: [HACKERS] bugs and bug tracking

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

Re: [HACKERS] pg_ctl/pg_rewind tests vs. slow AIX buildfarm members

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

Re: [HACKERS] Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')

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. >>

Re: [HACKERS] bugs and bug tracking

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

Re: [HACKERS] [COMMITTERS] pgsql: Cause TestLib.pm to define $windows_os in all branches.

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

Re: [HACKERS] Parallel Aggregate

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

[HACKERS] [PROPOSAL] DIAGNOSTICS = SKIPPED_ROW_COUNT

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

Re: [HACKERS] [PROPOSAL] DIAGNOSTICS = SKIPPED_ROW_COUNT

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

Re: [HACKERS] bugs and bug tracking

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

Re: [HACKERS] [COMMITTERS] pgsql: Cause TestLib.pm to define $windows_os in all branches.

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

Re: [HACKERS] [PROPOSAL] DIAGNOSTICS = SKIPPED_ROW_COUNT

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