Re: [HACKERS] Allow wal_keep_segments to keep all segments

2010-06-02 Thread Simon Riggs
On Wed, 2010-06-02 at 20:28 -0400, Bruce Momjian wrote: > Simon Riggs wrote: > > On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote: > > > > > The attached patch allows wal_keep_segments = -1 to keep all segements; > > > this is particularly useful for taking a base backup, where you need all

Re: [HACKERS] current value support

2010-06-02 Thread Michael Paquier
Sorry about my previous email, I sent a patch to the wrong mailing list. Once again my apologies about that. Regards, Michael P.

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug wrote: >> Oh.  Well, if that's the case, then I guess I lean toward applying the >> patch as-is.  Then there's no need for the caveat "and without manual >> intervention". > > That still leaves the messages awfully ambiguous concerning the cause (data

Re: [HACKERS] [RFC] A tackle to the leaky VIEWs for RLS

2010-06-02 Thread KaiGai Kohei
(2010/06/02 12:02), KaiGai Kohei wrote: >> Here's another thought. If we're leaning toward explicit syntax to >> designate security views (and I do mean IF, since only one person has >> signed on to that, even if it is Tom Lane!), then maybe we should >> think about ripping out the logic that caus

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-02 Thread Florian Pflug
On Jun 3, 2010, at 3:31 , Robert Haas wrote: > On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug wrote: >> On Jun 3, 2010, at 0:58 , Robert Haas wrote: >>> But maybe the message isn't right the first time either. After all >>> the point of having a write-ahead log in the first place is that we >>> sh

Re: [HACKERS] Comments on Exclusion Constraints and related datatypes

2010-06-02 Thread Bruce Momjian
Robert Haas wrote: > > * inet datatypes don't have a commutative operator on which a unique > > index can be built. There is no "overlaps" equivalent, which again is a > > shame because that stops them being used with the new feature. > > This would be a nice thing to fix, and I was thinking about

Re: [HACKERS] Comments on Exclusion Constraints and related datatypes

2010-06-02 Thread Bruce Momjian
Greg Stark wrote: > On Mon, Mar 22, 2010 at 1:15 PM, Simon Riggs wrote: > > > > * Circles, Boxes and other geometric datatypes defined "overlaps" to > > include touching shapes. So > > > > * inet datatypes don't have a commutative operator on which a unique > > index can be built. There is no "ove

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 3:10 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié jun 02 14:16:33 -0400 2010: > >> We could, but I think we'd be better off just freezing at the time we >> mark the page PD_ALL_VISIBLE and then using the visibility map for >> both purposes.  Keeping

Re: [HACKERS] Comments on Exclusion Constraints and related datatypes

2010-06-02 Thread Bruce Momjian
David Fetter wrote: > On Mon, Mar 22, 2010 at 04:04:16PM -0300, Alvaro Herrera wrote: > > David Fetter wrote: > > > > > diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml > > > index 9881ff4..9313112 100644 > > > --- a/doc/src/sgml/func.sgml > > > +++ b/doc/src/sgml/func.sgml > > > @@ -7

[HACKERS] current value support

2010-06-02 Thread Michael Paquier
Hi all, Please see attached a patch that finishes the support for currval. All the structure was in place in GTM but there was still one missing call in sequence.c when calling the function. Now it is possible to get current values for sequences in the whole cluster. Regards, -- Michael Paquie

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug wrote: > On Jun 3, 2010, at 0:58 , Robert Haas wrote: >> But maybe the message isn't right the first time either.  After all >> the point of having a write-ahead log in the first place is that we >> should be able to prevent corruption in the event of

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-02 Thread Florian Pflug
On Jun 3, 2010, at 0:58 , Robert Haas wrote: > But maybe the message isn't right the first time either. After all > the point of having a write-ahead log in the first place is that we > should be able to prevent corruption in the event of an unexpected > shutdown. Maybe the right thing to do is t

Re: [HACKERS] [BUGS] BUG #5487: dblink failed with 63 bytes connection names

2010-06-02 Thread Takahiro Itagaki
Heikki Linnakangas wrote: > Well, looking at the callers, most if not all of them seem to actually > pass a palloc'd copy, allocated by text_to_cstring(). > > Should we throw a NOTICE like vanilla truncate_identifier() does? > > I feel it would be better to just call truncate_identifier() tha

Re: [HACKERS] ALTER TABLE .... make constraint DEFERRABLE

2010-06-02 Thread Bruce Momjian
Simon Riggs wrote: > > Deferrable unique constraints seem an interesting feature, though I have > either some questions or some issues, not sure which. > > I don't seem to be able to find any way to do an ALTER TABLE that adds > this new capability to an existing table. I was able to do it:

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Greg Stark writes: > > So I think this isn't necessarily such a blue moon event. As I > > understand it, all it would take is a single long-running report and a > > vacuum or HOT cleanup occurring on the master. > > I think this is mostly FUD too. How oft

Re: [HACKERS] Allow wal_keep_segments to keep all segments

2010-06-02 Thread Bruce Momjian
Robert Haas wrote: > > The attached patch allows wal_keep_segments = -1 to keep all segements; > > this is particularly useful for taking a base backup, where you need all > > the WAL files during startup of the standby. ?I have documented this > > usage in the patch as well. > > > > I am thinking

Re: [HACKERS] Allow wal_keep_segments to keep all segments

2010-06-02 Thread Bruce Momjian
Simon Riggs wrote: > On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote: > > > The attached patch allows wal_keep_segments = -1 to keep all segements; > > this is particularly useful for taking a base backup, where you need all > > the WAL files during startup of the standby. I have document

Re: [HACKERS] Exposing the Xact commit order to the user

2010-06-02 Thread Greg Stark
On Wed, Jun 2, 2010 at 6:45 PM, Chris Browne wrote: > It would make it easy to conclude: > >   "This next transaction did 8328194 updates.  Maybe we should do >   some kind of checkpoint (e.g. - commit transaction or such) before >   working on it." > >    versus > >   "This transaction we're thin

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-02 Thread Bruce Momjian
Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mi?? jun 02 14:16:33 -0400 2010: > > > We could, but I think we'd be better off just freezing at the time we > > mark the page PD_ALL_VISIBLE and then using the visibility map for > > both purposes. Keeping around the old xmin values

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Tom Lane
Greg Stark writes: > I was assuming the walreceiver only requests more wal in relatively > small chunks and only when replay has caught up and needs more data. I > haven't actually read this code so if that assumption is wrong then > I'm off-base. It is off-base. The receiver does not "request"

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Greg Stark
On Wed, Jun 2, 2010 at 8:14 PM, Tom Lane wrote: > Indeed, but nothing we do can prevent that, if the slave is just plain > slower than the master.  You have to assume that the slave is capable of > keeping up in the absence of query-caused delays, or you're hosed. I was assuming the walreceiver o

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 5:39 PM, Heikki Linnakangas wrote: > On 02/06/10 23:50, Robert Haas wrote: >> >> First, is it appropriate to set the control file state to >> DB_SHUTDOWNED_IN_RECOVERY even when we're in crash recovery (as >> opposed to archive recovery/SR)?  My vote is no, but Heikki though

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-02 Thread Heikki Linnakangas
On 02/06/10 23:50, Robert Haas wrote: First, is it appropriate to set the control file state to DB_SHUTDOWNED_IN_RECOVERY even when we're in crash recovery (as opposed to archive recovery/SR)? My vote is no, but Heikki thought it might be OK. My logic on that is: If the database is known to b

Re: [HACKERS] How to pass around collation information

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 3:46 PM, Peter Eisentraut wrote: > On fre, 2010-05-28 at 20:59 +0300, Peter Eisentraut wrote: >> The feature I'm thinking of is what >> people might call "per-column locale", and the SQL standard defines >> that.  It would look like this: >> >> CREATE TABLE test ( >>     a v

Re: [HACKERS] "caught_up" status in walsender

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 2:44 PM, Tom Lane wrote: > I wrote: >> I'm still inclined to apply the part of Simon's patch that adds a >> transmit timestamp to each SR send chunk.  That would actually be >> completely unused by the slave given my proposal above, but I think that >> it is an important ste

Re: [HACKERS] recovery getting interrupted is not so unusual as it used to be

2010-06-02 Thread Robert Haas
On Mon, May 17, 2010 at 4:33 AM, Fujii Masao wrote: > On Sat, May 15, 2010 at 3:20 AM, Robert Haas wrote: >> Hmm, OK, I think that makes sense.  Would you care to propose a patch? > > Yep. Here is the patch. > > This patch distinguishes normal shutdown from unexpected exit, while the > server is

Re: [HACKERS] "caught_up" status in walsender

2010-06-02 Thread Dimitri Fontaine
Tom Lane writes: > Uh, if the slave is overloaded, *any* implementation will be playing > catchup all the time. Not sure about your point here. Well, sorry, I missed the part where the catchup is measured on walsender side of things. Now that means that a non interrupted flow of queries quicker

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Tom Lane
Heikki Linnakangas writes: > The problem with defining max_archive_delay that way is again that you > can fall behind indefinitely. See my response to Greg Stark --- I don't think this is really an issue. It's certainly far less of an issue than the current situation that query grace periods go

Re: [HACKERS] "caught_up" status in walsender

2010-06-02 Thread Tom Lane
Dimitri Fontaine writes: > I'm still trying to understand the implications of the proposal, which > sounds good but… given just enough load on the slave, wouldn't it be > playing catchup all the time? Uh, if the slave is overloaded, *any* implementation will be playing catchup all the time. No

Re: [HACKERS] How to pass around collation information

2010-06-02 Thread Peter Eisentraut
On fre, 2010-05-28 at 20:59 +0300, Peter Eisentraut wrote: > The feature I'm thinking of is what > people might call "per-column locale", and the SQL standard defines > that. It would look like this: > > CREATE TABLE test ( > a varchar COLLATE de, > b varchar COLLATE fr > ); > > SELECT *

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Heikki Linnakangas
On 02/06/10 20:14, Tom Lane wrote: For realistic values of max_standby_delay ... Hang on right there. What do you consider a realistic value for max_standby_delay? Because I'm not sure I have a grip on that myself. 5 seconds? 5 minutes? 5 hours? I can see use cases for all of those... Wha

Re: [HACKERS] "caught_up" status in walsender

2010-06-02 Thread Dimitri Fontaine
Tom Lane writes: > I wrote: >> I'm still inclined to apply the part of Simon's patch that adds a >> transmit timestamp to each SR send chunk. That would actually be >> completely unused by the slave given my proposal above, but I think that >> it is an important step to take to future-proof the

Re: [HACKERS] Allow wal_keep_segments to keep all segments

2010-06-02 Thread Simon Riggs
On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote: > The attached patch allows wal_keep_segments = -1 to keep all segements; > this is particularly useful for taking a base backup, where you need all > the WAL files during startup of the standby. I have documented this > usage in the patch

Re: [HACKERS] Allow wal_keep_segments to keep all segments

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 3:20 PM, Bruce Momjian wrote: > Bruce Momjian wrote: >> Robert Haas wrote: >> > On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote: >> > > Bruce Momjian writes: >> > >> Uh, did we decide that 'wal_keep_segments' was the best name for this >> > >> GUC setting? ?I know we shipp

Re: [HACKERS] Exposing the Xact commit order to the user

2010-06-02 Thread Chris Browne
heikki.linnakan...@enterprisedb.com (Heikki Linnakangas) writes: > On 24/05/10 19:51, Kevin Grittner wrote: >> The only thing I'm confused about is what benefit anyone expects to >> get from looking at data between commits in some way other than our >> current snapshot mechanism. Can someone expla

[HACKERS] Allow wal_keep_segments to keep all segments

2010-06-02 Thread Bruce Momjian
Bruce Momjian wrote: > Robert Haas wrote: > > On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote: > > > Bruce Momjian writes: > > >> Uh, did we decide that 'wal_keep_segments' was the best name for this > > >> GUC setting? ?I know we shipped beta1 using that name. > > > > > > I thought min_wal_segme

Re: [HACKERS] "caught_up" status in walsender

2010-06-02 Thread Tom Lane
Heikki Linnakangas writes: > On 02/06/10 21:44, Tom Lane wrote: >> In the current coding, the effect of not setting *caughtup here is just >> that we uselessly call XLogSend an extra time for each transmission >> (because the main loop won't ever delay immediately after a >> transmission). But wi

Re: [HACKERS] "caught_up" status in walsender

2010-06-02 Thread Heikki Linnakangas
On 02/06/10 21:44, Tom Lane wrote: In conjunction with that, I think there's a logic bug in XLogSend; it ought to be changed like so: /* if we went beyond SendRqstPtr, back off */ if (XLByteLT(SendRqstPtr, endptr)) + { endptr = SendRqstPtr; + *

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Tom Lane
Greg Stark writes: > On Wed, Jun 2, 2010 at 6:14 PM, Tom Lane wrote: >> I believe that the motivation for treating archived timestamps as live >> is, essentially, to force rapid catchup if a slave falls behind so far >> that it's reading from archive instead of SR. > Huh, I think this is the fir

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-02 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mié jun 02 14:16:33 -0400 2010: > We could, but I think we'd be better off just freezing at the time we > mark the page PD_ALL_VISIBLE and then using the visibility map for > both purposes. Keeping around the old xmin values after every tuple > on the page i

[HACKERS] "caught_up" status in walsender

2010-06-02 Thread Tom Lane
I wrote: > I'm still inclined to apply the part of Simon's patch that adds a > transmit timestamp to each SR send chunk. That would actually be > completely unused by the slave given my proposal above, but I think that > it is an important step to take to future-proof the SR protocol against > pos

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 2:27 PM, Simon Riggs wrote: > Syncing two servers in replication is common practice, as has been > explained here; I'm still surprised people think otherwise. Measuring > the time between two servers is the very purpose of the patch, so the > synchronisation is not a design

Re: [HACKERS] Exposing the Xact commit order to the user

2010-06-02 Thread Chris Browne
d...@csail.mit.edu (Dan Ports) writes: > I'm not clear on why the total rowcount is useful, but perhaps I'm > missing something obvious. It would make it easy to conclude: "This next transaction did 8328194 updates. Maybe we should do some kind of checkpoint (e.g. - commit transaction or s

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Simon Riggs
On Wed, 2010-06-02 at 13:14 -0400, Tom Lane wrote: > This patch seems to me to be going in fundamentally the wrong direction. > It's adding complexity and overhead (far more than is needed), and it's > failing utterly to resolve the objections that I raised to start with. Having read your proposa

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Greg Stark
On Wed, Jun 2, 2010 at 6:14 PM, Tom Lane wrote: > I believe that the motivation for treating archived timestamps as live > is, essentially, to force rapid catchup if a slave falls behind so far > that it's reading from archive instead of SR. Huh, I think this is the first mention of this that I

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 2:05 PM, Tom Lane wrote: > Alvaro Herrera writes: >> The problem is that vacuum doesn't know that a certain part of the table >> is already frozen.  It needs to scan it completely anyways.  If we had a >> "frozen" map, we could mark pages that are completely frozen and thus

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Robert Haas
On Wed, Jun 2, 2010 at 2:03 PM, Simon Riggs wrote: > On Wed, 2010-06-02 at 13:45 -0400, Tom Lane wrote: >> Stephen Frost writes: >> > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> Comments? >> >> > I'm not really a huge fan of adding another GUC, to be honest.  I'm more >> > inclined to say we tre

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-02 Thread Tom Lane
Alvaro Herrera writes: > The problem is that vacuum doesn't know that a certain part of the table > is already frozen. It needs to scan it completely anyways. If we had a > "frozen" map, we could mark pages that are completely frozen and thus do > not need any vacuuming; but we don't (I don't re

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Simon Riggs
On Wed, 2010-06-02 at 13:45 -0400, Tom Lane wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Comments? > > > I'm not really a huge fan of adding another GUC, to be honest. I'm more > > inclined to say we treat 'max_archive_delay' as '0', and turn > > max_streaming_d

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-02 Thread Alvaro Herrera
Excerpts from Russell Smith's message of mié jun 02 06:38:35 -0400 2010: > Don't you not get a positive enough effect by adjusting the table's > autovacuum_min_freeze_age and autovacuum_max_freeze_age. If you set > those numbers small, it appears to me that you would get very quickly to > a state

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Tom Lane
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Comments? > I'm not really a huge fan of adding another GUC, to be honest. I'm more > inclined to say we treat 'max_archive_delay' as '0', and turn > max_streaming_delay into what you've described. If we fall back so far > that w

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Andrew Dunstan
Tom Lane wrote: I'm still inclined to apply the part of Simon's patch that adds a transmit timestamp to each SR send chunk. That would actually be completely unused by the slave given my proposal above, but I think that it is an important step to take to future-proof the SR protocol against po

Re: [HACKERS] Synchronization levels in SR

2010-06-02 Thread Greg Smith
Tom Lane wrote: Heikki Linnakangas writes: It's pretty scary to call a user-defined function at that point in transaction. Not so much "pretty scary" as "zero chance of being accepted". And I do mean zero. I swear, you guys are such buzzkills some days. I was suggesting a model

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > An important property of this design is that all relevant timestamps > are taken on the slave, so clock skew isn't an issue. I agree that this is important, and I do run NTP on all my servers and even monitor it using Nagios. It's still not a cure-all for

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Tom Lane
Simon Riggs writes: > OK, here's v4. I've been trying to stay out of this thread, but with beta2 approaching and no resolution in sight, I'm afraid I have to get involved. This patch seems to me to be going in fundamentally the wrong direction. It's adding complexity and overhead (far more than

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Kevin Grittner
Simon Riggs wrote: > On Mon, 2010-05-31 at 14:40 -0400, Bruce Momjian wrote: > >> Uh, we have three days before we package 9.0beta2. It would be >> good if we could decide on the max_standby_delay issue soon. > > I've heard something from Heikki, not from anyone else. Those > comments amount to

Re: [HACKERS] Keepalive for max_standby_delay

2010-06-02 Thread Simon Riggs
On Mon, 2010-05-31 at 14:40 -0400, Bruce Momjian wrote: > Uh, we have three days before we package 9.0beta2. It would be good if > we could decide on the max_standby_delay issue soon. I've heard something from Heikki, not from anyone else. Those comments amount to "lets replace max_standby_delay

Re: [HACKERS] proposal - custom format for date, timestamp

2010-06-02 Thread Pavel Stehule
2010/6/2 Tom Lane : > Pavel Stehule writes: >> I thinking about request on custom datetime format. My first idea is: > >> a) add new datestyle format "custom" >> b) add new GUC variables - custom_date_format, custom_time_format, >> custom_timestamp_format > > Ick.  Why not just put them in one var

Re: [HACKERS] Synchronization levels in SR

2010-06-02 Thread Tom Lane
Heikki Linnakangas writes: > It's pretty scary to call a user-defined function at that point in > transaction. Not so much "pretty scary" as "zero chance of being accepted". And I do mean zero. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@pos

Re: [HACKERS] proposal - custom format for date, timestamp

2010-06-02 Thread Tom Lane
Pavel Stehule writes: > I thinking about request on custom datetime format. My first idea is: > a) add new datestyle format "custom" > b) add new GUC variables - custom_date_format, custom_time_format, > custom_timestamp_format Ick. Why not just put them in one variable. datestyle = 'cu

Re: [HACKERS] Streaming Replication: Checkpoint_segment and wal_keep_segments on standby

2010-06-02 Thread Fujii Masao
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas wrote: > On 02/06/10 06:23, Fujii Masao wrote: >> >> On Mon, May 31, 2010 at 7:17 PM, Fujii Masao >>  wrote: >>> >>> 4) Change it so that checkpoint_segments takes effect in standby mode, >>> but not during recovery otherwise >> >> I revised the p

[HACKERS] proposal - custom format for date, timestamp

2010-06-02 Thread Pavel Stehule
Hello I thinking about request on custom datetime format. My first idea is: a) add new datestyle format "custom" b) add new GUC variables - custom_date_format, custom_time_format, custom_timestamp_format There are some questions: a) what is good behave when datestyle = custom, but some necessary

Re: [HACKERS] Streaming Replication: Checkpoint_segment and wal_keep_segments on standby

2010-06-02 Thread Heikki Linnakangas
On 02/06/10 06:23, Fujii Masao wrote: On Mon, May 31, 2010 at 7:17 PM, Fujii Masao wrote: 4) Change it so that checkpoint_segments takes effect in standby mode, but not during recovery otherwise I revised the patch to achieve 4). This will enable checkpoint_segments to trigger a restartpoint

Re: [HACKERS] [BUGS] BUG #5487: dblink failed with 63 bytes connection names

2010-06-02 Thread Heikki Linnakangas
On 02/06/10 09:46, Takahiro Itagaki wrote: Heikki Linnakangas wrote: Hmm, seems that dblink should call truncate_identifier() for the truncation, to be consistent with truncation of table names etc. Hmmm, we need the same routine with truncate_identifier(), but we hard to use the function b

Re: [HACKERS] Idea for getting rid of VACUUM FREEZE on cold pages

2010-06-02 Thread Russell Smith
On 28/05/10 04:00, Josh Berkus wrote: >> Consider a table that is >> regularly written but append-only. Every time autovacuum kicks in, >> we'll go and remove any dead tuples and then mark the pages >> PD_ALL_VISIBLE and set the visibility map bits, which will cause >> subsequent vacuums to ignor

Re: [HACKERS] Synchronization levels in SR

2010-06-02 Thread Simon Riggs
On Wed, 2010-06-02 at 03:22 -0400, Greg Smith wrote: > Heikki Linnakangas wrote: > > The possibilities are endless... Your proposal above covers a pretty > > good set of scenarios, but it's by no means complete. If we try to > > solve everything the configuration will need to be written in a > >

Re: [HACKERS] obsolete comments in xlog.c

2010-06-02 Thread Heikki Linnakangas
On 02/06/10 10:39, Fujii Masao wrote: I found some obsolete comments in xlog.c, which are related to recently-deleted variable "fromArchive". Thanks, committed. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] Synchronization levels in SR

2010-06-02 Thread Heikki Linnakangas
On 02/06/10 10:22, Greg Smith wrote: Heikki Linnakangas wrote: The possibilities are endless... Your proposal above covers a pretty good set of scenarios, but it's by no means complete. If we try to solve everything the configuration will need to be written in a Turing-complete Replication Descr

[HACKERS] obsolete comments in xlog.c

2010-06-02 Thread Fujii Masao
Hi, I found some obsolete comments in xlog.c, which are related to recently-deleted variable "fromArchive". diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index c886571..65675b9 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xl

Re: [HACKERS] Synchronization levels in SR

2010-06-02 Thread Greg Smith
Heikki Linnakangas wrote: The possibilities are endless... Your proposal above covers a pretty good set of scenarios, but it's by no means complete. If we try to solve everything the configuration will need to be written in a Turing-complete Replication Description Language. We'll have to pick