On Tue, 2009-01-13 at 16:39 +0900, Fujii Masao wrote:
May as well leave it in, so people can use it with 8.3.
I'd like this patch to be reviewed and committed for 8.4 even if
synch-rep
is postponed to 8.5. Because this is very useful for existing
warm-standby
mechanism, and only
Joshua D. Drake wrote:
On Mon, 2009-01-12 at 13:23 -0500, Robert Haas wrote:
But wasn't I just reading something about having to wipe that repository
and re-import the CVS history to fix various problems?
Not sure; I hope not.
Actually yes we did. There was a bug in git-cvs that we fixed.
On Tue, 2009-01-13 at 13:21 +0900, Koichi Suzuki wrote:
I have no intention to make pglesslog to conflict to PostgreSQL
license. Any advice is welcome to make pglesslog available without
any license concern.
I understand, no part of my comments were against you or your work.
I've a
Hi,
On Mon, Jan 12, 2009 at 1:16 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2009-01-11 at 15:11 +0900, Fujii Masao wrote:
Yes, using semaphores for the communication is also my first approach.
The problem of this approach is that walsender cannot wait for both
signal from backends
The attached patch is proof of the concept.
It can be applied on the latest CVS HEAD with colprivs_2009011001.diff.gz.
- It unpatches unnecessary updates at parser/parse_expr.c, parser/parse_node.c
and parser/parse_relation.c.
- It adds markColumnForSelectPriv() to mark proper rte-cols_sel for
Hi,
On Sun, Jan 11, 2009 at 7:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
On Thu, Jan 8, 2009 at 2:14 AM, Bruce Momjian br...@momjian.us wrote:
Greg Stark wrote:
On 7 Jan 2009, at 09:47, Bruce Momjian br...@momjian.us wrote:
Heikki Linnakangas wrote:
It's required by the sync
Aidan Van Dyk wrote:
With git, you pull down the complete *history* of whatever branch, tag,
or reference you want to pull down.
You can do a so-called shallow clone, pulling only X most recent
commits, with git clone --depth=X. There's some limitations on what
you can do with a shallow
On Mon, 2009-01-12 at 20:52 -0500, Robert Haas wrote:
I think the
base backup should be integrated into the mechanism as well. I want
to just be able to configure the master and slave for replication,
fire up the slave, and walk away. Without that, I agree that it's
likely to be too
Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
A re-sort after locking doesn't really make things all nice and
intuitive either.
Would it make any sense to roll back and generate a
SERIALIZATION_FAILURE?
If that's what you want then
Kevin Grittner wrote:
Well, that's a PostgreSQL-specific point of view, although I
understand the point of maintaining that guarantee. (In Microsoft SQL
Server and Sybase ASE we actually had to run our read-only web
application at the READ UNCOMMITTED transaction isolation level
because so many
Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
Tom Lane wrote:
David Fetter da...@fetter.org writes:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our development process.
Agreed, or at least boost it up a good
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On 12 jan 2009, at 17.46, Tom Lane t...@sss.pgh.pa.us wrote:
However, one of the properties -1 is supposed to have is that any
failure aborts the whole restore; it's not immediately clear how to
preserve that with CREATE DATABASE
Joshua D. Drake wrote:
Does bzr, mecurial or monotone offer the same or better solution? Bzr in
particular is in very wide use and I run into mecurial all the time.
I have found that mercurial is pretty much feature-equivalent to git, at
least until you get to the really wizard-like use
Bruce Momjian wrote:
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; otherwise it looks fine.
Thanks, committed that way. I noticed that --lc-ctype and --lc-collate
were forgotten in SGML docs, so I added them too.
Should we
Robert Haas wrote:
I am just explaining how it works in practice. If the patch is still
being improved, the feeling is that the author wants more time to adjust
things, and with other things on our plate, we are glad to leave their
patch until last.
Well, it's good that you have an
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an existing database would render
indexes broken.
On Mon, 12 Jan 2009 12:19:51 -0500 (EST)
Bruce Momjian br...@momjian.us wrote:
Yep, that is my analysis as well. If you want a pretty ReST-like
output, that can be added later.
Not if you use border 3 for full ReST. I see nothing but pushback
later if you try to make border 4 give less than
Stephen Frost wrote:
Magnus, et al,
* Magnus Hagander (mag...@hagander.net) wrote:
Looking at the open item about the new error message shown when Kerberos
is compiled in, and not used:
assword:
FATAL: password authentication failed for user mha
psql: pg_krb5_init: krb5_cc_get_principal:
KaiGai Kohei wrote:
I updated patch set of SE-PostgreSQL and related stuff (r1403).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1403.patch
Random observations:
heapam.c: you've got a bunch of elog(ERROR) calls in there that should
be ereport(ERROR), and
2009/1/12 Bruce Momjian br...@momjian.us:
I supposed Solaris 2.5.1 (release 1996) is just too old to add
threading, and this code has been unchanged for years.
---
Andrew Chernow wrote:
for anyone interested
Tom, er al,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm thinking make_var is not the place to do this. The places that are
supposed to be taking care of permissions are the ones that do this:
/* Require read access --- see comments in setTargetTable() */
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an existing database would
Magnus Hagander mag...@hagander.net writes:
Now that we have support for mappings, I expect it will be more common
for a user to authenticate with princ 'A' and then connect using their
Unix id 'B' to a PG user 'B'. As such, I'm alright with dropping
support for this. Users can always use
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch is proof of the concept.
Thanks!
It can be applied on the latest CVS HEAD with colprivs_2009011001.diff.gz.
- It unpatches unnecessary updates at parser/parse_expr.c, parser/parse_node.c
and parser/parse_relation.c.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Robert Haas wrote:
(It would be interesting to here how much value people think it has
added, and get suggestions on how to do things better next time.)
I'm not sure how much round-robin-review has taken load off committers,
you
On 13 jan 2009, at 15.20, Gregory Stark st...@enterprisedb.com wrote:
Magnus Hagander mag...@hagander.net writes:
Now that we have support for mappings, I expect it will be more
common
for a user to authenticate with princ 'A' and then connect using
their
Unix id 'B' to a PG user 'B'. As
Tom Lane t...@sss.pgh.pa.us writes:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Robert Haas wrote:
(It would be interesting to here how much value people think it has
added, and get suggestions on how to do things better next time.)
I'm not sure how much
Stephen Frost sfr...@snowman.net writes:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
- The markColumnForSelectPriv() uses walker function internally, because
there is no guarantee all the entities within RangeTblEntry-joinaliasvars
are Var type node.
If any of them aren't Vars, then
Stephen Frost sfr...@snowman.net writes:
It's possible that we've missed some --- in particular, right at the
moment I am not sure that whole-row Vars are handled properly.
I added specific regression test for whole-row Vars, so I'd be concerned
if something isn't working there.
What I see
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
This was fixed on 1.84 of formatting.c for 8.0 (but not backpatched for
no apparent reason), which also changed some other stuff in that file.
The complete patch is attached.
I dunno why I didn't back-patch that; feel free
Bruce Momjian wrote:
I supposed Solaris 2.5.1 (release 1996) is just too old to add
threading, and this code has been unchanged for years.
Yeah, its old. Unfortunately for us, we still have to support it.
To set the record straight, the issue is not threads. Threads work fine
on 2.5.1.
Sorry, I didn't attatch the patch file. This is the second try.
2009/1/12 Koichi Suzuki koichi@gmail.com:
This is V4 patch to improve file read during startup for review.
Basic algorithm is same as V3 but works with Gregory's fadvise patch.
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
I notice in the documentation that the createdb --lc-ctype sets the
lc_ctype setting for the database, but the corresponding parameter for
CREATE DATABASE is CTYPE, but the global GUC setting is lc_ctype.
Should that be more consistent?
Peter Eisentraut pete...@gmx.net wrote:
Kevin Grittner wrote:
(In Microsoft SQL Server and Sybase ASE we actually had to run our
read-only web application at the READ UNCOMMITTED transaction
isolation level because so many SELECT queries were rolled back
when they deadlocked with the
Andrew Chernow wrote:
Bruce Momjian wrote:
I supposed Solaris 2.5.1 (release 1996) is just too old to add
threading, and this code has been unchanged for years.
Yeah, its old. Unfortunately for us, we still have to support it.
To set the record straight, the issue is not threads. Threads
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What I see being tested is SELECT *, which is a different animal
entirely. As required by spec, SELECT * is expanded to a list of
ordinary variables at parse time and then it's not really a special
case anymore. A true whole-row variable only occurs
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Would it make any sense to roll back and generate a
SERIALIZATION_FAILURE?
If that's what you want then you run the transaction in serializable
mode. The point of doing it in READ COMMITTED mode is that
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What I see being tested is SELECT *, which is a different animal
entirely.
Wouldn't this test cover those?
SELECT atest5 FROM atest5; -- fail
Oh, I didn't see that. Still, this doesn't test whether the
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
If that's what you want then you run the transaction in serializable
mode. The point of doing it in READ COMMITTED mode is that you
don't want such a failure.
Wait a minute -- there is not such guarantee
Alvaro Herrera alvhe...@commandprompt.com writes:
Heikki Linnakangas wrote:
Hmm, I remember I pondered for a long time if it should be COLLATE and
CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was
that a) COLLATE/CTYPE looks nicer and b) if we add support for ICU or
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
What I see being tested is SELECT *, which is a different animal
entirely.
Wouldn't this test cover those?
SELECT atest5 FROM atest5; -- fail
Oh, I didn't see
Tom Lane t...@sss.pgh.pa.us wrote:
Huh? Deadlocks were not the issue here. What you asked for was a
failure if someone else had updated the rows you're selecting for
update.
Logically, these are both forms of serialization failure when doing
SELECT FOR UPDATE in READ COMMITTED mode. One
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
Normally, GetRunningTransactionData determines the xid of the latest
running xid by scanning the procarray. If the subxid cache has
overflowed, it simply gives up. Comment there suggests that it could
call ReadNewTransactionId()
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Oh, I didn't see that. Still, this doesn't test whether the behavior
is correct with respect to ADD/DROP COLUMN --- if that were implemented
like SELECT * you'd not see any change in the regression result.
Hrm.
Kevin,
So, wouldn't it be better, if it's actually feasible to detect the
problem situation, to make this another situation where SELECT FOR
UPDATE can cause serialization failures? That would allow
applications to count on getting the rows in the requested order if
the query completes
Josh Berkus j...@agliodbs.com wrote:
That's not how SELECT FOR UPDATE works. SFU is pessimistic manual
locking, which is supposed to *wait* for the rows to be exclusively
available. The deadlock timeout you encountered is the correct
behaviour, not serialization failure, which is what
Deadlocks like this are the only kind of serialization error possible
under traditional (non-MVCC) databases. These are much more rare in
MVCC than update conflicts, but that doesn't mean they aren't
serialization failures there, too. I think it is a violation of the
standard for PostgreSQL
Josh Berkus j...@agliodbs.com wrote:
we'd break 100,000 existing Java applications if we changed the
error.
In what way would an application want to treat deadlocks and update
conflicts differently? Both result from conflicts with concurrent
transactions and can be retried automatically.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Josh Berkus j...@agliodbs.com wrote:
we'd break 100,000 existing Java applications if we changed the
error.
In what way would an application want to treat deadlocks and update
conflicts differently? Both result from conflicts with
On Sat, 2009-01-03 at 22:34 -0500, Bruce Momjian wrote:
Now that we are two months into the final commit fest, it is time to
finalize all the open patches so we can target a February beta.
The two major outstanding patches are:
...
o Recovery, Replication, Hot Standby: We need a
Gregory Stark st...@enterprisedb.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
In what way would an application want to treat deadlocks and update
conflicts differently? Both result from conflicts with concurrent
transactions and can be retried automatically. It seems like
On Tue, 2008-12-30 at 18:31 +0200, Heikki Linnakangas wrote:
You have to be careful to ignore the flags in read-only transactions
that started in hot standby mode, even if recovery has since ended and
we're in normal operation now.
My initial implementation in v6 worked, but had a corner
On Sat, 2009-01-10 at 09:40 +, Simon Riggs wrote:
But looking at that, I
think the 6a patch had a bug there: a subtransaction abort record
would release locks for the whole top level xact.
Fixed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
On Wed, 2009-01-07 at 13:18 +0200, Heikki Linnakangas wrote:
There's still something wrong with the way subtransactions are handled.
I got:
postgres=# SELECT * FROM foo;
ERROR: could not access status of transaction 118649
DETAIL: Could not open file pg_subtrans/0001: No such file or
Dear hackers,
during the last three months, I've compiled my thoughts and ideas around
Postgtres-R into a rounded concept covering lots of aspects. It
integrates findings from up-to-date research papers and it's meant to
lighten up the future direction of development for Postgres-R. See
Hello,
O.k. so I admit I probably should have known this already but I didn't.
Normally I setup logging to use -%a.log. However I had a requirement
today that is having me setup a flat filename... as in postgresql.log.
When I set it up, it automatically appended the time so I got:
Joshua D. Drake j...@commandprompt.com writes:
When I set it up, it automatically appended the time so I got:
postgresql.log.1231878270
That seems a bit, well wrong. If I say I want postgresql.log I should
get postgresql.log.
You'd probably reconsider around the time the log file filled your
On Tue, Jan 13, 2009 at 4:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joshua D. Drake j...@commandprompt.com writes:
When I set it up, it automatically appended the time so I got:
postgresql.log.1231878270
That seems a bit, well wrong. If I say I want postgresql.log I should
get postgresql.log.
Robert Haas wrote:
Joshua D. Drake j...@commandprompt.com writes:
When I set it up, it automatically appended the time so I got:
postgresql.log.1231878270
That seems a bit, well wrong. If I say I want postgresql.log I should
get postgresql.log.
You'd probably reconsider around the
On Tue, 2009-01-13 at 16:20 -0500, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
When I set it up, it automatically appended the time so I got:
postgresql.log.1231878270
That seems a bit, well wrong. If I say I want postgresql.log I should
get postgresql.log.
You'd
Joshua D. Drake j...@commandprompt.com writes:
I have perfectly good log rotation utility that exists on my OS. (yes I
am aware of the possibility of losing a log entry when using logrotate).
You might think you do, but it won't work with PG; external rotators
only work with programs that
On Tue, 2009-01-13 at 16:58 -0500, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
I have perfectly good log rotation utility that exists on my OS. (yes I
am aware of the possibility of losing a log entry when using logrotate).
You might think you do, but it won't work with
Joshua,
* Joshua D. Drake (j...@commandprompt.com) wrote:
When I set it up, it automatically appended the time so I got:
postgresql.log.1231878270
That seems a bit, well wrong. If I say I want postgresql.log I should
get postgresql.log.
Or am I completely cranked?
No. I agree with
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Joshua D. Drake j...@commandprompt.com writes:
I have perfectly good log rotation utility that exists on my OS. (yes I
am aware of the possibility of losing a log entry when using logrotate).
You might think you do, but it won't work with PG; external
* Joshua D. Drake (j...@commandprompt.com) wrote:
On Tue, 2009-01-13 at 16:58 -0500, Tom Lane wrote:
You might think you do, but it won't work with PG; external rotators
only work with programs that respond to SIGHUP by re-opening their log
files.
copytruncate resolves this issue does it
While regress/GNUmakefile appears to make an effort to run the regressions
tests with or without locale depending on the users choice, .e.g.,
# locale
NOLOCALE =
ifdef NO_LOCALE
NOLOCALE += --no-locale
endif
the pg_regress.c implementation spoils that completely by unconditionally
unsetting all
Stephen Frost wrote:
Joshua,
* Joshua D. Drake (j...@commandprompt.com) wrote:
When I set it up, it automatically appended the time so I got:
postgresql.log.1231878270
That seems a bit, well wrong. If I say I want postgresql.log I should
get postgresql.log.
Or am I completely cranked?
Attached is a patch that adds a namespace capability to reloptions. It
works this way:
alter table foo set (namespace.option = value)
Currently the only namespace that does anything is toast. What it
does is store the option in the toast table pg_class.reloptions.
It works fine, i.e. I can
On Tue, 13 Jan 2009 12:30:09 -0300 Alvaro Herrera wrote:
The other cases were already handled, so Andreas' initial patch was
enough -- applied.
Thank you.
Bye
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of
Alvaro Herrera alvhe...@commandprompt.com writes:
This uses a new parse node.
You need at least equalfuncs.c support for that, and outfuncs would be
advisable.
One possible disadvantage is that a command
like this works, but does nothing:
alvherre=# alter table foo set (test.foo = 1);
Uh,
Andrew Dunstan and...@dunslane.net writes:
Then Debian is (surprise!) not doing the smartest thing. Not using the logging
collector means you miss several possible advantages, including CSV logs and
protection against multiplexed log lines.
Well it's not the smartest thing by your set of
On Tue, Jan 13, 2009 at 4:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joshua D. Drake j...@commandprompt.com writes:
I have perfectly good log rotation utility that exists on my OS. (yes I
am aware of the possibility of losing a log entry when using logrotate).
You might think you do, but it
Koichi Suzuki koichi@gmail.com wrote:
This patc also include additional patch for posix_fadvise to skip
prefetch of pages which does not exist.
I reviewed your patch and found items to be fixed and improved.
- You should not claim your copyrights.
There are your copyright claims in two
Andrew,
* Andrew Dunstan (and...@dunslane.net) wrote:
Then Debian is (surprise!) not doing the smartest thing.
As Gregory pointed out, Debian is doing it for some very good reasons,
and is doing it the best it can. Also, I have a huge amount of respect
for Martin Pitt (the Debian maintainer),
Alvaro Herrera wrote:
KaiGai Kohei wrote:
I updated patch set of SE-PostgreSQL and related stuff (r1403).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1403.patch
Random observations:
Thanks for your comment!
heapam.c: you've got a bunch of elog(ERROR) calls
Stephen Frost wrote:
Tom, er al,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm thinking make_var is not the place to do this. The places that are
supposed to be taking care of permissions are the ones that do this:
/* Require read access --- see comments in setTargetTable() */
Stephen Frost wrote:
Surely a good log rotator allows a custom rotation action (in this case,
connecting to postgres and calling 'select pg_rotate_logfile()' )
Yes, logrotate will happily call external applications. Maybe I'm
missing something, but obviously if PG can't be configured
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
It seems to me you didn't add success cases for JOINs.
The previous patch tries to check privilege for each columns within
JOIN'ed tables unexpectedly, so the test case always fails.
Right, I realized that when I went back and looked at it.
Koichi Suzuki wrote:
Hi,
I have no intention to make pglesslog to conflict to PostgreSQL
license. Any advice is welcome to make pglesslog available without
any license concern.
I certainly have no concerns.
I've a question and ideas.
Bruce's modification directly points to my
Andrew Dunstan and...@dunslane.net writes:
I'm not sure what postgres does if the filename contains %% as the only
escape, although that's would be a fairly ugly hack.
Yes, any %-escape is enough to disable the addition of the timestamp.
Looking back at the archives, I believe the real reason
Peter Eisentraut wrote:
Bruce Momjian wrote:
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; otherwise it looks fine.
Thanks, committed that way. I noticed that --lc-ctype and --lc-collate
were forgotten in SGML docs, so I
D'Arcy J.M. Cain wrote:
On Mon, 12 Jan 2009 12:19:51 -0500 (EST)
Bruce Momjian br...@momjian.us wrote:
Yep, that is my analysis as well. If you want a pretty ReST-like
output, that can be added later.
Not if you use border 3 for full ReST. I see nothing but pushback
later if you try to
Andrew Chernow wrote:
Bruce Momjian wrote:
I supposed Solaris 2.5.1 (release 1996) is just too old to add
threading, and this code has been unchanged for years.
Yeah, its old. Unfortunately for us, we still have to support it.
To set the record straight, the issue is not threads.
Andrew Chernow wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
I supposed Solaris 2.5.1 (release 1996) is just too old to add
threading, and this code has been unchanged for years.
Yeah, its old. Unfortunately for us, we still have to support it.
To set the record straight,
Tom Lane wrote:
BTW, another corner case that I'm not sure gets handled right is
that the join columns in JOIN USING or NATURAL JOIN need to be marked
as requiring ACL_SELECT. (Or so I'd expect anyway; I didn't run through
the SQL spec looking for chapter and verse on that.) I forget whether
Andrew,
* Andrew Dunstan (and...@dunslane.net) wrote:
Stephen Frost wrote:
Yes, logrotate will happily call external applications. Maybe I'm
missing something, but obviously if PG can't be configured with a fixed
filename, pg_rotate_logfile() doesn't help the situation.
I should think a
Forgot to mention, there is an easy fix:
~]# LDFLAGS=-lnsl ./configure --enable-thread-safety
But I assume that only works if I use gethostbyname_r(), right?
No, works for gethostbyname as well. They are all in libnsl.
But we do check for that in thread_test.c.
The problem with
Pg_readahead is a tool to prefetch data pages before redoing, based on
the contents of archive/active WAL segment. For 8.3 and 8.4 without
sync.rep, this works together with restore_command. Pg_readahead
analyze WAL segment, schedule and issue posix_fadvise() to prefetch
data pages quickly
However, since there's no standard strftime escape for epoch,
Robert's proposal to rip out the functionality would break any existing
code that still depends on this formatting option. I can't say that
there is any, but by the same token he can't say there isn't.
Absolutely - so the question
Thanks for picking this up, despite my report was so vague.
Simon Riggs wrote:
Best way seems to be to do (almost) the same thing as ExtendSubtrans()
during recovery, so we zero out pages at the point that recovering
transactions get written to pg_subtrans.
Yep.
Do we have the same bug with
I updated patch set of SE-PostgreSQL and related stuff (r1408).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1408.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1408.patch
[3/5]
On Tue, Jan 13, 2009 at 10:05:45AM -0300, Alvaro Herrera wrote:
pgace.h: you have a bunch of static inline functions in here. As far
as I know this doesn't work in compilers other than GCC :-( See
pg_list.h (list_head) for an example. I think we can tolerate this for
the three functions in
93 matches
Mail list logo
