Re: [GENERAL] question
am Tue, dem 07.10.2008, um 21:20:53 -0400 mailte Tom Lane folgendes: > Luis Castillo <[EMAIL PROTECTED]> writes: > > I would like to know how can I control in my database the rows that a > > user has inserted. I mean many users can insert information in a table > > but when trying to update the information I want that a user can change > > only those rows inserted by him. Is this possible with Postgresql? > > Sure, if you add a column that records which user inserted the row, and > then make a BEFORE UPDATE trigger that throws an error if it doesn't > match. Additional, create a text-column with default current_user for the inserts. Example: [EMAIL PROTECTED]:~$ psql -U kretschmer test ... test=> create table usertab (id serial, username text default current_user); NOTICE: CREATE TABLE will create implicit sequence "usertab_id_seq" for serial column "usertab.id" CREATE TABLE test=*> insert into usertab values(default, default); INSERT 0 1 test=*> select * from usertab; id | username + 1 | kretschmer (1 row) Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] general table stats, ideas ?
On Tue, Oct 7, 2008 at 11:27 AM, Mark Roberts
<[EMAIL PROTECTED]> wrote:
>
>
>> My problem is, I need to benchmark set of tables, where - we can
>> assume - schema of each table is unknown, and we have no assumption on
>> any fields being present there. (altho, if there is no other way to do
>> it, we could assume id bigint not null default nextval('someseq'));
>> basically, I need to know when certain row was selected (read), and
>> when it was updated/created (insert). For that I need two fields. And
>> although former could be done, and I more or less know how to do it (I
>> think it can be done with rule, and default = now()) - I have yet to
>> find a way on how to do the same thing for select.
>
> So basically you've got a slony replicated database that you want to
> check (on a row by row level) when something gets read/inserted/deleted?
>
> It seems like you would want to add three fields to each table:
> last_read_time, last_update_time, and original_insert_time
If you need to keep track of all updates, past and present, then a
logging table of some kind would be needed, and a trigger to update it
possibly. Or some kind of time travel setup.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] ERROR: column "datpath" does not exist
On Tue, Oct 7, 2008 at 4:08 AM, tsp <[EMAIL PROTECTED]> wrote: > > I am facing this problem but i didn't find the solution what mentioned here. > Where are the folders "/usr/bin" and "usr/local/pgsql/bin/" Then I guess the first question is what OS are you running and how were the current and previous versions of pgsql installed? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] question
Luis Castillo <[EMAIL PROTECTED]> writes: > I would like to know how can I control in my database the rows that a > user has inserted. I mean many users can insert information in a table > but when trying to update the information I want that a user can change > only those rows inserted by him. Is this possible with Postgresql? Sure, if you add a column that records which user inserted the row, and then make a BEFORE UPDATE trigger that throws an error if it doesn't match. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Efficiency of inner joins across multiple tables
Hello, Q: How efficient is this? If connectionHash is unique or near to it, and everything's indexed... it could work for reasonable K values depending on your performance requirements. Nice to hear. Every time i create a new table should i create a table with all columns and query from that? Is there any reason you can't just add the new column to the existing table? Aah, very nice. I wasn't aware I could add a column once it has the table has been created. I see the Alter command will do the trick. Sounds good. Thank you very much Regards Saptarshi -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Efficiency of inner joins across multiple tables
On Tue, Oct 7, 2008 at 7:30 PM, Saptarshi Guha <[EMAIL PROTECTED]> wrote: > Q: How efficient is this? If connectionHash is unique or near to it, and everything's indexed... it could work for reasonable K values depending on your performance requirements. > Every time i create a new table should i create a table with all columns and > query from that? Is there any reason you can't just add the new column to the existing table? -- - David T. Wilson [EMAIL PROTECTED] -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_hba.conf use hostname not IP
Bessette-Halsema, Dominique E. wrote: > Is there a way to use the hostname that is in the /etc/hosts file > instead of the IP address in pg_hba.conf No. It has been discussed but we've not found a good way in which it should work. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] db_user_namespace, md5 and changing passwords
Bruce Momjian escribió: > Well, I posted about this in August with no one replying: > > http://archives.postgresql.org/pgsql-admin/2008-08/msg00068.php > > Basically, there is a mismatch between what libpq and the backend think > is the username, and that affects how MD5 uses the salt on the two sides > of the connection. I totally agree that this needs a redesign, but we must provide something to replace it with, not just rip it off. > The minimal solution would be to document this and print a proper > error message. Seems fair. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Left outer join question
Thanks much. Silly Me, I had an extraneous comma -Original Message- From: Raymond O'Donnell [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2008 8:12 PM To: Bill Reynolds Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Left outer join question On 08/10/2008 01:02, Bill Reynolds wrote: >Is it possible to have a left outer join on 2 tables from the same > originating table where T1 left outer joins to T2 and T1 left outer > joins to T3? I guess I'm stuck on the FROM clause syntax or trying to > do something you just can't do. Maybe I'm missing something, but it ought to be just: ...from T1 left join T2 on (T1.a_column = T2.a_column) left join T3 on (T1.another_column = T3.another_column) etc. Ray. -- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland [EMAIL PROTECTED] Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Left outer join question
On 08/10/2008 01:02, Bill Reynolds wrote: >Is it possible to have a left outer join on 2 tables from the same > originating table where T1 left outer joins to T2 and T1 left outer > joins to T3? I guess I'm stuck on the FROM clause syntax or trying to > do something you just can't do. Maybe I'm missing something, but it ought to be just: ...from T1 left join T2 on (T1.a_column = T2.a_column) left join T3 on (T1.another_column = T3.another_column) etc. Ray. -- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland [EMAIL PROTECTED] Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Left outer join question
Hey folks, stuck on something here and maybe I went down a dead end road. Is it possible to have a left outer join on 2 tables from the same originating table where T1 left outer joins to T2 and T1 left outer joins to T3? I guess I'm stuck on the FROM clause syntax or trying to do something you just can't do. Maybe it is possible to join T1 and T1again, back to each other but I didn't want to do that. Many Thanks, Bill -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Efficiency of inner joins across multiple tables
Hello, I guess this is basic question for DBAs. I have several tables, each numbering in 100,000's of rows. They all have have connectionHash as the primary key and indices on several variables. E.g Table1 has connectionHash, duration, type Table2 has connectionHash, location Table3 has connectionHash, region Now i need to select columns:connectionHash, duration, location, region (the variables can differ) from Tables 1,2 and 3 using an inner join on connectionHash(indexed). Q: How efficient is this? Issues involved: One might suggest that i make a table with all columns from across all tables, however, as my research continues more tables, TableK, with connectionHash, extracolumn will be created. Option: Every time i create a new table should i create a table with all columns and query from that? So I make one new table (made via an inner join, but done only once) and subsequent queries made from this larger table(union of all columns from Tables 1..K) Any suggestions will be very much welcome. Regards Saptarshi -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] question
Hi list, I would like to know how can I control in my database the rows that a user has inserted. I mean many users can insert information in a table but when trying to update the information I want that a user can change only those rows inserted by him. Is this possible with Postgresql? thanks, karina -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi!
* Martin Pitt <[EMAIL PROTECTED]> [2008-10-02 18:12:47 CEST]:
> Markus Wanner [2008-10-02 12:49 +0200]:
> > Unfortunately we are stuck with several Postgres 8.2 installations from
> > etch backports, which are no longer maintained by the backports, because
> > only 8.2 got dropped from testing.
>
> Indeed it was quite clear to me right from the beginning that Lenny
> would ship with 8.3 only. I think from the POV of not supporting
> several PostgreSQL versions in stable Debian releases there is no
> disagreement. Etch is an exception because we needed 7.4 to get an
> upgrade path from Sarge, but further Debian versions will only ever
> support the latest PostgreSQL release.
Alright, so it was actually my own fault to have done the pg-8.2
backports, and I'm sorry for have followed the request to do so. On the
other hand, I still don't fully understand the problems of not being
able to upgrade to pg-8.3 properly. People seem to have been able to
upgrade from 8.1 to 8.2, so what's the real big difference between 8.1
vs. 8.2 and 8.2 vs. 8.3? If it's soo deep, wouldn't that mean that we
are having a general problem with the upgrade path here, too?
> Nevertheless I acknowledge the problem with the existing backport, of
> course. I didn't request the 8.2 one, and personally I don't think it
> is a wise idea to run a production server purely on a backport version
> without being able to upgrade to 8.3 (or spending the necessary work
> to upgrade to newer 8.2 versions, of course), but the world is as it
> is, and people will do that.
Yes, the latter part is what puzzles me personally, too.
> > I'm providing upgraded packages for Postgres 8.2 on my own website [1].
> > There are certainly other people who have run into the same issue, see
> > for example [2] who dislikes using Postgres backports for exactly that
> > reason.
Erm, the referenced mail [2] refers to your own mail, so using that as
a reasoning argument is a bit fishy ... And you failed to outline the
"enough of a reason for an exception" argument you like to brag around
with.
But it's a valid argument to not use something from backports (or any
other repository out there, mind you, it's not limited to backports).
With backports you have a clear ruleset that applies, though.
> > On the backports-users mailing list I've requested that Postgres 8.2
> > gets re-added to etch-backports, with upgraded packages. So that
> > existing installations can get bug- and security fixes for that Postgres
> > versions. One argument for rejection [3] has been, that Postgres 8.2 is
> > not in testing anymore and can thus not be backported. I'm arguing that
> > Postgres 8.2 is a backport per se. Not from testing, but a backport of
> > newer software to etch.
Your argument might be valid, but it doesn't play for backports. It was
always clear that backports.org is about backporting packages from
testing.
> > * Postgres major versions that once got included should continue to be
> > supported and updated within the standard Debian infrastructure as long
> > as supported by the Postgres project itself.
Backports.org is not the standard Debian infrastructure. And even if it
were, you should this rather bring it up e.g. debian-project list.
Having a rule like that would though mean that an ancient version would
never be able to get removed anywhere at all, and would mean that the
postgres project decides what the volunteers within the Debian project
has to do. This doesn't work, and I would be highly surprised if the
PostgreSQL team would actually follow that reasoning, one could argue
the other way round too, and I'm quite sure that the postgresql team
wouldn't be happy to be told by any other project about how and what
they have to do.
> Not my favourite option, but if the postgresql maintenance team would
> actually double in size (IOW, would not just be me), and
> debian-{release,security}@ don't veto, it's ok with me.
If the PostgreSQL project wants to follow that path, they are happily
encouraged to join the Debian packaging team indeed. :)
> > * Postgres major versions dumped from testing, but once added to any
> > backport should be maintained on backports even if it gets dumped from
> > testing.
>
> That would basically lift backports.org to be an officially supported
> Debian archive, which it isn't, and shouldn't be.
By the same rule it could be argued that major version added to testing
should be maintained in testing for as long as can be. It's exactly the
same reasoning, and I guess you can see the pattern here and follow my
rationale outlined above.
> > * Never include Postgres major versions from testing in the backports,
> > as those might get dumped from testing thus support cannot be guaranteed
> > anymore. (Except perhaps when we can be very sure that this won't happen).
>
> That's a viable option. When 8.3 was released, and Lenny's release
> schedule got published (roughly at start of 2008), it was quite sure
> that
Re: [GENERAL] [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi again :) * Markus Wanner <[EMAIL PROTECTED]> [2008-10-06 17:34:13 CEST]: > Gerfried Fuchs wrote: > > On the > > other hand, I still don't fully understand the problems of not being > > able to upgrade to pg-8.3 properly. People seem to have been able to > > upgrade from 8.1 to 8.2, so what's the real big difference between 8.1 > > vs. 8.2 and 8.2 vs. 8.3? If it's soo deep, wouldn't that mean that we > > are having a general problem with the upgrade path here, too? > > Well, it's a general Postgres problem, not a Debian one. Upgrading > between major versions requires a full dump/restore cycle, for which the > downtime is proportional to the database size. For small or medium > databases that's not an issue, but above some Gigabytes, that begins to > hurt pretty badly. Then again, that was already required when switching from 8.1 to 8.2. And it was never a secret that backports.org is a moving target, just as testing is, where the backported versions on backports.org come from. > Another problem also mentioned in the cited threads is that of custom > built or contrib modules which are often problematic (i.e. costly to > adjust) to upgrade as well. Likewise, 8.2 was never in stable so people already must have done that thing at least once. > Once Postgres supports in-place upgrades between major versions, this > issue is solved. Good to hear. :) > > Erm, the referenced mail [2] refers to your own mail, so using that as > > a reasoning argument is a bit fishy ... > > Uhm.. I'm mistyping sometimes, but not this time. [2] references: > http://archives.postgresql.org/message-id/[EMAIL PROTECTED] > > Which is certainly not from me. Yes. But the only thing given therein is a reference to the thread started by you. That user clearly wants a clean stable system and seems to be well aware of what backports.org might gain him, or might not. And I don't think that your approach with yet another repository will make him happy neither. > > And you failed to outline the > > "enough of a reason for an exception" argument you like to brag around > > with. > > Well, at least several hours of downtime is enough of a reason for many > people to not upgrade between major Postgres versions. It certainly is > for us. And judging from the Postgres mailing lists, there are still > quite some people on 7.4 just for these reasons. And that's absolutely fine and that's what the stable releases in Debian are for. Backports.org is a moving target that is there to support backports from testing (which is obviously a moving target, too), and people doing upgraded from stable to versions from backports.org should hopefully be aware of that. New version usually mean new interfaces for working with them, and I don't see why this should be considered differently for postgres ... People who are worried about downtimes for upgrades should never follow a moving target, might it be testing, backports.org or anything else. Who is this "us" by the way, so just that "we" know who we are speaking about? > > Your argument might be valid, but it doesn't play for backports. It was > > always clear that backports.org is about backporting packages from > > testing. > > Okay, that's fine. > > In that case, 8.2 should never have been backported. Why do you claim so? It was a helpful ressource for quite some people. > And very likely 8.4 shouldn't be backported either. Which is a pity > IMO, and justifies an exception of such a rule. Why do you think so? What makes postgres so outrageous special in this area than any other package? > Note that I'm not just complaining, but offering to help and do better > myself: I continue to maintain "backports" of 8.2. But with that you are just adding to the diversion which you so strongly try to fight ... > > Backports.org is not the standard Debian infrastructure. And even if it > > were, you should this rather bring it up e.g. debian-project list. > > That's why I'm cross-posting this, yes. But you haven't cross-posted it to the debian-project list (which doesn't rule backports.org currently, but there's work underway here). I guess having your original mail not sent to backports-users was a mistake, you did bounce it there later. > > Having a rule like that would though mean that an ancient version would > > never be able to get removed anywhere at all, > > No. The Debian project could perfectly well drop it as soon as upstream > drops support for it (which has often been around five years after the > initial release, so far). Erm, that's extremely kind of you. Do you really want to go the path of claiming that it's non-debian's decisions when Debian drops support for a package? I consider that highly arrogant and unpractical. > Note that these are bugfixes only and backporting those is certainly as > much work as supporting a new major version. Often enough, this should > just mean upgrading the sources, without having to adjust anything > debian specific.
Re: [GENERAL] ERROR: column "datpath" does not exist
I am facing this problem but i didn't find the solution what mentioned here. Where are the folders "/usr/bin" and "usr/local/pgsql/bin/" [webattach] IT-Dienstleistungen wrote: > > Thanks Scott, now I got it! ;) > > I found older copies of pg_dump in "/usr/bin" while the newer were in > "/usr/local/pgsql/bin/". > > Beginner's mistake... 8-) > > Sascha > > > ---(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 > > -- View this message in context: http://www.nabble.com/-GENERAL--ERROR%3A--column-%22datpath%22-does-not-exist-tp3213375p19855174.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi! One (hopefully) last reply. :) * Markus Wanner <[EMAIL PROTECTED]> [2008-10-07 10:52:55 CEST]: > Gerfried Fuchs wrote: > > Then again, that was already required when switching from 8.1 to 8.2. > > And it was never a secret that backports.org is a moving target, just as > > testing is, where the backported versions on backports.org come from. > > While that's correct, nobody was forced to do that switch, because 8.1 > is still maintained in etch, while 8.2 is not maintained anywhere > anymore, forcing people to switch. But those people already chose a switching path so the impact isn't that diverse. And it's still nothing postgres specific here, people chosing backports are chosing a moving target. > That's why I'd like to merge those packets into backports, at least. > Better yet, back into the main Debian project. It would have to flow from the main pool to backports. I am no authority here, even though I understand that it might sound a bit like it, but I don't see the chances for the exception in this case. > I disagree here. If backported packages don't even try to be as stable > as the stable version they are backported to, there's no point in > backporting. There definitely is. Backported packages offer newer features onto an *otherwise* stable and (security-)supported system. While I strive to get the latter part fixed and more timely addressed and included into the security-tracker.debian.net, it still isn't there. The overall quality is pretty high because only Debian Developers are usually allowed to upload into backports, but there are different rules that apply here still. > Testing is a movable target, yes. But backports shouldn't be, IMO. > Otherwise, why should I use backports at all? To have newer features within a small subgroup of packages. Take e.g. the pidgin package. It was updated several times with newer features but also changed interfaces. A backported package is per definition a moving target and not a static content, otherwise you won't ever be able to update it at all. > > People who are worried about downtimes for upgrades should never follow > > a moving target, might it be testing, backports.org or anything else. > > Sure? Yes, sure. > "You are running Debian stable, because you prefer the stable Debian > tree. It runs great, there is just one problem: the software is a little > bit outdated compared to other distributions. That is where backports > come in." > > That's exactly how I understand what "backports" are. Striving to reach > high stability for selected packages from the "future" (seen from the > particular stable release). No. Striving to not affect the high stability of the _base_ system is why it's done. While striving to have high stability for the packages within backports, it's core reason of existence is to *not* influence the base system unto which it's applied to. Following your reasoning one could argue that you are calling pg 8.3 not having a high stability. > The front page continues to explain: > > "Backports are recompiled packages from testing (mostly) and unstable > (in a few cases only, e.g. security updates)" > > So there must already be other exceptions for good reasons. Yes. But pg 8.2 is neither in testing nor in unstable. > > Who is this "us" by the way, so just that "we" know who we are speaking > > about? > > In this case that should have read "me and the people from the company > I'm working for". We run several etchy systems with backported Postgres > 8.2 (because we need some of the 8.2 features). Alright, thanks. To some degree I got the impression by the writing style you chose that you were part of and speaking for the postgres team ... > >> In that case, 8.2 should never have been backported. > > > > Why do you claim so? It was a helpful ressource for quite some people. > > I absolutely agree. Heck we are productively using it. So do lots of > other people, because they want newer software to run on a stable > system. And they want the newer software to be as stable as their old > system whenever possible. That's why I'm saying 8.2 shouldn't just be > dropped. Sorry to say so then but your wording was badly chosen in some parts. I don't deny that propably mine too, and given that we both seem to be German natives discussing this in English even sounds like fishing for even more problems here. > Responses to this effort and downloads from my repository indicate, that > there are enough other people wanting a stable and maintained Postgres > 8.2 from Debian. I never really denied that. It's just that it wouldn't follow the current workflow that did hinder me to maintain it in the way it was before... > > But you haven't cross-posted it to the debian-project list (which > > doesn't rule backports.org currently, but there's work underway here). I > > guess having your original mail not sent to backports-users was a > > mistake, you did bounce it there later. > > I didn't know
[GENERAL] pg_hba.conf use hostname not IP
Hi Is there a way to use the hostname that is in the /etc/hosts file instead of the IP address in pg_hba.conf Dominique Bessette SAIC (858) 826-9182
[GENERAL] PgUS 2008 semi-annual election
Greetings! The United States PostgreSQL Association (PgUS), in accordance with its bylaws, is holding an election at the semi-annual meeting for the remaining four board seats. Information about the election procedure, timeframe, and links to the nominee platforms are all available at: https://www.postgresql.us/elections/2008 Best of luck to the excellent nominees! The election shall begin October 10th 2008 at approximately 10:30AM PDT and shall run until October 31st; any person who is a voting member before October 31st is eligible to vote. The nominees are Richard Broersma, Jr., Andrew Dunstan, Chander Ganesan, Ned Lilly, Greg Subino Mullane, Gavin Roy, and Robert Treat. ---Michael Brewer Secretary, PgUS [EMAIL PROTECTED] -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] db_user_namespace, md5 and changing passwords
Alvaro Herrera wrote: > Tom Lane escribi?: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > I don't know of a way to make MD5 and db_user_namespace work cleanly so > > > we are considering removing db_user_namespace in 8.4. > > > > We are? It's no more or less ugly than the day it was put in (the > > MD5 encryption option was already there). > > > > If we had some improved replacement to offer, I'd be all for getting > > rid of db_user_namespace; but without that I think we're just taking > > away a feature that some people are using. At least, the argument > > was made back in 2002 that people would use this if they had it; > > do we have evidence to the contrary now? > > I also disagree with removing it. I know some people (few and far > apart) are using it. Well, I posted about this in August with no one replying: http://archives.postgresql.org/pgsql-admin/2008-08/msg00068.php Basically, there is a mismatch between what libpq and the backend think is the username, and that affects how MD5 uses the salt on the two sides of the connection. The minimal solution would be to document this and print a proper error message. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi,
I enjoy discussing and I think we are getting closer to an understanding
with every mail.
Gerfried Fuchs wrote:
It would have to flow from the main pool to backports. I am no
authority here, even though I understand that it might sound a bit like
it, but I don't see the chances for the exception in this case.
Okay. Looks like I'm rather trying to join the "official" packaging team
and bring Postgres 8.2 back alive on testing. We'll soon see how that
turns out.
To have newer features within a small subgroup of packages. Take e.g.
the pidgin package. It was updated several times with newer features but
also changed interfaces. A backported package is per definition a moving
target and not a static content, otherwise you won't ever be able to
update it at all.
I think the main difference in understanding here is the updatability of
Postgres. I'm clearly thinking of Postgres 8.2 as a very different
package than Postgres 8.3.
We have more than one server where we are running *both* in parallel and
want to keep it that way. (Where "we" is Programmfabrik GmbH again). (In
fact even one where an additional 8.1 is running).
I think it's quite similar to python2.{3,4,5}.: sure one "can"
theoretically upgrade (with enough time and resources). But more often
enough one simply doesn't want to.
No. Striving to not affect the high stability of the _base_ system is
why it's done. While striving to have high stability for the packages
within backports, it's core reason of existence is to *not* influence
the base system unto which it's applied to.
I fail to see how that can be a reason for backports to exist. If your
main motivation is not to influence the base system, you certainly don't
need any backports.
Backporting always is a compromise between stability (of the old
software) and new features, IMO.
The front page continues to explain:
"Backports are recompiled packages from testing (mostly) and unstable
(in a few cases only, e.g. security updates)"
So there must already be other exceptions for good reasons.
Yes. But pg 8.2 is neither in testing nor in unstable.
Agreed.
Sorry to say so then but your wording was badly chosen in some parts. I
don't deny that propably mine too, and given that we both seem to be
German natives discussing this in English even sounds like fishing for
even more problems here.
Yeah...
I never really denied that. It's just that it wouldn't follow the
current workflow that did hinder me to maintain it in the way it was
before...
Understood.
I've been coming from another direction, thinking that adding Postgres
8.2 to only backports would be easier than adding it to Debian proper.
Maybe that's plain wrong. And Martin Pitt seems to be glad to get some
help...
Because the way you worded your mails made it sound like you wanted to
have some rules enforced that are out of the scope of the lists you post
to.
Sorry if it sounded that way. I just wanted to know in what direction I
should go with Postgres 8.2 packages.
And yes, I must admit that I've been a bit disappointed by "suddenly"
(didn't read the backport-users...) missing Postgres 8.2 upgrades.
I won't explain further here why I called that attitude arrogant, we
can do that in private and propably in German to reduce the language
barrier. And I'm glad to hear that you want to join the packaging team,
thanks.
Cool.
If you like and don't hold this discussion against me feel free to
pester me with anything you like to. :)
Thanks for the offer. I'm trying keep the discussion on the topic and to
avoid personal offense.
Keeping to maintain all major Postgres versions in testing (and
unstable) would solve that issue as well.
If we are able to work it out I'm all for doing so.
I'll try.
No worries - and like hinted above, I'm also sorry for having sounded
pretty strict, but I just wanted to point the things out properly
instead of doing it like some others with a "no, won't work" reply. ;)
Hehe.. it certainly helped me better than than, yeah. Thanks for
productive criticism.
Regards
Markus Wanner
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Pg Conference: West, bigger than last year!
On October 20th 2007 the first annual PostgreSQL Conference: West commenced. It was a single day, single room event. On March 29th and 30th the first annual PostgreSQL Conference: East commenced. It was a two day, three room event which. On October 10-12th the second annual PostgreSQL Conference: West will commence. A three day, three room event with PostgreSQL training, a code sprint, a Internals track, a web track and multiple talks on high availability, performance, and community. The West conference is set to overshadow the East conference as the most popular conference in the series (until East 09 that is). If you haven't registered, now is the time. Come and experience what PostgreSQL is all about. The fun, the education, the technical savvy! No other database, open source or propreitary has such a vibrant, diverse and dedicated community as PostgreSQL! Register here: http://www.postgresqlconference.org/west08/register See a list of talks here: http://www.postgresqlconference.org/west08/talks/ And of course, thank you to our sponsors: Command Prompt: http://www.commandprompt.com/ EnterpriseDB: http://www.enterprisedb.com/ Afilias : http://www.afilias.info/ HP: http://www.hp.com/ Xtuple: http://www.xtuple.com/ Emma : http://www.myemma.com/ Continuent : http://www.continuent.com/ Endpoint : http://www.endpoint.com/ OTG : http://www.otg-nc.com/ EFF: http://www.eff.org/ Google: http://www.google.com/ All proceeds from the conference benefit the United States (PgUS) PostgreSQL Association. -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] general table stats, ideas ?
> My problem is, I need to benchmark set of tables, where - we can
> assume - schema of each table is unknown, and we have no assumption on
> any fields being present there. (altho, if there is no other way to do
> it, we could assume id bigint not null default nextval('someseq'));
> basically, I need to know when certain row was selected (read), and
> when it was updated/created (insert). For that I need two fields. And
> although former could be done, and I more or less know how to do it (I
> think it can be done with rule, and default = now()) - I have yet to
> find a way on how to do the same thing for select.
So basically you've got a slony replicated database that you want to
check (on a row by row level) when something gets read/inserted/deleted?
It seems like you would want to add three fields to each table:
last_read_time, last_update_time, and original_insert_time
Then you restrict all access to the table and use security definer
functions to allow access. These functions would also update said
metadata to the table. If you need an ongoing log of access to the
tables, you could always add an accessor log table that looked like:
User (postgres/MYUSER) / Action (Select/Update/Insert) / Column
(some_column_name) / New Value (blah-value)
Erm, that's if I understand your question right. :-/
-Mark
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] general table stats, ideas ?
2008/10/7 Richard Broersma <[EMAIL PROTECTED]> > On Tue, Oct 7, 2008 at 9:47 AM, Grzegorz Jaśkiewicz <[EMAIL PROTECTED]> > wrote: > > > If someone loves a challenge, and is able to provide me with an answer to > my > > problem - please do so. Also, if this can be done, but with slightly > > different requirements - please let me know too. > > Thanks, this is my first post here - so welcome you guys > > > Would the facilities already in the PostgreSQL logging system not work for > you? at the end of a day, maybe - but we don't log by default, because quite few tables operate on bytea structures, that are failry large, and log file's size would be substantial. -- GJ
Re: [GENERAL] general table stats, ideas ?
On Tue, Oct 7, 2008 at 9:47 AM, Grzegorz Jaśkiewicz <[EMAIL PROTECTED]> wrote: > If someone loves a challenge, and is able to provide me with an answer to my > problem - please do so. Also, if this can be done, but with slightly > different requirements - please let me know too. > Thanks, this is my first post here - so welcome you guys Would the facilities already in the PostgreSQL logging system not work for you? -- Regards, Richard Broersma Jr. Visit the Los Angeles PostgreSQL Users Group (LAPUG) http://pugs.postgresql.org/lapug -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] general table stats, ideas ?
Hey folks,
I want to do a fairly simple thing, but so far I see no way in which this
could be implemented with postgresql. So I decided to ask folks here.
My problem is, I need to benchmark set of tables, where - we can assume -
schema of each table is unknown, and we have no assumption on any fields
being present there. (altho, if there is no other way to do it, we could
assume id bigint not null default nextval('someseq'));
basically, I need to know when certain row was selected (read), and when it
was updated/created (insert). For that I need two fields.
And although former could be done, and I more or less know how to do it (I
think it can be done with rule, and default = now()) - I have yet to find a
way on how to do the same thing for select.
If someone loves a challenge, and is able to provide me with an answer to my
problem - please do so. Also, if this can be done, but with slightly
different requirements - please let me know too.
Thanks, this is my first post here - so welcome you guys
--
GJ
Re: [GENERAL] localhost (windows) performance
On Tuesday 07 October 2008 08:54:31 am justin wrote: > johnf wrote: > > I have a friend I asked to load postgres 8.3 on his XP machine. He then > > tested a python script which accesses several tables and discovered that > > it retrieves data very slowly. It takes about 20 seconds to retrieve the > > data - on localhost. However, using a remote connection to a postgres > > database (mine) over the internet and running the same python script it > > takes only 12 seconds. The difference of 8 seconds makes no sense - the > > remote is completely on the other coast. > > > > I then thought it had something to do with the data -although the data > > set is small. I did a complete dump and restored on his machine and > > again got the same results. The machine has a recent motherboard with 2 > > gb of ram. It does not appear to be swapping out ram. > > > > > > Using my local XP (accessing the LINUX database on the LAN) runs the same > > python script in just under 3 seconds (most of the time is in loading the > > GUI). > > > > One other major difference is I'm running postgres8.2 on linux. > > > > Anybody, have a suggestion - I'm not a windows guru. Or is this normal > > for windows? > > Hardware related i'm betting. The client is having to run the python the > gui and postgresql on the same hard drive its getting IO bound > > What size is the data set 1 meg 20 megs or 100 megs. I have seen small > record counts but it was nothing but blobs in the table so the table was 5 > gigs. > > What is the hardware specs on the XP machine?? Can you post the Select > statements??? SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) AS size FROM pg_database reveals "5801 kB" Like I said very small. All the statements are similar: select * from arcust where ccustno = "some var" No blobs - there are a couple of 'text' fields. Total data retrieved is very small - just a few thousand bytes. If haven't said - this is a test database that contains only small amounts of data. Looks like we have gotten a major improvement by changing the shared-buffers. -- John Fabiani -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] localhost (windows) performance
johnf wrote: I have a friend I asked to load postgres 8.3 on his XP machine. He then tested a python script which accesses several tables and discovered that it retrieves data very slowly. It takes about 20 seconds to retrieve the data - on localhost. However, using a remote connection to a postgres database (mine) over the internet and running the same python script it takes only 12 seconds. The difference of 8 seconds makes no sense - the remote is completely on the other coast. I then thought it had something to do with the data -although the data set is small. I did a complete dump and restored on his machine and again got the same results. The machine has a recent motherboard with 2 gb of ram. It does not appear to be swapping out ram. Using my local XP (accessing the LINUX database on the LAN) runs the same python script in just under 3 seconds (most of the time is in loading the GUI). One other major difference is I'm running postgres8.2 on linux. Anybody, have a suggestion - I'm not a windows guru. Or is this normal for windows? Hardware related i'm betting. The client is having to run the python the gui and postgresql on the same hard drive its getting IO bound What size is the data set 1 meg 20 megs or 100 megs. I have seen small record counts but it was nothing but blobs in the table so the table was 5 gigs. What is the hardware specs on the XP machine?? Can you post the Select statements??? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] localhost (windows) performance
On Tuesday 07 October 2008 08:20:16 am you wrote: > On Tue, Oct 7, 2008 at 11:11 AM, johnf <[EMAIL PROTECTED]> wrote: > > I then thought it had something to do with the data -although the data > > set is small. I did a complete dump and restored on his machine and > > again got the same results. The machine has a recent motherboard with 2 > > gb of ram. It does not appear to be swapping out ram. > > The standard first question- has the 8.3 db been analyzed? > > Compare the plans from the two systems- you may be getting different > plans that account for the apparent slowdown. No I did not check. But we are talking about very small data sets. No table has more than 50 rows. I doubt that analyze will provide anything - but I could be wrong. There is about 20 SQL statements that read data (selects only) and they are very straight forward without joins or sub-selects. So I'm thinking it has something to do with the way windows runs postgres or a setting in XP. -- John Fabiani -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] localhost (windows) performance
I have a friend I asked to load postgres 8.3 on his XP machine. He then tested a python script which accesses several tables and discovered that it retrieves data very slowly. It takes about 20 seconds to retrieve the data - on localhost. However, using a remote connection to a postgres database (mine) over the internet and running the same python script it takes only 12 seconds. The difference of 8 seconds makes no sense - the remote is completely on the other coast. I then thought it had something to do with the data -although the data set is small. I did a complete dump and restored on his machine and again got the same results. The machine has a recent motherboard with 2 gb of ram. It does not appear to be swapping out ram. Using my local XP (accessing the LINUX database on the LAN) runs the same python script in just under 3 seconds (most of the time is in loading the GUI). One other major difference is I'm running postgres8.2 on linux. Anybody, have a suggestion - I'm not a windows guru. Or is this normal for windows? -- John Fabiani -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] DBD::Pg 2.10.7 compile failed on RH4
Tapio.Niva wrote: > we have 32-bit PostgreSQL version 8.3.4 on 64-bit RHEL4 , Postgres > itself is working as expected. > We are using PostreSQL via following perl version > > # perl -v > This is perl, v5.10.0 built for i686-linux-thread-multi > (with 4 registered patches, see perl -V for more detail) > Copyright 1987-2007, Larry Wall > Binary build 1004 [287188] provided by ActiveState > http://www.ActiveState.com > Built Sep 3 2008 11:22:08 > > > Our problem is that DBD::Pg version 2.10.7 will not compile , > /usr/bin/ld skips all libpq files as incompatible - please see a slice > of the result below : > > rm -f blib/arch/auto/DBD/Pg/Pg.so > LD_RUN_PATH="/usr/lib" gcc -shared -O2 Pg.o dbdimp.o quote.o types.o > -o blib/arch/auto/DBD/Pg/Pg.so \ >-L/usr/lib -lpq -lm \ > > /usr/bin/ld: skipping incompatible /usr/lib/libpq.so when searching for > -lpq [...] > > # file /usr/lib/libpq.so.5.1 > /usr/lib/libpq.so.5.1: ELF 32-bit LSB shared object, Intel 80386, > version 1 (SYSV), stripped > # > > > > I assume that something is mixed here (=32/64-bit) because linker claims > for incompatibility - but because there is only 1 libpq created by > Postgres install, I'm a bit lost. > Should we use some other linker version ? > > Any ideas how to proceed ? Yes, the problem must be that the compiler produces 64-bit code which cannot be linked with 32-bit code. You can either install 64-bit PostgreSQL libraries or give gcc the -m32 option so that it generates 32-bit code. Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Magnus Hagander wrote: > Not having followed the whole discussion here.. But if location is the > only issue, we could perhaps provide a repository on the postgresql.org > servers for this, in case Debian does not want it on their official ones? Thanks for the offer, but location is not really the issue here. I'm in contact with Martin Pitt, who's the only maintainer of the Postgres packages for Debian. Helping him with maintaining these packages is a good thing per se, IMO. I'm trying to join forces and not diversify. Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Markus Wanner wrote: > Hi, > > Alvaro Herrera wrote: >> If there are no backported packages for any given Postgres major >> version, what will happen is that a lot of people will be forced to >> build them from source, which is a lot worse. (There is a reason why >> PGDG provides RPM for all major versions, for a lot of Redhat >> distributions -- people do want them). > > Uh.. in case that didn't get clear: I've already done the backports of > Postgres 8.2.9 and 8.2.10 for debian etch. You can get these packages > from the temporary repository here: http://www.bluegap.ch/debian/ Not having followed the whole discussion here.. But if location is the only issue, we could perhaps provide a repository on the postgresql.org servers for this, in case Debian does not want it on their official ones? //Magnus -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgres/postgis
Hi, On Tue, 2008-10-07 at 09:23 -0500, Eduardo Arévalo wrote: > distro Centos 5.2 x64 Since you want to use 8.3 IIRC, then, run: rpm -Uvh \ http://yum.pgsqlrpms.org/reporpms/8.3/pgdg-centos-8.3-4.noarch.rpm and then use yum to install GeOS, PostGIS and PostgreSQL 8.3.4. All have 64-bit support. I am the maintainer of this repository. For details, you may want to visit: http://yum.pgsqlrpms.org Regards, -- Devrim GÜNDÜZ, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
Re: [GENERAL] Installation on CentOS 5.2 (readline trouble)
Tom Lane wrote: > > libreadline depends on libtermcap in RHEL-5, but so far as I can see > this dependency is explicit in the RPM, so it shouldn't have been > possible to not install termcap. (However, I'm not sure just how bright > the dependency solver was in RHEL-5 ... maybe it let you install a > 64-bit readline but only the 32-bit version of termcap?) > I suspected something like that after the results of a Google search (before posting here) --- I tried termcap-devel, and it tells me that there's no such package; then I noticed that there is the package termcap, and also libtermcap, with the accompanying libtermcap-devel. Turns out that, as Greg pointed out, it was the missing ncurses-devel. Strangely enough, the little dummy test program still reports the exact same errors when compiling with -lreadline. But PostgreSQL's configure script now runs successfully! Thanks, and thanks Greg for the valuable tip ! Carlos -- -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] How do I save data and then raise an exception?
Thank you, Scott. That's interesting to know about. It doesn't solve my initial problem, though, because the C++ application was written without transactions. (Yet another illustration of the lack of database knowledge on the part of the initial developers.) RobR -Original Message- From: Scott Marlowe [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2008 4:59 PM To: Rob Richardson Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] How do I save data and then raise an exception? On Fri, Oct 3, 2008 at 1:48 PM, Rob Richardson <[EMAIL PROTECTED]> wrote: > I didn't see anything in the documentation about deferred constraints. > Can you point to someplace where I can read about them? http://www.postgresql.org/docs/8.3/static/sql-createtable.html -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] pg_hotbackup how to
I have 3 database in my cluster , and would make backup online just one database ,atually i using pg_hotbackup --backupdir=/var/lib/pgsql/backups --datadir=/var/lib/pgsql/data but this command make a full backup in cluster. anybody help me! Tnks Paulo Moraes Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. http://br.new.mail.yahoo.com/addresses
Re: [GENERAL] DBD::Pg 2.10.7 compile failed on RH4
Hello, thanks for help, -m32 option to Makefile and make was successful, so was also make test & make install. Our own tests are connecting to postgres - at least so far. Tom,we are using 32-bit perl & 32-bit postgres on 64-bit RHEL4, because some of our sw still are 32-bit. DBD::Pg is the latest version 2.10.7 from CPAN. Again, thanks for great help ! Have a nice day BR, Tapio -Original Message- From: Albe Laurenz [mailto:[EMAIL PROTECTED] Sent: 7. lokakuuta 2008 15:04 To: Niva Tapio; pgsql-general@postgresql.org Subject: RE: [GENERAL] DBD::Pg 2.10.7 compile failed on RH4 Tapio.Niva wrote: > we have 32-bit PostgreSQL version 8.3.4 on 64-bit RHEL4 , Postgres > itself is working as expected. > We are using PostreSQL via following perl version > > # perl -v > This is perl, v5.10.0 built for i686-linux-thread-multi > (with 4 registered patches, see perl -V for more detail) > Copyright 1987-2007, Larry Wall > Binary build 1004 [287188] provided by ActiveState > http://www.ActiveState.com > Built Sep 3 2008 11:22:08 > > > Our problem is that DBD::Pg version 2.10.7 will not compile , > /usr/bin/ld skips all libpq files as incompatible - please see a slice > of the result below : > > rm -f blib/arch/auto/DBD/Pg/Pg.so > LD_RUN_PATH="/usr/lib" gcc -shared -O2 Pg.o dbdimp.o quote.o types.o > -o blib/arch/auto/DBD/Pg/Pg.so \ >-L/usr/lib -lpq -lm \ > > /usr/bin/ld: skipping incompatible /usr/lib/libpq.so when searching for > -lpq [...] > > # file /usr/lib/libpq.so.5.1 > /usr/lib/libpq.so.5.1: ELF 32-bit LSB shared object, Intel 80386, > version 1 (SYSV), stripped > # > > > > I assume that something is mixed here (=32/64-bit) because linker claims > for incompatibility - but because there is only 1 libpq created by > Postgres install, I'm a bit lost. > Should we use some other linker version ? > > Any ideas how to proceed ? Yes, the problem must be that the compiler produces 64-bit code which cannot be linked with 32-bit code. You can either install 64-bit PostgreSQL libraries or give gcc the -m32 option so that it generates 32-bit code. Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Installation on CentOS 5.2 (readline trouble)
Carlos Moreno <[EMAIL PROTECTED]> writes: > I just downloaded the latest, 8.3.4, and I'm trying to install it on > a CentOS 5.2 machine with all the updates (64-bit --- the system > is an Opteron DC) > The configure script fails reporting it doesn't find readline. libreadline depends on libtermcap in RHEL-5, but so far as I can see this dependency is explicit in the RPM, so it shouldn't have been possible to not install termcap. (However, I'm not sure just how bright the dependency solver was in RHEL-5 ... maybe it let you install a 64-bit readline but only the 32-bit version of termcap?) If you're sure both libraries are there, please show the config.log output that's probing for readline and not finding it. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] DBD::Pg 2.10.7 compile failed on RH4
<[EMAIL PROTECTED]> writes:
> we have 32-bit PostgreSQL version 8.3.4 on 64-bit RHEL4 , Postgres
> itself is working as expected.
> ...
> Our problem is that DBD::Pg version 2.10.7 will not compile ,
> LD_RUN_PATH="/usr/lib" gcc -shared -O2 Pg.o dbdimp.o quote.o types.o
> -o blib/arch/auto/DBD/Pg/Pg.so \
>-L/usr/lib -lpq -lm \
> /usr/bin/ld: skipping incompatible /usr/lib/libpq.so when searching for
> -lpq
What it looks like to me is that you've got a 64-bit perl build ("file"
on the perl executable would be a good way to confirm that). If so,
you're going to need a 64-bit version of libpq.so to link into it.
There's no reason a 64-bit libpq wouldn't interoperate with a 32-bit
server, so just installing the 64-bit postgresql-libs RPM alongside what
you have ought to be sufficient.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgres/postgis
On Mon, 2008-10-06 at 09:26 -0500, Eduardo Arévalo wrote: > hello is campatible install postgresql-8.3.4-1-linux-x64 with > postgis-1.3.3. > postgis there for 64-bit architecture?? > There are the libraries and proj4 GEOS arqitectura for 64-bit?? For which distro? Many distros has these stuff in their repositories. -- Devrim GÜNDÜZ, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi Markus, Markus Wanner [2008-10-07 11:08 +0200]: > Do I understand correctly, that https://code.launchpad.net/postgresql > currently holds the debian packaging files in a bazaar repository? It has branches for p-common and 8.3. http://arch.debian.org/arch/pkg-postgresql/mpitt/ has the branches for etch (7.4 and 8.1). I set the public branch for 8.2 [1] to "abandoned", since I don't maintain it any more. However, I'm fine with reviving it if you want to take it over. (If you don't want to maintain it on LP, put it somewhere else, and I convert it to be a mirror of your branch) Thanks, Martin [1] https://code.launchpad.net/~pitti/postgresql/debian-8.2 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [GENERAL] how to remove the duplicate records from a table
Yi Zhao wrote: > I have a table contains some duplicate records, and this table create > without oids, for example: > id | temp_id > +- > 10 | 1 > 10 | 1 > 10 | 1 > 20 | 4 > 20 | 4 > 30 | 5 > 30 | 5 > I want get the duplicated records removed and only one is reserved, so > the results is: > 10 1 > 20 4 > 30 5 > > I know create a temp table will resolve this problem, but I don't want > this way:) > > can someone tell me a simple methold? Don't know if you'd call that simple, but if the table is called "t", you could do DELETE FROM t t1 USING t t2 WHERE t1.id = t2.id AND t1.temp_id = t2.temp_id AND t1.ctid > t2.ctid; Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Martin Pitt wrote: > So it's not a lot of work, but it must be done regularly and in time. That's good news. And about my experience when backporting 8.2.9 and 8.2.10 for etch as well. Do I understand correctly, that https://code.launchpad.net/postgresql currently holds the debian packaging files in a bazaar repository? Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Alvaro Herrera wrote: > If there are no backported packages for any given Postgres major > version, what will happen is that a lot of people will be forced to > build them from source, which is a lot worse. (There is a reason why > PGDG provides RPM for all major versions, for a lot of Redhat > distributions -- people do want them). Uh.. in case that didn't get clear: I've already done the backports of Postgres 8.2.9 and 8.2.10 for debian etch. You can get these packages from the temporary repository here: http://www.bluegap.ch/debian/ Regards Markus Wanner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: [Pkg-postgresql-public] Postgres major version support policy on Debian
Hi, Gerfried Fuchs wrote: > Then again, that was already required when switching from 8.1 to 8.2. > And it was never a secret that backports.org is a moving target, just as > testing is, where the backported versions on backports.org come from. While that's correct, nobody was forced to do that switch, because 8.1 is still maintained in etch, while 8.2 is not maintained anywhere anymore, forcing people to switch. > Yes. But the only thing given therein is a reference to the thread > started by you. That user clearly wants a clean stable system and seems > to be well aware of what backports.org might gain him, or might not. And > I don't think that your approach with yet another repository will make > him happy neither. True. And from what I can tell, he got that impression from the thread I started, yes. It outlines a maintenance problem of Postgres from backports. That's why I'd like to merge those packets into backports, at least. Better yet, back into the main Debian project. > And that's absolutely fine and that's what the stable releases in > Debian are for. Backports.org is a moving target that is there to > support backports from testing (which is obviously a moving target, > too), and people doing upgraded from stable to versions from > backports.org should hopefully be aware of that. New version usually > mean new interfaces for working with them, and I don't see why this > should be considered differently for postgres ... I disagree here. If backported packages don't even try to be as stable as the stable version they are backported to, there's no point in backporting. Testing is a movable target, yes. But backports shouldn't be, IMO. Otherwise, why should I use backports at all? > People who are worried about downtimes for upgrades should never follow > a moving target, might it be testing, backports.org or anything else. Sure? The backports.org website describes the project as follows: "You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in." That's exactly how I understand what "backports" are. Striving to reach high stability for selected packages from the "future" (seen from the particular stable release). The front page continues to explain: "Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates)" So there must already be other exceptions for good reasons. > Who is this "us" by the way, so just that "we" know who we are speaking > about? In this case that should have read "me and the people from the company I'm working for". We run several etchy systems with backported Postgres 8.2 (because we need some of the 8.2 features). >>> Your argument might be valid, but it doesn't play for backports. It was >>> always clear that backports.org is about backporting packages from >>> testing. >> Okay, that's fine. >> >> In that case, 8.2 should never have been backported. > > Why do you claim so? It was a helpful ressource for quite some people. I absolutely agree. Heck we are productively using it. So do lots of other people, because they want newer software to run on a stable system. And they want the newer software to be as stable as their old system whenever possible. That's why I'm saying 8.2 shouldn't just be dropped. > Why do you think so? What makes postgres so outrageous special in this > area than any other package? I think I've explained that enough, now. >> Note that I'm not just complaining, but offering to help and do better >> myself: I continue to maintain "backports" of 8.2. > > But with that you are just adding to the diversion which you so > strongly try to fight ... What diversion do you mean here? I'm trying to get Postgres 8.2 back into backports (or testing and thus backports as well) to reduce diversion of repositories and Debian packages for Postgres. Responses to this effort and downloads from my repository indicate, that there are enough other people wanting a stable and maintained Postgres 8.2 from Debian. > But you haven't cross-posted it to the debian-project list (which > doesn't rule backports.org currently, but there's work underway here). I > guess having your original mail not sent to backports-users was a > mistake, you did bounce it there later. I didn't know that, sorry. I'm already cross-posting to three mailing lists. How complicated can "wanting to help" be? Why does a mailing list as general as a "debian-project" list need to deal with such an issue? >> No. The Debian project could perfectly well drop it as soon as upstream >> drops support for it (which has often been around five years after the >> initial release, so far). > > Erm, that's extremely kind of you. Do you really want to go the path of > claiming that it's non-debian's decisions when Debian drops support for > a package? I consider
[GENERAL] DBD::Pg 2.10.7 compile failed on RH4
Hello, we have 32-bit PostgreSQL version 8.3.4 on 64-bit RHEL4 , Postgres itself is working as expected. We are using PostreSQL via following perl version # perl -v This is perl, v5.10.0 built for i686-linux-thread-multi (with 4 registered patches, see perl -V for more detail) Copyright 1987-2007, Larry Wall Binary build 1004 [287188] provided by ActiveState http://www.ActiveState.com Built Sep 3 2008 11:22:08 Our problem is that DBD::Pg version 2.10.7 will not compile , /usr/bin/ld skips all libpq files as incompatible - please see a slice of the result below : rm -f blib/arch/auto/DBD/Pg/Pg.so LD_RUN_PATH="/usr/lib" gcc -shared -O2 Pg.o dbdimp.o quote.o types.o -o blib/arch/auto/DBD/Pg/Pg.so \ -L/usr/lib -lpq -lm \ /usr/bin/ld: skipping incompatible /usr/lib/libpq.so when searching for -lpq /usr/bin/ld: skipping incompatible /usr/lib/libpq.a when searching for -lpq /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../libpq.so when searching for -lpq /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../libpq.a when searching for -lpq /usr/bin/ld: skipping incompatible /usr/lib/libpq.so when searching for -lpq /usr/bin/ld: skipping incompatible /usr/lib/libpq.a when searching for -lpq /usr/bin/ld: cannot find -lpq collect2: ld returned 1 exit status make: *** [blib/arch/auto/DBD/Pg/Pg.so] Error 1 libpq files available ( actually there seems to be only 1 file=/usr/lib/libpq.so.5.1 with 2 links to it ) are as below : # find / -name libpq.so* /usr/lib/libpq.so.5.1 /usr/lib/libpq.so /usr/lib/libpq.so.5 # ll /usr/lib/libpq.so.5.1 -rwxr-xr-x 1 root root 122616 Sep 20 18:52 /usr/lib/libpq.so.5.1 # ll /usr/lib/libpq.so lrwxrwxrwx 1 root root 12 Oct 6 14:06 /usr/lib/libpq.so -> libpq.so.5.1 # ll /usr/lib/libpq.so.5 lrwxrwxrwx 1 root root 12 Oct 6 14:05 /usr/lib/libpq.so.5 -> libpq.so.5.1 # file /usr/lib/libpq.so.5.1 /usr/lib/libpq.so.5.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped # I assume that something is mixed here (=32/64-bit) because linker claims for incompatibility - but because there is only 1 libpq created by Postgres install, I'm a bit lost. Should we use some other linker version ? Any ideas how to proceed ? Best Regards, Tapio -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] how to remove the duplicate records from a table
2008/10/7 Yi Zhao <[EMAIL PROTECTED]>: > I have a table contains some duplicate records, and this table create > without oids, for example: > id | temp_id > +- > 10 | 1 > 10 | 1 > 10 | 1 > 20 | 4 > 20 | 4 > 30 | 5 > 30 | 5 > I want get the duplicated records removed and only one is reserved, so > the results is: > 10 1 > 20 4 > 30 5 > > I know create a temp table will resolve this problem, but I don't want > this way:) > > can someone tell me a simple methold? > > any help is appreciated, > > thanks, > > I would not say this is easier 1. alter table t add key serial; 2. delete from table where key not in (select max(key) from table group on id,temp_id); The truth is this is not any less work then using a temporary table (whole table still needs rewriting). Which method you select really depends on why these duplicate records exist in the first place. Regards Peter -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
