Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 08:26 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: Conflict resolution improvements are important to include in this release, as discussed many times. Proposal given here http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php presents a viable design to improve this. Following patch is a complete working implementation of that design. I'm still testing it, but its worth publishing as early as possible to allow discussion. Not for commit, just yet, but soon. Um, you're not considering this for 9.0, are you? I think it's time to concentrate on the must-fix issues and fix the rough edges in what we have. Yes, it is important. For example, the can't start hot standby mode from a shutdown checkpoint issue is a must-fix issue in my opinion, about 10x as important as this. When that was last discussed, many others agreed. I run into that all the time when testing streaming replication, and every time I go Huh, why isn't the standby opening up for connections?, and then, Ahh, it's this stupid shutdown checkpoint issue again. That was not the feedback I have received. Nobody has commented on that to me, though many have commented on the need for the current patch. As mentioned, I went to the trouble of running a meeting to gain additional feedback and the result was very clear. Of course, if we ignore any feature, then someone will say its that stupid issue again, but that won't imply we got our priority wrong. And the VACUUM FULL issue is still hanging too. Yes, that is a must fix. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, Jan 29, 2010 at 9:03 AM, Simon Riggs si...@2ndquadrant.com wrote: That was not the feedback I have received. Nobody has commented on that to me, though many have commented on the need for the current patch. As mentioned, I went to the trouble of running a meeting to gain additional feedback and the result was very clear. I don't have a technical opinion about this problem yet as I haven't tested HS+SR yet but I'm not sure it's a good idea to base technical decisions and priorities on user polls (I'm pretty sure most of them don't use HS+SR as much as Heikki these days). If you ask people what they want in their future cars, they won't answer they want wheels or an engine: it's something obvious for them. AFAICS (but I might be wrong), you asked this question to people who are interested in HS+SR but don't have any idea of what it's like to use HS+SR daily with or without this limitation. There are perhaps better arguments for not doing it but this one seems a bit weird to me. -- Guillaume -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication, and walsender during recovery
On Fri, 2010-01-29 at 09:49 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: On Thu, 2010-01-28 at 21:00 +0200, Heikki Linnakangas wrote: I think it is a pretty important safety feature that we keep all the WAL around that's needed to recover the standby. To avoid out-of-disk-space situation, it's probably enough in practice to set checkpoint_timeout small enough in the standby to trigger restartpoints often enough. Hmm, I'm sorry but that's bogus. Retaining so much WAL that we are strongly in danger of blowing disk space is not what I would call a safety feature. Since there is no way to control or restrain the number of files for certain, that approach seems fatally flawed. The other alternative is to refuse to recover if the master can't be contacted to stream the missing WAL again. Surely that's worse. What is the behaviour of the standby if it hits a disk full error while receiving WAL? Hopefully it stops receiving WAL and then clears enough disk space to allow it to receive from archive instead? Yet stays up to allow queries to continue? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication, and walsender during recovery
On Fri, Jan 29, 2010 at 4:13 AM, Simon Riggs si...@2ndquadrant.com wrote: Hmm, I'm sorry but that's bogus. Retaining so much WAL that we are strongly in danger of blowing disk space is not what I would call a safety feature. Since there is no way to control or restrain the number of files for certain, that approach seems fatally flawed. Reducing checkpoint_timeout is the opposite of what you would want to do for performance. Why do you worry about that only in the standby? The primary (i.e., postgres in the normal mode) has been in the same situation until now. But usually the cycle of restartpoint is longer than that of checkpoint. Because restartpoint occurs when the checkpoint record has been replayed AND checkpoint_timeout has been reached. So the WAL files might more easily accumulate in the standby. To improve the situation, I think that we need to use checkpoint_segment/timeout as a trigger of restartpoint, regardless of the checkpoint record. Though I'm not sure that is possible and should be included in v9.0. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 09:20 +0100, Guillaume Smet wrote: On Fri, Jan 29, 2010 at 9:03 AM, Simon Riggs si...@2ndquadrant.com wrote: That was not the feedback I have received. Nobody has commented on that to me, though many have commented on the need for the current patch. As mentioned, I went to the trouble of running a meeting to gain additional feedback and the result was very clear. I don't have a technical opinion about this problem yet as I haven't tested HS+SR yet but I'm not sure it's a good idea to base technical decisions and priorities on user polls (I'm pretty sure most of them don't use HS+SR as much as Heikki these days). If you ask people what they want in their future cars, they won't answer they want wheels or an engine: it's something obvious for them. AFAICS (but I might be wrong), you asked this question to people who are interested in HS+SR but don't have any idea of what it's like to use HS+SR daily with or without this limitation. Well, you are correct that a larger group of users *could* have avoided an obvious and important issue. Though if you deploy that argument it can be applied both ways: Heikki may also be missing an obvious and important issue. Where does that leave us? I am not against putting both into this release. If I am forced to choose just one, I've at least given reasons why that should be so. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication, and walsender during recovery
On Fri, 2010-01-29 at 17:31 +0900, Fujii Masao wrote: On Fri, Jan 29, 2010 at 4:13 AM, Simon Riggs si...@2ndquadrant.com wrote: Hmm, I'm sorry but that's bogus. Retaining so much WAL that we are strongly in danger of blowing disk space is not what I would call a safety feature. Since there is no way to control or restrain the number of files for certain, that approach seems fatally flawed. Reducing checkpoint_timeout is the opposite of what you would want to do for performance. Why do you worry about that only in the standby? I don't. The safety feature we just added makes it much more likely that this will happen on standby. To improve the situation, I think that we need to use checkpoint_segment/timeout as a trigger of restartpoint, regardless of the checkpoint record. Though I'm not sure that is possible and should be included in v9.0. Yes, that is a simple change. I think it is needed now. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
Simon Riggs wrote: On Fri, 2010-01-29 at 08:26 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: Conflict resolution improvements are important to include in this release, as discussed many times. Proposal given here http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php presents a viable design to improve this. Following patch is a complete working implementation of that design. I'm still testing it, but its worth publishing as early as possible to allow discussion. Not for commit, just yet, but soon. Um, you're not considering this for 9.0, are you? I think it's time to concentrate on the must-fix issues and fix the rough edges in what we have. Yes, it is important. For example, the can't start hot standby mode from a shutdown checkpoint issue is a must-fix issue in my opinion, about 10x as important as this. When that was last discussed, many others agreed. I run into that all the time when testing streaming replication, and every time I go Huh, why isn't the standby opening up for connections?, and then, Ahh, it's this stupid shutdown checkpoint issue again. That was not the feedback I have received. Nobody has commented on that to me, Yes they have. I have on several occasions, as have other people on this mailing list: http://archives.postgresql.org/message-id/603c8f070912201611h4951087craa080ff6b48a9...@mail.gmail.com http://archives.postgresql.org/message-id/4b30ae53.6020...@gmail.com http://archives.postgresql.org/message-id/407d949e0912220738je1e0141m87d7b688dd4ba...@mail.gmail.com I even *fixed* that already, but you decided to take it out before committing. I then added it to the list of must-fix items in the TODO list, but you took that out too. I have no objection to doing things in smaller steps, but this *is* a must-fix item before release. I still don't understand why you took it out, nor why you're objecting to that. though many have commented on the need for the current patch. Who? As mentioned, I went to the trouble of running a meeting to gain additional feedback and the result was very clear. So what was the clear result? If you're looking for things to do, I agree with Greg Stark that the removal of max_standby_delay=-1 option is not good. That should be fixed too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote: So what was the clear result? I have spoken clearly enough. You were welcome to attend the Hot Standby User Group. The fact that you did not expresses your own priorities quite well, ISTM. Your protestations to know more about the wishes of users than they do themselves isn't hugely impressive. There are many features we should add. I will add them in priority order until forced to stop. If you or anyone else believes features are essential, then either add them yourselves or have the courage to stand up and say the release should be delayed so that I can. To do otherwise is to admit you do not actually consider them essential. It cannot be both ways. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
Heikki Linnakangas wrote: Simon Riggs wrote: Conflict resolution improvements are important to include in this release, as discussed many times. Proposal given here http://archives.postgresql.org/pgsql-hackers/2009-12/msg01175.php presents a viable design to improve this. Following patch is a complete working implementation of that design. I'm still testing it, but its worth publishing as early as possible to allow discussion. Not for commit, just yet, but soon. Um, you're not considering this for 9.0, are you? I think it's time to concentrate on the must-fix issues and fix the rough edges in what we have. I agree - this looks like a completely new feature development to me that tries to move the goalpost quite far for 9.0. For example, the can't start hot standby mode from a shutdown checkpoint issue is a must-fix issue in my opinion, about 10x as important as this. When that was last discussed, many others agreed. I run into that all the time when testing streaming replication, and every time I go Huh, why isn't the standby opening up for connections?, and then, Ahh, it's this stupid shutdown checkpoint issue again. Yeah I ran into that one during testing as well - and I consider it a serious issue And the VACUUM FULL issue is still hanging too. And maybe you could help with some other things on the open items or commitfest list. yeah and we keep finding major bugs nearly daily so I don't think we should add features that way now. First is stability and reliability, optimization and new features are imho clearly 9.1+ material. Just calling the release 9.0 and saying we do that because it is a radical change and we expect some instability should NOT mean we are free to put in every feature at the last minute with yeah thats fine because people expect instability anyways. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] plperl db access documentation enhancement
Hello,
We were asked by Enova Financial to improve the documentation of PL/Perl
database access functions.
Alvaro and me worked on that and we produced the patch that is attached. It
splits initial block of functions
into the groups with the description directly following each of the group,
corrects couple of mistakes and
adds an example.
One of the existing mistakes was confusion in definitions of spi_exec_prepared
and spi_query_prepared.
Another one is usage of INTEGER type to return the result of spi_prepare in the
example for prepared queries.
When trying to execute that function I've got the following error:
postgres=# CREATE OR REPLACE FUNCTION init() RETURNS INTEGER AS $#
$_SHARED{my_plan} = spi_prepare( 'SELECT (now() + $1)::date AS now',
'INTERVAL');
$$ LANGUAGE plperl;
CREATE FUNCTION
postgres=# select init();
ERROR: invalid input syntax for integer: 0x1007d6f40
CONTEXT: PL/Perl function init
Since the return value is not used anyway, I've changed the return type of the
function declaration in the example to VOID.
I think this is a good reason to suggest backpatching these changes down to
8.2.
plperl_db.diff
Description: Binary data
--
Alexey Klyukin http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
Simon Riggs wrote: On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote: So what was the clear result? I have spoken clearly enough. You were welcome to attend the Hot Standby User Group. The fact that you did not expresses your own priorities quite well, ISTM. Your protestations to know more about the wishes of users than they do themselves isn't hugely impressive. huh? traditionally discussions of that kind had to happen on -hackers and not in some online place some unnamed people attended. There are many features we should add. I will add them in priority order until forced to stop. we are past the point of adding new features for 9.0 imho If you or anyone else believes features are essential, then either add them yourselves or have the courage to stand up and say the release should be delayed so that I can. To do otherwise is to admit you do not actually consider them essential. It cannot be both ways. bugfix and stabilization mode is what we are in now (except for the stuff that already made it into the commitfest). Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote: yeah and we keep finding major bugs nearly daily Facts, please? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
2010/1/29 Stefan Kaltenbrunner ste...@kaltenbrunner.cc: Simon Riggs wrote: On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote: So what was the clear result? I have spoken clearly enough. You were welcome to attend the Hot Standby User Group. The fact that you did not expresses your own priorities quite well, ISTM. Your protestations to know more about the wishes of users than they do themselves isn't hugely impressive. huh? traditionally discussions of that kind had to happen on -hackers and not in some online place some unnamed people attended. +1. Haven't we had enough communications failures with off-hackers groups trying to come up with something only to have it not be agreed upon by hackers later on? (win32 would be the biggest thing so far, but it's not like we haven't done it before in more cases) There are many features we should add. I will add them in priority order until forced to stop. we are past the point of adding new features for 9.0 imho If you or anyone else believes features are essential, then either add them yourselves or have the courage to stand up and say the release should be delayed so that I can. To do otherwise is to admit you do not actually consider them essential. It cannot be both ways. bugfix and stabilization mode is what we are in now (except for the stuff that already made it into the commitfest). Well, per some recent discussions, it seems small features are still ok. But I doubt this qualifies as such. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 11:12 +0100, Stefan Kaltenbrunner wrote: There are many features we should add. I will add them in priority order until forced to stop. we are past the point of adding new features for 9.0 imho So presumably we cannot add the new feature to start hot standby at shutdown checkpoints then either? If you or anyone else believes features are essential, then either add them yourselves or have the courage to stand up and say the release should be delayed so that I can. To do otherwise is to admit you do not actually consider them essential. It cannot be both ways. bugfix and stabilization mode is what we are in now (except for the stuff that already made it into the commitfest). That's where we'd like to be, but these new features have not been in the tree long enough for what you say to be the actual position. We can pretend it is, but that doesn't make it so. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
Simon Riggs wrote: On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote: yeah and we keep finding major bugs nearly daily Facts, please? 5 seconds of time spent on archives.postgresql.org show at least the following SR/HS related bugs in the last 7 days or so: http://archives.postgresql.org/pgsql-committers/2010-01/msg00400.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00410.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00396.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00323.php some of those you might call minor but they are bugs and given the current rate we are seeing them is imho a clear sign of code by far not stable enough to consider new features that late in the cycle Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
Simon Riggs wrote: On Fri, 2010-01-29 at 11:12 +0100, Stefan Kaltenbrunner wrote: There are many features we should add. I will add them in priority order until forced to stop. we are past the point of adding new features for 9.0 imho So presumably we cannot add the new feature to start hot standby at shutdown checkpoints then either? well as far as I recall that ones has been proposed much earlier than mid of december(like the patch in discussion here) and I agree with heikki that I'm not clear on what your actual objections to that patch were - care to provide a link to the archives please? If you or anyone else believes features are essential, then either add them yourselves or have the courage to stand up and say the release should be delayed so that I can. To do otherwise is to admit you do not actually consider them essential. It cannot be both ways. bugfix and stabilization mode is what we are in now (except for the stuff that already made it into the commitfest). That's where we'd like to be, but these new features have not been in the tree long enough for what you say to be the actual position. We can pretend it is, but that doesn't make it so. Not sure I follow (maybe because I'm not a native speaker) but are you trying to say that we can simply add new features late in the release cycle to stuff commited because it is not long in the tree instead of focusing stabilizing what we have? If you are so sure that we NEED those features to be releaseworthy - maybe it was premature to commit HS and SR for this cycle? Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 11:20 +0100, Stefan Kaltenbrunner wrote: Simon Riggs wrote: On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote: yeah and we keep finding major bugs nearly daily Facts, please? 5 seconds of time spent on archives.postgresql.org show at least the following SR/HS related bugs in the last 7 days or so: http://archives.postgresql.org/pgsql-committers/2010-01/msg00400.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00410.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00396.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00323.php some of those you might call minor but they are bugs and given the current rate we are seeing them is imho a clear sign of code by far not stable enough to consider new features that late in the cycle I don't think two very minor bugs in Hot Standby, reported and fixed 7 days apart is any indication of instability. It isn't the daily bugs reported you suggested. Personally, I think it indicates quite the opposite - if those are the only bugs I can find now, I'm ecstatic. I think your argument does apply to Streaming Rep, at this point. We should consider releasing Alpha4 and then later going to Beta. My point of view expressed here is not built in a few seconds, it is built on discussion and feedback over 18 months. The conflict issue was discussed by me with hackers at the May 2008 dev meeting. It should be improved upon in this release and it has been the main issue concerning the full range of people I have discussed HS with. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Streaming replication and pg_xlogfile_name()
On Thu, Jan 28, 2010 at 5:28 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: How about extending the format of the string returned by pg_last_xlog_receive/replay_location() to include the timeline ID? When it currently returns e.g '6/200016C', it could return '1/6/200016C', where 1 is the timeline ID. Then just teach pg_xlogfile_name[_offset]() to accept that format as well. Sounds good. The attached patch does so. Also the code is available in the 'replication' branch in my git repository. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center *** a/doc/src/sgml/func.sgml --- b/doc/src/sgml/func.sgml *** *** 13152,13157 postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup()); --- 13152,13161 This is usually the desired behavior for managing transaction log archiving behavior, since the preceding file is the last one that currently needs to be archived. + These functions also accept as a parameter the string that consists of timeline and + location, separated by a slash. In this case a transaction log file name is computed + by using the given timeline. On the other hand, if timeline is not supplied, the + current timeline is used for the computation. /para para *** *** 13198,13210 postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup()); literalfunctionpg_last_xlog_receive_location/function()/literal /entry entrytypetext/type/entry !entryGet last transaction log location received and synced to disk during ! streaming recovery. If streaming recovery is still in progress this will increase monotonically. If streaming recovery has completed then this value will remain static at the value of the last WAL record received and synced to disk during that recovery. When the server has been started without a streaming recovery then the return value will be ! InvalidXLogRecPtr (0/0). /entry /row row --- 13202,13216 literalfunctionpg_last_xlog_receive_location/function()/literal /entry entrytypetext/type/entry !entryGet timeline and location of last transaction log received and synced ! to disk during streaming recovery. The return string is separated by a slash, ! the first value indicates the timeline and the other the location. ! If streaming recovery is still in progress this will increase monotonically. If streaming recovery has completed then this value will remain static at the value of the last WAL record received and synced to disk during that recovery. When the server has been started without a streaming recovery then the return value will be ! literal0/0/0/. /entry /row row *** *** 13212,13223 postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup()); literalfunctionpg_last_xlog_replay_location/function()/literal /entry entrytypetext/type/entry !entryGet last transaction log location replayed during recovery. If recovery is still in progress this will increase monotonically. If recovery has completed then this value will remain static at the value of the last WAL record applied during that recovery. When the server has been started normally without a recovery ! then the return value will be InvalidXLogRecPtr (0/0). /entry /row /tbody --- 13218,13231 literalfunctionpg_last_xlog_replay_location/function()/literal /entry entrytypetext/type/entry !entryGet timeline and location of last transaction log replayed during ! recovery. The return string is separated by a slash, the first value ! indicates the timeline and the other the location. If recovery is still in progress this will increase monotonically. If recovery has completed then this value will remain static at the value of the last WAL record applied during that recovery. When the server has been started normally without a recovery ! then the return value will be literal0/0/0/. /entry /row /tbody *** a/src/backend/access/transam/xlog.c --- b/src/backend/access/transam/xlog.c *** *** 395,400 typedef struct XLogCtlData --- 395,402 TimestampTz recoveryLastXTime; /* end+1 of the last record replayed */ XLogRecPtr recoveryLastRecPtr; + /* tli of last record replayed */ + TimeLineID recoveryLastTLI; slock_t info_lck; /* locks shared variables shown above */ } XLogCtlData; *** *** 5864,5873 StartupXLOG(void) /* use volatile pointer to prevent code rearrangement */ volatile XLogCtlData *xlogctl = XLogCtl;
Re: [HACKERS] Streaming replication, and walsender during recovery
On Fri, Jan 29, 2010 at 5:41 PM, Simon Riggs si...@2ndquadrant.com wrote: To improve the situation, I think that we need to use checkpoint_segment/timeout as a trigger of restartpoint, regardless of the checkpoint record. Though I'm not sure that is possible and should be included in v9.0. Yes, that is a simple change. I think it is needed now. On second thought, it's difficult to force restartpoint without a checkpoint record. A recovery always needs to start from a checkpoint redo location. Otherwise a torn page might be caused because a full-page image has not been replayed. So restartpoint will not start without a checkpoint record. But at least we might have to change the bgwriter so as to use not only checkpoint_timeout but also checkpoint_segments as a trigger of restartpoint. It would be useful for people who want to control the cycle of checkpoint by using only checkpoint_segments. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add on_perl_init and proper destruction to plperl UPDATED [PATCH]
On Thu, Jan 28, 2010 at 11:02:23PM -0500, Andrew Dunstan wrote: Tim Bunce wrote: This is an updated version of the third of the patches to be split out from the former 'plperl feature patch 1'. It includes changes following discussions with Tom Lane and others. Changes in this patch: - Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP) SPI functions are not available when the code is run. - Added interpreter destruction behaviour Hooked via on_proc_exit(). Only has any effect for normal shutdown. END blocks, if any, are run then objects are destroyed, calling their DESTROY methods, if any. SPI functions will die if called at this time. This patch is giving me a build error on Windows: undefined reference to `Perl_sv_clean_objs' Ah, phooey. That's technically a private function so isn't exported on platforms that support selective exporting. The options are either to go back to calling perl_destruct(), which would then require careful auditing of what perl_destruct actually does, or do simply not bother destroying objects. I'm going to go for the latter. Time is short and calling END blocks is still a major step forward. (Anyone who needs objects destroyed can probably arrange that themselves via an END block.) Updated patch to follow... Tim. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl compiler warning
On Thu, Jan 28, 2010 at 07:49:37PM +, Tim Bunce wrote: I think I missed this because the Xcode compiler on Snow Leopard is fairly old (gcc 4.2.1). For the record, gcc 4.2.1 does report the error. I'd missed it because I'd done most of my builds with perl 5.8.x and the notnull attributes was added later, in 5.10.0. Tim. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, Jan 29, 2010 at 5:08 AM, Simon Riggs si...@2ndquadrant.com wrote: On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote: So what was the clear result? I have spoken clearly enough. You were welcome to attend the Hot Standby User Group. The fact that you did not expresses your own priorities quite well, ISTM. Your protestations to know more about the wishes of users than they do themselves isn't hugely impressive. This doesn't make any sense at all. It is not the case that people who attended the Hot Standby user group are the only ones who are entitled to provide any feedback, and that people who read pgsql-hackers are not (unless they also happen to have attended the Hot Standby user group). If anything, that's 100% backwards, but at any rate Heikki has probably spent more time over the last year on this feature than anyone in the world with the exception of yourself; I think that counts for a lot more than one two-hour meeting. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] helpers to convert C types to postgres types (Array)
I'm still trying to collect all the bits to be able to read and return several types of data in C functions. I'm looking for quick ways to deal with ArrayType. I'd expect some helper because these kind of operation should be frequent and without any helper (function/macro) they really make the code awful. Generally you work with C types that later you've to convert to Postgres types. So for example you may have an array of int2 that then you've to place into an ArrayType. I think there are 3 kinds of operation you may have to do: 1 You may have an already formed C array type and you'd just copy it into an ArrayType 2 You may know the # of elements of the C array type but you're filling it an element at a time 3 You don't know the number of elements in the array in advance so you'd like to append to the ArrayType one element at a time 1 seems to require - creating an array of Datum - looping over the C array - assign to each Datum element the converted C value - construct_array the Postgres array That's a pain. Any other way? macro? 2 Seems the easiest 3 ??? Is there any function in postgres that let you append elements to an ArrayType? thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 07:01 -0500, Robert Haas wrote: On Fri, Jan 29, 2010 at 5:08 AM, Simon Riggs si...@2ndquadrant.com wrote: On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote: So what was the clear result? I have spoken clearly enough. You were welcome to attend the Hot Standby User Group. The fact that you did not expresses your own priorities quite well, ISTM. Your protestations to know more about the wishes of users than they do themselves isn't hugely impressive. This doesn't make any sense at all. I am busy working on the right features for the most number of people, as expressed to me. I accept there are people that disagree and I am sorry for that. Others are welcome to add code to do the things I will not be doing through lack of time, if they are not satisfied with my priority. I think we should extend the time available to make sure we have a sensible set of features for 9.0. The heat of this discussion tells me that we are going to be lacking features that are must-have to someone, whether or not they are in the majority. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Pathological regexp match
2010/1/29 Alvaro Herrera alvhe...@commandprompt.com: Hi Michael, Michael Glaesemann wrote: We came across a regexp that takes very much longer than expected. PostgreSQL 8.4.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44), 64-bit SELECT 'ooo...' ~ $r$Z(Q)[^Q]*A.*?(\1)$r$; -- omitted for email brevity The ? after .* is pointless. If you remove it, the query returns immediately. (There's a badly needed CHECK_FOR_INTERRUPTS in this code BTW) Incidentally, I ran across the exact same issue with a non-greedy regexp with a client earlier this week, and put on my TODO to figure out a good place to stick a check for interrupts. Does this mean I don't have to, because you're on it? ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WARNING: pgstat wait timeout
2010/1/29 Greg Smith g...@2ndquadrant.com:
I just found a few of these errors in a log file during some pgbench testing
tonight. Linux, recent CVS HEAD; given the range of systems and versions
this has been reported against now, this bug doesn't look like a platform or
version/build specific issue.
Unfortunately the instance I had up wasn't setup very well for logging, but I
did notice that all of the ones I saw had nearby messages about autovacuum
issues, which seems to match Tom's earlier suggestion at
http://archives.postgresql.org/pgsql-bugs/2009-07/msg00083.php that the
source of the warning (but not necessarily the underlying problem) for these
is the autovacuum launcher complaining; here's two different sets:
ERROR: canceling autovacuum task
CONTEXT: automatic analyze of table pgbench.public.pgbench_accounts
WARNING: pgstat wait timeout
WARNING: pgstat wait timeout
ERROR: canceling autovacuum task
CONTEXT: automatic analyze of table pgbench.public.pgbench_accounts
WARNING: pgstat wait timeout
ERROR: canceling autovacuum task
CONTEXT: automatic analyze of table pgbench.public.pgbench_accounts
ERROR: canceling autovacuum task
CONTEXT: automatic analyze of table pgbench.public.pgbench_accounts
Because of what I'm (not) seeing in pg_stat_bgwriter, I'm suspicious that its
underlying work or messages may be involved here. I'm not seeing the sort of
totals I expect in that view after these large bouts of activity. Now, my
use tonight has included the new pg_stat_reset_shared('bgwriter') to clear
out those stats between runs, so perhaps that's involved too. Guessing not
only because of the reports going back to 8.4 that also have this error
message.
Will keep an eye out for this one now that I know I might run into it, have
already cranked up the logging and will look for something reproducible to
gather more info.
I've seen this happen semi-frequently during initdb on win32 on an
Amazon EC2 image. I attributed it to the combination of windows and
overloaded virtualization, but it may just be that it shows up more
often there.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HS/SR and smart shutdown
On Thu, Jan 21, 2010 at 4:27 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: It's a good question if that still makes sense with Hot Standby. Perhaps we should redefine smart shutdown in standby mode to shut down as soon as all read-only connections have died. Okay. Let's work out the details. I guess that the startup process and the walreceiver should wait for all read only backends to exit in smart shutdown case. It's because those backends might be waiting for the record that conflicts with their queries to be replayed. Is this OK? Or we should kill the startup process and the walreceiver on ahead? If my guess is right, we would need to add new PMState to cancel recovery and replication after all read only connections have died. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Add on_perl_init and proper destruction to plperl UPDATE v3 [PATCH]
This is an updated version of the third of the patches to be
split out from the former 'plperl feature patch 1'.
It includes changes following discussions with Tom Lane and others.
Changes in this patch:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available when the code is run.
- Added interpreter destruction behaviour
Hooked via on_proc_exit().
Only has any effect for normal shutdown.
END blocks, if any, are run.
SPI functions will die if called at this time.
This updated version no longer tries to call object destructors.
I've added a note in the Limitations section of the PL/Perl docs.
It also adds a PERL_SET_CONTEXT() that's needed but was missing.
Tim.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 5fa7e3a..c4d5d8e 100644
*** a/doc/src/sgml/plperl.sgml
--- b/doc/src/sgml/plperl.sgml
*** CREATE TRIGGER test_valid_id_trig
*** 1028,1034
/para
/sect1
! sect1 id=plperl-missing
titleLimitations and Missing Features/title
para
--- 1028,1098
/para
/sect1
! sect1 id=plperl-under-the-hood
! titlePL/Perl Under the Hood/title
!
! sect2 id=plperl-config
! titleConfiguration/title
!
! para
! This section lists configuration parameters that affect applicationPL/Perl/.
! To set any of these parameters before applicationPL/Perl/ has been loaded,
! it is necessary to have added quoteliteralplperl// to the
! xref linkend=guc-custom-variable-classes list in
! filenamepostgresql.conf/filename.
! /para
!
! variablelist
!
! varlistentry id=guc-plperl-on-perl-init xreflabel=plperl.on_perl_init
! termvarnameplperl.on_perl_init/varname (typestring/type)/term
! indexterm
!primaryvarnameplperl.on_perl_init/ configuration parameter/primary
! /indexterm
! listitem
!para
!Specifies perl code to be executed when a perl interpreter is first initialized.
!The SPI functions are not available when this code is executed.
!If the code fails with an error it will abort the initialization of the interpreter
!and propagate out to the calling query, causing the current transaction
!or subtransaction to be aborted.
!/para
!para
! The perl code is limited to a single string. Longer code can be placed
! into a module and loaded by the literalon_perl_init/ string.
! Examples:
! programlisting
! plplerl.on_perl_init = '$ENV{NYTPROF}=start=no; require Devel::NYTProf::PgPLPerl'
! plplerl.on_perl_init = 'use lib /my/app; use MyApp::PgInit;'
! /programlisting
!/para
!para
!Initialization will happen in the postmaster if the plperl library is included
!in literalshared_preload_libraries/ (see xref linkend=shared_preload_libraries),
!in which case extra consideration should be given to the risk of destabilizing the postmaster.
!/para
!para
!This parameter can only be set in the postgresql.conf file or on the server command line.
!/para
! /listitem
! /varlistentry
!
! varlistentry id=guc-plperl-use-strict xreflabel=plperl.use_strict
! termvarnameplperl.use_strict/varname (typeboolean/type)/term
! indexterm
!primaryvarnameplperl.use_strict/ configuration parameter/primary
! /indexterm
! listitem
!para
!When set true subsequent compilations of PL/Perl functions have the literalstrict/ pragma enabled.
!This parameter does not affect functions already compiled in the current session.
!/para
! /listitem
! /varlistentry
!
! /variablelist
!
! sect2 id=plperl-missing
titleLimitations and Missing Features/title
para
*** CREATE TRIGGER test_valid_id_trig
*** 1063,1072
--- 1127,1146
literalreturn_next/literal for each row returned, as shown
previously.
/para
+ /listitem
+ listitem
+ para
+ When a session ends normally, not due to a fatal error, any
+ literalEND/ blocks that have been defined are executed.
+ Currently no other actions are performed. Specifically, file handles are
+ not flushed and objects are not destroyed.
+ /para
/listitem
/itemizedlist
/para
+ /sect2
+
/sect1
/chapter
diff --git a/src/pl/plperl/plc_perlboot.pl b/src/pl/plperl/plc_perlboot.pl
index 24e2487..5d2e962 100644
*** a/src/pl/plperl/plc_perlboot.pl
--- b/src/pl/plperl/plc_perlboot.pl
***
*** 2,8
# $PostgreSQL$
PostgreSQL::InServer::Util::bootstrap();
- PostgreSQL::InServer::SPI::bootstrap();
use strict;
use warnings;
--- 2,7
diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index 9277072..8b1d697 100644
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
***
*** 27,32
--- 27,33
#include miscadmin.h
#include nodes/makefuncs.h
#include parser/parse_type.h
+
[HACKERS] [CFReview] Red-Black Tree
Hi Robert, I've also spent some time reviewing this patch since it is a pre-requisite to the KNNGiST patch. I did have a much more comprehensive list of suggestions, but it seems you've managed to resolve most of these with your latest re-write. Please find some more comments inline: Here's an edited version, which I've now reviewed more fully. Some more substantive review comments: Firstly: the re-worked patch that you have posted seems to contain remnants of at least 2 other patches. I have extracted the rbtree-only sections and re-attached to this email. The patch was tested against git head 124a3cc... and applied without any fuzz or other issues. 1. I'm pretty satisfied that the rbtree code is generally sane, although I wonder if we should think about putting it in access/common rather than utils/misc. I'm not sure that I have a sufficiently clearly defined notion of what each subdirectory is for to draw a definitive conclusion on this point; hopefully someone else will weigh in. I'm happy that the code is a reasonable implementation of an RB-Tree, at least with respect to the link to the related public domain source that was posted. In terms of location, I think utils/misc is a reasonable place for it to live since I see it as analogous to the hash table implementation, i.e. it's a template RB-Tree implementation designed to be used as required throughout the codebase. backend/access seems to be the home of index AMs only. Other code points: - The new names for the iterator enum seem much better to me - or at least it helped understand the meaning of the iterator code. - You correctly picked up on the namespace issue, although I noticed that you left RED and BLACK as they were. Maybe RBRED and RBBLACK would be better, though not that there are any colour related defines around in a database backend to make a name clash probable. - I found the name of the appendator method misleading - perhaps updater would make more sense? 2. I'm a little concerned about the performance implications of this patch. Looking at http://www.sai.msu.su/~megera/wiki/2009-04-03, it's clear that the patch is a huge win in some cases. But I'm also surprised by how much performance is lost in some of the other cases that you tested. I suspect, on balance, that it's probably still a good idea to put this in, but I wonder if you've profiled this at all to see where the extra time is going and/or explored possible ways of squashing that overhead down a little more. 3. In ginInsertEntry(), the else branch of the if statement really looks like magic when you first read it. I wonder if it would make sense to pull the contents of EAAllocate() directly into this function, since there's only one call site anyhow. God yes. This is not a good example of maintainable code - even with your comment I struggled for a while to try and figure it out :( I would suggest that this is refactored appropriately before commit. I still have not done any performance testing of my own on this code, and it probably needs that. If anyone else has time to step up and help with that, it would be much appreciated. It would be useful to have some plain old benchmarks as well as some profiling data as mentioned above. As part of my testing, I attempted to duplicate some of the benchmarks at http://www.sai.msu.su/~megera/wiki/2009-04-03. Unfortunately I was not really able to reproduce the RND (teodor's) dataset, nor the random array test as the SQL used to test the implementation was not present on the page above. For each test, I dropped and recreated the database to ensure that any autovacuum impact would be the same. 1) Fixed length random sequential string arrays SELECT array_to_string(ARRAY(select '' || a || '.' || b from generate_series(1,50) b), ' ')::tsvector AS i INTO seq FROM generate_series(1,10) a; SELECT array_to_string(ARRAY(select '' || random() from generate_series(1,50) b), ' ')::tsvector AS i INTO rnd FROM generate_series(1,10) a; Before patch: test=# create index seq_idx on seq using gin (i); CREATE INDEX Time: 103205.790 ms test=# create index rnd_idx on rnd using gin (i); CREATE INDEX Time: 6770.131 ms After patch: test=# create index seq_idx on seq using gin (i); CREATE INDEX Time: 87724.953 ms test=# create index rnd_idx on rnd using gin (i); CREATE INDEX Time: 5596.666 ms 2) Identical records, variable length test select ARRAY(select generate_series(1,len)) as a50 into arr50 from generate_series(1,10) b; Before patch: i) len=3 select ARRAY(select generate_series(1,3)) as a3 into arr3 from generate_series(1,10) b; test=# create index arr3_idx on arr3 using gin (a3); CREATE INDEX Time: 324.251 ms ii) len=30 select ARRAY(select generate_series(1,30)) as a30 into arr30 from generate_series(1,10) b; test=# create index arr30_idx on arr30 using gin (a30); CREATE INDEX Time: 2163.786 ms iii) len=50 select ARRAY(select generate_series(1,50)) as
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 11:33 +0200, Heikki Linnakangas wrote: I even *fixed* that already, but you decided to take it out before committing. I then added it to the list of must-fix items in the TODO list, but you took that out too. I have no objection to doing things in smaller steps, but this *is* a must-fix item before release. I still don't understand why you took it out, nor why you're objecting to that. This is a misrepresentation of what has happened. The item you mention was added to the TODO by me in response to your comments and has never been removed at any point; it is still there now. You added a duplicate and the duplicate was removed. I removed code that you mentioned was buggy because I don't have time to fix it and it is not high enough up the priority list. We have discussed all of these things before yet you raise them again as if those things have never been said. I am working on TODO in a priority order. The priority list has changed over time in response to comments received from both you and other people. I understand you don't like my current sequence of actions and I'm sorry for that. I am trying to be rational and balance what has been said to me for the benefit of the community from all stakeholders and have consulted widely to gather thoughts. I am more than happy for other people to work on items on the list, as Joachim and Andres have done. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] helpers to convert C types to postgres types (Array)
On Fri, Jan 29, 2010 at 7:34 AM, Ivan Sergio Borgonovo m...@webthatworks.it wrote: I'm still trying to collect all the bits to be able to read and return several types of data in C functions. I'm looking for quick ways to deal with ArrayType. I'd expect some helper because these kind of operation should be frequent and without any helper (function/macro) they really make the code awful. Generally you work with C types that later you've to convert to Postgres types. So for example you may have an array of int2 that then you've to place into an ArrayType. I think there are 3 kinds of operation you may have to do: 1 You may have an already formed C array type and you'd just copy it into an ArrayType 2 You may know the # of elements of the C array type but you're filling it an element at a time 3 You don't know the number of elements in the array in advance so you'd like to append to the ArrayType one element at a time 1 seems to require - creating an array of Datum - looping over the C array - assign to each Datum element the converted C value - construct_array the Postgres array That's a pain. Any other way? macro? 2 Seems the easiest 3 ??? Is there any function in postgres that let you append elements to an ArrayType? well, you have the entire backend array api available. you can always call array_cat or array_push depending on how you want to do it. if you are worried about performance though the fastest way is going to be to collect your element datums in a vector and calling construct_array however. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
Simon Riggs wrote: I removed code that you mentioned was buggy because I don't have time to fix it and it is not high enough up the priority list. We have discussed all of these things before yet you raise them again as if those things have never been said. *sigh*. Yeah, we've been through this. As I've said before, I never said the code was buggy, that was just a misunderstanding at your end. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
The fundamental disagreement here is over what qualifies as a wishlist item, aka a feature or added functionality. And what qualifies as a must-fix bug. Priorities are context sensitive. If this were early in the cycle then working on bigger impact features like conflict resolution code might be more important because it's important to get them into the code base where other people can see if it solves their problems and the behaviour can be tweaked. Fixing rare but outright broken things might not be high priority because while they have to be done by release nobody is blocking on on the solution before then. On the other hand near release we stop trying to incorporate new features and focus on basic bug features. The new features don't become any less important to the users, it's just that they'll make it into the next release. There will always be more features that can help users and we'll always think of cool new things to knock off the rough edges off what we have now and get it out so we can go back to the playground for the next release. You said I think we should extend the time available to make sure we have a sensible set of features for 9.0. Perhaps part of the problem is that I couldn't understand what your patch did from the description you posted and can't evaluate whether it's fixing a problem that makes the current feature set incoherent. Can you explain what it does in more detail so we can understand why it's necessary for a sensible set of features? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 16:44 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: I removed code that you mentioned was buggy because I don't have time to fix it and it is not high enough up the priority list. We have discussed all of these things before yet you raise them again as if those things have never been said. *sigh*. Yeah, we've been through this. As I've said before, I never said the code was buggy, that was just a misunderstanding at your end. OK, if you say I misunderstood, then I accept that. The deed is done and the code removed. Putting it back takes time and given enough of that rare cloth, it will eventually be put back. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Pathological regexp match
Magnus Hagander wrote: 2010/1/29 Alvaro Herrera alvhe...@commandprompt.com: (There's a badly needed CHECK_FOR_INTERRUPTS in this code BTW) Incidentally, I ran across the exact same issue with a non-greedy regexp with a client earlier this week, and put on my TODO to figure out a good place to stick a check for interrupts. Does this mean I don't have to, because you're on it? ;) No, sorry :-( -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)
Jonah H. Harris escribió: The syntax is listagg(expression [, delimiter]) WITHIN GROUP (order by clause) [OVER partition clause] If a delimiter is defined, it must be a constant. Query: SELECT listagg(a, ',') WITHIN GROUP (ORDER BY a) FROM foo; Result: aaa,bbb,ccc So that's how Oracle supports ordered aggregates? Interesting -- we just got that capability but using a different syntax. Hmm, the SQL:200x draft also has within group specification which seems the standard way to do the ORDER BY stuff for aggregates ... Should we change the syntax? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)
2010/1/29 Alvaro Herrera alvhe...@commandprompt.com: Jonah H. Harris escribió: The syntax is listagg(expression [, delimiter]) WITHIN GROUP (order by clause) [OVER partition clause] If a delimiter is defined, it must be a constant. Query: SELECT listagg(a, ',') WITHIN GROUP (ORDER BY a) FROM foo; Result: aaa,bbb,ccc So that's how Oracle supports ordered aggregates? Interesting -- we just got that capability but using a different syntax. Hmm, the SQL:200x draft also has within group specification which seems the standard way to do the ORDER BY stuff for aggregates ... Should we change the syntax? Oracle syntax is little bit longer, but it is safer. What is a standard? Regards Pavel Stehule p.s. if it is only syntactic suger, then can't be a problem. Pavel -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 64-bit size pgbench
Greg Smith g...@2ndquadrant.com writes: Was looking for general feedback on whether the way I've converted this to use 64 bit integers for the account numbers seems appropriate, and to see if there's any objection to fixing this in general given the potential downsides. In the past we've rejected proposed patches for pgbench on the grounds that they would make results non-comparable to previous results. So the key question here is how much this affects the speed. Please be sure to test that on a 32-bit machine, not a 64-bit one. ! retval = (int64) strtol(res, endptr, 19); That bit is merely wishful thinking :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] quoting psql varible as identifier
On Fri, Jan 29, 2010 at 2:08 AM, Pavel Stehule pavel.steh...@gmail.com wrote: First, you can't just remove support for the escape syntax from \d commands without some discussion of whether or not that's the right thing to do, and I don't think it is. The cases where this will potentially cause a problem are limited to those where the input is invalidly encoded, and I don't think that's important enough to justify the surprise factor of having backslash commands behave differently from everything else. Second, even if it were OK to remove support for the escape syntax from \d commands, you failed to update the documentation you cribbed from my patch to match the behavior you implemented. we can discus about programming style, but in this case I am sure. The problem is \set command. We cannot ignore error in this case. In other cases invalid escaping raises error, not in this case. So there is two ways again: a) remove escaped expansion from \command b) implement \set command differently I don't view either of those solutions as appropriate or acceptable. I am also thinking that it doesn't make sense to push the result of PQescapeLiteral() or PQescapeIdentifier() as a new buffer, because we don't want to process variable expansions recursively. At first I thought this was a security hole, but on further reflection I don't think it is: it'll rescan as a quoted string anyway, so any colon-escapes will be ignored. But I believe it's unnecessary at any rate. I think so it was a back door for scripting support in psql. It can break backward compatibility! I don't understand your point here. I would like to go ahead and commit my version of this patch and will do so later today if no one else objects. yes, I have. * your patch remove some feature without any warning and documentation * your patch doesn't solve issue with \set command It does not remove any feature at all that I can see. The fact that backslash commands don't properly report errors is a problem, but I don't see why I have to solve that problem as part of this patch, and even less why I should fix \set and leave all the others alone. Another problem I've found looking at this code is that \copy does not support variable substitutions at all, which seems rather unfortunate. Still another is that the regular expression used for variable substitutions in SQL commands is subtly different than the one used for backslash commands: the latter matches a single colon with no following characters, while the former does not. All of this stuff may be worth fixing but I'm sticking with my position that it's not material for this patch. If you want to submit a separate patch to change the error handling, go ahead. But I don't think fixing it for \set only is going to fly, and I don't think that it should be specific to handling only errors resulting from encoding violations or out of memory conditions in variable substitutions. It needs to be a general mechanism that can be applied to existing types of error conditions where it's appropriate and to new error conditions that may arise in the future. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 64-bit size pgbench
On Fri, Jan 29, 2010 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote: Greg Smith g...@2ndquadrant.com writes: Was looking for general feedback on whether the way I've converted this to use 64 bit integers for the account numbers seems appropriate, and to see if there's any objection to fixing this in general given the potential downsides. In the past we've rejected proposed patches for pgbench on the grounds that they would make results non-comparable to previous results. Perhaps we need an option indicating whether or not the use of bigint columns is OK. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] out-of-scope cursor errors
On Fri, Jan 29, 2010 at 06:32:20AM +0100, Boszormenyi Zoltan wrote: I know. Patches were already posted for that, waiting for Michael to review and apply it. Just came back from another trip. Patch works on my system, so I committed it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 12:56 +, Simon Riggs wrote: I think we should extend the time available to make sure we have a sensible set of features for 9.0. The heat of this discussion tells me that we are going to be lacking features that are must-have to someone, whether or not they are in the majority. -1 Missing release dates because of some patch that isn't done is something the community has been trying to get away from, aggressively. The way this is supposed to work is: We have a release date Features that aren't going to make that date, don't. We release Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Strange heuristic in analyze.c
So I never realized the consequences of this little heuristic in
analyze.c in the handling of very low cardinality columns where we
want to just capture the complete list of values in the mcv and throw
away the histogram:
else if (toowide_cnt == 0 nmultiple == ndistinct)
{
/*
* Every value in the sample appeared more than once.
Assume the
* column has just these values.
*/
stats-stadistinct = ndistinct;
}
The problem with this heuristic is that if the table is small enough
you might expect you can set the statistics target high and sample
the entire table and get a very accurate mcv covering all the values.
However if any of the values in the table appears only once this
heuristic will defeat you. The following code will then throw out of
the mcv any value which isn't 25% more common than average. Leaving
you with a histogram for those values which often does very poorly if
the values don't fit any pattern and are just discrete arbitrary
values.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 14:52 +, Greg Stark wrote: You said I think we should extend the time available to make sure we have a sensible set of features for 9.0. Perhaps part of the problem is that I couldn't understand what your patch did from the description you posted and can't evaluate whether it's fixing a problem that makes the current feature set incoherent. Can you explain what it does in more detail so we can understand why it's necessary for a sensible set of features? I'll break down the patch into two pieces to make it easier to review, and add more description, as you suggest. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
NaN/Inf fix for ECPG Re: [HACKERS] out-of-scope cursor errors
Michael Meskes írta: On Fri, Jan 29, 2010 at 06:32:20AM +0100, Boszormenyi Zoltan wrote: I know. Patches were already posted for that, waiting for Michael to review and apply it. Just came back from another trip. Patch works on my system, so I committed it. Michael Thanks. Hopefully that will make the buildfarm green from this problem. As you might have noticed, the fix you just committed deleted the test for NaN in the outofscope.pgc regression test, which I tried to fix separately. The buildfarm revealed a problem with NaN/Inf handling, like: - Windows (and mybe others) don't accept NaN in strtod() - different UNIX(-like) platforms write out different strings in printf() for a double variable storing. NaN. E.g.: Linux: nan, Solaris: NaN, AIX: NaNQ Can you also review the NaN/Infinity patch, too? This fix uses the same methods as the backend, i.e. looking for special strings and attempt to handle them in a portable way. There is one possible problem regarding NaNs and risnull()/rsetnull(): I had to introduce a new symbol (NUMERIC_NULL) for handling NULL inline in the numeric value itself. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)
Alvaro Herrera alvhe...@commandprompt.com writes: So that's how Oracle supports ordered aggregates? Interesting -- we just got that capability but using a different syntax. Hmm, the SQL:200x draft also has within group specification which seems the standard way to do the ORDER BY stuff for aggregates ... Should we change the syntax? No. The syntax we are using is also standard. As best I can tell, WITHIN GROUP means something different --- the spec only defines it for rank functions (RANK | DENSE_RANK | PERCENT_RANK | CUME_DIST) and it's basically a shorthand form of a window function call. I find it doubtful that it's actually necessary in Oracle's version of listagg ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
Simon Riggs wrote: On Fri, 2010-01-29 at 11:20 +0100, Stefan Kaltenbrunner wrote: Simon Riggs wrote: On Fri, 2010-01-29 at 11:10 +0100, Stefan Kaltenbrunner wrote: yeah and we keep finding major bugs nearly daily Facts, please? 5 seconds of time spent on archives.postgresql.org show at least the following SR/HS related bugs in the last 7 days or so: http://archives.postgresql.org/pgsql-committers/2010-01/msg00400.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00410.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00396.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00323.php some of those you might call minor but they are bugs and given the current rate we are seeing them is imho a clear sign of code by far not stable enough to consider new features that late in the cycle I don't think two very minor bugs in Hot Standby, reported and fixed 7 days apart is any indication of instability. It isn't the daily bugs reported you suggested. Personally, I think it indicates quite the opposite - if those are the only bugs I can find now, I'm ecstatic. well we have not even made a realistic release (not even an alpha!) with the current HS/SR code, we still have must fix issues on the table(for both SR and HS) AND we find/fix more than a bug every two days in those two features that are the cause for moving to 9.0. If we want to release in anya realistic timeframe (and I recall you advocating for doing that in the past) we really need to wrap up what we have now, make it robust and see what we have left for all the further releases. I think your argument does apply to Streaming Rep, at this point. We should consider releasing Alpha4 and then later going to Beta. so you basically say that the current codebase(as a whole) is in need of stabilisation and we need to make the cut off and release alpha4 now? Not sure how that fits into proposing new features for other parts of the system... My point of view expressed here is not built in a few seconds, it is built on discussion and feedback over 18 months. The conflict issue was discussed by me with hackers at the May 2008 dev meeting. It should be improved upon in this release and it has been the main issue concerning the full range of people I have discussed HS with. in this release refers to the current patch I guess - because there was no HS in older versions of pg :) Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)
On Fri, Jan 29, 2010 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: I find it doubtful that it's actually necessary in Oracle's version of listagg ... Eh? http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/functions087.htm Defines: *LISTAGG* (measure_expr [, 'delimiter_expr']) *WITHIN GROUP* (order_by_clause) [*OVER* query_partition_clause] -- Jonah H. Harris
Re: [HACKERS] ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)
On Fri, Jan 29, 2010 at 12:09 PM, Jonah H. Harris jonah.har...@gmail.comwrote: On Fri, Jan 29, 2010 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: I find it doubtful that it's actually necessary in Oracle's version of listagg ... Eh? http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/functions087.htm Defines: *LISTAGG* (measure_expr [, 'delimiter_expr']) *WITHIN GROUP* (order_by_clause) [*OVER* query_partition_clause] SQL Server's listagg is similar to the PG implementation. It seems Oracle thinks people would prefer to order the list and for that reason, made their listagg a rank function type. Having done quite a bit of work generating delimited lists/arrays based on ordering in PG, I generally agree that it's what I would generally want. -- Jonah H. Harris
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, Jan 29, 2010 at 11:32 AM, Joshua D. Drake j...@commandprompt.com wrote: On Fri, 2010-01-29 at 12:56 +, Simon Riggs wrote: I think we should extend the time available to make sure we have a sensible set of features for 9.0. The heat of this discussion tells me that we are going to be lacking features that are must-have to someone, whether or not they are in the majority. -1 Missing release dates because of some patch that isn't done is something the community has been trying to get away from, aggressively. The way this is supposed to work is: We have a release date Features that aren't going to make that date, don't. We release Exactly. It would be nice to see 9.0 come out in 2010, and we're not going to get there unless we start fixing the issues that are actually release-blockers, rather than adding new features. Hot Standby was committed with at least one known release blocker (VACUUM FULL) on the assumption that that release blocker would be fixed by the committer who introduced it (isn't that the rule?). Two months on, there is zero sign of any activity on that front, and instead we're now being bombarded with a series of other patches that fix issues that are not release-blockers under the theory that the feature isn't good enough to be used without them. If that's really true, it wasn't ready for commit in the first place. If this were any other patch, I'd propose reverting it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 12:23 -0500, Robert Haas wrote: Exactly. It would be nice to see 9.0 come out in 2010, and we're not going to get there unless we start fixing the issues that are actually release-blockers, rather than adding new features. Hot Standby was committed with at least one known release blocker (VACUUM FULL) on the assumption that that release blocker would be fixed by the committer who introduced it (isn't that the rule?). Two months on, there is zero sign of any activity on that front, and instead we're now being bombarded with a series of other patches that fix issues that are not release-blockers under the theory that the feature isn't good enough to be used without them. If that's really true, it wasn't ready for commit in the first place. If this were any other patch, I'd propose reverting it. I would suggest that if we don't see activity on the release blockers, pretty much stat... we revert it. Joshua D. Drake ...Robert -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ordered aggregates using WITHIN GROUP (was Re: can somebody execute this query on Oracle 11.2g and send result?)
Jonah H. Harris jonah.har...@gmail.com writes: http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/functions087.htm Defines: *LISTAGG* (measure_expr [, 'delimiter_expr']) *WITHIN GROUP* (order_by_clause) [*OVER* query_partition_clause] Hmph. I don't know what would possess them to model their function on the rank-function syntax extension rather than ARRAY_AGG. The latter seems a lot closer to the functionality that's actually needed. I'm still trying to wrap my brain around what the spec says about the rank-function syntax, but it's notable that the order-by clause is tightly tied to the aggregate input value(s) --- the sort expressions have to have the same number and types as the inputs. Which is certainly not very sensible for listagg. Can anyone figure out exactly what SQL:2008 10.9 rule 6 is actually saying? The references to VE1..VEk in the scalar subquery seem to me to be semantically invalid. They would be sensible if this were a window function, but it's an aggregate, so I don't understand what row they'd be evaluated with respect to. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 12:23 -0500, Robert Haas wrote: Two months on, there is zero sign of any activity on that front I'm surprised that you call 14 commits in 28 days following a publicly available priority list: zero sign of activity. Further discussion seems pointless. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, Jan 29, 2010 at 1:08 PM, Simon Riggs si...@2ndquadrant.com wrote: On Fri, 2010-01-29 at 12:23 -0500, Robert Haas wrote: Two months on, there is zero sign of any activity on that front I'm surprised that you call 14 commits in 28 days following a publicly available priority list: zero sign of activity. Further discussion seems pointless. Wow, that was an awesome way to quote what I said out of context and make it sound like I said something ridiculous. The problem I and others have is not with the quantity of your commits but with the issues you are choosing (not) to address. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 18:08 +, Simon Riggs wrote: On Fri, 2010-01-29 at 12:23 -0500, Robert Haas wrote: Two months on, there is zero sign of any activity on that front I'm surprised that you call 14 commits in 28 days following a publicly available priority list: zero sign of activity. Further discussion seems pointless. Let's be clear. Robert is discussing release blockers. He is not suggesting that no work has been done. I believe the community considers release-blocks the priority. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
2010/1/28 KaiGai Kohei kai...@ak.jp.nec.com: (2010/01/29 9:58), KaiGai Kohei wrote: (2010/01/29 9:29), Robert Haas wrote: 2010/1/28 KaiGai Koheikai...@ak.jp.nec.com: (2010/01/29 0:46), Robert Haas wrote: 2010/1/27 KaiGai Koheikai...@ak.jp.nec.com: Hmm, indeed, this logic (V3/V5) is busted. The idea of V4 patch can also handle this case correctly, although it is lesser in performance. I wonder whether it is really unacceptable cost in performance, or not. Basically, I assume ALTER TABLE RENAME/TYPE is not frequent operations, and I don't think this bugfix will damage to the reputation of PostgreSQL. Where should we go on the next? Isn't the problem here just that the following comment is 100% wrong? /* * Unlike find_all_inheritors(), we need to walk on child relations * that have diamond inheritance tree, because this function has to * return correct expected inhecount to the caller. */ It seems to me that the right solution here is to just add one more argument to find_all_inheritors(), something like List **expected_inh_count. Am I missing something? The find_all_inheritors() does not walk on child relations more than two times, even if a child has multiple parents inherited from common origin, because list_concat_unique_oid() ignores the given OID if it is already on the list. It means all the child relations under the relation already walked on does not checked anywhere. (Of course, this assumption is correct for the purpose of find_all_inheritors() with minimum cost.) What we want to do here is to compute the number of times a certain child relation is inherited from a common origin; it shall be the expected-inhcount. So, we need an arrangement to the logic. For example, see the following diagram. T2 / \ T1 T4---T5 \ / T3 If we call find_all_inheritors() with T1. The find_inheritance_children() returns T2 and T3 for T1. Then, it calls find_inheritance_children() for T2, and it returns T4. Then, it calls find_inheritance_children() for T3, and it returns T4, but it is already in the rels_list, so list_concat_unique_oid() ignores it. Then, it calls find_inheritance_children() for T4, and it returns T5. In this example, we want the expected inhcount for T2 and T3 should be 1, for T4 and T5 should be 2. However, it walks on T4 and T5 only once, so they will have 1 incorrectly. Even if we count up the ignored OID (T4), find_all_inheritors() does not walk on T5, because it is already walked on obviously when T4 is ignored. I think the count for T5 should be 1, and I think that the count for T4 can easily be made to be 2 by coding the algorithm correctly. Ahh, it is right. I was confused. Is it possible to introduce the logic mathematical-strictly? Now I'm considering whether the find_all_inheritors() logic is suitable for any cases, or not. I modified the logic to compute an expected inhcount of the child relations. What we want to compute here is to compute the number of times a certain relation being inherited directly from any relations delivered from a unique origin. If the column to be renamed is eventually inherited from a common origin, its attinhcount is not larger than the expected inhcount. WITH RECURSIVE r AS ( SELECT 't1'::regclass AS inhrelid UNION ALL SELECT c.inhrelid FROM pg_inherits c, r WHERE r.inhrelid = c.inhparent ) -- r is all the child relations inherited from 't1' SELECT inhrelid::regclass, count(*) FROM pg_inherits WHERE inhparent IN (SELECT inhrelid FROM r) GROUP BY inhrelid; The modified logic increments the expected inhcount of the relation already walked on. If we found a child relation twice or more, it means the child relation is at the junction of the inheritance tree. In this case, we don't walk on the child relations any more, but it is not necessary, because the first path already checked it. The find_all_inheritors() is called from several points more than renameatt(), so I added find_all_inheritors_with_inhcount() which takes argument of the expected inhcount list. And, find_all_inheritors() was also modified to call find_all_inheritors_with_inhcount() with NULL argument to avoid code duplication. It is the result of Berrnd's test case. - CVS HEAD 0.895s 0.903s 0.884s 0.896s 0.892s - with V6 patch 0.972s 0.941s 0.961s 0.949s 0.946s Well, that seems a lot better. Unfortunately, I can't commit this code: it's mind-bogglingly ugly. I don't believe that duplicating find_all_inheritors is the right solution (a point I've mentioned previously), and it's certainly not right to use typeName-location as a place to store an unrelated attribute inheritance count. There is also at least one superfluous variable renaming; and the recursion handling looks pretty grotty to me, too. I wonder if we should just
Re: [HACKERS] Review: listagg aggregate
On Fri, Jan 29, 2010 at 2:43 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2010/1/28 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: with get_fn_expr_arg_stable() we are able to fix second parameter without some performance issues. No, that will create its own performance issues --- get_fn_expr_arg_stable isn't especially cheap. If there were a really strong reason why we had to do it, then I'd agree, but frankly the argument for disallowing a variable delimiter is too thin. it could be called only once. But I agree, so could be better, check it in parser time. ok - I am only one who like original behave - so I am withdrawing. Robert, If you like, please commit Itagaki's patch. + add note about behave when second parameter isn't stable. I haven't even looked at this code - I sort of assumed Itagaki was handling this one. But it might be good to make sure that the docs have been read through by a native English speaker prior to commit... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: listagg aggregate
On Jan 29, 2010, at 10:43 AM, Robert Haas wrote: I haven't even looked at this code - I sort of assumed Itagaki was handling this one. But it might be good to make sure that the docs have been read through by a native English speaker prior to commit... I did and revised them slightly. There isn't much, just a brief comment in the table of aggregate functions. The documentation for all the functions on that page could use a little love, frankly. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: listagg aggregate
On Fri, Jan 29, 2010 at 1:45 PM, David E. Wheeler da...@kineticode.com wrote: On Jan 29, 2010, at 10:43 AM, Robert Haas wrote: I haven't even looked at this code - I sort of assumed Itagaki was handling this one. But it might be good to make sure that the docs have been read through by a native English speaker prior to commit... I did and revised them slightly. There isn't much, just a brief comment in the table of aggregate functions. The documentation for all the functions on that page could use a little love, frankly. Want to take a short at it? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: listagg aggregate
On Jan 29, 2010, at 10:46 AM, Robert Haas wrote: I did and revised them slightly. There isn't much, just a brief comment in the table of aggregate functions. The documentation for all the functions on that page could use a little love, frankly. Want to take a short at it? ENOTUITS! /me is already sorely over-committed… David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [CFReview] Red-Black Treey
Mark, do you need my data to reproduce results from http://www.sai.msu.su/~megera/wiki/2009-07-27 ? Oleg On Fri, 29 Jan 2010, Mark Cave-Ayland wrote: Hi Robert, I've also spent some time reviewing this patch since it is a pre-requisite to the KNNGiST patch. I did have a much more comprehensive list of suggestions, but it seems you've managed to resolve most of these with your latest re-write. Please find some more comments inline: Here's an edited version, which I've now reviewed more fully. Some more substantive review comments: Firstly: the re-worked patch that you have posted seems to contain remnants of at least 2 other patches. I have extracted the rbtree-only sections and re-attached to this email. The patch was tested against git head 124a3cc... and applied without any fuzz or other issues. 1. I'm pretty satisfied that the rbtree code is generally sane, although I wonder if we should think about putting it in access/common rather than utils/misc. I'm not sure that I have a sufficiently clearly defined notion of what each subdirectory is for to draw a definitive conclusion on this point; hopefully someone else will weigh in. I'm happy that the code is a reasonable implementation of an RB-Tree, at least with respect to the link to the related public domain source that was posted. In terms of location, I think utils/misc is a reasonable place for it to live since I see it as analogous to the hash table implementation, i.e. it's a template RB-Tree implementation designed to be used as required throughout the codebase. backend/access seems to be the home of index AMs only. Other code points: - The new names for the iterator enum seem much better to me - or at least it helped understand the meaning of the iterator code. - You correctly picked up on the namespace issue, although I noticed that you left RED and BLACK as they were. Maybe RBRED and RBBLACK would be better, though not that there are any colour related defines around in a database backend to make a name clash probable. - I found the name of the appendator method misleading - perhaps updater would make more sense? 2. I'm a little concerned about the performance implications of this patch. Looking at http://www.sai.msu.su/~megera/wiki/2009-04-03, it's clear that the patch is a huge win in some cases. But I'm also surprised by how much performance is lost in some of the other cases that you tested. I suspect, on balance, that it's probably still a good idea to put this in, but I wonder if you've profiled this at all to see where the extra time is going and/or explored possible ways of squashing that overhead down a little more. 3. In ginInsertEntry(), the else branch of the if statement really looks like magic when you first read it. I wonder if it would make sense to pull the contents of EAAllocate() directly into this function, since there's only one call site anyhow. God yes. This is not a good example of maintainable code - even with your comment I struggled for a while to try and figure it out :( I would suggest that this is refactored appropriately before commit. I still have not done any performance testing of my own on this code, and it probably needs that. If anyone else has time to step up and help with that, it would be much appreciated. It would be useful to have some plain old benchmarks as well as some profiling data as mentioned above. As part of my testing, I attempted to duplicate some of the benchmarks at http://www.sai.msu.su/~megera/wiki/2009-04-03. Unfortunately I was not really able to reproduce the RND (teodor's) dataset, nor the random array test as the SQL used to test the implementation was not present on the page above. For each test, I dropped and recreated the database to ensure that any autovacuum impact would be the same. 1) Fixed length random sequential string arrays SELECT array_to_string(ARRAY(select '' || a || '.' || b from generate_series(1,50) b), ' ')::tsvector AS i INTO seq FROM generate_series(1,10) a; SELECT array_to_string(ARRAY(select '' || random() from generate_series(1,50) b), ' ')::tsvector AS i INTO rnd FROM generate_series(1,10) a; Before patch: test=# create index seq_idx on seq using gin (i); CREATE INDEX Time: 103205.790 ms test=# create index rnd_idx on rnd using gin (i); CREATE INDEX Time: 6770.131 ms After patch: test=# create index seq_idx on seq using gin (i); CREATE INDEX Time: 87724.953 ms test=# create index rnd_idx on rnd using gin (i); CREATE INDEX Time: 5596.666 ms 2) Identical records, variable length test select ARRAY(select generate_series(1,len)) as a50 into arr50 from generate_series(1,10) b; Before patch: i) len=3 select ARRAY(select generate_series(1,3)) as a3 into arr3 from generate_series(1,10) b; test=# create index arr3_idx on arr3 using gin (a3); CREATE INDEX Time: 324.251 ms ii) len=30 select ARRAY(select generate_series(1,30)) as a30 into arr30 from generate_series(1,10) b;
[HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
On Tue, Jan 19, 2010 at 3:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: That function *seriously* needs documentation, in particular the fact that it's a no-op on machines without the right kernel call. The name you've chosen is very bad for those semantics. I'd pick something else myself. Maybe pg_start_data_flush or something like that? I would like to make one token argument in favour of the name I picked. If it doesn't convince I'll change it since we can always revisit the API down the road. I envision having two function calls, pg_fsync_start() and pg_fsync_finish(). The latter will wait until the data synced in the first call is actually synced. The fall-back if there's no implementation of this would be for fsync_start() to be a noop (or something unreliable like posix_fadvise) and fsync_finish() to just be a regular fsync. I think we can accomplish this with sync_file_range() but I need to read up on how it actually works a bit more. In this case it doesn't make a difference since when we call fsync_finish() it's going to be for the entire file and nothing else will have been writing to these files. But for wal writing and checkpointing it might have very different performance characteristics. The big objection to this is that then we don't really have an api for FADV_DONT_NEED which is more about cache policy than about syncing to disk. So for example a sequential scan might want to indicate that it isn't planning on reading the buffers it's churning through but doesn't want to force them to be written sooner than otherwise and is never going to call fsync_finish(). -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [CFReview] Red-Black Tree
On Fri, Jan 29, 2010 at 9:00 AM, Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk wrote: I'm happy that the code is a reasonable implementation of an RB-Tree, at least with respect to the link to the related public domain source that was posted. In terms of location, I think utils/misc is a reasonable place for it to live since I see it as analogous to the hash table implementation, i.e. it's a template RB-Tree implementation designed to be used as required throughout the codebase. backend/access seems to be the home of index AMs only. Not really. access/common has things in it like reloptions.c and printtup.c, which are clearly not index AMs. I suppose another option is to put it in lib. The only things there right now are dllinfo.c and stringinfo.c, but in some ways generic in-memory red-black trees seem analagous to generic string buffers. - You correctly picked up on the namespace issue, although I noticed that you left RED and BLACK as they were. Maybe RBRED and RBBLACK would be better, though not that there are any colour related defines around in a database backend to make a name clash probable. Yeah, I thought about that. Since you came up with it independently, that's enough to make me think it's a good idea. - I found the name of the appendator method misleading - perhaps updater would make more sense? I like the existing name better. It's a little weird but I find it descriptive. 2. I'm a little concerned about the performance implications of this patch. Looking at http://www.sai.msu.su/~megera/wiki/2009-04-03, it's clear that the patch is a huge win in some cases. But I'm also surprised by how much performance is lost in some of the other cases that you tested. I suspect, on balance, that it's probably still a good idea to put this in, but I wonder if you've profiled this at all to see where the extra time is going and/or explored possible ways of squashing that overhead down a little more. 3. In ginInsertEntry(), the else branch of the if statement really looks like magic when you first read it. I wonder if it would make sense to pull the contents of EAAllocate() directly into this function, since there's only one call site anyhow. God yes. This is not a good example of maintainable code - even with your comment I struggled for a while to try and figure it out :( I would suggest that this is refactored appropriately before commit. Yeah it took me a while. I think we need Teodor and Oleg to prepare a new version of this patch based on these suggestions. This part, in particular, I feel like they need to rework rather than us. I don't know the GIN code well enough to be confident of what I'm doing. I have to say that it would be easier to understand what's going on here if there were a few more comments... With perhaps some minor tweaks to some of the names and a rework of the else clause in ginInsertEntry(), I feel this patch is reasonably close to commit. Yeah, I think it can get there, but only if Oleg and Teodor provide an updated version pretty soon... I shall now continue my review of the associated KNNGiST patch. ...especially if there is to be any thought of getting ANOTHER patch after this one committed, too. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
sri...@postgresql.org (Simon Riggs) writes: Log Message: --- Augment WAL records for btree delete with GetOldestXmin() to reduce false positives during Hot Standby conflict processing. Simple patch to enhance conflict processing, following previous discussions. Controlled by parameter minimize_standby_conflicts = on | off, with default off allows measurement of performance impact to see whether it should be set on all the time. WTF? Simon, this seems to be getting way way beyond anything the community has agreed to. Particularly, inventing GUCs is not something to be doing without consensus. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [CFReview] Red-Black Tree
Robert Haas robertmh...@gmail.com writes: On Fri, Jan 29, 2010 at 9:00 AM, Mark Cave-Ayland mark.cave-ayl...@siriusit.co.uk wrote: ... In terms of location, I think utils/misc is a reasonable place for it to live since I see it as analogous to the hash table implementation, i.e. it's a template RB-Tree implementation designed to be used as required throughout the codebase. backend/access seems to be the home of index AMs only. Not really. access/common has things in it like reloptions.c and printtup.c, which are clearly not index AMs. That may be, but it's not a place for random generic data structures, at least not ones that might be useful outside access/. I suppose another option is to put it in lib. The only things there right now are dllinfo.c and stringinfo.c, but in some ways generic in-memory red-black trees seem analagous to generic string buffers. I could live with either lib or utils/misc/. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Tom Lane wrote: sri...@postgresql.org (Simon Riggs) writes: Log Message: --- Augment WAL records for btree delete with GetOldestXmin() to reduce false positives during Hot Standby conflict processing. Simple patch to enhance conflict processing, following previous discussions. Controlled by parameter minimize_standby_conflicts = on | off, with default off allows measurement of performance impact to see whether it should be set on all the time. WTF? Simon, this seems to be getting way way beyond anything the community has agreed to. Particularly, inventing GUCs is not something to be doing without consensus. yeah actually both of the last commits seem rather strange given the current discussion on this list I must say... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 64-bit size pgbench
Tom Lane wrote: In the past we've rejected proposed patches for pgbench on the grounds that they would make results non-comparable to previous results. So the key question here is how much this affects the speed. Please be sure to test that on a 32-bit machine, not a 64-bit one. Sheesh, who has a 32-bit machine anymore? I'll see what older hardware I can dig up. I've realized there are two separate issues to be concerned about: 1) On small scale data sets, what's the impact of the main piece of data being shuffled around in memory (the account number in the accounts table) now being 64 bits? That part might be significantly worse on 32-bit hardware. 2) How does the expansion in size of the related primary key on that data impact the breakpoint where the database doesn't fit in RAM anymore? I did just updated my pgbench-tools package this month so that it happily runs against either 8.3 or 8.4/9.0 and I've done two rounds of extensive test runs lately, so plenty of data to compare against here. ! retval = (int64) strtol(res, endptr, 19); That bit is merely wishful thinking :-( I did specificially say I didn't trust that call one bit. There is a middle ground position here, similar to what Robert suggested, that I just add a large mode to the program for people who need it without touching the current case. That might allow me to sidestep some of these issues I may not have a good answer to with getting the \setshell feature working right in 64 bits, could just make that one specific to regular mode. In any case, I think this limitation in what pgbench can do has risen to be a full-on bug at this point for the expected users of the next version, and I'll sit on this until there's something better we can make available. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
All, Is there a working list of HS must-fix items somewhere which people agree on? Or are we still lacking consensus? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HS/SR and smart shutdown
Fujii, I guess that the startup process and the walreceiver should wait for all read only backends to exit in smart shutdown case. It's because those backends might be waiting for the record that conflicts with their queries to be replayed. Is this OK? Or we should kill the startup process and the walreceiver on ahead? If my guess is right, we would need to add new PMState to cancel recovery and replication after all read only connections have died. How could existing read queries on the slave be waiting on a WAL record? I don't follow this. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby: Relation-specific deferred conflict resolution
On Fri, 2010-01-29 at 11:41 -0800, Josh Berkus wrote: All, Is there a working list of HS must-fix items somewhere which people agree on? Or are we still lacking consensus? VACUUM FULL, I believe is one. Joshua D. Drake --Josh Berkus -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PG 9.0 and standard_conforming_strings
With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Bruce Momjian br...@momjian.us wrote: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? If not now, when? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
On Jan 29, 2010, at 11:51 AM, Bruce Momjian wrote: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? +1 David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] odd output in initdb
I saw some odd pgstat output during an initdb on Windows today: The files belonging to this database system will be owned by user pgrunner. This user must also own the server process. The database cluster will be initialized with locale C. The default database encoding has accordingly been set to SQL_ASCII. The default text search configuration will be set to english. creating directory data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 32MB creating configuration files ... ok creating template1 database in data/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... WARNING: pgstat wait timeout WARNING: pgstat wait timeout ok creating system views ... ok loading system objects' descriptions ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok loading PL/pgSQL server-side language ... ok vacuuming database template1 ... WARNING: pgstat wait timeout WARNING: pgstat wait timeout ok copying template1 to template0 ... WARNING: pgstat wait timeout ok copying template1 to postgres ... ok Success. You can now start the database server using: C:\msys\1.0\home\pgrunner\bf\root\HEAD\inst\bin\postgres -D data or C:\msys\1.0\home\pgrunner\bf\root\HEAD\inst\bin\pg_ctl -D data -l logfile start WARNING: enabling trust authentication for local connections You can change this by editing pg_hba.conf or using the -A option the next time you run initdb. A little searching on the buildfarm shows this started around Jan 10th: pgbfprod=# select min(snapshot) from build_status_log where sysname = 'red_bat' and log_stage = 'initdb.log' and log_text ~ 'pgstat'; min - 2010-01-10 23:30:01 (1 row) I can't see an obvious culprit in the commit logs right off. Does anyone have an idea what's going on? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Bruce Momjian br...@momjian.us writes: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? I'm inclined to think we're going to have enough problems without that. Changing that default will break, approximately speaking, every single Postgres client app. Do you really think more than epsilon of them are clean and ready for such a change? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
On Fri, 2010-01-29 at 14:04 -0500, Tom Lane wrote: sri...@postgresql.org (Simon Riggs) writes: Log Message: --- Augment WAL records for btree delete with GetOldestXmin() to reduce false positives during Hot Standby conflict processing. Simple patch to enhance conflict processing, following previous discussions. Controlled by parameter minimize_standby_conflicts = on | off, with default off allows measurement of performance impact to see whether it should be set on all the time. WTF? Simon, this seems to be getting way way beyond anything the community has agreed to. Particularly, inventing GUCs is not something to be doing without consensus. If you or anybody else would like me to revoke it then I am happy to do that, with no problem or argument. I agree it hasn't had discussion, though am happy to have such a discussion. The commit is a one line change, with parameter to control it, discussed by Heikki and myself in December 2008. I stand by the accuracy of the change; the parameter is really to ensure we can test during beta. I imagined such a minor addition would pass without comment. This is not the same patch not-being-discussed on the other thread, which is too complex for a commit without review. It is a separate change altogether, although it does relate to conflict processing. In any case I would never commit a patch while discussion on it continues. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
I wrote: Bruce Momjian br...@momjian.us writes: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? I'm inclined to think we're going to have enough problems without that. BTW, core already had that discussion, but maybe I should repeat it to try to forestall any other since this is going to be 9.0, let's break backwards compatibility in a big way! proposals. Now is not the time to be making big changes; we are much too late in the devel cycle to work through all the possible consequences. Because we switched from it's-8.5 to it's-9.0 at such a late stage, we really need to consider that that's only a marketing version number and technical compatibility decisions should be made the same way as for any other major release. Perhaps at some point we will choose to do a major version bump where we really do clean up a lot of bad backwards-compatibility things. That needs to be done in a deliberate fashion with a lot of advance planning; and things should get broken near the beginning of the devel cycle, not the end. [ still bearing scars from the 8.3 implicit-cast business, which we didn't think would generate nearly the backlash it did... ] regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? I'm inclined to think we're going to have enough problems without that. Changing that default will break, approximately speaking, every single Postgres client app. Do you really think more than epsilon of them are clean and ready for such a change? Well, if they aren't ready now, then we might as well say we are never going to change it and update the documentation and TODO list to reflect that --- we have had standard_conforming_strings since 2005. We can't keep pretending this will happen if we have no intention of doing it. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
On Fri, Jan 29, 2010 at 13:42, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: Bruce Momjian br...@momjian.us writes: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? I'm inclined to think we're going to have enough problems without that. [ still bearing scars from the 8.3 implicit-cast business, which we didn't think would generate nearly the backlash it did... ] Yeah that was my first reaction. But then again we also have a guc they can change back. Sure you could create your own typecasts to restore the old behavior in 8.3 (after trolling the mailing lists, or finding some blog entry that got created X months after the release...). Thats no where near as nice as a simple setting. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
On Fri, Jan 29, 2010 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: Bruce Momjian br...@momjian.us writes: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? I'm inclined to think we're going to have enough problems without that. Changing that default will break, approximately speaking, every single Postgres client app. Do you really think more than epsilon of them are clean and ready for such a change? Well, I already had to fix a great many things in my apps to prevent them from spewing warnings all over creation. If other people have done likewise it might not be too bad; OTOH, there's probably not a huge amount of downside in waiting. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
In response to Bruce Momjian br...@momjian.us: Tom Lane wrote: Bruce Momjian br...@momjian.us writes: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? I'm inclined to think we're going to have enough problems without that. Changing that default will break, approximately speaking, every single Postgres client app. Do you really think more than epsilon of them are clean and ready for such a change? Well, if they aren't ready now, then we might as well say we are never going to change it and update the documentation and TODO list to reflect that --- we have had standard_conforming_strings since 2005. We can't keep pretending this will happen if we have no intention of doing it. Announce it as a change for 9.1 NOW, and then it will be whoever's fault if they aren't paying attention. Plenty of time to fix it if it's announced now. Also, as long as the config option is there, they can always flip it back, which makes it MUCH lower overhead than the casting change was. Overall, I don't think this change is nearly as severe as the cast change in 8.3, and I don't feel it warrants the same eggshell walking. When the decision is made to remove the standard_conforming_string config option altogether ... that'll be a different story! -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
On Fri, 2010-01-29 at 15:45 -0500, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian br...@momjian.us writes: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? I'm inclined to think we're going to have enough problems without that. Changing that default will break, approximately speaking, every single Postgres client app. Do you really think more than epsilon of them are clean and ready for such a change? Well, if they aren't ready now, then we might as well say we are never going to change it and update the documentation and TODO list to reflect that --- we have had standard_conforming_strings since 2005. We can't keep pretending this will happen if we have no intention of doing it. I would argue that now is the perfect time for a number of reasons: (1) 9.x regardless of the fact that it is just a number, reflects a massive change as a whole. (2) HS/SR are going to be scary things to use for at least 6 months to a year. That is not to disparage the hard work, just that they are big enough and invasive enough to make sure we get through a couple of dot revs before we start seriously recommending them. (3) As Bruce suggests, we are on year 6 now. I think we can take the heat. (4) The 8.3 issue wasn't nearly as bad as Tom is making it out to be. Yes, there was a lot of WTF going on, but only by people that aren't paying attention anyway and the work to fix it was pretty nominal. (5) The time to change it is NOW, so that when we go into beta it becomes a serious in your face, we have to fix this if we want to be compatible with v9 of PostgreSQL. And get this... because of HS and SR, everybody is going to want to be compatible with v9. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Tom Lane wrote: I wrote: Bruce Momjian br...@momjian.us writes: With the release of Postgres 9.0, should we consider changing the default for 'standard_conforming_strings'? I'm inclined to think we're going to have enough problems without that. BTW, core already had that discussion, but maybe I should repeat it to try to forestall any other since this is going to be 9.0, let's break backwards compatibility in a big way! proposals. Now is not the time to be making big changes; we are much too late in the devel cycle to work through all the possible consequences. Because we switched from it's-8.5 to it's-9.0 at such a late stage, we really need to consider that that's only a marketing version number and technical compatibility decisions should be made the same way as for any other major release. Perhaps at some point we will choose to do a major version bump where we really do clean up a lot of bad backwards-compatibility things. That needs to be done in a deliberate fashion with a lot of advance planning; and things should get broken near the beginning of the devel cycle, not the end. [ still bearing scars from the 8.3 implicit-cast business, which we didn't think would generate nearly the backlash it did... ] I did ask this same question for the 8.5/9.0 release in April of 2009 so don't say I am only asking about this at the end of development cycles: http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Joshua D. Drake wrote: (4) The 8.3 issue wasn't nearly as bad as Tom is making it out to be. Yes, there was a lot of WTF going on, but only by people that aren't paying attention anyway and the work to fix it was pretty nominal. The big mistake we made in 8.3 is not having those compatibility functions that Peter created ready _at_ _release_ _time_. I believe that was pure sloppiness on our part. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Alex Hunsaker bada...@gmail.com writes: On Fri, Jan 29, 2010 at 13:42, Tom Lane t...@sss.pgh.pa.us wrote: [ still bearing scars from the 8.3 implicit-cast business, which we didn't think would generate nearly the backlash it did... ] Yeah that was my first reaction. But then again we also have a guc they can change back. There's a GUC for it is NOT a helpful answer; if there's one thing that we've learned the hard way over the past years, it's that GUCs don't solve compatibility problems. Applications don't know to set them, and having the wrong setting can easily become a security hole (particularly for this one). I stand by the position that it's way too late in the cycle for insufficiently-thought-out proposals for major behavioral changes. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HS/SR and smart shutdown
Josh Berkus wrote: I guess that the startup process and the walreceiver should wait for all read only backends to exit in smart shutdown case. It's because those backends might be waiting for the record that conflicts with their queries to be replayed. Is this OK? Or we should kill the startup process and the walreceiver on ahead? If my guess is right, we would need to add new PMState to cancel recovery and replication after all read only connections have died. How could existing read queries on the slave be waiting on a WAL record? Imagine that you do this in the master: begin; DROP TABLE foo (id int4); a lot of other stuff commit; When the DROP is replayed in the standby, the startup process acquires a lock on table foo, on behalf of the transaction that it's replaying. If you run SELECT * FROM foo in the standby after that, it will block until the startup process replays the COMMIT record and releases the lock. This is similar to the deadlock situation in hot standby that was discussed on the other thread, Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Tom Lane wrote: Alex Hunsaker bada...@gmail.com writes: On Fri, Jan 29, 2010 at 13:42, Tom Lane t...@sss.pgh.pa.us wrote: [ still bearing scars from the 8.3 implicit-cast business, which we didn't think would generate nearly the backlash it did... ] Yeah that was my first reaction. But then again we also have a guc they can change back. There's a GUC for it is NOT a helpful answer; if there's one thing that we've learned the hard way over the past years, it's that GUCs don't solve compatibility problems. Applications don't know to set them, and having the wrong setting can easily become a security hole (particularly for this one). I stand by the position that it's way too late in the cycle for insufficiently-thought-out proposals for major behavioral changes. Well, since I asked in April of 2009, at the beginning of the cycle, 6 years after the introduction of the variable, and we still are not doing it, then let's stop pretending we will ever do it. The way the docs stand now we hold it over people's heads and issue warnings that are meaningless if we are never going to change it. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
On Fri, Jan 29, 2010 at 14:03, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: On Fri, Jan 29, 2010 at 13:42, Tom Lane t...@sss.pgh.pa.us wrote: I stand by the position that it's way too late in the cycle for insufficiently-thought-out proposals for major behavioral changes. After skimming the thread Bruce linked: http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php It certainly seems insufficiently-thought-out. :( -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
I stand by the position that it's way too late in the cycle for insufficiently-thought-out proposals for major behavioral changes. I don't see how announcing this earlier in the dev cycle would help, at all. The people who read -hackers have been using standards-conforming-strings for years. Further, if we announce it now, people have 4-5 months to get ready for it, assuming they were updating to 9.0.0 anyway, which I doubt anyone is. For this release, I'm already planning to have big backwards compatibility section and web page with *lots* of warnings and explanations, and because of the media around the release for once it will be read. I'd argue that Bruce is right; if we're not going to do it now, we might as well stop pretending we ever are. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Alex Hunsaker wrote: On Fri, Jan 29, 2010 at 14:03, Tom Lane t...@sss.pgh.pa.us wrote: Alex Hunsaker bada...@gmail.com writes: On Fri, Jan 29, 2010 at 13:42, Tom Lane t...@sss.pgh.pa.us wrote: I stand by the position that it's way too late in the cycle for insufficiently-thought-out proposals for major behavioral changes. After skimming the thread Bruce linked: http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php It certainly seems insufficiently-thought-out. :( Is this still true? When we changed plpgsql so it shared the scanner with the backend scanner, does this issue no longer apply, i.e. consider honoring standard_conforming_strings in PL/pgSQL function bodies? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Alex Hunsaker bada...@gmail.com wrote: After skimming the thread Bruce linked: http://archives.postgresql.org/pgsql-hackers/2009-04/msg00512.php It certainly seems insufficiently-thought-out. :( Just as a clarification, while the GUC was *added* in 8.1, it was read-only with a value of 'off'. I submitted a patch and started using it under 8.1 in February of 2006 (because we had an urgent need), and it officially became *settable* in 8.2. I don't have strong feelings about changing the default. Obviously, this bites people primarily when converting to PostgreSQL -- that's when it bit me and that's where people normally are when they post to the lists about related issues. It's not clear to me that the issues related to functions have been thought out sufficiently; my personal feeling is that a function should run with the setting under which it was created (as the semantics of the literal seem as though they should be frozen at that point), but that was shot down. And then there's the issue about EXECUTE. If we don't have consensus on a solution to those issues, maybe we should wait. Those who need it who are already using PostgreSQL already have it figured out -- it's just a bump on the road to converting for those used to standard literals. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] odd output in initdb
Andrew Dunstan wrote: initializing dependencies ... WARNING: pgstat wait timeout WARNING: pgstat wait timeout ok vacuuming database template1 ... WARNING: pgstat wait timeout WARNING: pgstat wait timeout ok copying template1 to template0 ... WARNING: pgstat wait timeout I can't see an obvious culprit in the commit logs right off. Actually, on close inspection it looks to me like this commit: Create typedef pgsocket for storing socket descriptors. http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=ea1a4463e9de9662b7c9e13374ec8c7b92ff2f19 could well be the culprit. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Josh Berkus j...@agliodbs.com writes: I stand by the position that it's way too late in the cycle for insufficiently-thought-out proposals for major behavioral changes. I don't see how announcing this earlier in the dev cycle would help, at all. We would have more than no-time-at-all to test it and fix any breakage. Just to start close to home, do you really trust either psql or pg_dump to be completely free of standard_conforming_strings issues? How about JDBC or ODBC? Python drivers? PLs? The really short and sweet answer is that if you have any ambition at all to ship 9.0 this year, it is too late to add new work items. This is a work item, and not a small one. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Bruce Momjian br...@momjian.us writes: Well, since I asked in April of 2009, at the beginning of the cycle, 6 years after the introduction of the variable, and we still are not doing it, then let's stop pretending we will ever do it. We have made forward progress since that thread (we fixed the plpgsql parsing issues, partially in 8.4 and completely for 9.0). We can continue to make forward progress in the future. But *right now is not the time*. We have more than enough on our plates for 9.0 already, and just about nobody believes we are going to meet the schedule now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
On Friday 29 January 2010 23:34:09 Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: I stand by the position that it's way too late in the cycle for insufficiently-thought-out proposals for major behavioral changes. I don't see how announcing this earlier in the dev cycle would help, at all. The really short and sweet answer is that if you have any ambition at all to ship 9.0 this year, it is too late to add new work items. This is a work item, and not a small one. What about anouncing in the 9.0 releasenotes that it will be removed in 9.1? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Andres Freund wrote: On Friday 29 January 2010 23:34:09 Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: I stand by the position that it's way too late in the cycle for insufficiently-thought-out proposals for major behavioral changes. I don't see how announcing this earlier in the dev cycle would help, at all. The really short and sweet answer is that if you have any ambition at all to ship 9.0 this year, it is too late to add new work items. This is a work item, and not a small one. What about anouncing in the 9.0 releasenotes that it will be removed in 9.1? You mean turned on by default, right? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
Andres Freund and...@anarazel.de writes: What about anouncing in the 9.0 releasenotes that it will be removed in 9.1? That seems quite useless. I note that we've made such statements before and not followed through on them; one that just came up again is that contrib/xml2 is a couple releases past when it was said it'd be removed, and there is still no prospect of it really dying in the near future. The bottom line is that these sorts of changes take actual *work*, and not a trivial amount of it. No amount of blather in the documentation will substitute for somebody doing the work. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] HS/SR and smart shutdown
On Thu, 2010-01-21 at 09:27 +0200, Heikki Linnakangas wrote: Right, that's the way a standby server (= one still in recovery) has always behaved. It has made sense in the past: it's not in the spirit of smart shutdown to kill the WAL replay immediately. smart means wait for recovery to finish, then shutdown. It's a good question if that still makes sense with Hot Standby. Perhaps we should redefine smart shutdown in standby mode to shut down as soon as all read-only connections have died. It's clear that smart shutdown doesn't work while something is active. Recovery is active and so we shouldn't shutdown. It makes sense, it works like this already, lets leave it. Document it if needed. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Listen / Notify - what to do when the queue is full
Comments: * In standard_ProcessUtility(), case NotifyStmt, you add a comment: /* XXX the new listen/notify version can be enabled * for Hot Standby */ but I don't think that's correct. We may be able to support LISTEN on the standby, but not NOTIFY (right?). I don't think we should be adding speculative comments anyway, because there is some work still needed before HS can support LISTEN (notably, WAL-logging NOTIFY). * You have a TODO list as a comment. Can you remove it and explain those items on list if they aren't already? * You have the comment: /* * How long can a payload string possibly be? Actually it needs to be one * byte less to provide space for the trailing terminating '\0'. */ That should be written more simply, like Maximum size of the payload, including terminating NULL. * You have the Assert: Assert(strlen(n-payload) = NOTIFY_PAYLOAD_MAX_LENGTH); which is inconsistent with the earlier test: if (stmt-payload strlen(stmt-payload) NOTIFY_PAYLOAD_MAX_LENGTH - 1) ereport(ERROR, ... * ASCII-only is still an open issue. * 2PC is still an open issue (notifications are lost on restart, and there may be other problems, as well). I think it's easy enough to throw an error on PREPARE TRANSACTION if there are any notifications, right? * There's a bug where an UNLISTEN can abort, and yet you still miss the notification. This is because you unlisten before you actually commit the transaction, and an error between those times will cause the UNLISTEN to take effect even though the rest of the transaction fails. For example: -- session 1 LISTEN foo; BEGIN; UNLISTEN foo; -- session 2 NOTIFY foo; -- gdb in session 1 (gdb) break AtCommit_NotifyBeforeCommit (gdb) c -- session 1 COMMIT; -- gdb in session 1 (gdb) finish (gdb) p op_strict(7654322) (gdb) quit The notification is missed. It's fixed easily enough by doing the UNLISTEN step in AtCommit_NotifyAfterCommit. I'm still looking through some of the queue stuff, and I'll send an update soon. I wanted to give you some feedback now though. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PG 9.0 and standard_conforming_strings
On Friday 29 January 2010 23:54:15 Tom Lane wrote: Andres Freund and...@anarazel.de writes: What about anouncing in the 9.0 releasenotes that it will be removed in 9.1? That seems quite useless. I note that we've made such statements before and not followed through on them; one that just came up again is that contrib/xml2 is a couple releases past when it was said it'd be removed, and there is still no prospect of it really dying in the near future. The bottom line is that these sorts of changes take actual *work*, and not a trivial amount of it. No amount of blather in the documentation will substitute for somebody doing the work. It is not about somebody doing the work, it is about lowering the impact a bit. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
