On Tue, 2014-04-01 at 13:08 -0400, Tom Lane wrote:
> I think a patch that stood a chance of getting committed would need to
> detect whether the aggregate was being called in simple or grouped
> contexts, and apply different behaviors in the two cases.
The simple context doesn't seem like a big pr
25 окт. 2014 г., в 4:31, Jim Nasby написал(а):
> Please don't top-post.
>
> On 10/24/14, 3:40 AM, Borodin Vladimir wrote:
>> I have taken some backtraces (they are attached to the letter) of two
>> processes with such command:
>> pid=17981; while true; do date; gdb -batch -e back
>> /usr/pgsq
On Tue, 2014-12-16 at 00:27 +0100, Tomas Vondra wrote:
> > plperl.c: In function 'array_to_datum_internal':
> > plperl.c:1196: error: too few arguments to function 'accumArrayResult'
> > plperl.c: In function 'plperl_array_to_datum':
> > plperl.c:1223: error: too few arguments to function 'initArra
On Sun, 2014-12-21 at 13:00 -0500, Tom Lane wrote:
> Tomas Vondra writes:
> > i.e. either destroy the whole context if possible, and just free the
> > memory when using a shared memory context. But I'm afraid this would
> > penalize the shared memory context, because that's intended for cases
> >
On 29 December 2014 10:22 Amit Kapila Wrote,
>> Case1:In Case for CompleteDB:
>>
>> In base code first it will process all the tables in stage 1 then in stage2
>> and so on, so that at some time all the tables are analyzed at least up to
>> certain stage.
>>
>> But If we process all the stages f
On Wed, Dec 24, 2014 at 4:00 PM, Dilip kumar wrote:
>
> Case1:In Case for CompleteDB:
>
> In base code first it will process all the tables in stage 1 then in
stage2 and so on, so that at some time all the tables are analyzed at least
up to certain stage.
>
> But If we process all the stages for o
Hi
Currently tab completion for 'COMMENT ON {object} foo IS' will result in the
'IS'
being duplicated up to two times; not a world-shattering issue I know, but the
fix is trivial and I stumble over it often enough to for it to mildly annoy me.
Patch attached.
Regards
Ian Barwick
--
Ian Barw
Hi,
Anybody looks into problems in pgbench pointed out by Coverity? If no,
I would like to work on fixing them because I need to write patches
for "-f option" related issues anyway.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www
On 12/28/2014 04:58 PM, Noah Misch wrote:
On Sat, Oct 11, 2014 at 09:07:46AM -0400, Peter Eisentraut wrote:
On 10/11/14 1:41 AM, Noah Misch wrote:
Good question. It would be nice to make the change there, for the benefit of
other consumers. The patch's setlocale_native_forked() assumes it ne
On Sat, Dec 27, 2014 at 8:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Dec 27, 2014 at 7:55 PM, Tom Lane wrote:
>>> This would have the effect of transferring all responsibility for
>>> dead-stats-entry cleanup to autovacuum. For ordinary users, I think
>>> that'd be just fine. It m
On Sat, Oct 11, 2014 at 09:07:46AM -0400, Peter Eisentraut wrote:
> On 10/11/14 1:41 AM, Noah Misch wrote:
> > Good question. It would be nice to make the change there, for the benefit
> > of
> > other consumers. The patch's setlocale_native_forked() assumes it never
> > runs
> > in a multithre
On Sun, 2014-12-28 at 12:37 -0800, Jeff Davis wrote:
> I feel like I made a mistake -- can someone please do a
> sanity check on my numbers?
I forgot to randomize the inputs, which doesn't matter much for hashagg
but does matter for sort. New data script attached. The results are even
*better* for
On Thu, 2014-12-11 at 02:46 -0800, Jeff Davis wrote:
> On Sun, 2014-08-10 at 14:26 -0700, Jeff Davis wrote:
> > This patch is requires the Memory Accounting patch, or something similar
> > to track memory usage.
> >
> > The attached patch enables hashagg to spill to disk, which means that
> > hash
On Sun, Dec 28, 2014 at 12:37 PM, Jeff Davis wrote:
> Do others have similar numbers? I'm quite surprised at how little
> work_mem seems to matter for these plans (HashJoin might be a different
> story though). I feel like I made a mistake -- can someone please do a
> sanity check on my numbers?
On Tue, 2014-12-23 at 01:16 -0800, Jeff Davis wrote:
> New patch attached (rebased, as well).
>
> I also see your other message about adding regression testing. I'm
> hesitant to slow down the tests for everyone to run through this code
> path though. Should I add regression tests, and then remove
21.12.2014, 18:48, Fabrízio de Royes Mello kirjoitti:
> I work with some customer that have databases with a lot of schemas and
> sometimes we need to run manual VACUUM in one schema, and would be nice
> to have a new option to run vacuum in relations from a specific schema.
>
> The new syntax cou
On Sat, Dec 27, 2014 at 3:42 AM, Alexey Vasiliev wrote:
> Thanks for suggestions.
>
> Patch updated.
Cool, thanks. I just had an extra look at it.
+This is useful, if I using for restore of wal logs some
+external storage (like AWS S3) and no matter what the slave database
+
Hi all,
While reviewing another patch, I have noticed that recovery_min_apply_delay
can have a negative value. And the funny part is that we actually attempt
to apply a delay even in this case, per se this condition
recoveryApplyDelay@xlog.c:
/* nothing to do if no delay configured */
On 12/28/2014 10:18 PM, Ravi Kiran wrote:
> Sir, I followed the instructions in the link which you gave , but this
> time I am getting the following error.
>
> *Can't find a source file at
> "/build/buildd/eglibc-2.19/socket/../sysdeps/unix/sysv/linux/x86_64/recv.c" *
> *Locate the file or edit th
Sir, I followed the instructions in the link which you gave , but this time
I am getting the following error.
*Can't find a source file at
"/build/buildd/eglibc-2.19/socket/../sysdeps/unix/sysv/linux/x86_64/recv.c" *
*Locate the file or edit the source lookup path to include its location.*
is the
On 12/28/2014 07:49 PM, Ravi Kiran wrote:
> Thank you for the response sir, I am running both the eclipse and the
> client under the same user name which is ravi, I have installed postgres
> source code under the user ravi not postgres,
It doesn't matter how you installed it. How you *run* it matt
On Fri, Dec 26, 2014 at 4:16 PM, Michael Paquier
wrote:
> On Fri, Dec 26, 2014 at 3:24 PM, Fujii Masao
wrote:
>> pglz_compress() and pglz_decompress() still use PGLZ_Header, so the
frontend
>> which uses those functions needs to handle PGLZ_Header. But it basically
should
>> be handled via the va
On 12/28/2014 06:37 PM, Ravi Kiran wrote:
>
> "Could not attach to process. If your uid matches the uid of the target
> process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
> again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf"
>
> how do we rectify th
On 12/28/2014 06:37 PM, Ravi Kiran wrote:
>
> "Could not attach to process. If your uid matches the uid of the target
> process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
> again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf"
>
> how do we rectify th
hi,
I am working with postgresql 9.4.0 source using eclipse(indigo version) in
ubuntu 14.04. I am facing a problem of attaching a client process to
postgresql server.
I am following the steps given in this link
https://wiki.postgresql.org/wiki/Working_with_Eclipse#Debugging_PostgreSQL_from_Eclips
On 12/25/2014 02:35 AM, Euler Taveira wrote:
> Hi,
>
> Currently the same message goes to server log and client app. Sometimes
> it bothers me since I have to analyze server logs and discovered that
> lc_messages is set to pt_BR and to worse things that stup^H^H^H
> application parse some error me
26 matches
Mail list logo
