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 else before relinqui
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 about
> > >.net's intern
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
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 s
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 be an improvement.
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 = hentry->portal;
> >>
> >> +
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
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
> >enough
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. Thanks for the test case.
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 data,
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 timing
> > dependent: As
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. Please see attached a patch to
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 s
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 the close actually occ
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? */
>> if (portal->crea
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 do
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 the transient event object attachments.
>
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 look like any of the cleanup I suggested i
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 suspect that we'll contin
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 actua
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
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,
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 assoc
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 data you're putting in
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
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 results I shared 22.12.2015 are
wrong
>> > >
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 tha
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 probable reason of the pr
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 dela
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 I get a dump of "ta
On 2016-01-02 12:05, Amit Kapila wrote:
On Sat, Jan 2, 2016 at 3:16 PM, Andres Freund mailto:and...@anarazel.de>> 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
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 multiple people are looki
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
co
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
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 91fa7b4719ac583420d9143132b
35 matches
Mail list logo