On Sat, Sep 17, 2011 at 4:22 AM, Joshua Berkus j...@agliodbs.com wrote:
that makes it look like one of the WAL archive transfer trigger
files,
which does not seem like a great analogy. The pg_standby
documentation
suggests names like foo.trigger for failover triggers, which is a
bit
better
On Tue, 2011-09-20 at 01:37 -0400, Tom Lane wrote:
As has been mentioned a couple times, we're well overdue for updates
of the back branches. Seems like time to get that done, so we'll be
wrapping 8.2.x and up this Thursday for release Monday the 26th.
Can we also specify a final release
On Fri, Sep 16, 2011 at 9:25 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2011-09-16 at 11:54 +0900, Fujii Masao wrote:
#1
Use empty recovery.ready file to enter arhicve recovery. recovery.conf
is not read automatically. All recovery parameters are expected to be
specified in
On Tue, Sep 20, 2011 at 12:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
As has been mentioned a couple times, we're well overdue for updates of
the back branches. Seems like time to get that done, so we'll be
wrapping 8.2.x and up this Thursday for release Monday the 26th.
8.2 up, including
On Fri, Sep 16, 2011 at 2:46 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 15-09-2011 23:54, Fujii Masao wrote:
#1
Use empty recovery.ready file to enter arhicve recovery. recovery.conf
is not read automatically. All recovery parameters are expected to be
specified in
On Fri, Sep 16, 2011 at 3:54 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Sep 15, 2011 at 11:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This seems like it's already predetermining the outcome of the argument
about recovery.conf. Mind you, I'm not unhappy with this choice, but
it's
On Fri, Sep 16, 2011 at 1:13 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2011-09-16 at 01:32 -0400, Tom Lane wrote:
As far as the other issues go, I think there is actually a
prerequisite
discussion to be had here, which is whether we are turning the
recovery
parameters into plain
On 20 September 2011 05:20, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 19, 2011 at 10:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We could possibly add a HINT suggesting that the locale isn't installed,
but I don't see that we could offer any useful
On Fri, Sep 16, 2011 at 2:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Sep 16, 2011 at 7:53 AM, Simon Riggs si...@2ndquadrant.com wrote:
This patch splits bgwriter into 2 processes: checkpointer and
bgwriter, seeking to avoid contentious changes. Additional changes are
expected in
On 20.09.2011 10:48, Simon Riggs wrote:
On Fri, Sep 16, 2011 at 2:38 AM, Fujii Masaomasao.fu...@gmail.com wrote:
On Fri, Sep 16, 2011 at 7:53 AM, Simon Riggssi...@2ndquadrant.com wrote:
This patch splits bgwriter into 2 processes: checkpointer and
bgwriter, seeking to avoid contentious
On Tue, Sep 20, 2011 at 9:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.09.2011 10:48, Simon Riggs wrote:
On Fri, Sep 16, 2011 at 2:38 AM, Fujii Masaomasao.fu...@gmail.com
wrote:
On Fri, Sep 16, 2011 at 7:53 AM, Simon Riggssi...@2ndquadrant.com
wrote:
This
On 20.09.2011 11:18, Simon Riggs wrote:
The bgwriter avoids I/O, if it is operating correctly. This patch
ensures it continues to operate even during heavy checkpoints. So it
helps avoid extra I/O during a period of very high I/O activity.
I don't see what difference it makes which process
On Sep19, 2011, at 19:46 , Stephen Frost wrote:
I agree that it'd be interesting to do, but I share Lord Stark's
feelings about the challenges and lack of potential gain- it's a very
small set of queries that would benefit from this. You need to be
working with enough data to make the cost of
Hi Fujita-san,
(2011/09/12 19:40), Etsuro Fujita wrote:
Hi there,
To enable file_fdw to estimate costs of scanning a CSV file more
accurately, I would like to propose a new FDW callback routine,
AnalyzeForeignTable, which allows to ANALYZE command to collect
statistics on a foreign table,
Hello.
Database Designer for PostgreSQL is an easy CASE tool which works
natively under Windows OS family and Linux under Wine/WineHQ.
This release introduces new functionality as well as several bug fixes.
Support for PostgreSQL 9.1 added, new Create HTML Report functionality
present, unlogged
On Tue, Sep 20, 2011 at 10:03 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.09.2011 11:18, Simon Riggs wrote:
The bgwriter avoids I/O, if it is operating correctly. This patch
ensures it continues to operate even during heavy checkpoints. So it
helps avoid extra I/O
Since it seems that you have spent some considerable time investigating and
producing a working concept, what would your best guess time estimate be,
assuming the requisite skills/talent/will in (planner/executor/etc.), to
have a solid working module put together? Are we looking at something like
Hello
2011/9/20 David Rinaldi edwbro...@gmail.com:
Since it seems that you have spent some considerable time investigating and
producing a working concept, what would your best guess time estimate be,
assuming the requisite skills/talent/will in (planner/executor/etc.), to
have a solid
On 09/20/2011 02:46 AM, Devrim GÜNDÜZ wrote:
On Tue, 2011-09-20 at 01:37 -0400, Tom Lane wrote:
As has been mentioned a couple times, we're well overdue for updates
of the back branches. Seems like time to get that done, so we'll be
wrapping 8.2.x and up this Thursday for release Monday the
On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggs si...@2ndquadrant.com wrote:
I don't see what difference it makes which process does the I/O. If a
write() by checkpointer process blocks, any write()s by the separate
bgwriter process at that time will block too. If the I/O is not saturated,
and
On 20.09.2011 16:29, Greg Stark wrote:
On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggssi...@2ndquadrant.com wrote:
I don't see what difference it makes which process does the I/O. If a
write() by checkpointer process blocks, any write()s by the separate
bgwriter process at that time will block
On Tue, Sep 20, 2011 at 15:35, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.09.2011 16:29, Greg Stark wrote:
On Tue, Sep 20, 2011 at 11:03 AM, Simon Riggssi...@2ndquadrant.com
wrote:
I don't see what difference it makes which process does the I/O. If a
write() by
On sön, 2011-09-18 at 12:43 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On sön, 2011-09-18 at 09:45 -0500, Dave Page wrote:
That is much more reasonable, though unfortunately not what was said.
Regardless, I stand by my main point that such a representative should
be
Excerpts from Peter Eisentraut's message of mar sep 20 10:51:51 -0300 2011:
On sön, 2011-09-18 at 12:43 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On sön, 2011-09-18 at 09:45 -0500, Dave Page wrote:
That is much more reasonable, though unfortunately not what was
2011/9/12 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
This is called when ANALYZE command is executed. (ANALYZE
command should be executed because autovacuum does not analyze foreign
tables.)
This is a good idea.
However, if adding these statistics requires an explicit ANALYZE
command, then we
On 20.09.2011 16:49, Magnus Hagander wrote:
Isn't there also the advantage of that work put in two different
processes can use two different CPU cores? Or is that likely to never
ever come in play here?
You would need one helluva I/O system to saturate even a single CPU,
just by doing
Andrew Dunstan and...@dunslane.net writes:
On 09/20/2011 02:46 AM, Devrim GÃNDÃZ wrote:
Can we also specify a final release version for 8.2? This set will be
8.2.21, and I propose to EOL 8.2 as of 8.2.22.
I don't see why we should deviate from the policy at
2011/9/20 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 20.09.2011 16:49, Magnus Hagander wrote:
Isn't there also the advantage of that work put in two different
processes can use two different CPU cores? Or is that likely to never
ever come in play here?
You would need one
On 09/20/2011 10:28 AM, Tom Lane wrote:
I don't think we've yet decided what the policy means if a release
happens during the stated calendar month, which seems rather likely
this time around in view of our historical record of doing updates
roughly quarterly. Should we settle that detail
2011/9/20 Andrew Dunstan and...@dunslane.net:
On 09/20/2011 10:28 AM, Tom Lane wrote:
I don't think we've yet decided what the policy means if a release
happens during the stated calendar month, which seems rather likely
this time around in view of our historical record of doing updates
Dave Page dp...@pgadmin.org writes:
2011/9/20 Andrew Dunstan and...@dunslane.net:
On 09/20/2011 10:28 AM, Tom Lane wrote:
does after December really mean in or after December, or did we
really mean after?
If we really want to get that specific, let's just say that the EOL date is
at the end
On 20.09.2011 17:31, Cédric Villemain wrote:
2011/9/20 Heikki Linnakangasheikki.linnakan...@enterprisedb.com:
On 20.09.2011 16:49, Magnus Hagander wrote:
Isn't there also the advantage of that work put in two different
processes can use two different CPU cores? Or is that likely to never
ever
2011/9/20 Tom Lane t...@sss.pgh.pa.us:
Dave Page dp...@pgadmin.org writes:
2011/9/20 Andrew Dunstan and...@dunslane.net:
On 09/20/2011 10:28 AM, Tom Lane wrote:
does after December really mean in or after December, or did we
really mean after?
If we really want to get that specific, let's
On Tue, Sep 20, 2011 at 9:35 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
All that said my question is which way is the code more legible and
easier to follow?
Hear hear. If we're going to give the bgwriter more responsibilities, this
might make sense even if it has no
Dave Page dp...@pgadmin.org writes:
On Tue, Sep 20, 2011 at 12:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
As has been mentioned a couple times, we're well overdue for updates of
the back branches. Seems like time to get that done, so we'll be
wrapping 8.2.x and up this Thursday for release
On Fri, Sep 16, 2011 at 01:53, Simon Riggs si...@2ndquadrant.com wrote:
This patch splits bgwriter into 2 processes: checkpointer and
bgwriter, seeking to avoid contentious changes. Additional changes are
expected in this release to build upon these changes for both new
processes, though this
On Tue, Sep 20, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Tue, Sep 20, 2011 at 12:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
As has been mentioned a couple times, we're well overdue for updates of
the back branches. Seems like time to get that
Marti Raudsepp ma...@juffo.org writes:
2011/9/12 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
This is called when ANALYZE command is executed. (ANALYZE
command should be executed because autovacuum does not analyze foreign
tables.)
This is a good idea.
However, if adding these statistics
On 20-09-2011 11:12, Marti Raudsepp wrote:
2011/9/12 Etsuro Fujitafujita.ets...@lab.ntt.co.jp:
This is called when ANALYZE command is executed. (ANALYZE
command should be executed because autovacuum does not analyze foreign
tables.)
This is a good idea.
However, if adding these statistics
Thom Brown t...@linux.com writes:
On 20 September 2011 05:20, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Maybe something like this?
HINT: The operating system was unable to find any locale data for the
locale name you specified.
Hmm, that's not bad. We
On Tue, Sep 20, 2011 at 11:01 AM, Marti Raudsepp ma...@juffo.org wrote:
On Fri, Sep 16, 2011 at 01:53, Simon Riggs si...@2ndquadrant.com wrote:
This patch splits bgwriter into 2 processes: checkpointer and
bgwriter, seeking to avoid contentious changes. Additional changes are
expected in this
Simon Riggs si...@2ndquadrant.com writes:
I sympathise with this view, to an extent.
If people want to put all parameters in one file, they can do so. So +1 to
that.
Should they be forced to adopt that new capability by us deliberately
breaking their existing setups? No. So -1 to that.
I don't buy this argument at all. I don't believe that recovery.conf is
part of anyone's automated processes at all, let alone to an extent that
they won't be able to cope with a change to rationalize the file layout.
And most especially I don't buy that someone who does want to keep using
Thom Brown t...@linux.com writes:
[ unhelpful reporting of ENOENT from newlocale() ]
BTW, on examining the code I note that we're doing something else that
promotes the confusion of bad locale name with bad file name: we're
using errcode_for_file_access() to select the SQLSTATE. If we don't
On 20 September 2011 17:45, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
[ unhelpful reporting of ENOENT from newlocale() ]
BTW, on examining the code I note that we're doing something else that
promotes the confusion of bad locale name with bad file name: we're
using
All,
First, if we're going to change behavior, I assert that we should stop
calling stuff recovery and either call it replica or standby. Our
use of the word recovery confuses users; it is historical in nature
and requires an understanding of PostgreSQL internals to know why it's
called that.
On Tue, Sep 20, 2011 at 1:01 PM, Josh Berkus j...@agliodbs.com wrote:
I'll go further and say that we only want one trigger file by default,
one which either enables or disables recovery. I'll further suggest
that we:
a) have a standby.on file which puts the server in replica/recovery mode
On 9/20/11 10:09 AM, Robert Haas wrote:
I like the idea of some kind of sentinel file that tells the server to
start up in recovery mode. But instead of having the user remove it
to cause a promotion, I think the server should remove it when it does
promote. That's more like what we've done
Thom Brown t...@linux.com writes:
On 20 September 2011 17:45, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, on examining the code I note that we're doing something else that
promotes the confusion of bad locale name with bad file name: we're
using errcode_for_file_access() to select the SQLSTATE.
Josh Berkus j...@agliodbs.com writes:
First, if we're going to change behavior, I assert that we should stop
calling stuff recovery and either call it replica or standby. Our
use of the word recovery confuses users; it is historical in nature
and requires an understanding of PostgreSQL
On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
First, if we're going to change behavior, I assert that we should stop
calling stuff recovery and either call it replica or standby. Our
use of the word recovery confuses users; it is
I notice that heap_update releases the buffer lock, after checking the
HeapTupleSatifiesUpdate result, and before marking the tuple as updated,
to pin the visibility map page -- heapam.c lines 2638ff in master branch.
Is this not a bug? I imagine that while this code releases the lock,
someone
On 20 September 2011 18:25, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
On 20 September 2011 17:45, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, on examining the code I note that we're doing something else that
promotes the confusion of bad locale name with bad file name:
On 20.09.2011 20:42, Alvaro Herrera wrote:
I notice that heap_update releases the buffer lock, after checking the
HeapTupleSatifiesUpdate result, and before marking the tuple as updated,
to pin the visibility map page -- heapam.c lines 2638ff in master branch.
Is this not a bug? I imagine that
Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Tue, Sep 20, 2011 at 12:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
As has been mentioned a couple times, we're well overdue for updates of
the back branches. �Seems like time to get that done, so we'll be
wrapping 8.2.x and up this Thursday
On Tue, Sep 20, 2011 at 2:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.09.2011 20:42, Alvaro Herrera wrote:
I notice that heap_update releases the buffer lock, after checking the
HeapTupleSatifiesUpdate result, and before marking the tuple as updated,
to pin the
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Are we all talking about the same thing? In my mind recovery.conf is
for configuring a point-in-time archive recovery run. It's got nothing
to do with either replication or standbys.
Excerpts from Robert Haas's message of mar sep 20 16:04:03 -0300 2011:
On Tue, Sep 20, 2011 at 2:28 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20.09.2011 20:42, Alvaro Herrera wrote:
I notice that heap_update releases the buffer lock, after checking the
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Robert Haas's message of mar sep 20 16:04:03 -0300 2011:
On 20.09.2011 20:42, Alvaro Herrera wrote:
I notice that heap_update releases the buffer lock, after checking the
HeapTupleSatifiesUpdate result, and before marking the
The point I'm trying to make is that it seems like this discussion is
getting driven entirely by the standby case, without remembering that
recovery.conf was originally designed for, and is still used in,
a significantly different use-case. Maybe we had better take two
steps back and think
On Tue, Sep 20, 2011 at 3:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Are we all talking about the same thing? In my mind recovery.conf is
for configuring a point-in-time archive
I already did some benchmarks with GPU sorting (not in pgsql), and
measured total sort times, copy bandwidth and energy usage, and got
some exciting results:
Was that qsort implementation on CPU cache friendly and optimized for SSE ?
To make a fair comparison you have to take the best CPU
Hi,
I faced similar issue as discussed in
http://postgresql.1045698.n5.nabble.com/Fwd-DBD-Pg-on-HP-UX-11-31-64bit-td3305163.html;.
(man xopen_networking -
http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html)
... There are two ways to obtain X/Open Sockets
On Tue, Sep 20, 2011 at 04:51:51PM +0300, Peter Eisentraut wrote:
On sön, 2011-09-18 at 12:43 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On sön, 2011-09-18 at 09:45 -0500, Dave Page wrote:
That is much more reasonable, though unfortunately not what was said.
Marko Tiikkaja marko.tiikk...@2ndquadrant.com writes:
The attached patch is the best I could come up with. I considered
showing Rows Removed by Foo: (never executed) and omitting the line
altogether, but I didn't particularly like either of those options. The
current patch simply displays
MUHAMMAD ASIF anaeem...@hotmail.com writes:
I faced similar issue as discussed in
http://postgresql.1045698.n5.nabble.com/Fwd-DBD-Pg-on-HP-UX-11-31-64bit-td3305163.html;.
(man xopen_networking -
http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/xopen_networking.7.html)
...
On 20 September 2011 03:51, Tom Lane t...@sss.pgh.pa.us wrote:
Considering that -O2 is our standard optimization level, that
observation seems to translate to this patch will be useless in
practice. I think you had better investigate that aspect in some
detail before spending more effort.
I
Marko Tiikkaja marko.tiikk...@2ndquadrant.com writes:
The attached patch is the best I could come up with. I considered
showing Rows Removed by Foo: (never executed) and omitting the line
altogether, but I didn't particularly like either of those options. The
current patch simply displays
On Tue, Sep 20, 2011 at 11:13:05AM -0400, Tom Lane wrote:
Marti Raudsepp ma...@juffo.org writes:
2011/9/12 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
This is called when ANALYZE command is executed. (ANALYZE
command should be executed because autovacuum does not analyze foreign
tables.)
The buildfarm is still showing isolation test failures more days than
not, eg
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pikadt=2011-09-17%2012%3A43%3A11
and I've personally seen such failures when testing with
CLOBBER_CACHE_ALWAYS. Could we please fix those tests to not have such
Excerpts from David Fetter's message of mar sep 20 21:22:32 -0300 2011:
On Tue, Sep 20, 2011 at 11:13:05AM -0400, Tom Lane wrote:
Probably a more interesting question is why we wouldn't change
autovacuum so that it calls this automatically for foreign tables.
How about a per-table
- Цитат от Peter Geoghegan (pe...@2ndquadrant.com), на 21.09.2011 в 02:53
-
On 20 September 2011 03:51, Tom Lane t...@sss.pgh.pa.us wrote:
Considering that -O2 is our standard optimization level, that
observation seems to translate to this patch will be useless in
practice. I think
Tom Lane wrote:
The buildfarm is still showing isolation test failures more days
than not, eg
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pikadt=2011-09-17%2012%3A43%3A11
and I've personally seen such failures when testing with
CLOBBER_CACHE_ALWAYS. Could we please fix those
Excerpts from Kevin Grittner's message of mar sep 20 22:51:39 -0300 2011:
If I remember right, Alvaro chose these timings to balance run time
against chance of failure. Unless we want to remove these deadlock
handling tests or ignore failures (which both seem like bad ideas to
me), I think
On Tue, Sep 20, 2011 at 8:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@2ndquadrant.com writes:
The attached patch is the best I could come up with. I considered
showing Rows Removed by Foo: (never executed) and omitting the line
altogether, but I didn't particularly
2011/9/13 Jun Ishiduka ishizuka@po.ntts.co.jp:
Update patch.
Changes:
* set 'on' full_page_writes by user (in document)
* read FROM: XX in backup_label (in xlog.c)
* check status when pg_stop_backup is executed (in xlog.c)
Thanks for updating the patch.
Before reviewing the patch,
On tis, 2011-09-20 at 11:12 -0300, Alvaro Herrera wrote:
+1 for a closed mailing list. It's a bit annoying to have to do
such
a thing, but it's not like we haven't got other closed lists for
appropriate purposes.
Well, that much we've already decided a few years ago. The blocking
Alvaro Herrera alvhe...@commandprompt.com writes:
The main problem I have is that I haven't found a way to reproduce the
problems in my machine.
Try -DCLOBBER_CACHE_ALWAYS.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
I am interested in the development you are doing regarding join push down
and fdw stuff for remote postgreSQL servers.
Is there a way to get the postgres fdw you are providing here for common
9.1?
I saw that the tar you are providing here is adapted only for your patch.
Regards,
Michael
On tis, 2011-09-20 at 10:28 -0400, Tom Lane wrote:
I don't think we've yet decided what the policy means if a release
happens during the stated calendar month, which seems rather likely
this time around in view of our historical record of doing updates
roughly quarterly. Should we settle that
On Wed, Sep 21, 2011 at 04:50, Fujii Masao masao.fu...@gmail.com wrote:
2011/9/13 Jun Ishiduka ishizuka@po.ntts.co.jp:
Update patch.
Changes:
* set 'on' full_page_writes by user (in document)
* read FROM: XX in backup_label (in xlog.c)
* check status when pg_stop_backup is executed
81 matches
Mail list logo
