Florian Pflug wrote:
glibc defines O_DSYNC as an alias for O_SYNC and warrants that with
Most Linux filesystems don't actually implement the POSIX O_SYNC semantics, which
require all metadata updates of a write to be on disk on returning to userspace, but only
the O_DSYNC semantics, which
Bruce Momjian wrote:
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010:
Yes, the folks at commandprompt need to be told about this. Loudly.
It's a serious packaging error.
Just notified Lacey, the packager (not so loudly, though); she's
On Sat, Jun 12, 2010 at 1:45 AM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-06-11 at 08:15 -0400, Stephen Frost wrote:
* Pr, Solaiyappan (NSN - IN/Bangalore) (solaiyappan...@nsn.com) wrote:
I understand this is very early to ask this.. but, is there any tentative
timeline has been
Robert Haas robertmh...@gmail.com writes:
On Sat, Jun 12, 2010 at 1:45 AM, Peter Eisentraut pete...@gmx.net wrote:
I wrote it down now:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan
Thanks! Looks good, except I thought our plan was to cut alpha1
before the git switch.
On Thu, Jun 10, 2010 at 4:09 PM, Simon Riggs si...@2ndquadrant.com wrote:
Here's the code.
I haven't more than glanced at this, but +1 for committing it if
you're confident it DTRT.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via
On Sat, Jun 12, 2010 at 4:51 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Dimitri Fontaine dfonta...@hi-media.com writes:
Also, should I try to send a patch implementing my proposal (internal
command exposed as a function at the SQL level, and while at it, maybe
the internal command
On Fri, Jun 11, 2010 at 9:29 PM, Rafael Martinez
r.m.guerr...@usit.uio.no wrote:
I am testing HS + SR in a system running 9.0beta2. What I am doing is
just trying all kind of crazy combinations and see how the system
handles them.
Thanks!
One of the test I knew was going to fail was to
Robert Haas robertmh...@gmail.com writes:
I'm a bit perplexed here. The archive cleanup has to run on the
standby, not the master, right? Whereas pg_switch_xlog() can only run
on the master.
I used it just to show a possible use case, easy to grasp. Sorry if
that's confusing instead.
The
On Sun, Jun 13, 2010 at 1:04 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Robert Haas robertmh...@gmail.com writes:
I'm a bit perplexed here. The archive cleanup has to run on the
standby, not the master, right? Whereas pg_switch_xlog() can only run
on the master.
I used it just to
Robert Haas robertmh...@gmail.com writes:
Robert Haas robertmh...@gmail.com writes:
The purpose of making this a standalone executable is
so that people who have, for example, multiple standbys, can customize
the logic without having to hack the backend. Pushing this into the
backend would
Dimitri Fontaine wrote:
I still read
here from time to time that contrib's chapter is maintaining working
examples of extensibility, not maintaining production ready add-ons.
Even if this were true, and I don't believe it is, ISTM the solution
would be to have a utility command
On Sun, Jun 13, 2010 at 12:42:49PM -0400, Robert Haas wrote:
I think the behavior is correct (what else would we do? we must be
able to replace the subsequent WAL records that use the new
tablespace) but I agree that the hint is a little misleading.
Ideally, it seems like we'd like to issue
On Sun, Jun 13, 2010 at 4:52 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Sun, Jun 13, 2010 at 12:42:49PM -0400, Robert Haas wrote:
I think the behavior is correct (what else would we do? we must be
able to replace the subsequent WAL records that use the new
tablespace) but I agree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Haas wrote:
On Fri, Jun 11, 2010 at 9:29 PM, Rafael Martinez
I'm somewhat disinclined to try to address this for 9.0. We've had
this problem for a long time, and I'm not sure that the fact that it
can now happen in a slightly wider set of
2010/6/1 Bruce Momjian br...@momjian.us:
Tom Lane wrote:
(...)
The index-based-max code is throwing in the IS NOT NULL condition
without thought for where it has to go in the index condition order.
Will look into fixing this tomorrow.
FYI, this no longer throws an error in current CVS so was
Bruce Momjian wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010:
Yes, the folks at commandprompt need to be told about this. Loudly.
It's a serious packaging error.
Just notified Lacey, the packager (not
Rafael Martinez wrote:
A minimum and probably the only feasible thing for 9.0 will be to update
the documentation. We need an entry in the hot-standby caveats section
explaining that if you create a tablespace and the directory needed does
not exist in the the standby, the standby will shutdown
Florian Pflug wrote:
To be able to asses the performance characteristics of the different
wal-related options, I patched pgbench to show the average latency of each
individual statement. The idea is to be able to compare the latency of the
COMMIT with the ones of the other statements.
In response to a complaint from Hartmut Goebel:
http://archives.postgresql.org/pgsql-bugs/2010-06/msg00018.php
And per a design proposed by Tom Lane:
http://archives.postgresql.org/pgsql-bugs/2010-06/msg00211.php
PFA a patch to implement $SUBJECT. One interesting aspect of this
patch is that
On Fri, Jun 11, 2010 at 7:14 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 09/06/10 08:24, Fujii Masao wrote:
On Wed, Jun 9, 2010 at 12:52 PM, Andrew Dunstanand...@dunslane.net
wrote:
There is precedent for .pgpass being a bit ambiguous. See the way
localhost is
visibilitymap.c begins with a long and useful comment - but this part
seems to have a bit of split personality disorder.
* Currently, the visibility map is not 100% correct all the time.
* During updates, the bit in the visibility map is cleared after releasing
* the lock on the heap page.
I am curious how could I solve the problem:
During refreshing I would like to know, if MV is stale or fresh? And I
had an idea:
In fact, MV need to know if its last refresh (transaction id) is older
than any INSERT, UPDATE, DELETE transaction launched against source
tables. So if MV has
I am curious how could I solve the problem:
During refreshing I would like to know, if MV is stale or fresh? And I
had an idea:
In fact, MV need to know if its last refresh (transaction id) is older
than any INSERT, UPDATE, DELETE transaction launched against source
tables. So if MV has
On Thu, Jun 10, 2010 at 9:29 AM, Robert Haas robertmh...@gmail.com wrote:
(moving to -hackers)
On Wed, Jun 9, 2010 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
In going back through emails I had marked as possibly needing another
look before 9.0 is
On Mon, Jun 14, 2010 at 3:51 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
I now realize that my proposal ain't helping if Streaming Replication is
filling the standby's pg_xlog and hot_standby = off. I don't remember
that SR rebuilds pg_xlog on the standby though, does it?
In SR, WAL
On 14/06/10 06:08, Robert Haas wrote:
visibilitymap.c begins with a long and useful comment - but this part
seems to have a bit of split personality disorder.
* Currently, the visibility map is not 100% correct all the time.
* During updates, the bit in the visibility map is cleared after
On 12/06/10 17:18, Pavel Baros wrote:
I am curious how could I solve the problem:
During refreshing I would like to know, if MV is stale or fresh? And I
had an idea:
In fact, MV need to know if its last refresh (transaction id) is older
than any INSERT, UPDATE, DELETE transaction launched
Pavel Baros wrote:
After each INSERT, UPDATE, DELETE statement (transaction)
pg_class.rellastxid would be updated. That should not be time- or
memory- consuming (not so much) since pg_class is cached, I guess.
An update in PostgreSQL is essentially an INSERT followed a later DELETE
when
28 matches
Mail list logo
