On Wed, Mar 25, 2009 at 7:29 AM, Fujii Masao wrote:
> Attached patch fixes the above problem by adding a new trigger option
> to pg_standby; the presence of this new trigger file causes recovery to
> end after replaying all the available WAL files.
Shouldn't it be the default? It seems like the m
Hi,
Current pg_standby is dangerous because the presence of the trigger
file causes recovery to end whether or not the next WAL file is available.
So, some *available* transactions may be lost at failover. Such danger
will become high if the standby server has not caught up with the primary.
Atta
On Tue, 24 Mar 2009, Sam Mason wrote:
The conceptual idea is to have at most one outstanding flush for the
log going through the filesystem at any one time.
Quoting from src/backend/access/transam/xlog.c, inside XLogFlush:
"Since fsync is usually a horribly expensive operation, we try to
pig
Sorry for top-posting -- blame apple.
Isn't this just a good description of exactly how it works today?
--
Greg
On 24 Mar 2009, at 20:51, Tom Lane wrote:
Sam Mason writes:
The conceptual idea is to have at most one outstanding flush for the
log going through the filesystem at any one time
Tom,
The other global lists seem to be in good health from what I can see.
Can't speak to the regional or user-group lists, I don't follow them.
Those have specific reasons to survive regardless of traffic level.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
> "David" == "David E Wheeler" writes:
> On Mar 24, 2009, at 2:51 PM, Andrew Gierth wrote:
>> By popular demand, a version of this will go up on pgfoundry for
>> use with 8.3 etc.
David> Wow. Nice stuff! I hope it's not too late for 8.4…
I personally have no expectation of it getting in
Josh Berkus writes:
> I'm not sure about -interfaces, but -performance, -sql, -jdbc and others
> definitely have specific audiences and themes which they are already
> handling a *lot* of traffic for.
It does look like -interfaces is dying: almost no traffic, and what
questions it does get are
> "Sam" == Sam Mason writes:
Sam> Hi,
Sam> I had an idea while going home last night and still can't think
Sam> why it's not implemented already as it seems obvious.
[snip idea about WAL fsyncs]
Unless I'm badly misunderstanding you, I think it already has (long
ago).
Only the holder of
Personally I'm of the opinion we should eliminate most of these
duplicative mailing lists like -performance and -interfaces and just
use -general. I don't see that having multiple lists for user
questions helps either the users or the answerers due to just this
type of problem.
... and instead
Greg Stark writes:
> On Tue, Mar 24, 2009 at 9:31 PM, Robert Lor wrote:
>> I think the is-enabled test will address the issues you encountered. I see a
>> few alternative to fixing this:
> Another option is to impose a policy that all arguments to probes must
> be simple local variables -- no ex
On 3/24/09 3:38 PM, David E. Wheeler wrote:
On Mar 24, 2009, at 2:51 PM, Andrew Gierth wrote:
By popular demand, a version of this will go up on pgfoundry for use
with 8.3 etc.
Wow. Nice stuff! I hope it's not too late for 8.4…
It is for anything but the undocumented size limits, which are
Sam Mason writes:
> The conceptual idea is to have at most one outstanding flush for the
> log going through the filesystem at any one time.
I think this is a variant of the "group commit" or "commit delay"
stuff that's already in there (and doesn't work real well :-().
The problem is to sync mul
On Tue, Mar 24, 2009 at 04:55:47PM -0700, Josh Berkus wrote:
> On 3/24/09 1:18 PM, Tom Lane wrote:
>> I've committed this patch with additional editorialization --- mostly
>> cosmetic changes, except for removing the stats-driven cleanup in favor
>> of letting cleanups occur during auto-ANALYZE, as
On 3/24/09 1:18 PM, Tom Lane wrote:
I've committed this patch with additional editorialization --- mostly
cosmetic changes, except for removing the stats-driven cleanup in favor
of letting cleanups occur during auto-ANALYZE, as per my suggestion
yesterday.
By my count, this was the last patch l
Hi,
I had an idea while going home last night and still can't think why it's
not implemented already as it seems obvious.
The conceptual idea is to have at most one outstanding flush for the
log going through the filesystem at any one time. The effect, as far
as I can think through, would be to
On Tue, Mar 24, 2009 at 10:53 PM, Martijn van Oosterhout
wrote:
> Sorry, I meant to say that the compiler could determine the address at
> compile time, something like:
>
> __builtin_constant_p( !&(__x)) )
Hm, that's a better idea.
How about something like
(__builtin_constant_p(__x) || __builti
On Tue, Mar 24, 2009 at 10:18:08PM +, Greg Stark wrote:
> On Tue, Mar 24, 2009 at 10:12 PM, Martijn van Oosterhout
> wrote:
> > Not really a GCC extension, but you could have the macro check that it
> > can take the address of the arguments, which amounts to almost the same
> > thing. It only
On Mar 24, 2009, at 2:51 PM, Andrew Gierth wrote:
By popular demand, a version of this will go up on pgfoundry for use
with 8.3 etc.
Wow. Nice stuff! I hope it's not too late for 8.4…
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
On Mar 24, 2009, at 9:41 AM, Bruce Momjian wrote:
So far taking the CVS logs and making a list of only the items we want
for the release notes took one day; researching and rewording the
items
so they are ready for the release notes took five days; grouping them
into sections and rewording/
On Tue, Mar 24, 2009 at 10:12 PM, Martijn van Oosterhout
wrote:
> Not really a GCC extension, but you could have the macro check that it
> can take the address of the arguments, which amounts to almost the same
> thing. It only doesn't work on constants.
No, there are all kinds of complex express
On Tue, Mar 24, 2009 at 09:49:50PM +, Greg Stark wrote:
> I wonder if there's a gcc extension that would let us check if a macro
> parameter is a simple variable or expression. That would let us
> enforce the polilcy strictly at build-time.
Not really a GCC extension, but you could have the ma
On Tue, Mar 24, 2009 at 9:31 PM, Robert Lor wrote:
>
> I think the is-enabled test will address the issues you encountered. I see a
> few alternative to fixing this:
Another option is to impose a policy that all arguments to probes must
be simple local variables -- no expressions.
I'm starting
Tom Lane wrote:
Whilst cleaning up the dtrace probe documentation, I realized that
there is nothing the aforementioned probes tell you that you can't find
out (with a lot more data besides) from the final argument of the
BUFFER_READ_DONE probe. Furthermore, tallying them as-is would be
misleadin
Tom Lane wrote:
Greg Stark writes:
i like the idea of just have a separate pair of probes for table
extension. I bet there are people who would actually like to see that
alone sometimes too.
After further thought I concluded that the best solution for this is to
add the isExtend flag
Tom Lane wrote:
Zdenek Kotala writes:
Answer why it happens when probes are disabled is, that for user
application there are piece of code which prepare DTrace probes
arguments which will be passed into kernel DTrace modul. This code has
performance penalty which depends on number of argum
Robert Haas writes:
> 2009/3/24 Tom Lane :
>> catversion bumped because of change in GIN's pg_am entry, and because
>> the format of GIN indexes changed on-disk (there's a metapage now,
>> and possibly a pending list).
> Will this break pg_migrator?
No worse than it's already broken by hash inde
2009/3/24 Tom Lane :
> Implement "fastupdate" support for GIN indexes, in which we try to accumulate
> multiple index entries in a holding area before adding them to the main index
> structure. This helps because bulk insert is (usually) significantly faster
> than retail insert for GIN.
>
> This
Thanks ! Now, it works fine.
Greg Stark wrote:
> Personally I'm of the opinion we should eliminate most of these
> duplicative mailing lists like -performance and -interfaces and just
> use -general. I don't see that having multiple lists for user
> questions helps either the users or th
I've committed this patch with additional editorialization --- mostly
cosmetic changes, except for removing the stats-driven cleanup in favor
of letting cleanups occur during auto-ANALYZE, as per my suggestion
yesterday.
regards, tom lane
--
Sent via pgsql-hackers mailing
> "Andrew" == Andrew Gierth writes:
Andrew> - many new functions and operators:
Andrew> hstore = hstore returns hstore (equality)
Andrew> hstore <> hstore returns hstore (inequality)
Of course those should be
hstore = hstore returns boolean (equality)
hstore
Patch attached, also available at
http://www.rhodiumtoad.org.uk/junk/hstore_20090324.patch.txt
The user-visible changes are:
- removal of previous 65535-byte limit on keys/values; both keys and
values can now be as long as desired, within the 1GB limit for the
whole hstore value (though
Just returned from vacation ...
Tom Lane wrote:
I notice that we have in md.c
TRACE_POSTGRESQL_SMGR_MD_READ_DONE(forknum, blocknum, reln->smgr_rnode.spcNode,
reln->smgr_rnode.dbNode, reln->smgr_rnode.relNode, relpath(reln->smgr_rnode,
forknum), nbytes, BLCKSZ);
TRACE_POSTGRES
On Tue, Mar 24, 2009 at 2:11 PM, Greg Stark wrote:
> Personally I'm of the opinion we should eliminate most of these
> duplicative mailing lists like -performance and -interfaces and just
> use -general. I don't see that having multiple lists for user
> questions helps either the users or the answ
On Tue, Mar 24, 2009 at 4:54 PM, Ben Ali Rachid wrote:
> Hello,
>
> I posted my problem (on pgsql-interfaces list) about the INOUT parameters on
> PostgreSQL 8.3.6 (Win32), but without success. I re-post my question here,
> while hoping to have more success.
Personally I'm of the opinion we shoul
Ben Ali Rachid writes:
> I posted my problem (on pgsql-interfaces list) about the INOUT parameters on
> PostgreSQL 8.3.6 (Win32), but without success. I re-post my question here,
> while hoping to have more success.
You apparently have no understanding at all of how parameters are passed
to and
Hello,
I posted my problem (on pgsql-interfaces list) about the INOUT parameters on
PostgreSQL 8.3.6 (Win32), but without success. I re-post my question here,
while hoping to have more success.
When I use a function with one INOUT (or OUT) parameter like below, everyting
is OK.
CREATE OR REP
ginInsertCleanup(); is it accurate? (If it isn't, I think
Exactly, that is right.
* This can be called concurrently by multiple backends, so it must cope.
* On first glance it looks completely not concurrent-safe and not crash-safe
* either. The reason it's okay is that multiple inserti
Teodor Sigaev writes:
> Oops, I was wrong, I supposed that all pages in chunk should be lossy, but
> it's
> true only for chunk page. So, tbm_add_page() should only call
> tbm_mark_page_lossy()...
OK, thanks, that's what I thought. I've changed it in the copy I'm
editing here.
I have another
Why is tbm_add_page() not coded as a simple wrapper around
tbm_mark_page_lossy()? As coded, it sometimes forces a whole bunch of
pages *other than* the target page to become lossy too, which I cannot
see a reason for it to be doing.
[after digging in tidbitmap]
Oops, I was wrong, I supposed tha
Bruce Momjian writes:
> Wow, I have no idea what that means. I am wondering if we should just
> remove this TODO item. We don't even support comments on indexed
> columns, so why would pg_dump need to dump it?
The system will let you do it, both cases:
regression=# create type foo as (f1 int,
Hi.
> Wow, I have no idea what that means. I am wondering if we should just
> remove this TODO item. We don't even support comments on indexed
> columns, so why would pg_dump need to dump it?
Oh I see.
But we still can comment on indexed columns like following on 8.3.7,
is it unsupported featur
higepon wrote:
> Hi.
> I found a TODO item "Add dumping of comments on index columns and
> composite type columns" for pg_dump
> and want to write a patch for it.
>
> But I'm not sure if I understand the problem correctly.
> Does "Add dumping of comments on index columns" mean that
> pg_dump shoul
Peter Eisentraut writes:
> On March 10, 2009, Tom Lane wrote:
>> FWIW, the systemtap guys are really, really close to having a working
>> DTrace equivalent for Linux:
>> http://gnu.wildebeest.org/diary/2009/02/24/systemtap-09-markers-everywhere/
> So how is this going? Is it usable? I assume it
Robert Haas wrote:
> On Sat, Mar 21, 2009 at 12:55 PM, Joshua D. Drake
> wrote:
> >> Robert, ?this has been discussed many times before, and most people agree
> >> with
> >> you, but Bruce doesn't. I think the ony way this will change is if someone
> >> takes on the role of "release notes manage
Tom Lane wrote:
> Bruce Momjian writes:
> > bruce wrote:
> >> Here are some of the emails I consider open for 8.4:
> >>
> >> http://momjian.us/cgi-bin/pgsql/open
>
> > FYI, Tom has added a lot of comments to this page. I have also updated
> > the HTML because some browsers were not showing the
On March 10, 2009, Tom Lane wrote:
FWIW, the systemtap guys are really, really close to having a working
DTrace equivalent for Linux:
http://gnu.wildebeest.org/diary/2009/02/24/systemtap-09-markers-everywhere/
It's not *quite* there for our purposes
https://bugzilla.redhat.com/show_bug.cgi?id=48
Hi Nikhil,
Update operation is performed as a combination of 'delete' and 'insert'.
In Update trigger, the row is deleted from relation according to it's
'ctid'. A look-up on system catalog for partitions is performed to identify
the target table by evaluating values of partition-key attributes,
Hello
attention, MODULE is ANSI SQL keyword, and modules are class from ANSI SQL.
::=
CREATE MODULE
[ ]
[ ] [ ]
[ ... ]
...
END MODULE
::=
NAMES ARE
::=
SCHEMA
::=
::=
::=
Regards
Pavel Stehule
2009/3/23 Tom Lane :
> Robert Haas writes:
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Yes, dungbeetle is ... I took tcl out of its config until we had this
sorted out. Are you going to commit a _1.out file?
Done
Can't catch a break:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-03-23%2021:06:01
This t
49 matches
Mail list logo
