Re: [HACKERS] use less space in xl_xact_commit patch
int counts[1]; /* variable-length array of counts, xinfo flags define length of array and meaning of counts */ Damn, that's much cleaner than what I did. I don't know why I stuck with the idea that it had to be: int array int array ... instead of: int int ... array array ... which makes much more sense. Then, I'd make macros like this: #define XactCommitNumberOfDroppedRelFileNodes(xlrec) \ ((xlref-xinfo XACT_COMMIT_DROPPED_RELFILENODES) ? xlrec-counts[0] : 0) #define XactCommitNumberOfCommittedSubXids(xlrec) \ ((xlref-xinfo XACT_COMMITED_SUBXDIDS) ? xlrec-counts[(xlrec-xinfo XACT_COMMIT_DROPPED_RELFILENODES) ? 1 : 0] : 0) ...etc... ehm I don't know if macros would be enough; that's ok for the first 2, then I think it would become a mess... Maybe I'll use a simple function that gets all ints at once. ...and a similar set of macros that will return a pointer to the beginning of the corresponding array, if it's present. I'd lay out the record like this: - main record - array of counts (might be zero-length) - array of dropped relfilnodes (if any) - array of committed subxids (if any) - array of sinval messages (if any) ok Also, it's important not to confuse xact completion with xact commit, as I think some of your naming does. Completion could perhaps be thought to include abort. mmh... I don't know if I got it... but I'll give a look, and ask questions... Thank you very much for the help Leonardo -- 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] use less space in xl_xact_commit patch
this is a second version: now using intcounts[1]; /* variable-length array of counts */ in xl_xact_commit to keep track of number of different arrays at the end of the struct. Waiting for feedbacks... Leonardo commitlog_lessbytes00.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] Passing an array or record to a stored procedure in PostgreSQL
On Wed, May 18, 2011 at 12:40 AM, Max Bourinov bouri...@gmail.com wrote: Hi Highly Respected Hackers! I have a task to pass arrays, records and in some cases array of records as a parameter to the stored procedures in PostgreSQL. I will use JDBC to work with PostgreSQL 9.0 At first I would like to learn how to pass arrays. This is more of a question for the -general list than -hackers. The one way to pass arrays/reccords/etc that is guaranteed to work is to construct a text literal that postgres understands which represents the structures you would like to send. There might be simpler/better ways but that is mostly going to depend on the JDBC driver. 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] deprecating contrib for PGXN
Darren Duncan dar...@darrenduncan.net writes: Would now be a good time to start deprecating the contrib/ directory as a way to distribute Pg add-ons, with favor given to PGXN and the like instead? The first important fact is that contrib/ code is maintained by the PostgreSQL-core product team, and I guess they prefer to have it all in a single git repository. Some contribs are only there so that we know when we break extensibility features, so it would be bad to move them away. The other problem is that the facility we need to provide the most is binary distributions (think apt-get). Lots of site won't ever compile stuff on their production servers. So while PGXN is a good tool, it's not a universal answer. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] Why not install pgstattuple by default?
Greg Smith wrote: Attached is a second patch to move a number of extensions from contrib/ to src/test/. Extensions there are built by the default built target, making installation of the postgresql-XX-contrib package unnecessary for them to be available. That was supposed to be contrib/ to src/extension , no idea where that test bit came from. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- 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] switch UNLOGGED to LOGGED
By the time the startup process releases the AccessExclusiveLock acquired by the proposed UNLOGGED - normal conversion process, that relfilenode needs to be either fully copied or unlinked all over again. (Alternately, find some other way to make sure queries don't read the half-copied file.) About this issue: how are AccessExclusiveLocks released on the standby when the master crashes? -- 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] deprecating contrib for PGXN
On 05/18/2011 10:30 AM, Dimitri Fontaine wrote: Darren Duncan dar...@darrenduncan.net writes: Would now be a good time to start deprecating the contrib/ directory as a way to distribute Pg add-ons, with favor given to PGXN and the like instead? The first important fact is that contrib/ code is maintained by the PostgreSQL-core product team, and I guess they prefer to have it all in a single git repository. Some contribs are only there so that we know when we break extensibility features, so it would be bad to move them away. The other problem is that the facility we need to provide the most is binary distributions (think apt-get). Lots of site won't ever compile stuff on their production servers. So while PGXN is a good tool, it's not a universal answer. yeah moving contrib/ to pgxn will significantly reduce its usefulness - a lot of places have a policy that will allow stuff that is packaged by the OS-supplier (and that will include the contrib-package) but there is no way at all that they will allow something like pgxn or cpan or any other from source installation method. So by moving contrib somewhere else we will loose a lot of functionality in those scenarios. 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] Use of access(X_OK) check in pg_upgrade
I broke the Win32 build members by using access(X_OK) in pg_upgrade. I have a fix for this but looking at pg_upgrade's exec.c, I see for Win32: if ((buf.st_mode S_IXUSR) == 0) I am confused why Windows supports S_IXUSR but not X_OK. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] switch UNLOGGED to LOGGED
On Wed, May 18, 2011 at 04:02:59PM +0100, Leonardo Francalanci wrote: By the time the startup process releases the AccessExclusiveLock acquired by the proposed UNLOGGED - normal conversion process, that relfilenode needs to be either fully copied or unlinked all over again. (Alternately, find some other way to make sure queries don't read the half-copied file.) About this issue: how are AccessExclusiveLocks released on the standby when the master crashes? I assume those locks remain. It wouldn't be safe to release them; a master crash is just one kind of WAL receipt latency. When you promote the standby, though, ShutdownRecoveryTransactionEnvironment() releases the locks. -- 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] Use of access(X_OK) check in pg_upgrade
On Wed, May 18, 2011 at 11:41, Bruce Momjian br...@momjian.us wrote: I broke the Win32 build members by using access(X_OK) in pg_upgrade. I have a fix for this but looking at pg_upgrade's exec.c, I see for Win32: if ((buf.st_mode S_IXUSR) == 0) I am confused why Windows supports S_IXUSR but not X_OK. It doesn't natively - we define it in port/win32.h -- 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] Use of access(X_OK) check in pg_upgrade
Bruce Momjian wrote:
I broke the Win32 build members by using access(X_OK) in pg_upgrade. I
have a fix for this but looking at pg_upgrade's exec.c, I see for
Win32:
if ((buf.st_mode S_IXUSR) == 0)
I am confused why Windows supports S_IXUSR but not X_OK.
I have applied the attached patch to fix this.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/exec.c b/contrib/pg_upgrade/exec.c
new file mode 100644
index 6f1c6ef..ec2f944
*** a/contrib/pg_upgrade/exec.c
--- b/contrib/pg_upgrade/exec.c
*** void
*** 94,100
verify_directories(void)
{
! if (access(., R_OK | W_OK | X_OK) != 0)
pg_log(PG_FATAL,
You must have read and write access in the current directory.\n);
--- 94,109
verify_directories(void)
{
! if (access(., R_OK | W_OK
! #ifndef WIN32
! /*
! * Directory execute permission on NTFS means can execute scripts,
! * which we don't care about, so skip the check. Also, X_OK is not
! * defined in the API.
! */
! | X_OK
! #endif
! ) != 0)
pg_log(PG_FATAL,
You must have read and write access in the current directory.\n);
--
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] deprecating contrib for PGXN
On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote: The other problem is that the facility we need to provide the most is binary distributions (think apt-get). Lots of site won't ever compile stuff on their production servers. So while PGXN is a good tool, it's not a universal answer. Yeah, I would think that, *if* we were to seriously look at deprecating contrib (and I'm not suggesting that at all), one would *first* need to solve the binary distribution problems. I think building tools so that PGXN distributions are automatically harvested and turned into StackBuilder/RPM/.deb binaries would be the place to start on that. 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] Use of access(X_OK) check in pg_upgrade
Magnus Hagander wrote: On Wed, May 18, 2011 at 11:41, Bruce Momjian br...@momjian.us wrote: I broke the Win32 build members by using access(X_OK) in pg_upgrade. ?I have a fix for this but looking at pg_upgrade's exec.c, I see for Win32: ? ? ? ? ? ?if ((buf.st_mode S_IXUSR) == 0) I am confused why Windows supports S_IXUSR but not X_OK. It doesn't natively - we define it in port/win32.h Sure, but that is defined as _S_IEXEC: #define S_IXUSR _S_IEXEC #define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR) So what is _S_IEXEC. Anyway, execute permission means something different on Win32 for directories so I have a fix applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Adding an example for replication configuration to pg_hba.conf
I reviewed the process for configuring replication, and found that we don't have an example for allowing replication access in pg_hba.conf. Before we release 9.1, I think we should add this example to make it more obvious this is a necessary part of replication configuration. At the risk of starting an epic bikeshedding thread, I've attached a small patch that includes an example for both ipv4 and ipv6 localhost configuration. -selena -- http://chesnok.com pg_hba_bikeshed1.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] Use of access(X_OK) check in pg_upgrade
On Wed, May 18, 2011 at 12:16, Bruce Momjian br...@momjian.us wrote: Magnus Hagander wrote: On Wed, May 18, 2011 at 11:41, Bruce Momjian br...@momjian.us wrote: I broke the Win32 build members by using access(X_OK) in pg_upgrade. ?I have a fix for this but looking at pg_upgrade's exec.c, I see for Win32: ? ? ? ? ? ?if ((buf.st_mode S_IXUSR) == 0) I am confused why Windows supports S_IXUSR but not X_OK. It doesn't natively - we define it in port/win32.h Sure, but that is defined as _S_IEXEC: #define S_IXUSR _S_IEXEC #define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR) So what is _S_IEXEC. Anyway, execute permission means something different on Win32 for directories so I have a fix applied. I'm pretty sure it's mapped to read permissions internally in the API headers. -- 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] deprecating contrib for PGXN
On Wed, May 18, 2011 at 12:15 PM, David E. Wheeler da...@kineticode.com wrote: On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote: The other problem is that the facility we need to provide the most is binary distributions (think apt-get). Lots of site won't ever compile stuff on their production servers. So while PGXN is a good tool, it's not a universal answer. Yeah, I would think that, *if* we were to seriously look at deprecating contrib (and I'm not suggesting that at all), one would *first* need to solve the binary distribution problems. I think building tools so that PGXN distributions are automatically harvested and turned into StackBuilder/RPM/.deb binaries would be the place to start on that. Yep, that seems pretty apropos. And for sure, we'd want to have the contrib material easily included via PGXN-derived packages *before* deprecating them from the 'core'. It ought to be reasonably easy to cope with contrib material switching between 'core' and 'some other well-identifiable place'; that's merely the matter of having a pointer point into contrib or into some place else. (I have observed this, and I'm sure Dimitri can concur, with the way the el-get package manager for Emacs can point to packages in a diverse set of kinds of places, including dpkg, Git repos, bzr repos, or pulling them via wget from wikis and such.) It'll be time to drop the contrib material from the core when that shift leads to a 1 line configuration change somewhere that leads to packages for Debian/Fedora/Ports drawing their code from the new spot. I'd fully expect that to wait until a year or more from now. -- When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- 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] deprecating contrib for PGXN
On May 18, 2011, at 12:24 PM, Christopher Browne wrote: It'll be time to drop the contrib material from the core when that shift leads to a 1 line configuration change somewhere that leads to packages for Debian/Fedora/Ports drawing their code from the new spot. I'd fully expect that to wait until a year or more from now. Right, and assuming someone has the tuits to create the necessary automation to feed into other systems. 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] Adding an example for replication configuration to pg_hba.conf
And this patch is aligned in a more pleasing way. -selena -- http://chesnok.com pg_hba_bikeshed2.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] Adding an example for replication configuration to pg_hba.conf
On Wed, May 18, 2011 at 12:17 PM, Selena Deckelmann sel...@chesnok.com wrote: At the risk of starting an epic bikeshedding thread, I've attached a small patch that includes an example for both ipv4 and ipv6 localhost configuration. My bikeshedding would be to ensure that the sample pg_hba.conf includes some kind of reference comment indicating where to look in the documentation for more about this. Section numbers aren't stable enough; section title is probably apropos. The most relevant docs seem to be Preparing the Master for Standby Servers http://www.postgresql.org/docs/9.1/static/warm-standby.html#PREPARING-MASTER-FOR-STANDBY or Streaming Replication Authentication http://www.postgresql.org/docs/9.1/static/warm-standby.html#STREAMING-REPLICATION-AUTHENTICATION -- When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- 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] deprecating contrib for PGXN
David E. Wheeler da...@kineticode.com writes: On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote: The other problem is that the facility we need to provide the most is binary distributions (think apt-get). Lots of site won't ever compile stuff on their production servers. So while PGXN is a good tool, it's not a universal answer. Yeah, I would think that, *if* we were to seriously look at deprecating contrib (and I'm not suggesting that at all), one would *first* need to solve the binary distribution problems. I think building tools so that PGXN distributions are automatically harvested and turned into StackBuilder/RPM/.deb binaries would be the place to start on that. Hmmm ... I think the real point of those policies about no source builds is to ensure that their systems are only running code that's been vetted to some degree by a responsible person (ie, an authorized packager for whatever distro they run). So any sort of automated collection of packages would go directly against what the policies are trying to accomplish, and would likely lead to the policies being amended to specifically ban use of your repo :-( 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] Adding an example for replication configuration to pg_hba.conf
On Wed, May 18, 2011 at 9:35 AM, Christopher Browne cbbro...@gmail.com wrote: On Wed, May 18, 2011 at 12:17 PM, Selena Deckelmann sel...@chesnok.com wrote: At the risk of starting an epic bikeshedding thread, I've attached a small patch that includes an example for both ipv4 and ipv6 localhost configuration. My bikeshedding would be to ensure that the sample pg_hba.conf includes some kind of reference comment indicating where to look in the documentation for more about this. Section numbers aren't stable enough; section title is probably apropos. We don't do this in any of the other configuration files, so while I like the focus on helping users out, it would be a significant departure from convention. Creating an annotated config file in the wiki would be welcome. :) -selena -- http://chesnok.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] deprecating contrib for PGXN
On May 18, 2011, at 1:23 PM, Tom Lane wrote: I think building tools so that PGXN distributions are automatically harvested and turned into StackBuilder/RPM/.deb binaries would be the place to start on that. Hmmm ... I think the real point of those policies about no source builds is to ensure that their systems are only running code that's been vetted to some degree by a responsible person (ie, an authorized packager for whatever distro they run). So any sort of automated collection of packages would go directly against what the policies are trying to accomplish, and would likely lead to the policies being amended to specifically ban use of your repo :-( Well, it's up to the maintainers of those repos whether they want use such a feed. Magnus and Devrim seemed interested in it on Twitter last week; Magnus, in fact, originally suggested it. https://twitter.com/magnushagander/status/65431239770898434 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] deprecating contrib for PGXN
David E. Wheeler da...@kineticode.com writes: I think building tools so that PGXN distributions are automatically harvested and turned into StackBuilder/RPM/.deb binaries would be the place to start on that. Well, I'm not sure I buy into that idea, I need to think about it some more. The thing with debian for example is that the package building needs to be all automatic, and determistic — you're not granted to have the next version build a different set of binary packages. We're working about that very point with postgresql-X.Y-extension packages so that you can have a new binary package produced when you add support for a new major version, but we're not there yet. Having the set of binary packages change manually is ok, but debian also have the concept of binNMU which is an infrastructure forced rebuild if you wish (picture libc upgrades). So, given how the debian packaging actually works, having something automated that works from “distributions” which in PGXN can contain several extensions — I'm not seeing it. It looks a little like how things work in the Java world with jar and war packaging… FYI, I'm still working on apt.postgresql.org so that we have debian packaging for all major versions here, and all extensions for all those major versions too. It's not the first item on my TODO list, but we will get there eventually — this year I would figure, we even have a team forming. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] deprecating contrib for PGXN
On May 18, 2011, at 1:47 PM, Dimitri Fontaine wrote: Well, I'm not sure I buy into that idea, I need to think about it some more. The thing with debian for example is that the package building needs to be all automatic, and determistic — you're not granted to have the next version build a different set of binary packages. We're working about that very point with postgresql-X.Y-extension packages so that you can have a new binary package produced when you add support for a new major version, but we're not there yet. Having the set of binary packages change manually is ok, but debian also have the concept of binNMU which is an infrastructure forced rebuild if you wish (picture libc upgrades). So, given how the debian packaging actually works, having something automated that works from “distributions” which in PGXN can contain several extensions — I'm not seeing it. It looks a little like how things work in the Java world with jar and war packaging… I think it must be my ignorance of Debian (and Java) packaging at work here, because I don't understand any of the above (except the par where you need to think about it some more, which is smart). FYI, I'm still working on apt.postgresql.org so that we have debian packaging for all major versions here, and all extensions for all those major versions too. It's not the first item on my TODO list, but we will get there eventually — this year I would figure, we even have a team forming. That sounds awesome. 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] deprecating contrib for PGXN
On Wed, May 18, 2011 at 13:47, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: David E. Wheeler da...@kineticode.com writes: I think building tools so that PGXN distributions are automatically harvested and turned into StackBuilder/RPM/.deb binaries would be the place to start on that. Well, I'm not sure I buy into that idea, I need to think about it some more. The thing with debian for example is that the package building needs to be all automatic, and determistic — you're not granted to have the next version build a different set of binary packages. We're working about that very point with postgresql-X.Y-extension packages so that you can have a new binary package produced when you add support for a new major version, but we're not there yet. Having the set of binary packages change manually is ok, but debian also have the concept of binNMU which is an infrastructure forced rebuild if you wish (picture libc upgrades). So, given how the debian packaging actually works, having something automated that works from “distributions” which in PGXN can contain several extensions — I'm not seeing it. It looks a little like how things work in the Java world with jar and war packaging… I don't see why it couldn't, at least for a fair number of extensions.. It does require the ability to differentiate between patch releases and feature releases, though, which I believe is currently missing in pgxn (correct me if i'm wrong), but that's a solvable problem, no? Also, if it has several extensions, it should generate several DEB's - assuming they're independent extensions, right? If so, where's the problem? -- 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] deprecating contrib for PGXN
On May 18, 2011, at 2:47 PM, Magnus Hagander wrote: I don't see why it couldn't, at least for a fair number of extensions.. It does require the ability to differentiate between patch releases and feature releases, though, which I believe is currently missing in pgxn (correct me if i'm wrong), but that's a solvable problem, no? PGXN requires semantic versions. If authors use the correctly, then you can rely on the z in x.y.z to be a patch/bug fix release, and the y and z to indicate new features. Also, if it has several extensions, it should generate several DEB's - assuming they're independent extensions, right? If so, where's the problem? Maybe they're not independent. But why is that a problem. There are a *lot* of DEBs with multiple Perl modules in them. 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] Why not install pgstattuple by default?
On Wed, May 18, 2011 at 10:25, Greg Smith g...@2ndquadrant.com wrote: Attached is a second patch to move a number of extensions from contrib/ to src/test/. Extensions there are built by the default built target, making installation of the postgresql-XX-contrib package unnecessary for them to be available. +1 in general on the concept :-) This request--making some of these additions available without the contrib name/package being involved--has popped up many times before, and it turys out to be really easy to resolve with the new extensions infrastructure. I think it's even a reasonable change to consider applying now, between 9.1 Beta 1 and Beta 2. The documentation adjustments are the only serious bit left here that I've been able to find, the code changes here are all internal to the build process and easy. Does this include regression tests? Or will they need some mods? I moved the following extensions: auto_explain pageinspect pg_buffercache pg_freespacemap pgrowlocks pg_stat_statements pgstattuple My criteria was picking extensions that: 1) Don't have any special dependencies 2) Are in contrib mainly because they don't need to be internal functions, not because their code quality is demo/early 3) Tend to be installed on a production server for troubleshooting problems, rather than being required by development. 4) Regularly pop up as necessary/helpful in production deployment These seem like reasonable criteria. Some of my personal discussions of this topic have suggested that some other popular extensions like pgcrypto and hstore get converted too. I think those all fail test (3), and I'm not actually sure where pgcrypto adds any special dependency/distribution issues were it to be moved to the main database package. If this general idea catches on, a wider discussion of what else should get promoted to this extensions area would be appropriate. The ones I picked seemed the easiest to justify by this criteria set. pgcrypto would cause trouble for any builds *without* SSL. I don't think any packagers do that, but people doing manual builds would certainly get different results. Any packager who grabs the shared/postgresql/extension directory in 9.1, which I expect to be all of them, shouldn't need any changes to pick up this adjustment. For example, pgstattuple installs these files: share/postgresql/extension/pgstattuple--1.0.sql share/postgresql/extension/pgstattuple--unpackaged--1.0.sql share/postgresql/extension/pgstattuple.control And these are the same locations they were already at. The location of the source and which target built it is the change here, the result isn't any different. This means that this change won't even break extensions already installed. Once the basic directory plumbing is in place, conversion of a single extension from contrib/ to src/test/ is, trivial. The diff view I did five of them in an hour once I figured out what was needed. Easiest to view the changes at https://github.com/greg2ndQuadrant/postgres/commits/move-contrib , the patch file is huge because of all the renames. https://github.com/greg2ndQuadrant/postgres/commit/d647091b18c4448c5a582d423f8839ef0c717e91 show a good example of one convert, that changes pg_freespacemap. There are more changes to the comments listing the name of the file than to any code. (Yes, I know there are some whitespace issues I introduced in the new Makefile, they should be fixed by a later commit in the series) This is where the compare view rocks: https://github.com/greg2ndQuadrant/postgres/compare/postgres:master...greg2ndQuadrant:move-contrib -- 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] deprecating contrib for PGXN
On Wed, May 18, 2011 at 14:49, David E. Wheeler da...@kineticode.com wrote: On May 18, 2011, at 2:47 PM, Magnus Hagander wrote: I don't see why it couldn't, at least for a fair number of extensions.. It does require the ability to differentiate between patch releases and feature releases, though, which I believe is currently missing in pgxn (correct me if i'm wrong), but that's a solvable problem, no? PGXN requires semantic versions. If authors use the correctly, then you can rely on the z in x.y.z to be a patch/bug fix release, and the y and z to indicate new features. Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same time? I somehow got the idea that old versions were removed when I uploaded a new one, but I happy to be wrong :-) Also, if it has several extensions, it should generate several DEB's - assuming they're independent extensions, right? If so, where's the problem? Maybe they're not independent. But why is that a problem. There are a *lot* of DEBs with multiple Perl modules in them. Yeah, I don't see the problem if they *are* dependent. -- 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] deprecating contrib for PGXN
On May 18, 2011, at 2:58 PM, Magnus Hagander wrote: Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same time? I somehow got the idea that old versions were removed when I uploaded a new one, but I happy to be wrong :-) The distribution has only one version, of course, but perl extensions in 9.1, you can include multiple versions of an extension in one distribution. 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] deprecating contrib for PGXN
On Wed, May 18, 2011 at 15:05, David E. Wheeler da...@kineticode.com wrote: On May 18, 2011, at 2:58 PM, Magnus Hagander wrote: Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same time? I somehow got the idea that old versions were removed when I uploaded a new one, but I happy to be wrong :-) The distribution has only one version, of course, but perl extensions in 9.1, you can include multiple versions of an extension in one distribution. Won't that break if different (major) versions have different dependencies? -- 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] deprecating contrib for PGXN
On May 18, 2011, at 3:08 PM, Magnus Hagander wrote: The distribution has only one version, of course, but perl extensions in 9.1, you can include multiple versions of an extension in one distribution. Won't that break if different (major) versions have different dependencies? I don't understand the question… 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] deprecating contrib for PGXN
On Wed, May 18, 2011 at 15:17, David E. Wheeler da...@kineticode.com wrote: On May 18, 2011, at 3:08 PM, Magnus Hagander wrote: The distribution has only one version, of course, but perl extensions in 9.1, you can include multiple versions of an extension in one distribution. Won't that break if different (major) versions have different dependencies? I don't understand the question… If I include both version 1 and version 2 of an extension in one. And version 2 has more dependencies than version 1 (or the other way around). Then those dependencies will be required for version 1 as well... -- 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] deprecating contrib for PGXN
On May 18, 2011, at 3:22 PM, Magnus Hagander wrote: If I include both version 1 and version 2 of an extension in one. And version 2 has more dependencies than version 1 (or the other way around). Then those dependencies will be required for version 1 as well... Yes. But if they're that decoupled, then they ought to be in separate distributions. 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] deprecating contrib for PGXN
David E. Wheeler da...@kineticode.com writes: Yes. But if they're that decoupled, then they ought to be in separate distributions. I somehow fail to picture how you map distributions with debian packages. The simple way is to have a distribution be a single source package that will produce as many binary packages as it contains extensions. Now, if a single extension appears in more than one distribution, as far as debian packaging is concerned, you're hosed. So I still think we need to manually package for debian… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- 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] Why not install pgstattuple by default?
On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander mag...@hagander.net wrote: On Wed, May 18, 2011 at 10:25, Greg Smith g...@2ndquadrant.com wrote: Some of my personal discussions of this topic have suggested that some other popular extensions like pgcrypto and hstore get converted too. I think those all fail test (3), and I'm not actually sure where pgcrypto adds any special dependency/distribution issues were it to be moved to the main database package. If this general idea catches on, a wider discussion of what else should get promoted to this extensions area would be appropriate. The ones I picked seemed the easiest to justify by this criteria set. pgcrypto would cause trouble for any builds *without* SSL. I don't think any packagers do that, but people doing manual builds would certainly get different results. What kind of trouble? It should work fine without SSL. -- marko -- 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] deprecating contrib for PGXN
On May 18, 2011, at 3:27 PM, Dimitri Fontaine wrote: David E. Wheeler da...@kineticode.com writes: Yes. But if they're that decoupled, then they ought to be in separate distributions. I somehow fail to picture how you map distributions with debian packages. The simple way is to have a distribution be a single source package that will produce as many binary packages as it contains extensions. How do CPAN modules get packaged? Example: http://packages.debian.org/squeeze/all/libsvn-notify-perl/filelist Now, if a single extension appears in more than one distribution, as far as debian packaging is concerned, you're hosed. Yeah. That might happen, but should be uncommon. So I still think we need to manually package for debian… Well, maybe packages could be auto-generated but vetted by a human? Just a thought. 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] Why not install pgstattuple by default?
On Wed, May 18, 2011 at 15:29, Marko Kreen mark...@gmail.com wrote: On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander mag...@hagander.net wrote: On Wed, May 18, 2011 at 10:25, Greg Smith g...@2ndquadrant.com wrote: Some of my personal discussions of this topic have suggested that some other popular extensions like pgcrypto and hstore get converted too. I think those all fail test (3), and I'm not actually sure where pgcrypto adds any special dependency/distribution issues were it to be moved to the main database package. If this general idea catches on, a wider discussion of what else should get promoted to this extensions area would be appropriate. The ones I picked seemed the easiest to justify by this criteria set. pgcrypto would cause trouble for any builds *without* SSL. I don't think any packagers do that, but people doing manual builds would certainly get different results. What kind of trouble? It should work fine without SSL. Oh, you're right - it does. But it does provide different functionalties? Or does it actually do exactly the same stuff, just in different ways? -- 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] Why not install pgstattuple by default?
Greg Smith wrote:
Any packager who grabs the shared/postgresql/extension directory in
9.1, which I expect to be all of them, shouldn't need any changes to
pick up this adjustment. For example, pgstattuple installs these files:
share/postgresql/extension/pgstattuple--1.0.sql
share/postgresql/extension/pgstattuple--unpackaged--1.0.sql
share/postgresql/extension/pgstattuple.control
And these are the same locations they were already at.
...and the bit I missed here is that there's a fourth file here:
lib/postgresql/pgstattuple.so
If you look at a 9.1 spec file, such as
http://svn.pgrpms.org/browser/rpm/redhat/9.1/postgresql/EL-6/postgresql-9.1.spec
, you'll find:
%files contrib
...
%{pgbaseinstdir}/lib/pgstattuple.so
Which *does* require a packager change to relocate from the
postgresql-91-package to the main server one. So the theory that a
change here might happen without pushing a repackaging suggestion toward
packagers is busted. This does highlight that some packaging guidelines
would be needed here to completely this work.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
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 DATABASE
On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova ja...@2ndquadrant.com wrote: So we the lock will be released at end of the session or when the UNLOCK DATABASE command is invoked, right? A question: why will we beign so rude by killing other sessions instead of avoid new connections and wait until the current sessions disconnect? There were multiple alternatives suggested, which is probably useful to outline. 1. I suggested that this looks a lot like the controls of pg_hba.conf When our DBAs are doing major management of replication, they are known to reconfigure pg_hba.conf to lock out all users save for the one used by Slony. And I'm not sure it'll be the right thing to lock out everything except the present connection. When doing Slony cluster surgery, it would NOT be acceptable to restrict DB activity to a single connection - multiple slon processes legitimately need to get in. And that sure does look a lot more like something that's appropriate to manage via fiddling with pg_hba.conf than via something smelling like restrict to something looking a lot like single user mode. 2. Jan Wieck pointed out that shutting off access to users would be very well accomplished via allowing their access through a connection pool (e.g. - like pgbouncer, pgpool), and cutting them off there. That seems like a better mechanism to me, too, though we've not been able to use any of those pools with our apps thus far. 3. There's some analogy to be drawn against pg_ctl... It has 3 modes for shutdown: smart - quits once all clients have disconnected fast - quit, with proper shutdown of all clients immediate - quit without complete shutdown Those are all potentially legitimate modes for this lockdown, as there will be cases where you want to be friendly to applications, as well as cases where We right well announced this 3pm outage to everyone, and, it being 3:00:01, I'm booting you off Right Now. I thought about #3 during the discussion, but didn't bring it up then. If the mechanism: - Doesn't offer the ability to leave Needful Processes (notably, replication processes) running - Doesn't allow [friendly/unfriendly] operation modes (as in #3) then I think the use cases will be a bit thin. -- When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- 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_upgrade error checking improvement
The attached, applied patch improves pg_upgrade error reporting if the
bin or data directories do not exist or are not directories. Previously
the error message was not clear.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/exec.c b/contrib/pg_upgrade/exec.c
new file mode 100644
index 7c69175..a8f455d
*** a/contrib/pg_upgrade/exec.c
--- b/contrib/pg_upgrade/exec.c
*** is_server_running(const char *datadir)
*** 71,77
if ((fd = open(path, O_RDONLY, 0)) 0)
{
if (errno != ENOENT)
! pg_log(PG_FATAL, could not open file \%s\ for reading\n,
path);
return false;
--- 71,78
if ((fd = open(path, O_RDONLY, 0)) 0)
{
if (errno != ENOENT)
! /* issue a warning but continue so we can throw a clearer error later */
! pg_log(PG_WARNING, could not open file \%s\ for reading\n,
path);
return false;
*** void
*** 94,99
--- 95,102
verify_directories(void)
{
+ prep_status(Checking current, bin, and data directories);
+
if (access(., R_OK | W_OK
#ifndef WIN32
/*
*** verify_directories(void)
*** 107,126
pg_log(PG_FATAL,
You must have read and write access in the current directory.\n);
- prep_status(Checking old data directory (%s), old_cluster.pgdata);
- check_data_dir(old_cluster.pgdata);
- check_ok();
-
- prep_status(Checking old bin directory (%s), old_cluster.bindir);
check_bin_dir(old_cluster);
! check_ok();
!
! prep_status(Checking new data directory (%s), new_cluster.pgdata);
! check_data_dir(new_cluster.pgdata);
! check_ok();
!
! prep_status(Checking new bin directory (%s), new_cluster.bindir);
check_bin_dir(new_cluster);
check_ok();
}
--- 110,119
pg_log(PG_FATAL,
You must have read and write access in the current directory.\n);
check_bin_dir(old_cluster);
! check_data_dir(old_cluster.pgdata);
check_bin_dir(new_cluster);
+ check_data_dir(new_cluster.pgdata);
check_ok();
}
*** check_data_dir(const char *pg_data)
*** 139,163
{
char subDirName[MAXPGPATH];
int subdirnum;
! const char *requiredSubdirs[] = {base, global, pg_clog,
pg_multixact, pg_subtrans, pg_tblspc, pg_twophase,
! pg_xlog};
for (subdirnum = 0;
subdirnum sizeof(requiredSubdirs) / sizeof(requiredSubdirs[0]);
++subdirnum)
{
struct stat statBuf;
-
snprintf(subDirName, sizeof(subDirName), %s/%s, pg_data,
requiredSubdirs[subdirnum]);
if (stat(subDirName, statBuf) != 0)
report_status(PG_FATAL, check for %s failed: %s\n,
! requiredSubdirs[subdirnum], getErrorText(errno));
else if (!S_ISDIR(statBuf.st_mode))
report_status(PG_FATAL, %s is not a directory\n,
! requiredSubdirs[subdirnum]);
}
}
--- 132,156
{
char subDirName[MAXPGPATH];
int subdirnum;
! /* start check with top-most directory */
! const char *requiredSubdirs[] = {, base, global, pg_clog,
pg_multixact, pg_subtrans, pg_tblspc, pg_twophase,
! pg_xlog};
for (subdirnum = 0;
subdirnum sizeof(requiredSubdirs) / sizeof(requiredSubdirs[0]);
++subdirnum)
{
struct stat statBuf;
snprintf(subDirName, sizeof(subDirName), %s/%s, pg_data,
requiredSubdirs[subdirnum]);
if (stat(subDirName, statBuf) != 0)
report_status(PG_FATAL, check for %s failed: %s\n,
! subDirName, getErrorText(errno));
else if (!S_ISDIR(statBuf.st_mode))
report_status(PG_FATAL, %s is not a directory\n,
! subDirName);
}
}
*** check_data_dir(const char *pg_data)
*** 173,178
--- 166,181
static void
check_bin_dir(ClusterInfo *cluster)
{
+ struct stat statBuf;
+
+ /* check bindir */
+ if (stat(cluster-bindir, statBuf) != 0)
+ report_status(PG_FATAL, check for %s failed: %s\n,
+ cluster-bindir, getErrorText(errno));
+ else if (!S_ISDIR(statBuf.st_mode))
+ report_status(PG_FATAL, %s is not a directory\n,
+ cluster-bindir);
+
validate_exec(cluster-bindir, postgres);
validate_exec(cluster-bindir, pg_ctl);
validate_exec(cluster-bindir, pg_resetxlog);
*** validate_exec(const char *dir, const cha
*** 211,221
*/
if (stat(path, buf) 0)
pg_log(PG_FATAL, check for %s failed - %s\n,
! cmdName, getErrorText(errno));
!
! if (!S_ISREG(buf.st_mode))
pg_log(PG_FATAL, check for %s failed - not an executable file\n,
! cmdName);
/*
* Ensure that the file is both executable and readable (required for
--- 214,223
*/
if (stat(path, buf) 0)
pg_log(PG_FATAL, check for %s failed - %s\n,
! path, getErrorText(errno));
! else if (!S_ISREG(buf.st_mode))
pg_log(PG_FATAL, check for %s failed - not an executable file\n,
! path);
/*
* Ensure that
Re: [HACKERS] LOCK DATABASE
Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400 2011: On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova ja...@2ndquadrant.com wrote: So we the lock will be released at end of the session or when the UNLOCK DATABASE command is invoked, right? A question: why will we beign so rude by killing other sessions instead of avoid new connections and wait until the current sessions disconnect? There were multiple alternatives suggested, which is probably useful to outline. 1. I suggested that this looks a lot like the controls of pg_hba.conf When our DBAs are doing major management of replication, they are known to reconfigure pg_hba.conf to lock out all users save for the one used by Slony. Yeah, I mentioned this but I think it actually sucks. And I'm not sure it'll be the right thing to lock out everything except the present connection. When doing Slony cluster surgery, it would NOT be acceptable to restrict DB activity to a single connection - multiple slon processes legitimately need to get in. Well, I don't intend to lock everything except the present connection. The only thing this LOCK DATABASE does is prevent the establishment of new connections. Existing connections can continue to exist and work. So you do the LOCK DATABASE, then boot whoever shouldn't be allowed (which is a separate step that needs to be taken), then do your deed. If you want the slon connections to persist, just don't terminate them. And that sure does look a lot more like something that's appropriate to manage via fiddling with pg_hba.conf than via something smelling like restrict to something looking a lot like single user mode. I really dislike the idea of having to edit config files for this kind of thing. I mean, sure it can be made to work, but it seems the wrong tool for the job. 2. Jan Wieck pointed out that shutting off access to users would be very well accomplished via allowing their access through a connection pool (e.g. - like pgbouncer, pgpool), and cutting them off there. That seems like a better mechanism to me, too, though we've not been able to use any of those pools with our apps thus far. Yeah, it would work except when it doesn't; it would force you to use a tool that you may not otherwise need. So this also seems to me the wrong solution. 3. There's some analogy to be drawn against pg_ctl... It has 3 modes for shutdown: smart - quits once all clients have disconnected fast - quit, with proper shutdown of all clients immediate - quit without complete shutdown Those are all potentially legitimate modes for this lockdown, as there will be cases where you want to be friendly to applications, as well as cases where We right well announced this 3pm outage to everyone, and, it being 3:00:01, I'm booting you off Right Now. Well, that's a policy decision. I mean you, as the DBA or as the tool writer can decide to boot everyone immediately or wait until they are done with the current transaction or whatever. I'm just offering the mechanism to lock out new connections until you're finished with what you want to do. If the mechanism: - Doesn't offer the ability to leave Needful Processes (notably, replication processes) running - Doesn't allow [friendly/unfriendly] operation modes (as in #3) then I think the use cases will be a bit thin. I think we're clear in both fronts :-) -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Adding an example for replication configuration to pg_hba.conf
Two things that could be changed from this example to make it more useful: -Document at least a little bit more how this is different from the all/all rule. I can imagine users wondering do I use this instead of the other one? In addition? Is it redundant if I have 'all' in there? A little more description here aiming at the expected FAQs here would make this much more useful. -The default database is based on your user name, which is postgres in most packaged builds but not if you compile your own. I don't know whether it's practical to consider substituting that into this file, or if it's just enough to mention that as an additional doc comment. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- 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] Adding an example for replication configuration to pg_hba.conf
Excerpts from Greg Smith's message of mié may 18 23:07:13 -0400 2011: Two things that could be changed from this example to make it more useful: -The default database is based on your user name, which is postgres in most packaged builds but not if you compile your own. I don't know whether it's practical to consider substituting that into this file, or if it's just enough to mention that as an additional doc comment. You mean the default username, not the default database, but yeah; so do we need a @default_username@ token to be replaced by initdb with whatever it has as effective_user? (In this case the patch is no longer 2 lines, but still should be trivial enough). -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 DATABASE
On May 18, 2011, at 6:11 PM, Alvaro Herrera wrote: Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400 2011: On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova ja...@2ndquadrant.com wrote: So we the lock will be released at end of the session or when the UNLOCK DATABASE command is invoked, right? A question: why will we beign so rude by killing other sessions instead of avoid new connections and wait until the current sessions disconnect? There were multiple alternatives suggested, which is probably useful to outline. 1. I suggested that this looks a lot like the controls of pg_hba.conf When our DBAs are doing major management of replication, they are known to reconfigure pg_hba.conf to lock out all users save for the one used by Slony. Yeah, I mentioned this but I think it actually sucks. How would this differ from just UPDATE pg_database SET datallowconn = FALSE for the databases in question? Regards, David -- David Christensen End Point Corporation da...@endpoint.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] LOCK DATABASE
Excerpts from David Christensen's message of jue may 19 00:55:36 -0400 2011: How would this differ from just UPDATE pg_database SET datallowconn = FALSE for the databases in question? Several ways actually. First, it is automatically gone when the locking session disconnects (so it clean ups after itself). Second, it doesn't require manually updating the catalogs, which is frowned upon (with good reason). Third, the database owner could do it, not just superuser. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 DATABASE
On Thursday, May 19, 2011 06:55:36 AM David Christensen wrote: On May 18, 2011, at 6:11 PM, Alvaro Herrera wrote: Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400 2011: On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova ja...@2ndquadrant.com wrote: So we the lock will be released at end of the session or when the UNLOCK DATABASE command is invoked, right? A question: why will we beign so rude by killing other sessions instead of avoid new connections and wait until the current sessions disconnect? There were multiple alternatives suggested, which is probably useful to outline. 1. I suggested that this looks a lot like the controls of pg_hba.conf When our DBAs are doing major management of replication, they are known to reconfigure pg_hba.conf to lock out all users save for the one used by Slony. Yeah, I mentioned this but I think it actually sucks. How would this differ from just UPDATE pg_database SET datallowconn = FALSE for the databases in question? Automated lock release on session end. Which imo is quite important... andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FW: issue building uuid-ossp on win32 with VS2005
Hi, I am trying to build Postgresql 8.3.15 on Win32 with VS2005. I was able to build all the projects except uuid-ossp. I am getting the following error fatal error LNK1104: cannot open file 'c:\prog\pgsql\depend\ossp-uuid\lib\uuid.lib' I tried to get the code for uuid-1.6.2 project from ossp but I don't know how to build it for windows. Please share me how to build uuid-1.6.2 to get the binaries for win32. Or help me with the binaries if anybody has it (uuid.h uuid.lib and uuid.dll). Thanks and Regards, Sreekanth Polaka
