"David E. Wheeler" writes:
> On Jan 18, 2011, at 1:39 PM, Tom Lane wrote:
>> At the moment my opinion is that gist__int_ops is too broken to be
>> usable, and it's also too uncommented to be fixable by anyone other
>> than the original author.
> That seems to jibe with your comments from last yea
A.M. wrote:
>
> On Jan 18, 2011, at 3:55 PM, Bruce Momjian wrote:
>
> > I have modified test_fsync to use test labels that match wal_sync_method
> > values, and and added more tests for open_sync with different sizes.
> > This should make the program easier for novices to understand. Here is
>
Dne 18.1.2011 18:12, Robert Haas napsal(a):
> On Tue, Jan 18, 2011 at 4:53 AM, wrote:
>> So the most important question is how to intercept the new/updated rows,
>> and where to store them. I think each backend should maintain it's own
>> private list of new records and forward them only in case
On Jan 18, 2011, at 5:16 PM, Bruce Momjian wrote:
> A.M. wrote:
>>
>> On Jan 18, 2011, at 3:55 PM, Bruce Momjian wrote:
>>
>>> I have modified test_fsync to use test labels that match wal_sync_method
>>> values, and and added more tests for open_sync with different sizes.
>>> This should make
A.M. wrote:
>
> On Jan 18, 2011, at 5:16 PM, Bruce Momjian wrote:
>
> > A.M. wrote:
> >>
> >> On Jan 18, 2011, at 3:55 PM, Bruce Momjian wrote:
> >>
> >>> I have modified test_fsync to use test labels that match wal_sync_method
> >>> values, and and added more tests for open_sync with different
On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
> > Here they are. There are 16 patches in total. They amount to what's
> > currently in my refactor branch (and almost to what I've sent as the
> > complete refactor patch, while doi
2011/1/18 Tom Lane :
> Pavel Stehule writes:
>> 2011/1/18 Tom Lane :
>>> I looked at this patch and found it fairly awkward. What is the point
>>> of adding an additional flag to every variable, as opposed to just
>>> forcibly detoasting during assignment?
>
>> But detoasting on assignment isn't
On Jan 14, 2011, at 5:15 AM, Simon Riggs wrote:
> On Mon, 2010-12-13 at 17:15 +, Peter Geoghegan wrote:
>> On 13 December 2010 16:08, Robert Haas wrote:
>>> On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs wrote:
2. pg_validate_foreign_key('constraint name');
Returns immediately if FK
On Jan 18, 2011, at 5:21 PM, Bruce Momjian wrote:
> A.M. wrote:
>>
>> On Jan 18, 2011, at 5:16 PM, Bruce Momjian wrote:
>>
>>> A.M. wrote:
On Jan 18, 2011, at 3:55 PM, Bruce Momjian wrote:
> I have modified test_fsync to use test labels that match wal_sync_method
> valu
On Tue, 2011-01-18 at 14:26 -0600, Jim Nasby wrote:
> >
> > 2 sub-command changes:
> >
> > ALTER TABLE foo ADD FOREIGN KEY fkoo ... NOT VALID;
> >
> > ALTER TABLE foo VALIDATE CONSTRAINT fkoo;
>
> Sorry for the late reply; I just saw this...
>
> Is there any way to be able to get the bad recor
A.M. wrote:
> >> Because the fastest option may not be syncing to disk. For example,
> >> the only option that makes sense on OS X is fsync_writethrough- it
> >> would be helpful if the tool pointed that out (on OS X only, obviously).
> >
> > Yes, that would be a serious problem. :-(
> >
> > I a
Bruce Momjian writes:
> I have modified test_fsync to use test labels that match wal_sync_method
> values, and and added more tests for open_sync with different sizes.
Given that it was unclear whether the first such test was of any value,
why are you slowing down the program by adding more?
Tom Lane wrote:
> Bruce Momjian writes:
> > I have modified test_fsync to use test labels that match wal_sync_method
> > values, and and added more tests for open_sync with different sizes.
>
> Given that it was unclear whether the first such test was of any value,
> why are you slowing down the
On Jan 18, 2011, at 1:58 PM, Tom Lane wrote:
> I'm noticing also that I get different rowcounts than you do, although
> possibly that has something to do with the partial-index conditions,
> which I'm not trying to duplicate here (all rows in my table pass those
> two tests).
Shall I send you dat
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> I have modified test_fsync to use test labels that match wal_sync_method
>>> values, and and added more tests for open_sync with different sizes.
>> Given that it was unclear whether the first such test was of any value,
>> wh
"David E. Wheeler" writes:
> On Jan 18, 2011, at 1:58 PM, Tom Lane wrote:
>> I'm noticing also that I get different rowcounts than you do, although
>> possibly that has something to do with the partial-index conditions,
>> which I'm not trying to duplicate here (all rows in my table pass those
>>
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> I have modified test_fsync to use test labels that match wal_sync_method
> >>> values, and and added more tests for open_sync with different sizes.
>
> >> Given that it was unclear whether the first suc
On Jan 18, 2011, at 5:41 PM, Bruce Momjian wrote:
> A.M. wrote:
Because the fastest option may not be syncing to disk. For example,
the only option that makes sense on OS X is fsync_writethrough- it
would be helpful if the tool pointed that out (on OS X only, obviously).
>>>
>>> Y
A.M. wrote:
>
> On Jan 18, 2011, at 5:41 PM, Bruce Momjian wrote:
>
> > A.M. wrote:
> Because the fastest option may not be syncing to disk. For example,
> the only option that makes sense on OS X is fsync_writethrough- it
> would be helpful if the tool pointed that out (on OS X on
On Jan 18, 2011, at 3:08 PM, Tom Lane wrote:
>> Shall I send you data with the other two columns?:
>
> No, I see no reason to think that has much to do with it. I'm wondering
> if your table is itself a bit bloated ...
Nope. Just ran the bloat query from check_postgres.pl. Bloat is 0. Not
surp
I wrote:
> No, I see no reason to think that has much to do with it. I'm wondering
> if your table is itself a bit bloated ...
Actually ... I notice you did not show EXPLAIN ANALYZE output for your
tests. Now I'm wondering whether you tested the right thing at all.
I got burnt that way too. Obs
On Jan 18, 2011, at 3:46 PM, Tom Lane wrote:
> The above is "using" the index, but only as a guide to where the rows
> satisfying the partial-index predicate are --- note the lack of any
> index condition in the indexscan node. That's because the query_int
> query is not in fact compatible with t
I just got annoyed by the fact that contrib/intarray has support for
queries on GIN indexes on integer[] columns, but they only work if you
use the intarray-provided opclass, not the core-provided GIN opclass for
integer[] columns. In general, of course, two different GIN opclasses
aren't compatib
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Tuesday, January 18, 2011 2:53 PM
To: Simone Aiken
Cc: Alvaro Herrera; pgsql-hackers
Subject: Re: [HACKERS] ToDo List Item - System Table Index Clustering
>Sure - my point is just that we usually have as a criteri
Here is my review for this patch
Submission Review
-Patch applies cleanly
-Patch does not include documentation changes. At a minimum: update the
table that lists what pg_stat_activity and pg_stat_replication includes
in monitoring.sgml but I propose more below.
-No tests
I wrote:
> So here's what I'm thinking: we could redefine a GIN opclass, per se, as
> needing only compare() and extractValue() procs to be bound into it.
> The other three procs, as well as the query operators, could be "loose"
> in the containing opfamily. The index AM would choose which set of
On Tue, Jan 18, 2011 at 1:35 PM, Andreas Karlsson wrote:
> Hi Josh,
>
> Nope, I do not have any better ideas than "DO Blocks?".
>
> Everything looks good with the exception one bug now.
>
> \dL foo
> * QUERY **
> SELECT l.lanname AS "Name",
> pg_catalog.pg_get_userbyid(l.lano
2011/1/19 Peter Eisentraut :
> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
>> > Here they are. There are 16 patches in total. They amount to what's
>> > currently in my refactor branch (and almost to what I've sent as the
>> >
Excerpts from Steve Singer's message of mar ene 18 21:24:25 -0300 2011:
> Coding Review
> -
>
> As Alvaro pointed out BackendStatusShmemSize should be updated.
>
> To answer his question about why clientaddr works: clientaddr is a
> SockAddr which is a structure not a pointer so th
2011/1/18 Jan Urbański :
> On 17/01/11 09:26, Jan Urbański wrote:
>> On 17/01/11 01:02, Hitoshi Harada wrote:
>>> This is a review for the patch sent as
>>> https://commitfest.postgresql.org/action/patch_view?id=456
>>> It includes adequate amount of test. I found regression test failure
>>> in plp
On Tue, Jan 18, 2011 at 8:50 PM, Greg Smith wrote:
>> Why is the minimum value 64kB only when wal_buffers is set to
>> -1? This seems confusing for users.
>>
>
> That's because the current default on older versions is 64kB. Since the
> automatic selection is going to be the new default, I hope, I
Excerpts from Peter Eisentraut's message of mar ene 18 19:22:50 -0300 2011:
> #16: This is probably pointless because pgindent will reformat this.
pgindent used to remove useless braces around single-statement blocks,
but this behavior was removed years ago because it'd break formatting
around PG
On Tue, Jan 18, 2011 at 8:40 PM, Magnus Hagander wrote:
>> When I untar the tar file taken by pg_basebackup, I got the following
>> messages:
>>
>> $ tar xf base.tar
>> tar: Skipping to next header
>> tar: Archive contains obsolescent base-64 headers
>> tar: Error exit delayed from pre
Noah, thank you for this excellent review. I have taken over most
(allmost all) of your suggestions (except for the documentation which
is still missing). Please check the updated & attached patch for
details.
On Fri, Jan 14, 2011 at 10:13 PM, Noah Misch wrote:
> "" is a valid
On Wed, Jan 19, 2011 at 4:12 AM, Magnus Hagander wrote:
> Ah, ok. I've added the errorcode now, PFA. I also fixed an error in
> the change for result codes I broke in the last patch. github branch
> updated as usual.
Great. Thanks for the quick update!
Here are another comments:
+ * IDENTIFICAT
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Point being, until we get Andrew's jagged-csv-import magic committed to
> > core, we won't be able to import a log file that a user has changed the
> > field list for mid-stream (following the add-a-new-column use-case we've
> > be
On Thu, Jan 13, 2011 at 9:08 PM, Fujii Masao wrote:
> I did s/failover/promote. Here is the updated patch.
I rebased the patch to current git master.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
pg_ctl_promote_v3.patch
Description: Binary
101 - 137 of 137 matches
Mail list logo
