Re: [HACKERS] FSM search modes
On Fri, 2009-09-18 at 10:47 +0900, Itagaki Takahiro wrote: Simon Riggs si...@2ndquadrant.com wrote: * compact - page selection specifically attempts to find the lowest numbered blocks, so that the table will naturally shrink over time. We cannot shrink the table if one tuple remains at the end of table and the tuple is always HOT-updated, because we put a new tuple into the same page where the old tuple is placed if possible. In addition to your intelligent FSM search modes, do we need another algorithm to make the compaction to work better? Perhaps we can have an additional piece of information about a table. Something like target_size, so that normal updaters that attempt HOT updates on blocks greater than target_size would know to avoid that block and to seek a new location for the row lower in the table. Perhaps such information could be reset and then sent via invalidation mechanisms. I'm thinking along the lines of a fire alarm. An occasional mechanism by which we can inform users of the need to evacuate certain blocks. -- 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] [PATCH] pgbench: new feature allowing to launch shell commands
You really should be returning a value at the point since the function
signature defines a return type. If not the function should be void,
which it cannot be in this context since it is used for boolean tests
elsewhere. The returns in question are all part of error blocks and
should return false.
OK I got your point, I missed the part managing with CState, which is tested
after doCustom.
Another version of the patch is attached with this email.
I must be doing something wrong when I am running this script. It is
still throwing errors. Would you mind showing me the pgbench command you
used to run it?
Of course, here it is the list of commands I use:
pgbench -i dbname (in case your database is called dbname)
pgbench -c 10 -t 10 -f transaction_file_name.data dbname (customer and
transaction numbers can also bet set as you want).
Regards,
--
Michael Paquier
NTT OSSC
--- postgresql-8.4.0.orig/contrib/pgbench/pgbench.c 2009-09-17 09:07:24.0 +0900
+++ postgresql-8.4.0/contrib/pgbench/pgbench.c 2009-09-18 13:24:33.0 +0900
@@ -120,6 +120,7 @@ typedef struct
} Variable;
#define MAX_FILES 128 /* max number of SQL script files allowed */
+#define SHELL_COMMAND_SIZE 256 /* maximum size allowed for shell command */
/*
* structures used in custom query mode
@@ -984,7 +985,47 @@ top:
st-listen = 1;
}
+ else if (pg_strcasecmp(argv[0], shell) == 0)
+ {
+ int j,
+retval,
+retvalglob;
+ char commandLoc[SHELL_COMMAND_SIZE];
+
+ retval = snprintf(commandLoc,SHELL_COMMAND_SIZE-1,%s,argv[1]);
+ if (retval 0
+|| retval SHELL_COMMAND_SIZE-1)
+ {
+fprintf(stderr, Error launching shell command: too many characters\n);
+st-ecnt++;
+return;
+ }
+ retvalglob = retval;
+ for (j = 2; j argc; j++)
+ {
+char *commandLoc2 = strdup(commandLoc);
+retval = snprintf(commandLoc,SHELL_COMMAND_SIZE-1,%s %s, commandLoc2, argv[j]);
+retvalglob += retval;
+if (retval 0
+ || retvalglob SHELL_COMMAND_SIZE-1)
+{
+ fprintf(stderr, Error launching shell command: too many characters\n);
+ free(commandLoc2);
+ st-ecnt++;
+ return;
+}
+free(commandLoc2);
+ }
+ retval = system(commandLoc);
+ if (retval 0)
+ {
+fprintf(stderr, Error launching shell command: command not launched);
+st-ecnt++;
+return;
+ }
+ st-listen = 1;
+ }
goto top;
}
}
@@ -1280,6 +1321,14 @@ process_commands(char *buf)
fprintf(stderr, %s: extra argument \%s\ ignored\n,
my_commands-argv[0], my_commands-argv[j]);
}
+ else if (pg_strcasecmp(my_commands-argv[0], shell) == 0)
+ {
+ if (my_commands-argc 1)
+ {
+fprintf(stderr, %s: missing command\n, my_commands-argv[0]);
+return NULL;
+ }
+ }
else
{
fprintf(stderr, Invalid command %s\n, my_commands-argv[0]);
--
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] [patch] pg_ctl init extension
Peter Eisentraut píše v čt 17. 09. 2009 v 23:00 +0300: On tor, 2009-09-17 at 21:43 +0200, Zdenek Kotala wrote: Attached patch extends pg_ctl command with init option. pg_ctl -D /var/lib/postgres [-s] init This should replace usage of initdb command which has problematic name as we already discussed several times. Initdb binary will be still there, but it can be renamed and move into execlib dir in the future. If the name is a problem, why not change the name? What you are proposing above is effectively a very elaborate name change, so why not go for a simpler one? The idea is to have one command for server control. By my opinion init logically belongs to group of command like start/stop. It is also possible to add parameter for init+start in one command and so on. If you look on ZFS you have only two commands to manage everything, it is easy and you can start to use ZFS very quickly. I think this patch increase usability/adoption od postgreSQL for newbies. And second big advantage is that it would be possible easily extend pg_ctl to cope with different postgresql versions (e.g. pg_ctl -v 8.2 -D . init). There is no reason why pg_ctl couldn't start different postgreSQL version depends on PG_VERSION in data directory. Zdenek -- 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 0.2.1
On Thu, 2009-09-17 at 19:01 -0400, Robert Haas wrote: I'm going to put the index-only scans aside for now to focus on hot standby and streaming replication. Both are big patches, so there's plenty of work in those two alone, and not only for me. What is the best way to attack this? Should I keep reviewing index-only scans so that you have feedback for when you get back to it, or should I move on to something else? If something else, does it make more sense for me to look at HS since I did a bit of work with a previous version, or would it be better for me to just pick one of the other patches from the CommitFest and work on that? Also, stepping back from me personally, should we try to assign some additional reviewers to these patches? Is there some way we can divide up review tasks among multiple people so that we're not repeating each others work? Thoughts appreciated, from Heikki, Simon, or others. I think this is a great opportunity to widen the pool of people contributing to reviews. I suggest the creation of a second group of people, performing round-robin testing of patches. These people would be able to verify * documentation matches implemented features (does it do what it says on the tin?) * usability of explicit features (do the features work well?) * usability gap of unimplemented features (what else do we need?) * are there any bugs? These questions are often quickly answered for smaller patches, but HS's scope mean that such a task properly executed could take a full week, if not longer. Second group of people are just as skilled Postgres people as reviewers, in some cases more so, apart from they have less detailed knowledge of the codebase. We have many such people and it would be good to encourage them to perform thorough reviews rather than tire kicking. I'm not sure that Heikki needs additional reviewers. He now has significant knowledge of the patch and is good at focusing on key aspects of the internals. Other code reviewers are welcome, of course. -- 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] Feedback on getting rid of VACUUM FULL
Tom Lane wrote: I don't see any reason why not breaking the user visible behavior of tuples CTID between any two major releases, Am I completely wet here? Completely. This is a user-visible behavior that we have encouraged people to rely on, and for which there is no easy substitute. I second that: it would hurt to lose this generic technique for optimistic locking. Yours, Laurenz Albe -- 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] Feedback on getting rid of VACUUM FULL
On Thu, 2009-09-17 at 17:44 -0400, Tom Lane wrote: Dimitri Fontaine dfonta...@hi-media.com writes: I don't see any reason why not breaking the user visible behavior of tuples CTID between any two major releases, Am I completely wet here? Completely. This is a user-visible behavior that we have encouraged people to rely on, and for which there is no easy substitute. Agreed. I investigated that avenue as a possible implementation approach when designing HOT and I didn't find anything worth taking away. I'm very much in favour of a higher-level solution to compacting a table, as has been discussed for the batch update utility. That avoids most of the low-level yuck that VACUUM FULL imposes upon itself and everyone around it. If we want to move forward long term we need to keep the internals as clean as possible. Hot Standby would never have been possible without that principle having already been applied across the other subsystems. -- 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] FSM search modes
On Sep 18, 2009, at 1:09 AM, Simon Riggs wrote: On Fri, 2009-09-18 at 10:47 +0900, Itagaki Takahiro wrote: Simon Riggs si...@2ndquadrant.com wrote: * compact - page selection specifically attempts to find the lowest numbered blocks, so that the table will naturally shrink over time. We cannot shrink the table if one tuple remains at the end of table and the tuple is always HOT-updated, because we put a new tuple into the same page where the old tuple is placed if possible. In addition to your intelligent FSM search modes, do we need another algorithm to make the compaction to work better? Perhaps we can have an additional piece of information about a table. Something like target_size, so that normal updaters that attempt HOT updates on blocks greater than target_size would know to avoid that block and to seek a new location for the row lower in the table. Perhaps such information could be reset and then sent via invalidation mechanisms. I'm thinking along the lines of a fire alarm. An occasional mechanism by which we can inform users of the need to evacuate certain blocks. It might be better to not beat around the bush and provide a vacuum mode that explicitly tries to free the last X percent of the table. That's especially handy for a very large table, because you probably don't want to be forced into scanning the whole thing in vacuum just to free some space at the end. This mode could also be more aggressive about trying to acquire the lock that's needed to trim the file on disk. That said, *any* step that improves dealing with table bloat is extremely welcome, as right now you're basically stuck rebuilding the table. -- Decibel!, aka Jim C. Nasby, Database Architect deci...@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 -- 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 patch for CommitFest 2009-09
Heikki Linnakangas wrote: Heikki Linnakangas wrote: I'm thinking that walreceiver should be a stand-alone program that the startup process launches, similar to how it invokes restore_command in PITR recovery. Instead of using system(), though, it would use fork+exec, and a pipe to communicate. Here's a WIP patch to do that, over your latest posted patch. I've also pushed this to my git repository at git://git.postgresql.org/git/users/heikki/postgres.git, replication branch. I'll continue reviewing... BTW, my modified patch doesn't correctly zero-fill new WAL segments. Needs to be fixed... -- 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] ECPG patchset
New patch - two decimal-related memory leak fixes.
Happens on 8.4 and 8.5, maybe on older trees as well.
One of the two chunks was in the SQLDA patch originally.
This is independent from any other patches.
--
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/
diff -dcrpN pgsql.ifdef/src/interfaces/ecpg/compatlib/informix.c pgsql.decimalfix/src/interfaces/ecpg/compatlib/informix.c
*** pgsql.ifdef/src/interfaces/ecpg/compatlib/informix.c 2009-09-03 12:25:47.0 +0200
--- pgsql.decimalfix/src/interfaces/ecpg/compatlib/informix.c 2009-09-15 12:35:48.0 +0200
*** deccvasc(char *cp, int len, decimal *np)
*** 232,238
{
int i = PGTYPESnumeric_to_decimal(result, np);
! free(result);
if (i != 0)
ret = ECPG_INFORMIX_NUM_OVERFLOW;
}
--- 232,238
{
int i = PGTYPESnumeric_to_decimal(result, np);
! PGTYPESnumeric_free(result);
if (i != 0)
ret = ECPG_INFORMIX_NUM_OVERFLOW;
}
diff -dcrpN pgsql.dyncursor/src/interfaces/ecpg/ecpglib/data.c pgsql.sqlda/src/interfaces/ecpg/ecpglib/data.c
*** pgsql.dyncursor/src/interfaces/ecpg/ecpglib/data.c 2009-08-08 17:19:45.0 +0200
--- pgsql.sqlda/src/interfaces/ecpg/ecpglib/data.c 2009-09-03 12:56:36.0 +0200
*** ecpg_get_data(const PGresult *results, i
*** 554,560
else
PGTYPESnumeric_to_decimal(nres, (decimal *) (var + offset * act_tuple));
! free(nres);
break;
case ECPGt_interval:
--- 554,560
else
PGTYPESnumeric_to_decimal(nres, (decimal *) (var + offset * act_tuple));
! PGTYPESnumeric_free(nres);
break;
case ECPGt_interval:
--
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] Feedback on getting rid of VACUUM FULL
On Fri, 2009-09-18 at 08:50 +0200, Albe Laurenz wrote: Tom Lane wrote: I don't see any reason why not breaking the user visible behavior of tuples CTID between any two major releases, Am I completely wet here? Completely. This is a user-visible behavior that we have encouraged people to rely on, and for which there is no easy substitute. I second that: it would hurt to lose this generic technique for optimistic locking. CTIDs don't help with optimistic locking, though it seems they can. If you don't hold open the transaction then someone else can update the row. That sounds good, but because of HOT it is possible that the same CTID with the same PK value occupies that exact CTID value when you return to check it. You think row has not been updated so you perform your update, but it has been updated, so you overwrite previous data - data loss. Actually worse, sporadic data loss because of race conditions. -- 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] Feedback on getting rid of VACUUM FULL
Exactly. The application is typically going to throw a concurrent update type of error when this happens, and we don't want magic background operations to cause that. I`d give up the possibility of using CTIDs in the way You explained for an auto-debloater without blinking an eye. Maybe we should have a GUC to enable/disable the auto-debloater? Make it a reloption? -- 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] Feedback on getting rid of VACUUM FULL
Simon Riggs wrote: CTIDs don't help with optimistic locking, though it seems they can. If you don't hold open the transaction then someone else can update the row. That sounds good, but because of HOT it is possible that the same CTID with the same PK value occupies that exact CTID value when you return to check it. You think row has not been updated so you perform your update, but it has been updated, so you overwrite previous data - data loss. Actually worse, sporadic data loss because of race conditions. Yeah, you have to check xmin as well. -- 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
[HACKERS] numeric_to_number() function skipping some digits
Hi,
With PG84, I have tried something like this which seem incorrect to me.
# SELECT '' AS to_number_2, to_number('-347,58', '99G999');
to_number_2 | to_number
-+---
| -3458
(1 row)
After browsing the code (numeric_to_number), I have found that number string
is processed according to the number format. Which means, when 'G' is found
in the format we have moved the number pointer to next character. This is
why the digit '7' is skipped. And while processing ',', as it is not a digit
it is ignored.
Is this expected behaviour? or a bug?
Thanks
--
Jeevan B Chalke
EnterpriseDB Software India Private Limited, Pune
Visit us at: www.enterprisedb.com
---
If better is possible, then good is not enough
Re: [HACKERS] Streaming Replication patch for CommitFest 2009-09
Hi, On Fri, Sep 18, 2009 at 2:47 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Heikki Linnakangas wrote: I'm thinking that walreceiver should be a stand-alone program that the startup process launches, similar to how it invokes restore_command in PITR recovery. Instead of using system(), though, it would use fork+exec, and a pipe to communicate. Here's a WIP patch to do that, over your latest posted patch. I've also pushed this to my git repository at git://git.postgresql.org/git/users/heikki/postgres.git, replication branch. In my environment, I cannot use git protocol for some reason. Could you export your repository so that it can be accessed also via http? BTW, I seem to be able to access http://git.postgresql.org/git/bucardo.git. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-http How should we advance development of SR? Should I be concentrated on the primary side, and leave the standby side to you? When I change something, should I make a patch for the latest SR source in your git repo, and submit it? 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] Streaming Replication patch for CommitFest 2009-09
Fujii Masao wrote: Hi, On Fri, Sep 18, 2009 at 2:47 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Heikki Linnakangas wrote: I'm thinking that walreceiver should be a stand-alone program that the startup process launches, similar to how it invokes restore_command in PITR recovery. Instead of using system(), though, it would use fork+exec, and a pipe to communicate. Here's a WIP patch to do that, over your latest posted patch. I've also pushed this to my git repository at git://git.postgresql.org/git/users/heikki/postgres.git, replication branch. In my environment, I cannot use git protocol for some reason. Could you export your repository so that it can be accessed also via http? Sure, it should be accessible via HTTP as well: http://git.postgresql.org/git/users/heikki/postgres.git How should we advance development of SR? Should I be concentrated on the primary side, and leave the standby side to you? When I change something, should I make a patch for the latest SR source in your git repo, and submit it? Hmm, yeah, let's do that. Right now, I'm trying to understand the page boundary stuff and partial page handling in ReadRecord and walsender. -- 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] Streaming Replication patch for CommitFest 2009-09
Hi, On Thu, Sep 17, 2009 at 5:08 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: I'm thinking that walreceiver should be a stand-alone program that the startup process launches, similar to how it invokes restore_command in PITR recovery. Instead of using system(), though, it would use fork+exec, and a pipe to communicate. This approach is OK if the stand-alone walreceiver is treated steadily by the startup process like a child process under postmaster: * Handling of some interrupts: SIGHUP, SIGTERM?, SIGINT, SIGQUIT... For example, the startup process would need to rethrow walreceiver the interrupt from postmaster. * Communication with other child processes: stats collector? syslogger?... For example, the log message generated by walreceiver should also be collected by syslogger if requested. For now, I think that pipe is enough for communication between the startup process and walreceiver. Though there was the idea to pass XLOG to the startup process via wal_buffers, in which pipe is not suitable, I think that is overkill. 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] happy birthday Tom Lane ...
Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Best regards, Hans-Jürgen Schönig + team -- Cybertec Schoenig Schoenig GmbH Reyergasse 9 / 2 A-2700 Wiener Neustadt Web: www.postgresql-support.de -- 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] happy birthday Tom Lane ...
In response to Hans-Juergen Schoenig -- PostgreSQL : Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. +1 -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) -- 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] happy birthday Tom Lane ...
On Fri, 2009-09-18 at 13:04 +0200, Hans-Juergen Schoenig -- PostgreSQL wrote: On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Assuming that we have only one Tom Lane (i.e., he is not clustered yet), Happy birthday from here, too :) -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
Re: [HACKERS] happy birthday Tom Lane ...
Hans-Juergen Schoenig -- PostgreSQL postg...@cybertec.at wrote: Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Alright, Tom ... I'm in the area, when/where's the party? ;) In any event, happy birthday. -- Bill Moran http://www.potentialtech.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] [PATCH] DefaultACLs
Petr Jelinek wrote: So I've been working on solution with which I am happy with (does not mean anybody else will be also though). Hi Petr, I'm reviewing this patch and after reading it I have some comments. Unfortunately, when I got to the compiling part, it turned out that the attached patch is missing src/include/catalog/pg_default_acls.h (or is it just me?). I'll continue reviewing while waiting for a new patch with that header file and in any case will send the full review tommorrow. Cheers, Jan -- 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] happy birthday Tom Lane ...
Hans-Juergen Schoenig -- PostgreSQL wrote: Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Best regards, Hans-Jürgen Schönig + team Happy 30th Tom ;) -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.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] happy birthday Tom Lane ...
Happy birthday Tom, from the sunny island of Singapore. :-) Regards, Khee Chin. On Fri, Sep 18, 2009 at 7:04 PM, Hans-Juergen Schoenig -- PostgreSQL postg...@cybertec.at wrote: Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Best regards, Hans-Jürgen Schönig + team -- Cybertec Schoenig Schoenig GmbH Reyergasse 9 / 2 A-2700 Wiener Neustadt Web: www.postgresql-support.de -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- 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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 8:09 AM, Andrew Chernow a...@esilo.com wrote: Hans-Juergen Schoenig -- PostgreSQL wrote: Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Best regards, Hans-Jürgen Schönig + team Happy 30th Tom ;) so that's where he gets his energy... (happy birthday) 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] Rename StrNCpy to avoid conflictions on win32
Peter Eisentraut wrote: On Mon, 2009-09-07 at 11:36 +0200, Magnus Hagander wrote: On Mon, Sep 7, 2009 at 04:40, Itagaki Takahiroitagaki.takah...@oss.ntt.co.jp wrote: There might be some places to replace it to strlcpy() instead. Can't comment on that without looking at the code, but it wouldn't surprise me. There are some performance tradeoffs between these variants, and we already did change all (most?) of the not performance-critical calls to strlcpy a while ago. Of all the macro names we use, I would have bet StrNCpy() was the last one that would have conflicted with anything. :-O Did they copy it from our code? -- 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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 7:11 AM, A. Kretschmer andreas.kretsch...@schollglas.com wrote: In response to Hans-Juergen Schoenig -- PostgreSQL : Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. +1 Of all the responses so far I like this one the best. +1 from me, 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: Easier to translate psql help Instead of requiring translators
pet...@postgresql.org (Peter Eisentraut) writes: Log Message: --- Easier to translate psql help Looks like this broke the msvc build ... 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 0.2.1
Robert Haas robertmh...@gmail.com writes: Also, stepping back from me personally, should we try to assign some additional reviewers to these patches? Is there some way we can divide up review tasks among multiple people so that we're not repeating each others work? Thoughts appreciated, from Heikki, Simon, or others. How about this proposal: http://archives.postgresql.org/pgsql-hackers/2009-08/msg00764.php Regards, -- dim -- 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 0.2.1
On Tue, Sep 15, 2009 at 2:41 PM, Simon Riggs si...@2ndquadrant.com wrote:
OK, here is the latest version of the Hot Standby patchset. This is
about version 30+ by now, but we should regard this as 0.2.1
Patch against CVS HEAD (now): clean apply, compile, no known bugs.
Hi Simon,
Is there a reason that you remove the WAL_DEBUG shown below?
*** begin:;
*** 899,923
FIN_CRC32(rdata_crc);
record-xl_crc = rdata_crc;
- #ifdef WAL_DEBUG
- if (XLOG_DEBUG)
- {
- StringInfoData buf;
-
- initStringInfo(buf);
- appendStringInfo(buf, INSERT @ %X/%X: ,
-RecPtr.xlogid,
RecPtr.xrecoff);
- xlog_outrec(buf, record);
- if (rdata-data != NULL)
- {
- appendStringInfo(buf, - );
- RmgrTable[record-xl_rmid].rm_desc(buf,
record-xl_info, rdata-data);
- }
- elog(LOG, %s, buf.data);
- pfree(buf.data);
- }
- #endif
-
/* Record begin of record in appropriate places */
ProcLastRecPtr = RecPtr;
Insert-PrevRecord = RecPtr;
--- 947,952
Thanks,
Jeff
Re: [HACKERS] happy birthday Tom Lane ...
Hans-Juergen Schoenig -- PostgreSQL postg...@cybertec.at writes: Tom, happy birthday. +1 from me :) Regards, -- dim -- 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] happy birthday Tom Lane ...
Happy nice birthday Tom Lane On Fri, Sep 18, 2009 at 10:36 AM, Robert Haas robertmh...@gmail.com wrote: On Fri, Sep 18, 2009 at 7:11 AM, A. Kretschmer andreas.kretsch...@schollglas.com wrote: In response to Hans-Juergen Schoenig -- PostgreSQL : Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. +1 Of all the responses so far I like this one the best. +1 from me, 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 -- Marcelo Costa www.marcelocosta.net - “You can't always get what want”, Doctor House in apology to Mike Jagger
Re: [HACKERS] Hot Standby 0.2.1
On Fri, 2009-09-18 at 07:23 -0700, Jeff Janes wrote: On Tue, Sep 15, 2009 at 2:41 PM, Simon Riggs si...@2ndquadrant.com wrote: OK, here is the latest version of the Hot Standby patchset. This is about version 30+ by now, but we should regard this as 0.2.1 Patch against CVS HEAD (now): clean apply, compile, no known bugs. Is there a reason that you remove the WAL_DEBUG shown below? WAL_DEBUG is not removed by the patch, though that section of code is removed, as you observe. I recall an earlier bug report by me/conversation on hackers about how that section of code was irrecoverably broken, since it's calling an rmgr routine while not in recovery and also assuming the data is fully accessible at that point, which it is not. -- 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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 4:04 AM, Hans-Juergen Schoenig -- PostgreSQL postg...@cybertec.at wrote: Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. In short, +1 from me. :) -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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 0.2.1
Simon Riggs si...@2ndquadrant.com writes: On Fri, 2009-09-18 at 07:23 -0700, Jeff Janes wrote: Is there a reason that you remove the WAL_DEBUG shown below? WAL_DEBUG is not removed by the patch, though that section of code is removed, as you observe. I recall an earlier bug report by me/conversation on hackers about how that section of code was irrecoverably broken, since it's calling an rmgr routine while not in recovery and also assuming the data is fully accessible at that point, which it is not. Wouldn't it be sufficient to remove the rm_desc() call? I agree that that's broken, but the rest doesn't seem to be. 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] numeric_to_number() function skipping some digits
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
With PG84, I have tried something like this which seem incorrect to me.
# SELECT '' AS to_number_2, to_number('-347,58', '99G999');
Well, the input doesn't actually match the format, so I'm not totally
excited about this. You do get sane results from:
regression=# select to_number('-347,58', '999G99');
to_number
---
-34758
(1 row)
Should we have it throw an error if the input corresponding to a G
symbol doesn't match the expected group separator? I'm concerned that
that would break applications that work okay today.
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 0.2.1
On Fri, 2009-09-18 at 11:14 -0400, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: On Fri, 2009-09-18 at 07:23 -0700, Jeff Janes wrote: Is there a reason that you remove the WAL_DEBUG shown below? WAL_DEBUG is not removed by the patch, though that section of code is removed, as you observe. I recall an earlier bug report by me/conversation on hackers about how that section of code was irrecoverably broken, since it's calling an rmgr routine while not in recovery and also assuming the data is fully accessible at that point, which it is not. Wouldn't it be sufficient to remove the rm_desc() call? I agree that that's broken, but the rest doesn't seem to be. That would make sense also. Previous action just because that was earlier consensus. Will change. -- 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] [PATCH] pgbench: new feature allowing to launch shell commands
On Fri, Sep 18, 2009 at 03:10:14PM +0900, Michael Paquier wrote: You really should be returning a value at the point since the function signature defines a return type. If not the function should be void, which it cannot be in this context since it is used for boolean tests elsewhere. The returns in question are all part of error blocks and should return false. OK I got your point, I missed the part managing with CState, which is tested after doCustom. Another version of the patch is attached with this email. I must be doing something wrong when I am running this script. It is still throwing errors. Would you mind showing me the pgbench command you used to run it? Of course, here it is the list of commands I use: pgbench -i dbname (in case your database is called dbname) pgbench -c 10 -t 10 -f transaction_file_name.data dbname (customer and transaction numbers can also bet set as you want). Regards, -- Michael Paquier NTT OSSC OK, thank you for sending me the patch and the relivent commands. You're still not returning false where you should be, but that wasn't the issue I am seeing. I believe there is an issue in either the custom script you posted on the wiki or pgbench itself. Here is the script I am running, you might recongnize it :) \set nbranches :scale \set ntellers 10 * :scale \set naccounts 10 * :scale \setrandom aid 1 :naccounts \setrandom bid 1 :nbranches \setrandom tid 1 :ntellers \setrandom delta -5000 5000 \setrandom txidrand 0 1 START TRANSACTION; UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid; SELECT abalance FROM pgbench_accounts WHERE aid = :aid; SELECT abalance FROM pgbench_accounts WHERE aid = :aid; UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid; UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid; INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); PREPARE TRANSACTION ':txidrand'; \shell ls -ll /tmp/log_data`date '+%Y%m%d'`_`date '+%k%M'` COMMIT PREPARED ':txidrand'; So I get this output with and with out the shell command in there, against the unpatched and patched version on pgbench. The commands you sent will not work with this script since it is using prepared statements. I am using this command to run the script. ./contrib/pgbench/pgbench -c 10 -j 2 -M prepared -f custom.script test From which, I get the following output: starting vacuum...end. Client 0 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 1 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 2 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 5 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 8 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 6 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 7 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 3 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 4 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 Client 9 aborted in state 15: ERROR: bind message supplies 1 parameters, but prepared statement P0_15 requires 0 transaction type: Custom query scaling factor: 1 query mode: prepared number of clients: 10 number of threads: 2 number of transactions per client: 10 number of transactions actually processed: 0/100 tps = 0.00 (including connections establishing) tps = 0.00 (excluding connections establishing) Since it occurs on both versions, I'm having some trouble identifying whether this is a bug in the script or a bug in pgbench. Any help is appreciated. -- --Dan -- 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] Schedule for 8.5 Development
Bruce, CF1 7/15 to 8/14 Alpha1 by 8/20 CF2 9/15 to 10/14 Alpha2 by 10/20 CF3 11/15 to 12/14 Alpha3 by 11/20 CF4 1/15 to 2/14 Alpha4 by 2/20 Beta1est. 3/1 to 3/7 Release June, depending on bugs I think that June release date is realistic. Are we ready to put this up on /developer then and make it real? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.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] generic copy options
On 9/17/09 3:54 PM, Greg Smith wrote: On Thu, 17 Sep 2009, Dan Colish wrote: - Performance appears to be the same although I don't have a good way for testing this at the moment Here's what I do to generate simple COPY performance test cases: Is there any reason to think that *this* copy patch will affect performance at all? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.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] updated join removal patch
Robert Haas robertmh...@gmail.com writes: On Thu, Sep 17, 2009 at 4:59 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: You're the committer; I'm not. But I completely disagree. There isn't any reason at all to duplicate this logic in two separate places, let alone three. I'd actually be in favor of merging the existing two cases even if we weren't adding join removal. No, I still think this was a bad idea. There are *parts* of those tests that are similar, but combining them all into one function is just a recipe for bugs. Having read your commit, it makes more sense to me. The fact that we're now looking at innerrel-baserestrictinfo also is a pretty powerful argument for your way. Looking at it some more, I think that there is some value in factoring out the tests to see if the clause has the right variable membership, so I did that. 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] generic copy options
On Fri, Sep 18, 2009 at 10:21:08AM -0700, Josh Berkus wrote: On 9/17/09 3:54 PM, Greg Smith wrote: On Thu, 17 Sep 2009, Dan Colish wrote: - Performance appears to be the same although I don't have a good way for testing this at the moment Here's what I do to generate simple COPY performance test cases: Is there any reason to think that *this* copy patch will affect performance at all? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com Nope, but it was on the checklist and I was being thorough. -- Dan -- 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] generic copy options
Nope, but it was on the checklist and I was being thorough. That's a good thing. I was just seeing if I needed to get involved in performance testing. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.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] Draft for organized beta testing
Please comment on the draft if you see anything I'm missing; otherwise I'll start the call for testers as soon as Alpha2 comes out. Would help if I had a link, eh? http://wiki.postgresql.org/wiki/HowToBetaTest -- 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] Schedule for 8.5 Development
Josh Berkus wrote: Bruce, CF17/15 to 8/14 Alpha1 by 8/20 CF29/15 to 10/14 Alpha2 by 10/20 CF311/15 to 12/14 Alpha3 by 11/20 CF41/15 to 2/14 Alpha4 by 2/20 Beta1 est. 3/1 to 3/7 Release June, depending on bugs I think that June release date is realistic. Are we ready to put this up on /developer then and make it real? Sure. -- 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] generic copy options
On Fri, Sep 18, 2009 at 10:31:21AM -0700, Josh Berkus wrote: Nope, but it was on the checklist and I was being thorough. That's a good thing. I was just seeing if I needed to get involved in performance testing. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com I always say, the more tests the better. From the tests I ran it was clear the parser did not change speed. Might be good to have someone confirm that. -- Dan -- 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] updated join removal patch
On Fri, Sep 18, 2009 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Thu, Sep 17, 2009 at 4:59 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: You're the committer; I'm not. But I completely disagree. There isn't any reason at all to duplicate this logic in two separate places, let alone three. I'd actually be in favor of merging the existing two cases even if we weren't adding join removal. No, I still think this was a bad idea. There are *parts* of those tests that are similar, but combining them all into one function is just a recipe for bugs. Having read your commit, it makes more sense to me. The fact that we're now looking at innerrel-baserestrictinfo also is a pretty powerful argument for your way. Looking at it some more, I think that there is some value in factoring out the tests to see if the clause has the right variable membership, so I did that. Mmm, I like that. Putting that bunch of hairy logic in a subroutine instead of repeating it in several places definitely seems better. I don't really like the name clause_matches_join, though. It's more like clause has well-defined sides, and mark which is which as a side-effect. ...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] generic copy options
Josh Berkus wrote: Nope, but it was on the checklist and I was being thorough. That's a good thing. I was just seeing if I needed to get involved in performance testing. That would be good to have more people test the autopartitioning feature in COPY. If you want to be involved in performance testing on that, that would be great. Emmanuel -- Emmanuel Cecchet Aster Data Systems Web: http://www.asterdata.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] updated hstore patch
On Sep 15, 2009, at 8:31 PM, Andrew Gierth wrote:
Gah. rerolled to fix a missing file. includes the docs too this time.
Yay, thank you Andrew! Here are my review notes.
Testing
===
Here's what I did to try out the patch, paying special attention to in-
place upgrading:
* I built a simple database with a table with an (old) hstore column
from an unpatched Git checkout.
* I ran the script I developed for testing the previous patch in July,
commenting out the new features, just to test the existing
implementation.
* I applied your patch, rebuilt hstore, installed the DSO, and
restarted PotgreSQL. I did *not* dump the previous database or restore
it, I just just used the existing cluster. The only thing that changed
was the new hstore.
* I ran the hstore `make installcheck` and all tests passed.
* I ran the following to update the SQL functions in my simple database:
psql -d try --set hstore_xact='--' -f hstore.sql
The use of `--set hstore_xact='--' was on Andrew's advice via IRC,
because otherwise the entire update takes place in a single
transaction, and thus would fail since I already had the old hstore
installed. By using this psql variable hack to disable the
transactions, I was able to install over the old hstore.
* I connected to my simple database and did a select on the table I
created before installing the new hstore, and all the old data showed
up fine in psql.
* I uncommented the new stuff in my test script (attached) and ran it.
Everything worked as I expected.
Notes and minor issues:
* `hstore - hstore` resolves before `hstore - text`, meaning that this
failed:
SELECT 'a=1, b =2'::hstore - 'a' = 'b=2';
ERROR: Unexpected end of string
LINE 1: SELECT 'a=1, b =2'::hstore - 'a' = 'b=2';
But it works if I cast it:
SELECT 'a=1, b =2'::hstore - 'a'::text = 'b=2';
Not sure if there's anything to be done about that. I mentioned this
issue back in July, as well.
* Maybe it's time to kill off `...@` and `~`, eh? Or could they generate
warnings for a release or something? How are operators properly
deprecated?
* The documentation for `populate_record()` is wrong. It's still just
a cut-and-paste of `delete()`
* The NOTE about `populate_record()` says that it takes anyelement
instead of record and just throws an error if it's not a record. I
thought that C functions could take record arguments. Why do the extra
work here?
* Your original submission say that the new version offers btree and
hash support, but the docs still mention only GIN and GIST.
* I'd like to see more examples of the new functionality in the
documentation. I'd be happy to contribute them once the main patch is
committed.
* I think that there should be some exmples in the docs of the use of
the backslash with and without standard_conforming_strings and with
and without E''. That stuff is confusing enough, it should all be
spelled out, IMHO.
* The use of the `:hstore_xact` variable hack needs to be documented,
along with detailed instructions for those upgrading (in-place) from
8.4. You might consider documenting your `:hstore_default_schema`
variable as well: if I understand correctly, it's a way to specify a
schema on the command-line without having to edit the file, yes?
Currently, there are no installation instructions in the documentation.
Comments
* So the main objection to the original patch from the July
CommitFest, that it wasn't backwards compatible, seems to have been
addressed, assuming that the structure currently used in HEAD is just
like what's in 8.4, so in-place upgrade should work, yes? It apears
that you've taken the approach, in hstore_compat.c, of reading both
the old and the new formats. Does it also upgrade the old formats as
it reads them, or only as they're updated? (I'm assuming the latter.)
* I'm not qualified to talk about the approach taken to maintaining
compatibility, but would like to know if it imposes an overhead on the
use of the data type, and if so, how much?
* Also, just as an aside, I'm wondering if the approach you've taken
could be used for core data types going forward, so as to work towards
true in-place upgrades in the future?
* Regarding the bug you found in the old hstore format (mentioned
[here](http://archives.postgresql.org/pgsql-hackers/2009-07/msg01422.php)
), has that been fixed? Is it a regression that should be back-patched?
* Does there need to be documentation with upgrade instructions for
hstore-new users (the pgFoundry version)? Or will you handle that via
a new pgFoundry release?
* In addition to the functions to get all the keys and all the values
as arrays, I'd love a function (or, dare I say, a cast?) to get all
the rows and keys in an array. Something like this:
try=# select 'a = 1, b = 2'::hstore::text[];
array
---
{a,1,b,2}
I'd find this
Re: [HACKERS] Draft for organized beta testing
Would help if I had a link, eh? http://wiki.postgresql.org/wiki/HowToBetaTest It would also help if the mail servers cleared my original e-mail. Gr. Here's what I posted originally, which our servers have decided to eat: I'm about to launch on a program of organized alpha and beta testing by volunteers from our community. Initially, tests will be logged either by e-mail parsing on the pgsql-testers mailing list, or by a web-based Radix interface if I can get one up. Please comment on the draft if you see anything I'm missing; otherwise I'll start the call for testers as soon as Alpha2 comes out. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.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] updated join removal patch
Robert Haas robertmh...@gmail.com writes: Mmm, I like that. Putting that bunch of hairy logic in a subroutine instead of repeating it in several places definitely seems better. I don't really like the name clause_matches_join, though. It's more like clause has well-defined sides, and mark which is which as a side-effect. It was the first thing that came to mind ... got a better idea? 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] updated join removal patch
On Fri, Sep 18, 2009 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Mmm, I like that. Putting that bunch of hairy logic in a subroutine instead of repeating it in several places definitely seems better. I don't really like the name clause_matches_join, though. It's more like clause has well-defined sides, and mark which is which as a side-effect. It was the first thing that came to mind ... got a better idea? clause_has_well_defined_sides()? ...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] Unicode UTF-8 table formatting for psql text output
Hi!
Below is from Brad Slinger. I'm just forwarding his message so that
the review will be in the thread for the archives. (Sorry, Brad that I
missed this earlier.. I thought you'd already replied to the list for
some reason.)
Brad says:
Please forgive my top posting. Below is my patch review.
The purpose of this patch is to improve psql output
readability. This is accomplished through table formatting
improvements and line art improvements.
The patch is a unified diff, rather than a context diff. The
patch applies from the project root with with -p1 set. Patch(1)
reports with fuzz 1 when patching src/bin/psql/print.h. The patch
touches two files:
src/bin/psql/print.h
src/bin/psql/print.c
The patch does not include any documentation or tests.
Comments and style are similar to existing code.
The patched code compiles without any additional warnings.
Lint gripes about a trailing ',' in 'typedef enum printTextRule' in
print.h. Other additional lint seem to be false positives. The
regression tests pass against the new patch.
The patched code installs and runs. There were no crashes,
although I didn't try very hard. The ASCII line art works:
createdb test
psql test
\pset border 2
\pset format wrapped
SELECT 'short' AS short, lpad('', 1000, 'long') AS long;
I can trigger the new line art by setting LC_ALL=en_US.UTF-8 in
the environment.
As far as I can tell, the patch works as advertised. The patch
does not change the server/backend. I don't see any performance
problems.
Thanks,
--bts
--
http://chesnok.com/daily - me
http://endpoint.com - work
--
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] Lock Wait Statistics (next commitfest)
I have this patch, if you're interested. LWLock Instrumentation Patch - counts locks and waits in shared and exclusive mode - for selected locks, measures wait and hold times - for selected locks, displays a histogram of wait and hold times - information is printed at backend exit Configurable by #define's in lwlock.c Regards, pierre lwlock_instrument_v4.patch Description: Binary data -- 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] Lock Wait Statistics (next commitfest)
Pierre, Configurable by #define's in lwlock.c Given that we already have dtrace/systemtap probes around the lwlocks, is there some way you could use those instead of extra #defines? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.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] Join optimization for inheritance tables
Herodotos Herodotou herodotos.herodo...@asterdata.com writes: This patch extends the query optimizer to consider joins between child tables when hierarchies are joined together. I looked over this patch a bit. I am of the opinion that this is a lot of work towards a dead-end direction :-(. The patch contains a large amount of rather inefficient code that attempts to reverse-engineer knowledge about whether an inheritance tree forms a range-partitioned table. We already know that reasoning from first principles using a set of arbitrary per-table constraints doesn't scale very well, and this would make it a lot worse. pgsql-hackers have been talking for some time about implementing an explicit partitioning feature, which would give the planner direct knowledge about this type of table structure without expending nearly so much work (and then expending it all over again for the next query). I think the right way to go at it is to implement that first, and then see about teaching the planner to plan like this. We could possibly extract a subset of the patch that just deals with pushing joins down through appends, without the constraint-exclusion logic that tries to eliminate provably empty join pairs. But I'm dubious that that would be worthwhile by itself. I think you need the constraint exclusion to eliminate a good deal of work before this is actually better than doing a single join above the append. There are a number of other things I don't like, such as the restrictive and not-obviously-necessary requirement that all the join clauses be simple Var op Var clauses. But the main thing is that a large fraction of the patch is doing something I don't think we should try to do. 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] updated join removal patch
Robert Haas robertmh...@gmail.com writes:
On Fri, Sep 18, 2009 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Mmm, I like that. Putting that bunch of hairy logic in a subroutine
instead of repeating it in several places definitely seems better. I
don't really like the name clause_matches_join, though.
It was the first thing that came to mind ... got a better idea?
clause_has_well_defined_sides()?
Nah ... they're well defined in any case, they might just not be what
we need for the current join. As an example,
(a.f1 + b.f2) = c.f3
would be usable if joining {A B} to {C}, but not when joining
{A} to {B C}.
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] FSM search modes
On Thu, 2009-09-17 at 16:26 +0100, Simon Riggs wrote: Just been looking again at the way FSM works. In fsm_search_avail() we essentially have just a single way for working out how to search the tree. Seems like it would be good to abstract this so that we can implement a number of FSM search strategies * (current) randomize - page selection encourages different backends to access different blocks, thus reducing block contention * cluster - page selection made based around selecting block with freespace nearest current block and we prefer keep-in-sequence to avoid-contention Is the information about current block available to FSM search API, or do we need to change the API for that ? * compact - page selection specifically attempts to find the lowest numbered blocks, so that the table will naturally shrink over time. These are not all mutually exclusive, suggested combinations would be randomize, randomize | cluster, randomize | compact So we don't give up the load spreading behaviour, we just apply the logic at lower levels of the tree only. VACUUM could set the FSM into FSMstrategy = compact when it notices that most of the free blocks are at lower end of table. Or explicitly set during VF replacement utility. FSMstrategy = cluster would be the default if clustering is enabled on a table. FSMstrategy can change via ALTER TABLE ... WITH (fsm_strategy = ...) -- Simon Riggs www.2ndQuadrant.com -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- 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] happy birthday Tom Lane ...
On Fri, 2009-09-18 at 16:24 +0200, Dimitri Fontaine wrote: Hans-Juergen Schoenig -- PostgreSQL postg...@cybertec.at writes: Tom, happy birthday. +1 from me :) +1 from me too :D Regards, -- dim -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- 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] updated join removal patch
On Fri, Sep 18, 2009 at 3:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Sep 18, 2009 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Mmm, I like that. Putting that bunch of hairy logic in a subroutine
instead of repeating it in several places definitely seems better. I
don't really like the name clause_matches_join, though.
It was the first thing that came to mind ... got a better idea?
clause_has_well_defined_sides()?
Nah ... they're well defined in any case, they might just not be what
we need for the current join. As an example,
(a.f1 + b.f2) = c.f3
would be usable if joining {A B} to {C}, but not when joining
{A} to {B C}.
The clauses are well-defined, but they don't have well-defined sides.
I see now what you're going for with clause_matches_join, but
matches is a pretty broad term, IMO.
...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] updated join removal patch
Robert Haas robertmh...@gmail.com writes: The clauses are well-defined, but they don't have well-defined sides. I see now what you're going for with clause_matches_join, but matches is a pretty broad term, IMO. clause_sides_match_join? 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] TODO item: Allow more complex user/database default GUC settings
--On 25. August 2009 22:17:38 -0400 Alvaro Herrera alvhe...@commandprompt.com wrote: I'm just posting in case somebody has thoughts on the UI part of it. Other things that need fixed: - need to figure out locking for roles; this stuff must be synchronized with role drop - pg_shadow and pg_roles need a join to obtain settings - two regression tests need their expected file updated - catalog version bump Here's a first shot on this for my current review round. Patch needed to re-merged into current CVS HEAD due to some merge conflicts, i've also adjusted the regression tests (minor). On a first look, i like the patch (especially the code for the utility commands accessing the settings is better modularized now, which looks much nicer). -- Thanks Bernd complex_guc_review_v1.patch Description: Binary data -- 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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 01:04:23PM +0200, Hans-Juergen Schoenig -- PostgreSQL wrote: Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Best regards, Hans-Jürgen Schönig + team +1 from me too. -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Anonymous code blocks (was: Re: [HACKERS] GRANT ON ALL IN schema)
Hi Dimitri, The commitfest app has you listed as the reviewer for this patch. Any progress on your review? Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Anonymous code blocks (was: Re: [HACKERS] GRANT ON ALL IN schema)
Brendan Jurd dire...@gmail.com writes: The commitfest app has you listed as the reviewer for this patch. Any progress on your review? Funny I just sent a mail to rrr explaining I don't think I'll be able to complete my review until next Thursday. Feel free to steal me the patch if you want to, as I'm planning to start on Monday only... Regards, -- dim -- 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] numeric_to_number() function skipping some digits
2009/9/19 Tom Lane t...@sss.pgh.pa.us:
Should we have it throw an error if the input corresponding to a G
symbol doesn't match the expected group separator? I'm concerned that
that would break applications that work okay today.
It would be a substantial change to the behaviour, and to do it
properly we'd have to change to_date() to actually parse separator
characters as well.
That is, you can currently write to_date('2009/09/19', '-MM-DD')
-- it doesn't matter what the separator characters actually look like,
since per the format pattern they cannot affect the date outcome.
This naturally leads to the question we always have to ask with these
functions: What Does Oracle Do?
But FWIW, a -1 from me for changing this.
Cheers,
BJ
--
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] updated join removal patch
On Fri, Sep 18, 2009 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: The clauses are well-defined, but they don't have well-defined sides. I see now what you're going for with clause_matches_join, but matches is a pretty broad term, IMO. clause_sides_match_join? Yes, that's perfect. ...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] happy birthday Tom Lane ...
daveg wrote: On Fri, Sep 18, 2009 at 01:04:23PM +0200, Hans-Juergen Schoenig -- PostgreSQL wrote: Tom, On behalf of the entire PostgreSQL team here in Austria I want to wish you a happy birthday. We hope that you fill be a vital part of PostgreSQL for many years to come. Best regards, Hans-Jürgen Schönig + team +1 from me too. I generally hate to do me too, but in this case it is well justified :-) +1 Joe signature.asc Description: OpenPGP digital signature
Re: [HACKERS] patch: Review handling of MOVE and FETCH (ToDo)
Hello 2009/9/18 Selena Deckelmann selenama...@gmail.com: Hi! John Naylor and I reviewed this patch. John created two test cases to demonstrated issues described later in this email. I've attached those for reference. On Thu, Aug 27, 2009 at 8:04 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello, this small patch complete MOVE support in plpgsql and equalize plpgsql syntax with sql syntax. There are possible new directions: FORWARD expr, FORWARD ALL, BACKWARD expr, BACKWARD all. These directions are not allowed for FETCH statement, because returns more rows. This patch is related to ToDo issue: Review handling of MOVE and FETCH == Submission review == * Is the patch in the standard form? Yes, we have a contextual diff! * Does it apply cleanly to the current CVS HEAD? Yes! * Does it include reasonable tests, docs, etc? Suggestion: change variable 'returns_row' to 'returns_multiple_rows' and invert the values of 'returns_row' in the patch. good idea - changed Example: if (!fetch-returns_row) ereport(ERROR, (errcode(ERRCODE_SYNTAX_ERROR), errmsg(statement FETCH returns more rows.), errhint(Multirows fetch are not allowed in PL/pgSQL.))); instead do: if (fetch-returns_multiple_rows) ereport(ERROR, (errcode(ERRCODE_SYNTAX_ERROR), errmsg(statement FETCH returns more than one row.), errhint(Multirow FETCH is not allowed in PL/pgSQL.))); Does that make sense? In reading the code, we thought this change made this variable much easier to understand, and the affected code much easier to read. === Need a hard tab here to match the surrounding code: :) + %token K_ALL$ fixed === Can you clarify this comment? + /* + * Read FETCH or MOVE statement direction. For statement for are only + * one row directions allowed. MOVE statement can use FORWARD [(n|ALL)], + * BACKWARD [(n|ALL)] directions too. + */ We think what you mean is: By default, cursor will only move one row. To MOVE more than one row at a time see complete_direction() fixed - I add new comment there - I am sure, so this comments needs some correction from native speakers - sorry, my English is bad still. We tested on Mac OS X and Linux (Ubuntu) === Also, the tests did not test what the standard SQL syntax would require. John created a test case that demonstrated that the current patch did not work according to the SQL spec. We used that to find a little bug in complete_direction() (see below!). == Usability review == Read what the patch is supposed to do, and consider: * Does the patch actually implement that? No -- we found a bug: Line 162 of the patch: + expr = read_sql_expression2(K_FROM, K_IN, Should be: + fetch-expr = read_sql_expression2(K_FROM, K_IN, grr fixed And you don' t need to declare expr earlier in the function. Once that's changed, the regression test needs to be updated for the expected result set. * Does it follow SQL spec, or the community-agreed behavior? It conforms with the already implemented SQL syntax once the 'fetch-expr' thing is fixed. * Have all the bases been covered? We think so, as long the documentation is fixed and the above changes are applied. Another thing John noted is that additional documentation needs to be updated for the SQL standard syntax, so that it no longer says that PL/PgSQL doesn't implement the same functionality. Thanks! -selena John -- http://chesnok.com/daily - me http://endpoint.com - work Thank You Pavel *** ./doc/src/sgml/plpgsql.sgml.orig 2009-08-27 17:14:26.926410144 +0200 --- ./doc/src/sgml/plpgsql.sgml 2009-09-18 22:44:45.267608075 +0200 *** *** 2656,2670 para The options for the replaceabledirection/replaceable clause are ! the same as for commandFETCH/, namely literalNEXT/, literalPRIOR/, literalFIRST/, literalLAST/, literalABSOLUTE/ replaceablecount/replaceable, literalRELATIVE/ replaceablecount/replaceable, ! literalFORWARD/, or ! literalBACKWARD/. Omitting replaceabledirection/replaceable is the same as specifying literalNEXT/. replaceabledirection/replaceable values that require moving --- 2656,2670 para The options for the replaceabledirection/replaceable clause are ! similar to commandFETCH/, namely literalNEXT/, literalPRIOR/, literalFIRST/, literalLAST/, literalABSOLUTE/ replaceablecount/replaceable, literalRELATIVE/ replaceablecount/replaceable, ! literalFORWARD/ optional replaceablecount/replaceable | literalALL/ /optional, or ! literalBACKWARD/ optional replaceablecount/replaceable | literalALL/ /optional. Omitting replaceabledirection/replaceable is the same as specifying literalNEXT/. replaceabledirection/replaceable values that require moving *** *** 2678,2683 --- 2678,2684 MOVE curs1; MOVE LAST FROM
Re: [HACKERS] [PATCH] DefaultACLs
Jan Urbański napsal(a): Petr Jelinek wrote: So I've been working on solution with which I am happy with (does not mean anybody else will be also though). Hi Petr, I'm reviewing this patch and after reading it I have some comments. Unfortunately, when I got to the compiling part, it turned out that the attached patch is missing src/include/catalog/pg_default_acls.h (or is it just me?). I'll continue reviewing while waiting for a new patch with that header file and in any case will send the full review tommorrow. Hmm looks like I forgot to git add that file in the new branch, sorry about that. Attached patch should have the missing file (otherwise it's same). -- Regards Petr Jelinek (PJMODOS) defacl-2009-09-18.diff.gz Description: Unix tar archive -- 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 0.2.1
I want to help on this area, but I need a mentor for this. For example, Heikki will be a excellent mentor for me. Following the theme, I think that we have to wide all questions for the process of the acceptance of a patch on the same way that you Simon. We could write new requirements with all these ideas. Don´t you think? Regards The hurry is enemy of the success: for that reason...Be patient Ing. Marcos L. Ortiz Valmaseda Línea Soporte y Despliegue Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD) Linux User # 418229 PostgreSQL User http://www.postgresql.org http://www.planetpostgresql.org/ http://www.postgresql-es.org/ - Mensaje original - De: Simon Riggs si...@2ndquadrant.com Para: Robert Haas robertmh...@gmail.com CC: Heikki Linnakangas heikki.linnakan...@enterprisedb.com, Josh Berkus j...@agliodbs.com, pgsql-hackers@postgresql.org Enviados: Jueves, 17 de Septiembre 2009 20:53:24 GMT -10:00 Hawai Asunto: Re: [HACKERS] Hot Standby 0.2.1 On Thu, 2009-09-17 at 19:01 -0400, Robert Haas wrote: I'm going to put the index-only scans aside for now to focus on hot standby and streaming replication. Both are big patches, so there's plenty of work in those two alone, and not only for me. What is the best way to attack this? Should I keep reviewing index-only scans so that you have feedback for when you get back to it, or should I move on to something else? If something else, does it make more sense for me to look at HS since I did a bit of work with a previous version, or would it be better for me to just pick one of the other patches from the CommitFest and work on that? Also, stepping back from me personally, should we try to assign some additional reviewers to these patches? Is there some way we can divide up review tasks among multiple people so that we're not repeating each others work? Thoughts appreciated, from Heikki, Simon, or others. I think this is a great opportunity to widen the pool of people contributing to reviews. I suggest the creation of a second group of people, performing round-robin testing of patches. These people would be able to verify * documentation matches implemented features (does it do what it says on the tin?) * usability of explicit features (do the features work well?) * usability gap of unimplemented features (what else do we need?) * are there any bugs? These questions are often quickly answered for smaller patches, but HS's scope mean that such a task properly executed could take a full week, if not longer. Second group of people are just as skilled Postgres people as reviewers, in some cases more so, apart from they have less detailed knowledge of the codebase. We have many such people and it would be good to encourage them to perform thorough reviews rather than tire kicking. I'm not sure that Heikki needs additional reviewers. He now has significant knowledge of the patch and is good at focusing on key aspects of the internals. Other code reviewers are welcome, of course. -- 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 -- 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] happy birthday Tom Lane ...
happy_birthday++; -- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove 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] happy birthday Tom Lane ...
On Sep 18, 2009, at 5:18 PM, Paul Matthews wrote: happy_birthday++; SELECT count( happy ) FROM birthday WHERE name ~ 'Tom Lane'; WARNING : condition stack overflow: INF Sigh, Rob smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan z...@cybertec.at wrote: Boszormenyi Zoltan írta: Okay, we implemented only the lock_timeout GUC. Patch attached, hopefully in an acceptable form. Documentation included in the patch, lock_timeout works the same way as statement_timeout, takes value in milliseconds and 0 disables the timeout. Best regards, Zoltán Böszörményi New patch attached. It's only regenerated for current CVS so it should apply cleanly. I'm getting segfaults, built in 32 bit linux with gcc bin/pg_ctl -D data start -l logfile -o --lock_timeout=5 Session 1: jjanes=# begin; BEGIN jjanes=# select * from pgbench_branches where bid=3 for update; bid | bbalance | filler -+--+ 3 | -3108950 | (1 row) Session 2: jjanes=# select * from pgbench_branches where bid=3 for update; ERROR: could not obtain lock on row in relation pgbench_branches jjanes=# select * from pgbench_branches where bid=3 for update; ERROR: could not obtain lock on row in relation pgbench_branches jjanes=# select * from pgbench_branches where bid=3 for update; ERROR: could not obtain lock on row in relation pgbench_branches jjanes=# set lock_timeout = 0 ; SET jjanes=# select * from pgbench_branches where bid=3 for update; Session 2 is now blocked Session1: jjanes=# commit; long pause server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. I just realized I should have built with asserts turned on. I'll do that tomorrow, but don't want to delay this info until then, so I am sending it now. Cheers, Jeff
[HACKERS] Draft for organized beta testing
Hackers, I'm about to launch on a program of organized alpha and beta testing by volunteers from our community. Initially, tests will be logged either by e-mail parsing on the pgsql-testers mailing list, or by a web-based Radix interface if I can get one up. Please comment on the draft if you see anything I'm missing; otherwise I'll start the call for testers as soon as Alpha2 comes out. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Crypto
Folks, Here's what came out for Mozilla, which, I hope you'll pardon my saying so, is a teensy tad more widely used than PostgreSQL has any plans to become. http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+Cleared+of+US+Export+Rules.htm I suggest that we start by putting secure hashing algorithms into the core distribution so, should MD5 ever break, we have real alternatives, and not done in a panic. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] updated hstore patch
David == David E Wheeler da...@kineticode.com writes:
David * I ran the following to update the SQL functions in my simple database:
Davidpsql -d try --set hstore_xact='--' -f hstore.sql
DavidThe use of `--set hstore_xact='--' was on Andrew's advice
Davidvia IRC, because otherwise the entire update takes place in
Davida single transaction, and thus would fail since I already
Davidhad the old hstore installed. By using this psql variable
Davidhack to disable the transactions, I was able to install
Davidover the old hstore.
I'm more than half inclined to take this bit out again. It made sense in the
context of the pgfoundry version, but it doesn't fit in so well for contrib.
(It's a concept I was testing on the pgfoundry version)
However, I would prefer to keep the ability to do this:
psql --set hstore_schema='myschema' -f hstore.sql dbname
The logic to do it is a bit ugly, but editing the file to set what schema to
use is even uglier...
David Notes and minor issues:
David * `hstore - hstore` resolves before `hstore - text`, meaning
David that this failed:
The '-' operator did not previously exist so this isn't a compatibility issue.
BUT the delete(hstore,text) function did previously exist, however it seems to
still be resolved in preference to delete(hstore,hstore) when the second arg
is a bare text literal:
contrib_regression=# explain verbose select delete(('a' = now()::text),'a');
QUERY PLAN
---
Result (cost=0.00..0.02 rows=1 width=0)
Output: delete(('a'::text = (now())::text), 'a'::text)
(2 rows)
contrib_regression=# explain verbose select delete(('a' =
now()::text),'a=1'::hstore);
QUERY PLAN
Result (cost=0.00..0.02 rows=1 width=0)
Output: delete(('a'::text = (now())::text), 'a=1'::hstore)
(2 rows)
The only open question I can see is what delete(hs,$1) resolves to when $1 is
an unknown-type placeholder; this is probably an incompatibility with the old
version if anyone is relying on that (but I don't see why they would be).
David * Maybe it's time to kill off `...@` and `~`, eh? Or could they
David generate warnings for a release or something? How are
David operators properly deprecated?
David * The documentation for `populate_record()` is wrong. It's
David still just a cut-and-paste of `delete()`
GAH. I fixed some doc issues (stray s) but forgot that one. I'll fix it.
David * The NOTE about `populate_record()` says that it takes
David anyelement instead of record and just throws an error if it's
David not a record. I thought that C functions could take record
David arguments. Why do the extra work here?
Because record doesn't express the fact that the return type of
populate_record is the SAME record type as its parameter type, whereas
anyelement does.
David * Your original submission say that the new version offers
David btree and hash support, but the docs still mention only GIN
David and GIST.
I'll fix that.
David * I'd like to see more examples of the new functionality in
David the documentation. I'd be happy to contribute them once the
David main patch is committed.
Thanks. I'll do some (especially for populate_record, which really needs
them), but more can be added later.
David * I think that there should be some exmples in the docs of the
David use of the backslash with and without
David standard_conforming_strings and with and without E''. That
David stuff is confusing enough, it should all be spelled out, IMHO.
ugh. yeah
David * The use of the `:hstore_xact` variable hack needs to be
David documented,
(or removed, see above)
David along with detailed instructions for those upgrading
David (in-place) from 8.4. You might consider documenting your
David `:hstore_default_schema` variable as well: if I understand
David correctly, it's a way to specify a schema on the command-line
David without having to edit the file, yes? Currently, there are no
David installation instructions in the documentation.
ya.
David Comments
David
David * So the main objection to the original patch from the July
David CommitFest, that it wasn't backwards compatible, seems to have
David been addressed, assuming that the structure currently used in
David HEAD is just like what's in 8.4, so in-place upgrade should
David work, yes? It apears that you've taken the approach, in
David hstore_compat.c, of reading both the old and the new
David formats. Does it also upgrade the old formats as it reads
David them, or only as they're updated? (I'm assuming the latter.)
Old values are converted to new values in core, but they can't be
changed on-disk unless something actually updates them.
David * I'm not qualified to talk about the approach taken to
David maintaining
Re: [HACKERS] [PATCH] Largeobject access controls
Jamie, * Robert Haas (robertmh...@gmail.com) wrote: Jaime Casanova jcasa...@systemguards.com.ec - Largeobject access controls How is the review for this coming? Do you have any thoughts regarding the new GUC? Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCH] Largeobject access controls
On Fri, Sep 18, 2009 at 8:29 PM, Stephen Frost sfr...@snowman.net wrote: Jamie, How is the review for this coming? Do you have any thoughts regarding the new GUC? Hi, sorry... these have been hard days... i'm just starting reviewing -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- 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: Easier to translate psql help Instead of requiring translators
On Fri, 2009-09-18 at 09:46 -0400, Tom Lane wrote:
pet...@postgresql.org (Peter Eisentraut) writes:
Log Message:
---
Easier to translate psql help
Looks like this broke the msvc build ...
Yep, one of create_help.pl's arguments changed to not include the file
extension, but msvc was still trying to give it sql_help.h.
Quickpatch attached.
Wondered why my attempts to test and review another patch were suddenly
confounded...
regards, tom lane
- Josh Williams
Index: src/tools/msvc/Solution.pm
===
RCS file: /projects/cvsroot/pgsql/src/tools/msvc/Solution.pm,v
retrieving revision 1.47
diff -c -r1.47 Solution.pm
*** src/tools/msvc/Solution.pm 6 Jan 2009 18:37:50 - 1.47
--- src/tools/msvc/Solution.pm 19 Sep 2009 03:41:40 -
***
*** 235,241
{
print Generating sql_help.h...\n;
chdir('src\bin\psql');
! system(perl create_help.pl ../../../doc/src/sgml/ref sql_help.h);
chdir('..\..\..');
}
--- 235,241
{
print Generating sql_help.h...\n;
chdir('src\bin\psql');
! system(perl create_help.pl ../../../doc/src/sgml/ref sql_help);
chdir('..\..\..');
}
--
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] Crypto
David Do you can comment this altertatives or choices that we have? We can support us in Bruce Schneier[1], Chief Security Technology Officer, BT (schne...@schneier.com) who is one of the person that knows many topics about security in the world. Is a very nice person and allways is to able to help to people. One of his knowledge areas is the hashing algorithm's desing and study, and we can ask to him since his point of view which would be the best algoritm to do this. Regards [1] http://www.schneier.com The hurry is enemy of the success: for that reason...Be patient Ing. Marcos L. Ortiz Valmaseda Línea Soporte y Despliegue Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD) Linux User # 418229 PostgreSQL User http://www.postgresql.org http://www.planetpostgresql.org/ http://www.postgresql-es.org/ - Mensaje original - De: David Fetter da...@fetter.org Para: PG Hackers pgsql-hackers@postgresql.org Enviados: Viernes, 18 de Septiembre 2009 15:14:29 GMT -10:00 Hawai Asunto: [HACKERS] Crypto Folks, Here's what came out for Mozilla, which, I hope you'll pardon my saying so, is a teensy tad more widely used than PostgreSQL has any plans to become. http://www.internetnews.com/government/article.php/3839831/Mozilla+Firefox+Cleared+of+US+Export+Rules.htm I suggest that we start by putting secure hashing algorithms into the core distribution so, should MD5 ever break, we have real alternatives, and not done in a panic. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
