Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Hi Petr, On 2016-01-02 09:17:02 +0100, Petr Jelinek wrote: > so the commit which triggers this issue is > 387da18874afa17156ee3af63766f17efb53c4b9 , not sure why yet (wanted to give > heads up early since multiple people are looking at this). Note that the > compilation around this commit is made

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 14:26:47 +0100, Andres Freund wrote: > On 2016-01-02 18:40:38 +0530, Amit Kapila wrote: > > If we > > remember the closed socket event and then take appropriate action, > > then this problem won't happen. Attached patch which by no-means > > a complete fix shows what I wanted to say

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 12:05, Amit Kapila wrote: On Sat, Jan 2, 2016 at 3:16 PM, Andres Freund > wrote: Hi Petr, On 2016-01-02 09:17:02 +0100, Petr Jelinek wrote: > so the commit which triggers this issue is >

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 18:40:38 +0530, Amit Kapila wrote: > What I wanted to say is that the handling of socket closure is not > same in WaitLatchOrSocket() and pgwin32_waitforsinglesocket() > due to which this problem can arise and it seems that is the > right line of direction to pursue. I have found

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Hi, so the commit which triggers this issue is 387da18874afa17156ee3af63766f17efb53c4b9 , not sure why yet (wanted to give heads up early since multiple people are looking at this). Note that the compilation around this commit is made harder by the fact that commit

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On Sat, Jan 2, 2016 at 3:16 PM, Andres Freund wrote: > Hi Petr, > > On 2016-01-02 09:17:02 +0100, Petr Jelinek wrote: > > so the commit which triggers this issue is > > 387da18874afa17156ee3af63766f17efb53c4b9 , not sure why yet (wanted to > give > > heads up early since

Re: [HACKERS] pg_dump LOCK TABLE ONLY question

On Sat, Jan 2, 2016 at 12:28 PM, Noah Misch wrote: > On Sat, Oct 31, 2015 at 10:14:18AM +0100, Simon Riggs wrote: >> I agree with Filip that this is a bug. pg_dump clearly doesn't work >> correctly with inheritance. >> >> If I run this command >> >> pg_dump -t tab1 >> >> then

[HACKERS] Release notes of 9.0~9.3 mentioning recovery_min_apply_delay incorrectly

Hi all, While doing a git grep on recovery_min_apply_delay I noticed the following: $ git grep recovery_min_apply -- *release*.sgml src/sgml/release-9.0.sgml: that recovery_min_apply_delay failed to delay application src/sgml/release-9.1.sgml: that recovery_min_apply_delay failed to

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Wed, Dec 30, 2015 at 1:10 PM, Oleg Bartunov wrote: > > > > On Wed, Dec 30, 2015 at 5:44 PM, Andres Freund wrote: >> >> On 2015-12-30 11:37:19 -0300, Alvaro Herrera wrote: >> > Aleksander Alekseev wrote: >> > >> > > Here is a funny thing - benchmark

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 10:46, Andres Freund wrote: Hi Petr, On 2016-01-02 09:17:02 +0100, Petr Jelinek wrote: so the commit which triggers this issue is 387da18874afa17156ee3af63766f17efb53c4b9 , not sure why yet (wanted to give heads up early since multiple people are looking at this). Note that the

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On Sat, Jan 2, 2016 at 5:02 PM, Petr Jelinek wrote: > On 2016-01-02 12:05, Amit Kapila wrote: >> >> I am also able to reproduce now. The reason was that I didn't have >> latest .Net framework and Visual Studio, which is must for the recent >> version of Npgsql. >> >> One

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

Noah Misch writes: > On Thu, Sep 03, 2015 at 11:04:11PM -0400, Tom Lane wrote: >> *** AtSubAbort_Portals(SubTransactionId mySu >> --- 909,966 >> { >> Portal portal = hentry->portal; >> >> +/* Was it created in this subtransaction? */

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 16:20:58 +0100, Andres Freund wrote: > I really right now can see only two somewhat surgical fixes: > > 1) We do a nonblocking or select() *after* registering our events. Both >in WaitLatchOrSocket() and waitforsinglesocket. Since select/poll are >explicitly level triggered,

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > A bit of searching around brought up that we saw issues around this > before: > http://www.postgresql.org/message-id/4351.1336927...@sss.pgh.pa.us Indeed. It doesn't look like any of the cleanup I suggested in that thread has ever gotten done. I

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 13:00:09 -0500, Tom Lane wrote: > : More generally, it seems clear to me that Microsoft's code is designed > : around the assumption that an event object remains attached to a socket > : for the lifetime of the socket. This business of transiently associating > : event objects with

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 15:40:03 +0100, Andres Freund wrote: > I wonder if the following is the problem: The docs for WSAEventSelect() > says: > "Having successfully recorded the occurrence of the network event (by > setting the corresponding bit in the internal network event record) and > signaled the

Re: [HACKERS] Welcome to 2016, time to run src/tools/copyright.pl

On Fri, Jan 1, 2016 at 04:43:07PM +0900, Michael Paquier wrote: > Hi all, > > Happy new year to all and best wishes! > > I guess that the following command followed by a commit is the common > happy-new-year thing to do: > perl src/tools/copyright.pl > This would update the copyright headers to

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On January 2, 2016 6:28:10 PM GMT+01:00, Tom Lane wrote: >Andres Freund writes: >> A bit of searching around brought up that we saw issues around this >> before: >> http://www.postgresql.org/message-id/4351.1336927...@sss.pgh.pa.us > >Indeed. It doesn't

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

Tom Lane writes: > Andreas Seltenreich writes: >> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424) >> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564) > > Can you show us the definition of the index that's causing this, > and some samples of the

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 15:40:03 +0100, Andres Freund wrote: > If FD_CLOSE is indeed edge and not level triggered - which imo would be > supremely insane - we'd be in trouble. It'd explain why some failures > are noticed and others not. I wonder if the FD_CLOSE and FD_WRITE being edge-triggered is the

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > On January 2, 2016 6:28:10 PM GMT+01:00, Tom Lane wrote: >> Indeed. It doesn't look like any of the cleanup I suggested in that >> thread has ever gotten done. I suspect that we'll continue to see >> problems until we get rid of

Re: [HACKERS] Welcome to 2016, time to run src/tools/copyright.pl

On Sat, Jan 2, 2016 at 12:00:36PM -0500, Bruce Momjian wrote: > On Fri, Jan 1, 2016 at 04:43:07PM +0900, Michael Paquier wrote: > > Hi all, > > > > Happy new year to all and best wishes! > > > > I guess that the following command followed by a commit is the common > > happy-new-year thing to

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund writes: > I found a few more resources confirming that FD_CLOSE is edge > triggered. Which probably doesn't just make our code buggy when waiting > twice on the same socket, but probably also makes it very timing > dependent: As the event is only triggered when

Re: [HACKERS] Release notes of 9.0~9.3 mentioning recovery_min_apply_delay incorrectly

Michael Paquier writes: > This is obviously incorrect because recovery_min_apply_delay has been only > introduced in 9.4. The culprit is visibly the commit message of 8049839 and > others that mentioned the parameter, though the patch applied does nothing > about it.

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Sat, Jan 02, 2016 at 01:46:07PM -0500, Tom Lane wrote: > Noah Misch writes: > > On Thu, Sep 03, 2015 at 11:04:11PM -0400, Tom Lane wrote: > >> *** AtSubAbort_Portals(SubTransactionId mySu > > >> --- 909,966 > >> { > >> Portal portal =

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

Noah Misch writes: > I am inclined to add an Assert(portal->status != PORTAL_ACTIVE) to emphasize > that this is backup only. MarkPortalActive() callers remain responsible for > updating the status to something else before relinquishing control. No, I do not think that would

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 22:31, Andres Freund wrote: On 2016-01-02 22:25:31 +0100, Brar Piening wrote: Andres Freund wrote: That seems like a pretty straight forward bug. But it hinges on the client side calling shutdown() on the socket. I don't know enough about .net's internals to judge wether it does

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 15:11:42 -0500, Tom Lane wrote: > Andres Freund writes: > > I found a few more resources confirming that FD_CLOSE is edge > > triggered. Which probably doesn't just make our code buggy when waiting > > twice on the same socket, but probably also makes it very

Re: [HACKERS] Improved error reporting in format()

On 1/2/16 5:57 PM, Jim Nasby wrote: Attached patch clarifies that %-related error messages with hints as well as (IMHO) improving the clarity of the message: Sorry, forgot to update regression tests. New patch attached. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in

[HACKERS] Improved error reporting in format()

The current error message for an invalid format conversion type is extremely confusing except in the simplest of uses: select format( '% moo'); ERROR: unrecognized conversion type specifier " " Obviously in that example you can figure out what's going on, but frequently format() is used in a

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

Andres Freund wrote: That seems like a pretty straight forward bug. But it hinges on the client side calling shutdown() on the socket. I don't know enough about .net's internals to judge wether it does so. I've traced things far enough to find "Disposing a Stream object flushes any buffered

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

Andreas Seltenreich writes: > Here's a recipe for triggering the former: > create table t(c text); > create index on t using spgist(c); > insert into t select '' from generate_series(1,1); > set enable_seqscan to off; select count(1) from t; Ah-hah.

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On 2016-01-02 22:25:31 +0100, Brar Piening wrote: > Andres Freund wrote: > >That seems like a pretty straight forward bug. But it hinges on the > >client side calling shutdown() on the socket. I don't know enough about > >.net's internals to judge wether it does so. I've traced things far >

Re: [HACKERS] Some 9.5beta2 backend processes not terminating properly?

On Sun, Jan 3, 2016 at 3:01 AM, Andres Freund wrote: > On 2016-01-02 22:25:31 +0100, Brar Piening wrote: > > Andres Freund wrote: > > >That seems like a pretty straight forward bug. But it hinges on the > > >client side calling shutdown() on the socket. I don't know enough

Re: [HACKERS] Fwd: Core dump with nested CREATE TEMP TABLE

On Sat, Jan 02, 2016 at 07:22:13PM -0500, Tom Lane wrote: > Noah Misch writes: > > I am inclined to add an Assert(portal->status != PORTAL_ACTIVE) to emphasize > > that this is backup only. MarkPortalActive() callers remain responsible for > > updating the status to something