Marti Raudsepp writes:
> We're already seeing first buildfarm failures, on system "narwhal"
> using an msys/mingw compiler.
Yeah. After a full day's cycle, the answer seems to be that
denormalized input works fine everywhere except:
1. mingw on Windows (even though MSVC builds work)
2. some Ge
On 02/03/2012 03:49 AM, Tom Lane wrote:
Marti Raudsepp writes:
We're already seeing first buildfarm failures, on system "narwhal"
using an msys/mingw compiler.
Yeah. After a full day's cycle, the answer seems to be that
denormalized input works fine everywhere except:
1. mingw on Windows (
--On 3. Februar 2012 13:21:11 +0900 Fujii Masao wrote:
It seems to be more user-friendly to introduce a view like pg_stat_backup
rather than the function returning an array.
I like this idea. A use case i saw for monitoring backup_label's in the past,
was mainly to discover a forgotten exc
On Fri, Feb 3, 2012 at 6:10 PM, Bernd Helmle wrote:
>
>
> --On 3. Februar 2012 13:21:11 +0900 Fujii Masao
> wrote:
>
>> It seems to be more user-friendly to introduce a view like pg_stat_backup
>> rather than the function returning an array.
>
>
> I like this idea. A use case i saw for monitoring
On Fri, Feb 3, 2012 at 10:47, Fujii Masao wrote:
> On Fri, Feb 3, 2012 at 6:10 PM, Bernd Helmle wrote:
>>
>>
>> --On 3. Februar 2012 13:21:11 +0900 Fujii Masao
>> wrote:
>>
>>> It seems to be more user-friendly to introduce a view like pg_stat_backup
>>> rather than the function returning an arr
On Fri, Feb 3, 2012 at 6:52 PM, Magnus Hagander wrote:
> On Fri, Feb 3, 2012 at 10:47, Fujii Masao wrote:
>> On Fri, Feb 3, 2012 at 6:10 PM, Bernd Helmle wrote:
>>>
>>>
>>> --On 3. Februar 2012 13:21:11 +0900 Fujii Masao
>>> wrote:
>>>
It seems to be more user-friendly to introduce a view
* Peter Eisentraut wrote:
I noticed ecpglib still uses PQconnectdb() with a craftily assembled
connection string. Here is a patch to use PQconnectdbParams() instead.
+ const char *conn_keywords[6];
+ const char *conn_values[6];
Shouldn't these be [7]? You can have up to 6 items,
On Thu, Feb 2, 2012 at 8:31 PM, Joachim Wieland wrote:
> On Wed, Feb 1, 2012 at 12:24 PM, Robert Haas wrote:
>> I think we're more-or-less proposing to rename "Archive" to
>> "Connection", aren't we?
>>
>> And then ArchiveHandle can store all the things that aren't related to
>> a specific connec
On Sat, Jan 28, 2012 at 1:53 PM, Kohei KaiGai wrote:
> 2012/1/26 Robert Haas :
>> On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai wrote:
>>> It seems to me reasonable design.
>>> The attached patch is rebased one according to your perform-deletion patch.
>>
>> That looks pretty sensible. But I don
On Wed, Feb 1, 2012 at 2:39 PM, Simon Riggs wrote:
> On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut wrote:
>> On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
>>> Patch now locks index in AccessExclusiveLock in final stage of drop.
>>
>> Doesn't that defeat the point of doing the CONCURREN
If I run the following sequence of commands, I get an assertion
failure in current HEAD.
postgres=# BEGIN;
BEGIN
postgres=# SELECT 1/0;
ERROR: division by zero
postgres=# ROLLBACK TO A;
ERROR: no such savepoint
postgres=# \q
The process fails when the session is closed and aborted transaction
g
On Fri, Feb 3, 2012 at 7:52 AM, Robert Haas wrote:
> If you're OK with that much I'll go do it.
Sure, go ahead!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes wrote:
> On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra wrote:
>>
>> Fixed. The default value of TIMING option did not work as intended, it
>> was set to true even for plain EXPLAIN (without ANALYZE). In that case
>> the EXPLAIN failed.
>>
>
> I've appl
PostgreSQL 9.0.4:
While bringing up a streaming replica, and while it is working its way through
the WAL segments before connecting to the primary, I see a lot of messages of
the form:
2012-02-01 21:26:13.978 PST,,,24448,,4f2a1e61.5f80,54,,2012-02-01 21:25:53
PST,1/0,0,LOG,0,"restored log
On 3 Únor 2012, 17:12, Robert Haas wrote:
> On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes wrote:
>> On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra wrote:
>>>
>>> Fixed. The default value of TIMING option did not work as intended, it
>>> was set to true even for plain EXPLAIN (without ANALYZE). In t
On Fri, Feb 3, 2012 at 12:08 PM, Tomas Vondra wrote:
> I don't think changing the EXPLAIN syntax this way is a good idea. I think
> that one option should not silently enable/disable others, so ROWS should
> not enable ANALYZE automatically.
I didn't propose that. The point is that the desired b
On 3.2.2012 18:28, Robert Haas wrote:
> On Fri, Feb 3, 2012 at 12:08 PM, Tomas Vondra wrote:
>> I don't think changing the EXPLAIN syntax this way is a good idea. I think
>> that one option should not silently enable/disable others, so ROWS should
>> not enable ANALYZE automatically.
>
> I didn't
Hi Robert,
Thanks for the feedback! I think you make a good point about the small size of
dirty data in the OS cache. I think what you can say about this double-write
patch is that it will work not work well for configurations that have a small
Postgres cache and a large OS cache, since every
On Fri, Jan 27, 2012 at 8:35 AM, Heikki Linnakangas
wrote:
>> I think you should break this off into a new function,
>> LWLockWaitUntilFree(), rather than treating it as a new LWLockMode.
>> Also, instead of adding lwWaitOnly, I would suggest that we generalize
>> lwWaiting and lwExclusive into a
On Fri, Feb 3, 2012 at 3:14 PM, Dan Scales wrote:
> Thanks for the feedback! I think you make a good point about the small size
> of dirty data in the OS cache. I think what you can say about this
> double-write patch is that it will work not work well for configurations that
> have a small P
On Fri, Feb 3, 2012 at 2:56 PM, Tomas Vondra wrote:
> OK, thanks for the explanation. I don't like the idea of subsets as it
> IMHO makes it less obvious what options are enabled. For example this
>
> EXPLAIN (ROWS) query...
>
> does not immediately show it's actually going to do ANALYZE.
Well,
On 3.2.2012 22:51, Robert Haas wrote:
> On Fri, Feb 3, 2012 at 2:56 PM, Tomas Vondra wrote:
>> OK, thanks for the explanation. I don't like the idea of subsets as it
>> IMHO makes it less obvious what options are enabled. For example this
>>
>> EXPLAIN (ROWS) query...
>>
>> does not immediately
On Thu, Feb 2, 2012 at 8:48 PM, Tom Lane wrote:
> It's a bit disturbing that nobody has reported this from the field yet.
> Seems to imply that hot standby isn't being used much.
I have seen this, but didn't get to dig in, as I thought it could be a
problem from other things done outside Postgres
On Tue, Jan 31, 2012 at 3:43 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Tue, Jan 17, 2012 at 2:14 AM, Daniel Farina wrote:
>>> See the attached patch. It has a detailed cover letter/comment at the
>>> top of the file.
>
>> I have amended that description to be more accurate.
>
> I looked
On Thu, Feb 02, 2012 at 08:01:48PM +0200, Peter Eisentraut wrote:
> I noticed ecpglib still uses PQconnectdb() with a craftily assembled
> connection string. Here is a patch to use PQconnectdbParams() instead.
Thanks, committed. Will sync as soon as I'm online again.
Michael
--
Michael Meskes
M
On Fri, Feb 03, 2012 at 11:12:33AM -0500, Robert Haas wrote:
> After looking at this a bit, I think we can make the interface a bit
> more convenient. I'd like to propose that we call the EXPLAIN option
> "ROWS" rather than "TIMING", and that we provide the row-count
> information if *either* ROWS
Robert Haas wrote:
> A couple of things stand out at me from these graphs. First, some
> of these transactions had really long latency. Second, there are a
> remarkable number of seconds all of the test during which no
> transactions at all manage to complete, sometimes several seconds
> in a ro
On Fri, Feb 3, 2012 at 8:12 AM, Robert Haas wrote:
> On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes wrote:
>> On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra wrote:
>>>
>>> Fixed. The default value of TIMING option did not work as intended, it
>>> was set to true even for plain EXPLAIN (without ANAL
On Mon, Jan 16, 2012 at 5:59 PM, Greg Smith wrote:
> On 01/16/2012 11:00 AM, Robert Haas wrote:
>>
>> Also, I am still struggling with what the right benchmarking methodology
>> even is to judge whether
>> any patch in this area "works". Can you provide more details about
>> your test setup?
>
>
On Fri, Feb 3, 2012 at 12:57 PM, Robert Haas wrote:
>
> I think I recommended a bad name for this function. It's really
> LWLockAcquireOrWaitUntilFree. Can we rename that?
>
> We might also want to consider what all the behaviors are that we
> might want here. It strikes me that there are two p
On Mon, Jan 30, 2012 at 6:57 AM, Heikki Linnakangas
wrote:
> On 27.01.2012 15:38, Robert Haas wrote:
>>
>> On Fri, Jan 27, 2012 at 8:35 AM, Heikki Linnakangas
>> wrote:
>>>
>>> Yeah, we have to be careful with any overhead in there, it can be a hot
>>> spot. I wouldn't expect any measurable diff
On Mon, Jan 16, 2012 at 12:06 PM, Marti Raudsepp wrote:
>
> Here's v6 of my expression caching patch.
i little review...
first, i notice a change of behaviour... i'm not sure if i can say
this is good or not.
with this function:
"""
create or replace function cached_random() returns numeric as
32 matches
Mail list logo
