On Sun, Oct 11, 2015 at 10:09 AM, Tom Lane wrote:
> Dmitry Vasilyev writes:
> > The log you can see bellow:
> > ...
> > 2015-10-10 19:00:32 AST DEBUG: cleaning up dynamic shared memory
control segment with ID 851401618
> > 2015-10-10 19:00:32 AST DEBUG: invoking IpcMemoryCreate(size=290095104)
Dmitry Vasilyev writes:
> On Сб, 2015-10-10 at 10:55 -0500, Tom Lane wrote:
>> and (b) you still haven't convinced me that you had an actual service
>> stop, and not just that the recovery time was longer than psql would
>> wait before retrying the connection.
> The log you can see bellow:
> ..
On Sun, Oct 11, 2015 at 8:54 AM, Ali Akbar wrote:
> C:\Windows\system32>taskkill /F /PID 2080
> SUCCESS: The process with PID 2080 has been terminated.
taskkill /f *forcefully* terminates the process targeted [1]. Isn't
that equivalent to a kill -9? If you headshot a backend process on
Linux with
On Fri, Sep 25, 2015 at 2:39 PM, Jeff Janes wrote:
> This needs a rebase, there are several conflicts in
> src/backend/executor/nodeAgg.c
I attached a revised version of the second patch in the series, fixing
this bitrot.
I also noticed a bug in tuplesort's TSS_SORTEDONTAPE case with the
previo
On Thu, Sep 3, 2015 at 5:35 PM, David Rowley
wrote:
> My test cases are:
Note that my text caching and unsigned integer comparison patches have
moved the baseline down quite noticeably. I think that my mobile
processor out-performs the Xeon you used for this, which seems a
little odd even taken t
Greetings,
2015-10-11 0:18 GMT+07:00 Pavel Stehule :
>
> 2015-10-10 18:04 GMT+02:00 Dmitry Vasilyev :
>
>>
>> On Сб, 2015-10-10 at 10:55 -0500, Tom Lane wrote:
>> > Dmitry Vasilyev writes:
>> > > I have written, what service stopped. This action is repeatable.
>> > > You can run command 'psql -c
On Sat, Oct 10, 2015 at 10:52 PM, Amir Rohan wrote:
> On 10/10/2015 04:32 PM, Michael Paquier wrote:
> I was arguing that it's an on-going task that would do
> better if it had a TODO list, instead of "ideas for tests"
> being scattered across 50-100 messages spanning a year or
> more in one threa
On Fri, Oct 9, 2015 at 5:54 PM, Robert Haas wrote:
> I think that is true. I spent some time thinking about whether the
> way you used INT_MIN as a sentinel value should be changed around
> somehow, but ultimately I decided that it wasn't too bad and that
> suggesting something else would be poin
2015-10-10 18:04 GMT+02:00 Dmitry Vasilyev :
> Hello Tom!
>
> On Сб, 2015-10-10 at 10:55 -0500, Tom Lane wrote:
> > Dmitry Vasilyev writes:
> > > I have written, what service stopped. This action is repeatable.
> > > You can run command 'psql -c "do $$ unpack p,1x8 $$ language
> > > plperlu;"'
>
Hello Tom!
On Сб, 2015-10-10 at 10:55 -0500, Tom Lane wrote:
> Dmitry Vasilyev writes:
> > I have written, what service stopped. This action is repeatable.
> > You can run command 'psql -c "do $$ unpack p,1x8 $$ language
> > plperlu;"'
> > and after this windows service will stop.
>
> Well, (a)
Dmitry Vasilyev writes:
> I have written, what service stopped. This action is repeatable.
> You can run command 'psql -c "do $$ unpack p,1x8 $$ language plperlu;"'
> and after this windows service will stop.
Well, (a) that probably means that your plperl installation is broken,
and (b) you still
Jinyu writes:
> Proposal: vacuum full table takes an ExclusiveLock on relation instead of
> AccessExclusiveLock at start. It can' block select statement before call
> function "finish_heap_swap". and select statement is safe because vacuum full
> table copys tuples from old relation to new re
I have written, what service stopped. This action is repeatable.
You can run command 'psql -c "do $$ unpack p,1x8 $$ language plperlu;"'
and after this windows service will stop.
On Сб, 2015-10-10 at 10:23 -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Oct 9, 2015 at 5:52 AM, Dmitry Va
Now vacuum full table takes an AccessExclusiveLock on relation at start and
select statement takes an AccessShareLock on relation. So 'vacuum full table'
blocks select statement on the same table until it is committed and select
statement block 'vacuum full table' until it is finished. The concu
Robert Haas writes:
> On Fri, Oct 9, 2015 at 5:52 AM, Dmitry Vasilyev
>> postgres=# select 1;
>> server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the request.
>> The connection to the server was lost. Attempting reset:
On 2015-10-05 19:25, Alexander Korotkov wrote:
On Sun, Oct 4, 2015 at 4:27 PM, Amit Kapila mailto:amit.kapil...@gmail.com>> wrote:
On Sat, Oct 3, 2015 at 5:07 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote:
On 2015-10-03 08:27, Amit Kapila wrote:
On Fri, Oct 2, 20
On 10/10/2015 04:32 PM, Michael Paquier wrote:
> On Sat, Oct 10, 2015 at 9:04 PM, Amir Rohan wrote:
>> Now that v9 fixes the problem, here's a summary from going over the
>> entire thread one last time:
>
> Thanks a lot for the summary of the events.
>
>> # Windows and TAP sets
>> Noah (2015-03)
On 10/10/2015 04:32 PM, Michael Paquier wrote:
> On Sat, Oct 10, 2015 at 9:04 PM, Amir Rohan wrote:
>> The patch focuses on providing facilities, while providing new coverage
>> for several features. There should be a TODO list on the wiki (bug
>> tracker, actually), where the list of tests to be w
On Sat, Oct 10, 2015 at 9:04 PM, Amir Rohan wrote:
> Now that v9 fixes the probkem, here's a summary from going over the
> entire thread one last time:
Thanks a lot for the summary of the events.
> # Windows and TAP sets
> Noah (2015-03) mentioned TAP doesn't work on windows, and hoped
> this wou
On Sat, Oct 10, 2015 at 3:42 PM, Rajeev rastogi
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.
>
> Moreover it is also allowed to execute query on the connected client
> s
On 10/10/2015 02:43 PM, Michael Paquier wrote:
> On Fri, Oct 9, 2015 at 8:53 PM, Michael Paquier
> wrote:
>> On Fri, Oct 9, 2015 at 8:47 PM, Amir Rohan wrote:
>>> Ok, I've put myself down as reviewer in cfapp. I don't think I can
>>> provide any more useful feedback that would actually result in c
On Fri, Oct 9, 2015 at 8:53 PM, Michael Paquier
wrote:
> On Fri, Oct 9, 2015 at 8:47 PM, Amir Rohan wrote:
>> Ok, I've put myself down as reviewer in cfapp. I don't think I can
>> provide any more useful feedback that would actually result in changes
>> at this point, but I'll read through the ent
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.
Moreover it is also allowed to execute query on the connected client session
without any other background process.
But If I try to execu
23 matches
Mail list logo
