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
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
On 2015-10-05 19:25, Alexander Korotkov wrote:
On Sun, Oct 4, 2015 at 4:27 PM, Amit Kapila > wrote:
On Sat, Oct 3, 2015 at 5:07 PM, Petr Jelinek > wrote:
On 2015-10-03
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
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)
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
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,
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
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
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
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
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
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
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
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
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
On 2015/10/03 6:18, Peter Geoghegan wrote:
On Wed, Sep 2, 2015 at 7:41 PM, Satoshi Nagayasu wrote:
I know this still needs to be discussed, but I would like to submit
a patch for further discussion at the next CF, 2015-11.
I think I already expressed this in my explanation
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
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
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,
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 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
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
23 matches
Mail list logo