Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
Bill Moran wrote: > Does the PostgreSQL project have any similar policy about EoLs? Even just > a simple statement like, "it is our goal to support major branches for 2 > years after release" or some such? I've been considering only maintaining the current and previous 2 versions in pgInstaller (the Windows binary distro). But that's a *lot* harder to maintain than just PostgreSQL because of all the bundled stuff. In other words, when 8.3 is out, the 8.0 series gets dropped. What do people think about that? Does anyone think it would be an unreasonable policy? Regards, Dave ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
Hi, On Sat, 2007-01-27 at 08:41 +, Dave Page wrote: > > What do people think about that? Does anyone think it would be an > unreasonable policy? I don't think so. You should build 8.0 binaries until the community stops maintaining PostgreSQL 8.0. This is what we do for RPMs -- I know it is really a lot of work to maintain older releases but as a community packager, it is not my "job" to force people to upgrade to new version by not supplying older binaries. Regards, -- Devrim GÜNDÜZ PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [GENERAL] Converting 7.x to 8.x
On 26/01/07, Jim Nasby <[EMAIL PROTECTED]> wrote:
On Jan 25, 2007, at 12:47 PM, Benjamin Smith wrote:
> On Tuesday 23 January 2007 13:55, Carlos wrote:
>> What would be the faster way to convert a 7.4.x database into an 8.x
>> database? A dump of the database takes over 20 hours so we want
>> to convert
>> the database without having to do a dump and resptore.
>
> You've probably already accounted for this, but make sure you've
> tried your
> options for loading the database. Using long ("insert") form vs
> copy can make
> a *huge* performance difference.
In case no one's mentioned it already, you can also perform this
migration using Slony, by making the 7.4 database the master, and
replicating to an 8.x database.
In case this is not what you meant above, you can pipe a dump directly
into psql, so that keeps it to only 20hrs...
Cheers
Antoine
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [GENERAL] Stats collector frozen?
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Attached patch seems to solve the problem on my machine at least. Uses >> pgwin32_waitforsinglesocket() instead of pgwin32_select(). Changes >> pgwin32_waitforsinglesocket() to accept the timeout as a parameter (this >> is why it touches files outside of the stats area). > > Applied to HEAD and 8.2 --- assuming the Windows buildfarm machines go > green, we should probably consider back-porting this to 8.1 and 8.0. Seems HEAD now passes thie check stage on at least snake and bandicoot. They're now exposing another problem with ECPG though... //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Predicted lifespan of different PostgreSQL
Devrim GUNDUZ wrote: -- Start of PGP signed section. > Hi, > > On Sat, 2007-01-27 at 08:41 +, Dave Page wrote: > > > > What do people think about that? Does anyone think it would be an > > unreasonable policy? > > I don't think so. You should build 8.0 binaries until the community > stops maintaining PostgreSQL 8.0. > > This is what we do for RPMs -- I know it is really a lot of work to > maintain older releases but as a community packager, it is not my "job" > to force people to upgrade to new version by not supplying older > binaries. Agreed, and I do believe we should be supporting releases as far back as reasonably possible. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
Dave Page wrote: > Bill Moran wrote: >> Does the PostgreSQL project have any similar policy about EoLs? Even just >> a simple statement like, "it is our goal to support major branches for 2 >> years after release" or some such? > > I've been considering only maintaining the current and previous 2 > versions in pgInstaller (the Windows binary distro). But that's a *lot* > harder to maintain than just PostgreSQL because of all the bundled > stuff. In other words, when 8.3 is out, the 8.0 series gets dropped. > > What do people think about that? Does anyone think it would be an > unreasonable policy? Just to have an opinion that differs from what others have said, I think it's perfectly reasonable given the amount of software that gets packed in there. Perhaps we should continue to support the old 8.0 version with just the binaries-no-installer.zip? IIRC, that one contains just the core software and not all the addons, which should then make it significantly easier to maintain? //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Converting 7.x to 8.x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/27/07 04:13, Anton Melser wrote:
> On 26/01/07, Jim Nasby <[EMAIL PROTECTED]> wrote:
>> On Jan 25, 2007, at 12:47 PM, Benjamin Smith wrote:
>> > On Tuesday 23 January 2007 13:55, Carlos wrote:
>> >> What would be the faster way to convert a 7.4.x database into an 8.x
>> >> database? A dump of the database takes over 20 hours so we want
>> >> to convert
>> >> the database without having to do a dump and resptore.
>> >
>> > You've probably already accounted for this, but make sure you've
>> > tried your
>> > options for loading the database. Using long ("insert") form vs
>> > copy can make
>> > a *huge* performance difference.
>>
>> In case no one's mentioned it already, you can also perform this
>> migration using Slony, by making the 7.4 database the master, and
>> replicating to an 8.x database.
>
> In case this is not what you meant above, you can pipe a dump directly
> into psql, so that keeps it to only 20hrs...
Using slony or "piped pg_dump" requires that you have *double* the
amount of disk space. Having a *very large* database and double
capacity of SCSI disks (including storage controllers, shelves, etc,
etc) is expensive, and might not be available.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFu3OMS9HxQb37XmcRAraIAJ0TbS3O4kh5W5UDZJM/PaRZARkLOACeNteM
YMN6nG/6RzMOWv9apJxwO6Q=
=F96M
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [GENERAL] Stats collector frozen?
Jeremy Haile wrote: > Using standard build (none of the things you mentioned) on 8.2.1 > currently. > > I really appreciate it! Ok. I've built a binary for you at http://www.hagander.net/download/pgsql_8.2.1_win32select.zip Note that while I named the file 8.2.1 it really isn't - it's current head of the REL_8_2_STABLE branch. Which means it has a few other fixes as well. I think it *should* work to just replace the postgres.exe file and ignore the rest, so I didn't put them in the ZIP. But as always, make sure you take a backup first :-) //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Stats collector frozen?
Will do - thanks Magnus! I'll test it for a while and post the results here. Jeremy Haile On Sat, 27 Jan 2007 17:21:23 +0100, "Magnus Hagander" <[EMAIL PROTECTED]> said: > Jeremy Haile wrote: > > Using standard build (none of the things you mentioned) on 8.2.1 > > currently. > > > > I really appreciate it! > > Ok. I've built a binary for you at > http://www.hagander.net/download/pgsql_8.2.1_win32select.zip > > Note that while I named the file 8.2.1 it really isn't - it's current > head of the REL_8_2_STABLE branch. Which means it has a few other fixes > as well. > > I think it *should* work to just replace the postgres.exe file and > ignore the rest, so I didn't put them in the ZIP. But as always, make > sure you take a backup first :-) > > //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
Dave Page <[EMAIL PROTECTED]> writes: > I've been considering only maintaining the current and previous 2 > versions in pgInstaller (the Windows binary distro). But that's a *lot* > harder to maintain than just PostgreSQL because of all the bundled > stuff. In other words, when 8.3 is out, the 8.0 series gets dropped. > What do people think about that? Does anyone think it would be an > unreasonable policy? Actually, I was just wondering last night about whether we should bother maintaining the 8.0/8.1 Windows ports at all. Everybody knew going in (or should have known) that 8.0 on Windows would be a pretty raw port with a lot of issues, as indeed it was, and so long-term support for it seems a bit pointless. Perhaps the 8.1 port was up to the point where it would be sane to use for production, or maybe not. I haven't tracked Windows-specific issues particularly, but I think there were at least some important patches we didn't back-port because of complexity. Certainly 8.0 and 8.1 src/backend/port/win32/ files look quite a bit different. Does anyone recall any specifics about Windows patches that were back-ported or not? Anyway I think that a fair case could be made for dropping the 8.0 branch now, and maybe 8.1 too, as far as Windows support goes. What you want to do going forward is a different decision --- these are edge cases because of the newness of the port. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Postgresql 8.1: plperl code works with LATIN1, fails with UTF8
On Fri, Jan 26, 2007 at 06:17:03PM +0100, Philippe Lang wrote:
> I've got plperl code that works just fine when the database is
> encoded using LATIN1, but fails as soon as I switch to UTF8.
>
> I've been testing PG 8.1.4 under Linux, and PG 8.1.6 under FreeBSD,
> both behave exactly the save.
[...]
> ERROR: error from Perl function: invalid input syntax for integer: "" at
> line 54.
The function has several integer output parameters and in some cases
the code sets the output value to '' (empty string). A couple of
those cases (larg_maconnerie, haut_maconnerie) involve comparisons
against strings with non-ASCII characters -- if you add an elog()
statement in each of those places you'll probably see that at least
one of them is being reached unexpectedly.
Aside from the fact that an empty string isn't a valid integer, I
think the problem can be reduced to the following example:
CREATE FUNCTION test(text) RETURNS boolean AS $$
return ($_[0] eq 'ä') ? 't' : 'f';
$$ LANGUAGE plperl IMMUTABLE STRICT;
SELECT test('ä');
test
--
f
(1 row)
In an 8.1.6 UTF-8 database this example returns false; in 8.2.1 it
returns true. See the following commit message and the related bug
report regarding PL/Perl and UTF-8:
http://archives.postgresql.org/pgsql-committers/2006-10/msg00277.php
http://archives.postgresql.org/pgsql-bugs/2006-10/msg00077.php
If you can't upgrade to 8.2 then you might be able to work around
the problem by creating the function as plperlu and adding 'use utf8;'.
--
Michael Fuhr
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
> Anyway I think that a fair case could be made for dropping the 8.0 > branch now, and maybe 8.1 too, as far as Windows support goes. What > you want to do going forward is a different decision --- these are > edge cases because of the newness of the port. Well as someone who has literally thousands of windows installations (thank goodness we are not front line support for that). It would be very helpful if the community did make a confirmed and public statement about the lifespan of the Windows ports. It would enable me to get certain customers to upgrade and stop wasting energy on hunting bugs on unsupported or unlikely to be supported releases. Sincerely, Joshua D. Drake > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
Tom Lane wrote: > Dave Page <[EMAIL PROTECTED]> writes: >> I've been considering only maintaining the current and previous 2 >> versions in pgInstaller (the Windows binary distro). But that's a *lot* >> harder to maintain than just PostgreSQL because of all the bundled >> stuff. In other words, when 8.3 is out, the 8.0 series gets dropped. >> What do people think about that? Does anyone think it would be an >> unreasonable policy? > > Actually, I was just wondering last night about whether we should bother > maintaining the 8.0/8.1 Windows ports at all. Everybody knew going in > (or should have known) that 8.0 on Windows would be a pretty raw port > with a lot of issues, as indeed it was, and so long-term support for it > seems a bit pointless. Perhaps the 8.1 port was up to the point where > it would be sane to use for production, or maybe not. > > I haven't tracked Windows-specific issues particularly, but I think > there were at least some important patches we didn't back-port because > of complexity. Certainly 8.0 and 8.1 src/backend/port/win32/ files look > quite a bit different. Does anyone recall any specifics about Windows > patches that were back-ported or not? > > Anyway I think that a fair case could be made for dropping the 8.0 > branch now, and maybe 8.1 too, as far as Windows support goes. What > you want to do going forward is a different decision --- these are > edge cases because of the newness of the port. Based on that it would be reasonable to cut 8.0 short, I agree on that. However, I really don't think we can do that to 8.1. For one, 8.2 is *way* too new yet. I also do believe we got most of the really big ones between those (though I can't remember them specifically right now, it's a feeling I have). But the important part is that either way I think it's way too early to drop 8.1. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
a feeling I have). But the important part is that either way I think it's way too early to drop 8.1. I agree. Started a project last summer, using 8.1, rollout is now. > 1 year for database projects is not unusual, and having the database release dropped during this time is not nice. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Reinsburgstraße 202b 70197 Stuttgart 0173/9409607 fx 01212-5-13695179 - Python: the only language with more web frameworks than keywords.
Re: [GENERAL] Stats collector frozen?
So far, the patched binary seems to have fixed the statistics issue in my environment. pgstat.stat is now updating constantly, pg_stat_user_tables is updating correctly, and autovacuum is running! Thanks for your quick response to this issue! Let me know if there is anything else I can do to assist. Jeremy Haile On Sat, 27 Jan 2007 11:23:39 -0500, "Jeremy Haile" <[EMAIL PROTECTED]> said: > Will do - thanks Magnus! I'll test it for a while and post the results > here. > > Jeremy Haile > > On Sat, 27 Jan 2007 17:21:23 +0100, "Magnus Hagander" > <[EMAIL PROTECTED]> said: > > Jeremy Haile wrote: > > > Using standard build (none of the things you mentioned) on 8.2.1 > > > currently. > > > > > > I really appreciate it! > > > > Ok. I've built a binary for you at > > http://www.hagander.net/download/pgsql_8.2.1_win32select.zip > > > > Note that while I named the file 8.2.1 it really isn't - it's current > > head of the REL_8_2_STABLE branch. Which means it has a few other fixes > > as well. > > > > I think it *should* work to just replace the postgres.exe file and > > ignore the rest, so I didn't put them in the ZIP. But as always, make > > sure you take a backup first :-) > > > > //Magnus > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Predicted lifespan of different PostgreSQL
Bruce Momjian <[EMAIL PROTECTED]> wrote: > > Devrim GUNDUZ wrote: > -- Start of PGP signed section. > > Hi, > > > > On Sat, 2007-01-27 at 08:41 +, Dave Page wrote: > > > > > > What do people think about that? Does anyone think it would be an > > > unreasonable policy? > > > > I don't think so. You should build 8.0 binaries until the community > > stops maintaining PostgreSQL 8.0. > > > > This is what we do for RPMs -- I know it is really a lot of work to > > maintain older releases but as a community packager, it is not my "job" > > to force people to upgrade to new version by not supplying older > > binaries. > > Agreed, and I do believe we should be supporting releases as far back as > reasonably possible. The problem I see is that different people have differing opinions on what is "reasonable". It might be educational for those not familiar to search back through the archives for the complaints that cropped up in Nov and Dec regarding the upcoming EoL of FreeBSD 4.x. Not sure if the official announcement (that was made several years ago) made that situation better or worse, but it goes to show that some people expect stuff to be supported forever. My concern is that without an official policy, the key developers of the Postgres team will get bogged down trying to maintain stuff long after it's technically practical, because some users find it "reasonable." Of course, the end of "official" support for a project doesn't prevent folks with an interest from continuing to support it unofficially. The CVS tree will still be there, etc. Anyway, just my thoughts on the matter. It's interesting to see the other discussion that's going on. -Bill ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Stats collector frozen?
On Sat, Jan 27, 2007 at 03:17:14PM +0100, Magnus Hagander wrote: > Seems HEAD now passes thie check stage on at least snake and bandicoot. > They're now exposing another problem with ECPG though... This should be fixed now. I just missed to change MinGW expected files when I changed the tests. That's why I prefer to have no platform specific expected files. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Predicted lifespan of different PostgreSQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/07 11:50, Bill Moran wrote: > Bruce Momjian <[EMAIL PROTECTED]> wrote: >> Devrim GUNDUZ wrote: [snip] > Of course, the end of "official" support for a project doesn't prevent folks > with an interest from continuing to support it unofficially. The CVS > tree will still be there, etc. > > Anyway, just my thoughts on the matter. It's interesting to see the other > discussion that's going on. The Debian Security Team will be patching security issues on v7.4 for another 18 months, if that helps anyone. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFu58lS9HxQb37XmcRAmYkAKCC+SMLzaph6Pby2/M1BGqCbounkgCcDYgd jkrBZF9CZdZO9q0G92mTqss= =vs5m -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] Password issue revisited
Fellow PostgreSQL fans, Last year there was a pretty lengthy discussion (Tom Lane offered a lot of insights) on this list about deprecating the PGPASSWORD environmental variable. I understand the security issues here very well. However, up through version 8.1, it has been easy to use pg_dump and pg_restore from other applications (PHP, Java, etc.) by capturing the Password prompt on stderr and sending the password on stdin. No more. Now, this interaction is done on low-level I/O data streams. Also, it appears from the documentation that the PGPASSFILE environmental variable has been deprecated for pg_dump and pg_restore. It appears the only way these utilities can run from a script or other application is to ensure that the user specified in the command-line has a .pgpass file. I would like to ask that we return to outputting the Password prompt on stderr and accepting password input on stdin. Here are the reasons. 1. I don't see that this would pose a major security risk. In fact, in applications where the user enters the password for each session, the password need never be saved to disk, which seems a definite security advantage. Some folks have noted that .pgpass is a plain text file, hence it could be vulnerable. 2. PostgreSQL has a tradition of respecting generally accepted standards. The use of high-level input/output is a standard for many programming languages. 3. PostgreSQL has a tradition of cross-platform compatibility. Use of high-level input/output allows cross-platform applications (e.g., Java) to interact with PostgreSQL in a straightforward and standardized fashion. 4. Low level input/output is considerably more difficult and less reliable for other applications to access and work with. Thanks for considering this matter. Michael Schmidt
Re: [GENERAL] Password issue revisited
Michael Schmidt wrote: > Fellow PostgreSQL fans, Last year there was a pretty lengthy discussion > (Tom Lane offered a lot of insights) on this list about deprecating > the PGPASSWORD environmental variable. I understand the security issues > here very well. However, up through version 8.1, it has been easy to > use pg_dump and pg_restore from other applications (PHP, Java, etc.) > by capturing the Password prompt on stderr and sending the password on > stdin. No more. Now, this interaction is done on low-level I/O data > streams. Also, it appears from the documentation that the PGPASSFILE > environmental variable has been deprecated for pg_dump and pg_restore. > It appears the only way these utilities can run from a script or other > application is to ensure that the user specified in the command-line > has a .pgpass file. > > I would like to ask that we return to outputting the Password prompt > on stderr and accepting password input on stdin. Here are the reasons. Unlikely. > 1. I don't see that this would pose a major security risk. In fact, > in applications where the user enters the password for each session, > the password need never be saved to disk, which seems a definite > security advantage. Some folks have noted that .pgpass is a plain text > file, hence it could be vulnerable. This doesn't work if the command actually is taking data from stdin. > 2. PostgreSQL has a tradition of respecting generally accepted > standards. The use of high-level input/output is a standard for many > programming languages. It is _not_ typical to read a password from stdin. I am sure you can find some tools that do this, but most do not. > 3. PostgreSQL has a tradition of cross-platform compatibility. Use > of high-level input/output allows cross-platform applications (e.g., > Java) to interact with PostgreSQL in a straightforward and standardized > fashion. > 4. Low level input/output is considerably more difficult and less > reliable for other applications to access and work with. The change is to read from /dev/tty. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Password issue revisited
"Michael Schmidt" <[EMAIL PROTECTED]> writes: > Also, it appears > from the documentation that the PGPASSFILE environmental variable has > been deprecated for pg_dump and pg_restore. Eh? Certainly not ... where did you get that idea? > I would like to ask that we return to outputting the Password prompt on > stderr and accepting password input on stdin. I think it's unlikely we will revert that, as it's been a done deal for several releases now (since 7.4 in fact). regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Password issue revisited
Tom Lane wrote: > "Michael Schmidt" <[EMAIL PROTECTED]> writes: > > Also, it appears > > from the documentation that the PGPASSFILE environmental variable has > > been deprecated for pg_dump and pg_restore. > > Eh? Certainly not ... where did you get that idea? I assumed he meant the PASSWORD environment variable. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
Tom Lane wrote: Dave Page <[EMAIL PROTECTED]> writes: I've been considering only maintaining the current and previous 2 versions in pgInstaller (the Windows binary distro). But that's a *lot* harder to maintain than just PostgreSQL because of all the bundled stuff. In other words, when 8.3 is out, the 8.0 series gets dropped. What do people think about that? Does anyone think it would be an unreasonable policy? Actually, I was just wondering last night about whether we should bother maintaining the 8.0/8.1 Windows ports at all. Everybody knew going in (or should have known) that 8.0 on Windows would be a pretty raw port with a lot of issues, as indeed it was, and so long-term support for it seems a bit pointless. Perhaps the 8.1 port was up to the point where it would be sane to use for production, or maybe not. I haven't tracked Windows-specific issues particularly, but I think there were at least some important patches we didn't back-port because of complexity. Certainly 8.0 and 8.1 src/backend/port/win32/ files look quite a bit different. Does anyone recall any specifics about Windows patches that were back-ported or not? Anyway I think that a fair case could be made for dropping the 8.0 branch now, and maybe 8.1 too, as far as Windows support goes. What you want to do going forward is a different decision --- these are edge cases because of the newness of the port. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly My 8.2c, Having 8.1 end of life this soon after the release of 8.2 seems pretty harsh. I am a Windows user with systems in the field in production and it would probably be disconcerting to customers to see/read that the version they are using will not have the benefits of full community support going forward. It should also be considered that it is probably more difficult to alleviate the concerns of people about using even the *best* Open Source database on a Windows platform (please don't bash us for using windows for now it is a necessary evil) It seems reasonable to expect 8.1 to be alive for more than 2 months after its replacement is released. For most production environments just the QA process for a major version change could take longer than 2 months to schedule and implement, let alone roll out to the hopefully growing numbers of customers. Oisin ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Stats collector frozen?
Magnus Hagander <[EMAIL PROTECTED]> writes: > On Fri, Jan 26, 2007 at 09:55:39AM -0500, Tom Lane wrote: >> Keep in mind also that we have seen the stats-test failure on >> non-Windows machines, so we still need to explain that ... > Yeah. But it *could* be two different stats issues lurking. Perhaps the > issue we've seen on non-windows can be fixed by the settings Alvaro had > me try (increasing autovacuum_vacuum_cost_delay or the delay in the > regression test). I had a sudden thought about that: the stats machinery is designed to be non-reliable, ie, drop messages under load. Maybe the occasional stats failures we see are just an artifact of that happening. It would be pretty unfortunate if the stats test and autovacuum together were sufficient load to cause message drops, but I doubt that's the explanation. I think the important change here has been the default enablement of stats_row_level. That means that some of the tests terminating just before the stats test starts may still be trying to dump statistics out to the collector at the same time the stats test is. (Keep in mind that psql does not wait around for the backend to be actually gone before it exits, hence backend-exit cleanup is very likely to happen in parallel with the start of the next test.) This idea explains why we mostly see the failure in parallel tests not serial: in the serial schedule there's no opportunity to have a gang of backends all exiting at the critical time. If this theory is correct, then we can improve the reliability of the stats test a good deal if we put a sleep() at the *start* of the test, to let any old backends get out of the way. It seems worth a try anyway. I'll add this to HEAD and if the stats failure noise seems to go down, we can back-port it. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] encode, lower and 0x8a
On Thu, Jan 25, 2007 at 02:28:38PM -0500, Michael Artz wrote: > Perhaps my understanding of the 'encode' function is incorrect, but I > was under the impression that I could do something like: > > SELECT lower(encode(bytes, 'escape')) FROM mytable; > > as it sounded like (from the manual) that 'encode' would return valid > ASCII, with all the non-ascii bytes hex escaped. The documentation for encode() does give that impression: "Encode binary string to ASCII-only representation. Supported types are: base64, hex, escape." However, the source code for esc_encode() in src/backend/utils/adt/encode.c says and does otherwise: * Only two characters are escaped: * \0 (null) and \\ (backslash) > When I have the byte 0x8a, however, I get the error: > > ERROR: invalid byte sequence for encoding "UTF8": 0x8a Since encode() returns text and doesn't escape non-ASCII characters, all of the original binary data will be treated as though it's text in the database's encoding. If the data contains byte sequences that aren't valid in that encoding then you get the above error. > I have the sneaking suspicion that I am missing something, so please > correct me if I am wrong. If I am wrong, is there a better way to > lowercase all the ascii characters in a bytea string? What are you trying to do? What is the binary data and why are you treating it (or part of it) as though it's text? Do you want the end result to be text with escape sequences or do you want to convert it back to bytea? Something like this might work: SELECT lower(textin(byteaout(bytes))) FROM mytable; To turn the result back into bytea: SELECT decode(lower(textin(byteaout(bytes))), 'escape') FROM mytable; -- Michael Fuhr ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] Limit on number of users in postgresql?
I want to make a client application that logs onto a postgresql server with an individual postgresql user role for each user. This is as opposed to having one user role for the entire app, storing that password on the local client, and using the client app to do authentication against a a table in the connected database. I'm wondering if there's a manageable limit on the number of users in postgresql. I could have conceivably thousands of different users for any particular app and multiple apps in the same server. I would distinguish between different users for different apps by something like a user encoded name myapp_myname where to the individual app that would be user myname. This seems like a persistent problem for a lot of database apps. Is there any simple way of dealing with this problem? A lot of apps store root passwords to the database locally, which is very insecure, especially on desktop applications. It seems like a big headache to declare users globally to the server instead of at the database level. Am I doing more work than I need to do? Thanks. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
> It should also be considered that it is probably more difficult to > alleviate the concerns of people about using even the *best* Open > Source database on a Windows platform (please don't bash us for using > windows for now it is a necessary evil) As much as I would like to say the community won't bash you for using windows, we all know better ;). However it is important to note that this thread is about supporting windows in general. 8.2 is a substantial improvement over the other releases for Win32. > It seems reasonable to expect > 8.1 to be alive for more than 2 months after its replacement is released. > For most production environments just the QA process for a major version > change could take longer than 2 months to schedule and implement, let > alone roll out to the hopefully growing numbers of customers. > I would agree. However, I don't think it would be unreasonable to consider when by the time 8.3.1 comes out which if all goes well would be in the fall (or so). Then continue our standard long term support for the 8.2+ series of PostgreSQL which would mean we would like give approximately 5 years support to that branch. Sincerely, Joshua D. Drake > Oisin > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
Oisin Glynn <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Anyway I think that a fair case could be made for dropping the 8.0 >> branch now, and maybe 8.1 too, as far as Windows support goes. > My 8.2c, > Having 8.1 end of life this soon after the release of 8.2 seems pretty > harsh. That's fine, I just wanted to run that idea up the flagpole and see if anyone would salute. The important point is that no one has spoken against retiring 8.0-on-Windows now. (Don't tell me people actually listened to us when we said not to run production with it ;-)) What'd probably be a good idea is for someone to go through the CVS logs and check for 8.2 Windows portability fixes that have not gotten into the 8.1 branch. If we want to continue supporting 8.1 then we should make sure it's up to speed. I think there might have been some changes we didn't back-port because we hadn't enough confidence in them, but 8.2 has been out long enough now that we can be pretty sure it's not a regression. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Predicted lifespan of different PostgreSQL branches
Tom Lane wrote: > Oisin Glynn <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Anyway I think that a fair case could be made for dropping the 8.0 >>> branch now, and maybe 8.1 too, as far as Windows support goes. > >> My 8.2c, >> Having 8.1 end of life this soon after the release of 8.2 seems pretty >> harsh. > > That's fine, I just wanted to run that idea up the flagpole and see if > anyone would salute. The important point is that no one has spoken > against retiring 8.0-on-Windows now. (Don't tell me people actually > listened to us when we said not to run production with it ;-)) They didn't, but those of us they call quickly made them upgrade ;) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Limit on number of users in postgresql?
Mark Walker <[EMAIL PROTECTED]> writes: > I'm wondering if there's a manageable limit on the number of users in > postgresql. I could have conceivably thousands of different users for > any particular app and multiple apps in the same server. Numbers in the low thousands are probably workable, as long as you aren't adding and removing users at a great rate. I think that the main bottleneck would be the "flat file" that's used to tell the postmaster about the set of valid users --- every time a user is added/dropped/changed, that file gets rewritten and then re-parsed by the postmaster. So you could eat a lot of overhead if you change users every few seconds or something like that. I'd suggest doing some testing to see if there are any unexpected bottlenecks, but I don't see a reason to reject the idea out of hand. (If you find any slownesses, report 'em, and we might be able to fix 'em.) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
