There is still valid a variant to move check function to contrib for fist
moment.
Regards
Pavel
2013/12/7 Pavel Stehule
> Hello
>
> thank you for review
>
>
> 2013/12/7 Steve Singer
>
>> On 08/22/2013 02:02 AM, Pavel Stehule wrote:
>>
>>> rebased
>>>
>>> Regards
>>>
>>> Pavel
>>>
>>> This p
On Fri, Dec 06, 2013 at 02:53:27PM +0100, Dr. Andreas Kunert wrote:
> >>Anything else missing?
> >
> >Functionally it's fine now, but I see few style problems:
> >
> >- "if (port->ssl > 0)" is wrong, ->ssl is pointer. So use just
> > "if (port->ssl)".
> >- Deeper indentation would look nicer wit
2013/12/6 Kohei KaiGai :
> What will happen if sender tries to send a large chunk that needs to
> be split into multiple sub-chunks and receiver concurrently detaches
> itself from the queue during the writes by sender?
> It seems to me the sender gets SHM_MQ_DETACHED and only
> earlier half of the
On Sun, Dec 8, 2013 at 1:00 AM, Peter Geoghegan wrote:
> On Sat, Dec 7, 2013 at 3:50 PM, Peter Eisentraut wrote:
> > 32-bit buildfarm members are having problems with this patch.
>
> This should fix that problem. Thanks.
>
Applied.
I also noted on
http://buildfarm.postgresql.org/cgi-bin/show_s
On Sun, Dec 8, 2013 at 3:41 AM, MauMau wrote:
> From: "MauMau"
>
> I've removed a limitation regarding event log on Windows with the attached
>> patch. I hesitate to admit this is a bug fix and want to regard this an
>> improvement, but maybe it's a bug fix from users' perspective. Actually,
On Sat, 2013-12-07 at 16:00 -0800, Peter Geoghegan wrote:
> On Sat, Dec 7, 2013 at 3:50 PM, Peter Eisentraut wrote:
> > 32-bit buildfarm members are having problems with this patch.
>
> This should fix that problem. Thanks.
This is incidentally the same problem that was reported here about
anoth
On Tue, 2013-11-19 at 18:24 +0100, Andres Freund wrote:
> On 2013-11-19 12:23:30 -0500, Robert Haas wrote:
> > On Mon, Nov 18, 2013 at 11:45 AM, Andres Freund
> > wrote:
> > >> Yes, we probably should make a decision, unless Robert's idea can be
> > >> implemented. We have to balance the ease of
On Tue, 2013-11-26 at 06:59 -0500, Peter Eisentraut wrote:
> Attached is my "final" patch. Let me know if it's OK for you.
Dimitri, will you have a change to review this?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
In my opinion, the idea of having a separate lint checker for a language
is antiquated. If there are problems, they should be diagnosed at
compile time or run time. You can add options about warning levels or
strictness if there are concerns about which diagnostics are
appropriate.
>
>
On Sun, 2013-12-08 at 09:45 +0100, Pavel Stehule wrote:
> There is still valid a variant to move check function to contrib for
> fist moment.
If we are not happy with the code or the interface, then moving it to
contrib is not a solution. We are still committed to main things in
contrib indefini
On Sun, 2013-12-08 at 01:32 +0100, Andres Freund wrote:
> Patch 02 converts some elog/ereport() callers to using the z modifier,
> some were wrong at least on 64 bit windows.
This is making the assumption that Size is the same as size_t. If we
are going to commit to that, we might as well g
On 2013-12-08 11:43:46 -0500, Peter Eisentraut wrote:
> On Sun, 2013-12-08 at 01:32 +0100, Andres Freund wrote:
> > Patch 02 converts some elog/ereport() callers to using the z modifier,
> > some were wrong at least on 64 bit windows.
>
> This is making the assumption that Size is the same a
2013/12/8 Peter Eisentraut
> In my opinion, the idea of having a separate lint checker for a language
> is antiquated. If there are problems, they should be diagnosed at
> compile time or run time. You can add options about warning levels or
> strictness if there are concerns about which diagno
Andrew Gierth writes:
> There's also the question of ungrouped vars, maybe. Consider these two
> queries:
> select array(select a+sum(x) from (values (0.3),(0.7)) v(a) group by a)
> from generate_series(1,5) g(x);
> select array(select percentile_disc(a) within group (order by x)
>
Joe Conway writes:
> I don't think it makes sense to create a new function in dblink either
> -- we're only talking about two lines of added redundancy which is
> less lines of code than a new function would add.
Indeed, and I think the claim that such a function "encapsulates" anything
useful is
On Sun, Dec 8, 2013 at 12:06 AM, Mark Kirkwood
wrote:
>
> bench=# ANALYZE pgbench_accounts;
> NOTICE: acquire sample will need 3 blocks
> NOTICE: sampled 3 blocks
> ANALYZE
> Time: 10059.446 ms
> bench=# \q
I did some experimenting here as well.
I hacked up a version of analyze.c that
2013/12/8 Dean Rasheed
> On 7 December 2013 21:34, Pavel Stehule wrote:
> >> Well I was basically proposing that does_not_exist_skipping() be
> >> enhanced to report on non-existent types that form part of the object
> >> specification. I think this would affect the CAST, FUNCTION, AGGREGATE
> >
On 12/08/2013 10:14 AM, Greg Stark wrote:
> With rows_per_block=1 the MCV frequency list ranges from .0082 to .0123
> With rows_per_block=4 the MCV frequency list ranges from .0063 to .0125
> With rows_per_block=16 the MCV frequency list ranges from .0058 to .0164
> With rows_per_block=64 the M
On 12/08/2013 08:14 PM, Greg Stark wrote:
The whole accounts table is 1.2GB and contains 10 million rows. As
expected with rows_per_block set to 1 it reads 240MB of that
containing nearly 2 million rows (and takes nearly 20s -- doing a full
table scan for select count(*) only takes about 5s):
O
On Fri, Nov 29, 2013 at 11:17 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 11/29/2013 11:41 AM, Heikki Linnakangas wrote:
>
>> On 11/28/2013 09:19 AM, Alexander Korotkov wrote:
>>
>>> On Wed, Nov 27, 2013 at 1:14 AM, Heikki Linnakangas
>>> >>
wrote:
>>>
>>> On 11/26/13
From: "Magnus Hagander"
Not having looked at it in detail yet, but this seems to completely remove
the default value. What happens if the error that needs to be logged is
the
one saying that it couldn't exec postgres to find out the value in the
config file? AFAICT it's going to try to registe
From: "David Johnston"
5. FATAL: terminating walreceiver process due to administrator command
6. FATAL: terminating background worker \"%s\" due to administrator
command
5 and 6: I don't fully understand when they would happen but likely fall
into the same "the DBA should know what is going o
From: "Greg Stark"
On the client end the FATAL is pretty logical but in the logs it makes
it sound like the entire server died. Especially in this day of
multithreaded servers. I was suggesting that that was the origin of
the confusion here. Anyone who has seen these messages on the client
end m
On Sun, Dec 8, 2013 at 7:03 PM, Josh Berkus wrote:
> They will certainly do so if you don't apply any statistical adjustments
> for selecting more rows from the same pages.
>
> So there's a set of math designed to calculate for the skew introduced
> by reading *all* of the rows in each block.
I j
On 09/12/13 08:03, Josh Berkus wrote:
So there's a set of math designed to calculate for the skew introduced
by reading *all* of the rows in each block. That's what I meant by
"block-based sampling"; you read, say, 400 pages, you compile statistics
on *all* of the rows on those pages, you apply
On 12/5/13 9:59 AM, Tom Lane wrote:
Greg Stark writes:
I think the way to use mmap would be to mmap very large chunks,
possibly whole tables. We would need some way to control page flushes
that doesn't involve splitting mappings and can be efficiently
controlled without having the kernel storin
If I'm understanding the vacuum truncate bug correctly, it can be avoided if
every 2^31 transactions[1] you:
SET vacuum_freeze_table_age = 0;
VACUUM FREEZE;
table_age = 0 disables partial vacuum and then everything[1] gets frozen,
eliminating the risk. Or am I missing something?
[1]: Obviousl
On Mon, Dec 9, 2013 at 6:33 AM, Jim Nasby wrote:
> If I'm understanding the vacuum truncate bug correctly, it can be avoided if
> every 2^31 transactions[1] you:
>
> SET vacuum_freeze_table_age = 0;
> VACUUM FREEZE;
>
> table_age = 0 disables partial vacuum and then everything[1] gets frozen,
> el
> "Tom" == Tom Lane writes:
Tom> We could alternatively decide that the agg has level 0, but that
Tom> doesn't seem terribly useful, and I think it's not per spec
Tom> either. SQL:2008 section 6.9 seems
Tom> pretty clear that only aggregated arguments should be considered
Tom> when det
On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule wrote:
>
>
>
> 2013/12/8 Peter Eisentraut
>>
>> In my opinion, the idea of having a separate lint checker for a language
>> is antiquated. If there are problems, they should be diagnosed at
>> compile time or run time. You can add options about war
On Mon, Dec 9, 2013 at 2:25 AM, MauMau wrote:
> From: "Magnus Hagander"
>
>> Not having looked at it in detail yet, but this seems to completely remove
>> the default value. What happens if the error that needs to be logged is
>> the
>> one saying that it couldn't exec postgres to find out the va
2013/12/9 Amit Kapila
> On Sun, Dec 8, 2013 at 10:31 PM, Pavel Stehule
> wrote:
> >
> >
> >
> > 2013/12/8 Peter Eisentraut
> >>
> >> In my opinion, the idea of having a separate lint checker for a language
> >> is antiquated. If there are problems, they should be diagnosed at
> >> compile time
(2013/12/05 23:42), Greg Stark wrote:
On Thu, Dec 5, 2013 at 8:35 AM, KONDO Mitsumasa
wrote:
Yes.　And using something efficiently DirectIO is more difficult than
BufferedIO.
If we change write() flag with direct IO in PostgreSQL, it will execute
hardest ugly randomIO.
Using DirectIO presumes
Robert Haas wrote:
> On Fri, Dec 6, 2013 at 5:02 AM, Etsuro Fujita
> wrote:
> > Though at first I agreed on this, while working on this I start to
> > think information about (2) is enough for tuning work_mem. Here are
> > examples using a version under development, where "Bitmap Memory
> > Usage
On 29 November 2013 19:20, Rajeev rastogi wrote:
> On 26 November 2013, Amit Khandelkar wrote:
>
> >Can you please submit the \COPY patch as a separate patch ? Since these
> are two different issues, I would like to have these two fixed and
> committed separately. You can always test the \COPY i
BTW, thanks to all who helped in improving this issue.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
36 matches
Mail list logo
