Thread: vista
has anybody gotten postgresql to install successfully under Windows Vista?
John Meyer wrote:
> has anybody gotten postgresql to install successfully under Windows Vista?
It's not out yet ;)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
--
=== 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/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/18/06 22:32, Joshua D. Drake wrote: > John Meyer wrote: >> has anybody gotten postgresql to install successfully under Windows >> Vista? > > It's not out yet ;) Release Candidates are, for the very purpose of allowing ISVs to have their s/w ready on time. But then, people who use Windows are just as scurvy as those scurvy dogs who use PHP and MySQL. Arrrr. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFD3NRS9HxQb37XmcRAjkwAKDLjM1pYEpUu9LRzMznmZYpkJl7AACgp7VG gQZx4msPMI0RfkL6SewZU6E= =WWrT -----END PGP SIGNATURE-----
Ron Johnson <ron.l.johnson@cox.net> writes:
> On 09/18/06 22:32, Joshua D. Drake wrote:
>> John Meyer wrote:
>>> has anybody gotten postgresql to install successfully under Windows
>>> Vista?
>>
>> It's not out yet ;)
> Release Candidates are, for the very purpose of allowing ISVs to
> have their s/w ready on time.
> But then, people who use Windows are just as scurvy as those scurvy
> dogs who use PHP and MySQL. Arrrr.
Well, we are entirely ready to accept patches from any Windows Vista
beta testers who are able to find and fix portability issues.
It's the folks who think that non-Windows-using developers should care
about Vista that bug me. This is open-source code, people. Scratch
your own itch.
regards, tom lane
Tom Lane wrote: > Ron Johnson <ron.l.johnson@cox.net> writes: > >> On 09/18/06 22:32, Joshua D. Drake wrote: >> >>> John Meyer wrote: >>> >>>> has anybody gotten postgresql to install successfully under Windows >>>> Vista? >>>> >>> It's not out yet ;) >>> > > >> Release Candidates are, for the very purpose of allowing ISVs to >> have their s/w ready on time. >> > > >> But then, people who use Windows are just as scurvy as those scurvy >> dogs who use PHP and MySQL. Arrrr. >> > > Well, we are entirely ready to accept patches from any Windows Vista > beta testers who are able to find and fix portability issues. > > It's the folks who think that non-Windows-using developers should care > about Vista that bug me. This is open-source code, people. Scratch > your own itch. > > One issue I've found in installation is that you are unable to create the user postgresql (and yes, I have run it in Administrator mode)
> > Well, we are entirely ready to accept patches from any Windows > Vista > > beta testers who are able to find and fix portability issues. > > > > It's the folks who think that non-Windows-using developers should > care > > about Vista that bug me. This is open-source code, people. > Scratch > > your own itch. > > > > > > > One issue I've found in installation is that you are unable to > create the user postgresql (and yes, I have run it in Administrator > mode) What error, exactly, did you get? Can you please open a bug for it on http://pgfoundry.org/projects/pginstaller, as this is clearly an installer issue and not a backend issue. Did it work well once you had created the user manually? //Magnus
> -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Tom Lane > Sent: 19 September 2006 05:43 > To: Ron Johnson > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] vista > > Ron Johnson <ron.l.johnson@cox.net> writes: > > On 09/18/06 22:32, Joshua D. Drake wrote: > >> John Meyer wrote: > >>> has anybody gotten postgresql to install successfully > under Windows > >>> Vista? > >> > >> It's not out yet ;) > > > Release Candidates are, for the very purpose of allowing ISVs to > > have their s/w ready on time. > > > But then, people who use Windows are just as scurvy as those scurvy > > dogs who use PHP and MySQL. Arrrr. > > Well, we are entirely ready to accept patches from any Windows Vista > beta testers who are able to find and fix portability issues. If it would run under VMWare, I would, however the last CTP wouldn't when I tested it (at the PG code sprint in fact). There is an update to VMWare that I don't have yet though, so if I get time I'll try that somewhen, but frankly it's low priority. Regards, Dave.
> It's the folks who think that non-Windows-using developers should care > about Vista that bug me. This is open-source code, people. Scratch > your own itch. > The "scratch your own itch" line can only be pushed so far, if it is being said by a developer who works on a project that desires to be taken seriously by professionals in industry. For minor features, yes, perhaps it could be argued that the core team could ignore certain issues, and just wait for a patch. For something like Vista compatibility, if you want to be taken seriously by anyone who uses Windows (hands up anyone who knows a Windows user), "scratch your own itch" is not really going to cut it, IMHO. I'm used to getting that line when talking to 2 developer obscure projects that have a userbase of a half a dozen, but for a project like PostgreSQL, the "they tell you to do it yourself" brush is one we do NOT want to get tarred with. If we don't have the resources to cope with a Vista port immediately then so be it. If it's low priority, so be it. However, lets not appear to deride as unnecessary that which we cannot immediately provide a solution to. That's small time project mentality. - Naz.
> -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Naz Gassiep > Sent: 19 September 2006 12:26 > To: Tom Lane > Cc: Ron Johnson; pgsql-general@postgresql.org > Subject: Re: [GENERAL] vista > > > The "scratch your own itch" line can only be pushed so far, if it is > being said by a developer who works on a project that desires to be > taken seriously by professionals in industry. For minor > features, yes, > perhaps it could be argued that the core team could ignore certain > issues, and just wait for a patch. For something like Vista > compatibility, if you want to be taken seriously by anyone who uses > Windows (hands up anyone who knows a Windows user), "scratch your own > itch" is not really going to cut it, IMHO. I'm used to > getting that line > when talking to 2 developer obscure projects that have a > userbase of a > half a dozen, but for a project like PostgreSQL, the "they > tell you to > do it yourself" brush is one we do NOT want to get tarred with. So what do you suggest? -core vote and "order" someone to do the work? Postgresql.org isn't a business and doesn't employ any developer - we only have the option of accepting patches from people/companies with itches. Regards, Dave.
> > So what do you suggest? -core vote and "order" someone to do the work? > Postgresql.org isn't a business and doesn't employ any developer - we > only have the option of accepting patches from people/companies with > itches. > I don't suggest any chance to any structures in place, it's a purely PR point. "That's important and we acknowledge the need." Even in the absence of any progress on that item, a statement like this sounds better to PHBs than "If you need it, submit a patch." Regards, - Naz.
# naz@mira.net / 2006-09-19 21:26:16 +1000:
> if you want to be taken seriously by anyone who uses Windows (hands up
> anyone who knows a Windows user)
1. what do those two things have in common?
2. what makes you think that "anyone who uses Windows" runs
PostgreSQL on it?
3. my guess is you're a Windows programmer, and thus in much better
position to fix the issue than Tom RedHat Lane.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
> -----Original Message----- > From: Naz Gassiep [mailto:naz@mira.net] > Sent: 19 September 2006 14:06 > To: Dave Page > Cc: Tom Lane; Ron Johnson; pgsql-general@postgresql.org > Subject: Re: [GENERAL] vista > > "That's important and we acknowledge the need." > Even in the absence of any progress on that item, a statement > like this > sounds better to PHBs than > "If you need it, submit a patch." In which case there's a good chance no-one will do the work. An awful lot of the features in and surrounding PostgreSQL only got developed because someone couldn't find the feature they wanted and were encouraged to work on it themselves. pgAdmin got started in almost exactly that way for example. Regards, Dave
On 9/19/06, Roman Neuhauser <neuhauser@sigpipe.cz> wrote: > # naz@mira.net / 2006-09-19 21:26:16 +1000: > > if you want to be taken seriously by anyone who uses Windows (hands up > > anyone who knows a Windows user) > > 1. what do those two things have in common? > 2. what makes you think that "anyone who uses Windows" runs > PostgreSQL on it? > 3. my guess is you're a Windows programmer, and thus in much better > position to fix the issue than Tom RedHat Lane. His point makes sense, Roman. While pg is not a company or a company product, it certainly needs to play nice with business in order for it to *have* (a significent number of) users. As much as I dislike it (probably the euphemism of the year), Windows is a fact on most development machines and on a substantial number of servers. In the case of Vista, even if none of the core commiters plan to support it, it makes a lot more sense to store the RFE and say it'll have to wait, than to say "you got a problem? go fix it". Both attitudes reflect the same reality, but the fact that one is positive and one negative is obvious. Cheers, t.n.a.
Dave Page wrote:
> because someone couldn't find the feature they wanted and were
> encouraged to work on it themselves. pgAdmin got started in almost
^^^^^^^^^^
That's the key word here, "encouraged", not "discouraged". IMHO telling
a Windows user to go do it himself is discouraging. Quite impolite too.
It is not much harder to say "We currently don't have the resources to
look into that, if you could be so kind to experiment a bit and see if
you can get it to work...".
It might even invite other readers of this ML to look into it instead.
Regards,
--
Alban Hertroys
alban@magproductions.nl
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
Tomi NA wrote: > On 9/19/06, Roman Neuhauser <neuhauser@sigpipe.cz> wrote: >> # naz@mira.net / 2006-09-19 21:26:16 +1000: >> > if you want to be taken seriously by anyone who uses Windows (hands up >> > anyone who knows a Windows user) >> >> 1. what do those two things have in common? >> 2. what makes you think that "anyone who uses Windows" runs >> PostgreSQL on it? >> 3. my guess is you're a Windows programmer, and thus in much better >> position to fix the issue than Tom RedHat Lane. > > His point makes sense, Roman. While pg is not a company or a company > product, it certainly needs to play nice with business in order for it > to *have* (a significent number of) users. As much as I dislike it > (probably the euphemism of the year), Windows is a fact on most > development machines and on a substantial number of servers. In the > case of Vista, even if none of the core commiters plan to support it, > it makes a lot more sense to store the RFE and say it'll have to wait, > than to say "you got a problem? go fix it". Both attitudes reflect the > same reality, but the fact that one is positive and one negative is > obvious. The response is not because it's Windows. The response 'to provide a patch' is made to anyone who would like to see a particular functionality in the application that the core group is not working on or is not on their radar. This is being made into a 'Windows vs..' thing and that's just not the case. I've seen folks suggest someone provide a patch for non-windows environments more so then windows environments. Although Tom's response may have seemed to be negative towards windows, the original posting had a bit of an attitude to start with. 'if you want to be taken seriously by anyone who uses Windows (hands up anyone who knows a Windows user)' -- Until later, Geoffrey Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
In response to "Tomi NA" <hefest@gmail.com>: > On 9/19/06, Roman Neuhauser <neuhauser@sigpipe.cz> wrote: > > # naz@mira.net / 2006-09-19 21:26:16 +1000: > > > if you want to be taken seriously by anyone who uses Windows (hands up > > > anyone who knows a Windows user) > > > > 1. what do those two things have in common? > > 2. what makes you think that "anyone who uses Windows" runs > > PostgreSQL on it? > > 3. my guess is you're a Windows programmer, and thus in much better > > position to fix the issue than Tom RedHat Lane. > > His point makes sense, Roman. While pg is not a company or a company > product, it certainly needs to play nice with business in order for it > to *have* (a significent number of) users. As much as I dislike it > (probably the euphemism of the year), Windows is a fact on most > development machines and on a substantial number of servers. In the > case of Vista, even if none of the core commiters plan to support it, > it makes a lot more sense to store the RFE and say it'll have to wait, > than to say "you got a problem? go fix it". Both attitudes reflect the > same reality, but the fact that one is positive and one negative is > obvious. To take a step back ... I think PostgreSQL is suffering from popularity. I remember when I first tried to get it up and running in the last 90s, and failed. There were some post-installation steps that I couldn't figure out at that time, so I jumped on the MySQL bandwagon for a few years. Nowadays, getting PostgreSQL running on FreeBSD is as easy as "make install". Now that you have a Windows installer, it's even easier. This means there's an influx of a new type of people. Back in the late 90s, the only people using PostgreSQL were those with enough smarts and patience to figure out how to get it running. But this new influx isn't just "less knowledgeable people" -- by making PostgreSQL available on Windows, we've crossed a cultural barrier. People in the Windows world think very differently than those from the OSS world (in general). Some specific cultural differences I see: Business: How much to get feature X implemented? OSS: How much are you willing to donate, and I'll do what I can. Business: Please give me a timeline for the when X will be done. OSS: It'll be done when we know it's right. Business: Who can I hire to write feature X? OSS: It's not interesting, if you want it, go ahead and do it. Business: If I pay someone to write X, will you include it in the main tree? OSS: We'll include any code in the tree, if it's _good_. There are some subtle differences in the way things are approached there, but they can be showstoppers when it comes to OSS and business working together. And the simple fact is that Windows is business, not software. "If you can solve the communication problems, everything else will just happen." Just my opinions from observing this and other similar conversations. -- Bill Moran Collaborative Fusion Inc.
I think the itch and scratch line is entirely appropriate. This is open source software, not prepackaged code guaranteed to work on the newest platforms. People who are trying it out on Vista are developers, not non-technical end-users. A developer who wants an open source product to work on a new platform should at least see what the problems are and then ask for help in fixing it, if he can't fix it himself. One of the big advantages of open source software is that business can see that if someone wants it to work on Vista, they can pay a programmer to get it to work on Vista and then submit the patch so that the rest of the community benefits as well. I would guess (being that it works fine in Windows XP), though I haven't even seen Vista yet, that the problem is relatively minor and going through the code with a debugger would probably allow the app to be installed within a couple hours. There may be a polite way of saying it, but you use that polite voice when talking to an end-user. When you're talking to a developer, I think you should say it like it is. Tomi NA wrote: > On 9/19/06, Roman Neuhauser <neuhauser@sigpipe.cz> wrote: >> # naz@mira.net / 2006-09-19 21:26:16 +1000: >> > if you want to be taken seriously by anyone who uses Windows (hands up >> > anyone who knows a Windows user) >> >> 1. what do those two things have in common? >> 2. what makes you think that "anyone who uses Windows" runs >> PostgreSQL on it? >> 3. my guess is you're a Windows programmer, and thus in much better >> position to fix the issue than Tom RedHat Lane. > > His point makes sense, Roman. While pg is not a company or a company > product, it certainly needs to play nice with business in order for it > to *have* (a significent number of) users. As much as I dislike it > (probably the euphemism of the year), Windows is a fact on most > development machines and on a substantial number of servers. In the > case of Vista, even if none of the core commiters plan to support it, > it makes a lot more sense to store the RFE and say it'll have to wait, > than to say "you got a problem? go fix it". Both attitudes reflect the > same reality, but the fact that one is positive and one negative is > obvious. > > Cheers, > t.n.a. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
On Tue, Sep 19, 2006 at 03:34:47PM +0200, Alban Hertroys wrote: > It is not much harder to say "We currently don't have the resources to > look into that, if you could be so kind to experiment a bit and see if > you can get it to work...". Except that would be a lie. Perhaps: "Postgresql developers do not have the ability to force anyone to do this. The best idea is if you could be so kind to experiment a bit and see if you can get it to work...". "We" have no resources to direct, or to look into things. Only individual developers (or their employers) can direct their own resources. If Vista is so important, why aren't seeing a rash of installation reports about it working (or not). Why hasn't someone offered to setup a buildfarm machine? Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
John Meyer wrote: > has anybody gotten postgresql to install successfully under Windows > Vista? > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > BTW, here's the issue at the pgFoundary http://pgfoundry.org/tracker/index.php?func=detail&aid=1000733&group_id=1000007&atid=126
> Although Tom's response may have seemed to be negative towards windows, > the original posting had a bit of an attitude to start with. Actually the original poster asked "has anybody gotten postgresql to install successfully under Windows Vista?" To which the answer should have been, "no. Send us the patch when you get it working."
> -----Original Message----- > From: Martijn van Oosterhout [mailto:kleptog@svana.org] > Sent: 19 September 2006 15:10 > To: Alban Hertroys > Cc: Dave Page; Naz Gassiep; Tom Lane; Ron Johnson; > pgsql-general@postgresql.org > Subject: Re: [GENERAL] vista > > If Vista is so important, why aren't seeing a rash of installation > reports about it working (or not). Why hasn't someone offered to setup > a buildfarm machine? Actually I did, but the most recent CTP didn't run under VMWare as I mentioned earlier. Still, the show stopper on the first release which I *really* briefly tested it on was that the installer couldn't create a service user account as I think started this thread. This is most likely Vista's tightened security model - the easy answer to which will probably be to simply run as the installing user, Administrator or better yet, Network Service (or whatever it's called). Now that we dump all privileges on startup it's less of an issue if we cannot create our own account. Regards, Dave.
Naz Gassiep <naz@mira.net> writes:
> For something like Vista
> compatibility, if you want to be taken seriously by anyone who uses
> Windows (hands up anyone who knows a Windows user), "scratch your own
> itch" is not really going to cut it, IMHO.
I was responding to someone who is obviously a Windows beta tester and
therefore presumably has more clue than the average Windows-oid ---
asking for a patch didn't seem unreasonable. But for arguments like the
above, I will happily say "apparently you've confused me with someone
who gives a damn about Windows".
regards, tom lane
> taken seriously by professionals in industry. For minor features, yes,
> perhaps it could be argued that the core team could ignore certain
> issues, and just wait for a patch. For something like Vista
> compatibility, if you want to be taken seriously by anyone who uses
> Windows (hands up anyone who knows a Windows user), "scratch your own
> itch" is not really going to cut it,
Then they can purchase MSSQL. No sweat off my back.
> IMHO. I'm used to getting that line
> when talking to 2 developer obscure projects that have a userbase of a
> half a dozen, but for a project like PostgreSQL, the "they tell you to
> do it yourself" brush is one we do NOT want to get tarred with.
>
> If we don't have the resources to cope with a Vista port immediately
> then so be it. If it's low priority, so be it. However, lets not appear
> to deride as unnecessary that which we cannot immediately provide a
> solution to. That's small time project mentality.
Asking someone to submit a patch is completely acceptable in this project.
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/
Roman Neuhauser wrote:
> # naz@mira.net / 2006-09-19 21:26:16 +1000:
>> if you want to be taken seriously by anyone who uses Windows (hands up
>> anyone who knows a Windows user)
>
> 1. what do those two things have in common?
> 2. what makes you think that "anyone who uses Windows" runs
> PostgreSQL on it?
Well I can tell you that lots of people run PostgreSQL on Windows. :).
> 3. my guess is you're a Windows programmer, and thus in much better
> position to fix the issue than Tom RedHat Lane.
Tom RedHat Lane... Hmmmm ;)
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/
Perhaps many of the core developers don't care if windows users take the project seriously? On Sep 19, 2006, at 4:26 AM, Naz Gassiep wrote: > >> It's the folks who think that non-Windows-using developers should >> care >> about Vista that bug me. This is open-source code, people. Scratch >> your own itch. >> > The "scratch your own itch" line can only be pushed so far, if it > is being said by a developer who works on a project that desires to > be taken seriously by professionals in industry. For minor > features, yes, perhaps it could be argued that the core team could > ignore certain issues, and just wait for a patch. For something > like Vista compatibility, if you want to be taken seriously by > anyone who uses Windows (hands up anyone who knows a Windows user), > "scratch your own itch" is not really going to cut it, IMHO. I'm > used to getting that line when talking to 2 developer obscure > projects that have a userbase of a half a dozen, but for a project > like PostgreSQL, the "they tell you to do it yourself" brush is one > we do NOT want to get tarred with. > > If we don't have the resources to cope with a Vista port > immediately then so be it. If it's low priority, so be it. However, > lets not appear to deride as unnecessary that which we cannot > immediately provide a solution to. That's small time project > mentality. > > - Naz. > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
> -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Ben > Sent: 19 September 2006 17:03 > To: Naz Gassiep > Cc: Tom Lane; Ron Johnson; pgsql-general@postgresql.org > Subject: Re: [GENERAL] vista > > Perhaps many of the core developers don't care if windows users take > the project seriously? Somehow I doubt that given that I was invited to join core precisely because of my work on the Windows distro. I would think that implies that at least 50% of the other members think the port is important. Regards, Dave
On Tue, Sep 19, 2006 at 05:11:54PM +0100, Dave Page wrote: > > Perhaps many of the core developers don't care if windows users take > > the project seriously? > > Somehow I doubt that given that I was invited to join core precisely > because of my work on the Windows distro. I would think that implies > that at least 50% of the other members think the port is important. Indeed. The people in core are not going to stand in the way of a good patch that will fix a problem for windows. But neither are they going to spend their own time debugging a platform they have no experience with. At the end of the day any problems with Vista are going to have to be fixed by people with the OS, compiler, debugging expertise and time to do it. The fact is that most people here don't have that. The same criteria applies to every other platform. So basically, anyone out there who meets the above criteria? Now is the time to show it. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
Ben wrote:
> Perhaps many of the core developers don't care if windows users take the
> project seriously?
Well that may or may not be true, but isn't really relevant. What is
relevant is that *any* community user would have been told the *exact*
same thing. Regardless of OS.
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/
Hello -
I am observing odd behavior that I am wondering if anyone here may have an
idea of how better to debug. I am suspecting a bug in the pgsql code, but
would be happy to find it is my error.
My specific situation is that I am using version 8.1.4 on a FreeBSD 6.1
AMD-64 system. I have a table with about 15000 records in it, which I
would like to add a new column to. The alter command shows success.
However, testing inserts reveals that the data for the new column is never
stored. Running the same exercise against the identical schema but with
only a few records finds that the test succeeds, and hence the problem is
not easily recreated. Experimentation has shown that the type of the
column doesn't matter. If the column has NOT NULL DEFAULT {value} added,
then it magically works.
A trivial example of the exercise is shown here:
create table foo (id bigserial);
insert into foo (id) values (8);
alter table foo add source_record bigint;
insert into foo (id,source_record) values (10,20);
select * from foo;
id | source_record
----+---------------
8 |
10 | 20
If I populate the table foo above with 15000 records, the exercise still
works OK. The only difference that I and others staring at this problem
see is that the real-world table contains a more complex definition,
included here for reference:
Column | Type | Modifiers
--------------------+-----------------------------+---------------------------------------------------------
id | bigint | not null default nextval('audit_logs_id_seq'::regclass)
timestamp | timestamp without time zone | not null default now()
notify_at | timestamp without time zone |
audit_log_type_id | bigint | not null
sdp_id | bigint |
customer_id | bigint |
customer_region_id | integer |
audit_format_id | bigint | not null
msg_args | text[] |
arg_names | text[] |
source_record | bigint |
Indexes:
"audit_logs_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
"audit_logs_audit_format_id_fkey" FOREIGN KEY (audit_format_id) REFERENCES audit_formats(id) ON DELETE RESTRICT
"audit_logs_audit_log_type_id_fkey" FOREIGN KEY (audit_log_type_id) REFERENCES audit_log_types(id) ON DELETE
RESTRICT
"audit_logs_audit_log_type_id_fkey1" FOREIGN KEY (audit_log_type_id) REFERENCES audit_log_types(id) ON DELETE
RESTRICT
"audit_logs_customer_id_fkey" FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE RESTRICT
"audit_logs_customer_region_id_fkey" FOREIGN KEY (customer_region_id) REFERENCES customer_regions(id) ON DELETE
RESTRICT
"audit_logs_sdp_id_fkey" FOREIGN KEY (sdp_id) REFERENCES sdps(id) ON DELETE RESTRICT
Triggers:
audit_log_delete_trigger BEFORE DELETE ON audit_logs FOR EACH ROW EXECUTE PROCEDURE audit_log_delete_restrict()
Does anybody have a suggestion about how to debug this?
Thanks in advance - Marc
naz@mira.net (Naz Gassiep) writes: >> It's the folks who think that non-Windows-using developers should care >> about Vista that bug me. This is open-source code, people. Scratch >> your own itch. >> > The "scratch your own itch" line can only be pushed so far, if it is > being said by a developer who works on a project that desires to be > taken seriously by professionals in industry. For minor features, yes, > perhaps it could be argued that the core team could ignore certain > issues, and just wait for a patch. For something like Vista > compatibility, if you want to be taken seriously by anyone who uses > Windows (hands up anyone who knows a Windows user), "scratch your own > itch" is not really going to cut it, IMHO. I'm used to getting that > line when talking to 2 developer obscure projects that have a userbase > of a half a dozen, but for a project like PostgreSQL, the "they tell > you to do it yourself" brush is one we do NOT want to get tarred with. > > If we don't have the resources to cope with a Vista port immediately > then so be it. If it's low priority, so be it. However, lets not > appear to deride as unnecessary that which we cannot immediately > provide a solution to. That's small time project mentality. Well, the same issue has come up with the subproject that I work on, namely Slony-I, and the nature of things seems much the same. *I* don't use Windows, haven't got any relevant build environment, and, organizationally, really couldn't care less if PostgreSQL or Slony-I runs on Windows or not, as Windows isn't a relevant platform. Asking me about Windows support in *any* context is pretty much useless; as far as I'm concerned, Windows support requires finding someone who has that particular itch. It turns out that there are people with a Windows itch, and I haven't turned away patches to provide Windows support due to its irrelevance to me. No, I'm pleased enough to see that come in. But if you present Windows-related issues to me, I see nothing improper in saying "scratch your own itch." I'm *not* the right one to help, and the community is large enough that I don't see any problem with that. -- select 'cbbrowne' || '@' || 'cbbrowne.com'; http://linuxfinances.info/info/advocacy.html Rules of the Evil Overlord #196. "I will hire an expert marksman to stand by the entrance to my fortress. His job will be to shoot anyone who rides up to challenge me." <http://www.eviloverlord.com/>
Marc Evans <Marc@SoftwareHackery.Com> writes:
> ... I have a table with about 15000 records in it, which I
> would like to add a new column to. The alter command shows success.
> However, testing inserts reveals that the data for the new column is never
> stored.
What do you mean by that exactly? The example you showed seems to be
doing just what it's supposed to.
regards, tom lane
On Tue, 19 Sep 2006, Tom Lane wrote: > Marc Evans <Marc@SoftwareHackery.Com> writes: >> ... I have a table with about 15000 records in it, which I >> would like to add a new column to. The alter command shows success. >> However, testing inserts reveals that the data for the new column is never >> stored. > > What do you mean by that exactly? The example you showed seems to be > doing just what it's supposed to. In the failure mode, the source_record column always has the value NULL, regardless of any value specified in an insert. If I use UPDATE to change a record, the value is properly stored. - Marc
Marc Evans <Marc@SoftwareHackery.Com> writes:
> On Tue, 19 Sep 2006, Tom Lane wrote:
>> What do you mean by that exactly? The example you showed seems to be
>> doing just what it's supposed to.
> In the failure mode, the source_record column always has the value NULL,
> regardless of any value specified in an insert.
What insert command is being issued exactly, and from what source? I'm
speculating about issues like stale plans or metadata caches, but you're
not providing any information about where to look.
regards, tom lane
On Tue, 19 Sep 2006, Tom Lane wrote:
> Marc Evans <Marc@SoftwareHackery.Com> writes:
>> On Tue, 19 Sep 2006, Tom Lane wrote:
>>> What do you mean by that exactly? The example you showed seems to be
>>> doing just what it's supposed to.
>
>> In the failure mode, the source_record column always has the value NULL,
>> regardless of any value specified in an insert.
>
> What insert command is being issued exactly, and from what source? I'm
> speculating about issues like stale plans or metadata caches, but you're
> not providing any information about where to look.
Sorry for being terse Tom. Here is the exact commands and responses:
insert into audit_logs (audit_log_type_id,source_record,audit_format_id) values (3,20,71);
INSERT 0 1
select * from audit_logs order by timestamp desc;
id | timestamp | notify_at | audit_log_type_id | sdp_id | customer_id |
customer_region_id| audit_format_id | msg_args
| arg_names | source_record
-------+----------------------------+----------------------------+-------------------+--------+-------------+--------------------+-----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+---------------
15646 | 2006-09-19 17:18:10.074006 | 2006-09-19 17:18:10.190341 | 3 | | |
| 71 | | |
update audit_logs set source_record = 10101 where id = 15646;
UPDATE 1
select * from audit_logs where id=15646;
id | timestamp | notify_at |
audit_log_type_id | sdp_id | customer_id | customer_region_id | audit_format_id | msg_args | arg_names | source_record
-------+----------------------------+----------------------------+-------------------+--------+-------------+--------------------+-----------------+----------+-----------+---------------
15646 | 2006-09-19 17:18:10.074006 | 2006-09-19 17:18:10.190341 | 3 | | |
| 71 | | | 10101
Does that help any?
- Marc
Marc Evans <Marc@SoftwareHackery.Com> writes:
> On Tue, 19 Sep 2006, Tom Lane wrote:
>> What insert command is being issued exactly, and from what source? I'm
>> speculating about issues like stale plans or metadata caches, but you're
>> not providing any information about where to look.
> Sorry for being terse Tom. Here is the exact commands and responses:
Hmph. You got any ON INSERT triggers or rules on that table? I can't
think of anything else that would interfere with data getting stored.
regards, tom lane
On Tue, 19 Sep 2006, Tom Lane wrote: > Marc Evans <Marc@SoftwareHackery.Com> writes: >> On Tue, 19 Sep 2006, Tom Lane wrote: >>> What insert command is being issued exactly, and from what source? I'm >>> speculating about issues like stale plans or metadata caches, but you're >>> not providing any information about where to look. > >> Sorry for being terse Tom. Here is the exact commands and responses: > > Hmph. You got any ON INSERT triggers or rules on that table? I can't > think of anything else that would interfere with data getting stored. No INSERT triggers. I do have a BEFORE DELETE trigger, and a pile of FOREIGN KEY items (which work kinda like an INSERT trigger). - Marc
So... If you're not a PostgreSQL Win32 port dev, and *don't know* what they're up to as far as Vista, why respond to the Q? Or why respond "fix it yourself" instead of "ask this guy" or "nobody here will know yet" or "post your query on -ports or -hackers". Otherwise it's as useful as saying "http://justgoogleit.com/" or "check the man pages". While technically a correct response, it's not a very useful one and certainly not what the poster was asking, yes? It's like a "SELECT * ..." statement returning a single row with an asterisk in it. Gee, thanks for the tautology. Heck, even "check CVS change logs" would be more useful. Presumably *a* person on the dev team will handle it eventually. And it's not unreasonable to expect that somebody, somewhere has asked the same question to the dev team and that they *might* know something about the state of PG on that platform. Frankly, I too could care less about PG on Vista. Longhorn isn't due until Vista SP1, so PG support has a long time to go before it's a real concern. But then I didn't try to answer the question. -- Brandon Aiken CS/IT Systems Engineer -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Chris Browne Sent: Tuesday, September 19, 2006 12:16 PM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] vista naz@mira.net (Naz Gassiep) writes: >> It's the folks who think that non-Windows-using developers should care >> about Vista that bug me. This is open-source code, people. Scratch >> your own itch. >> > The "scratch your own itch" line can only be pushed so far, if it is > being said by a developer who works on a project that desires to be > taken seriously by professionals in industry. For minor features, yes, > perhaps it could be argued that the core team could ignore certain > issues, and just wait for a patch. For something like Vista > compatibility, if you want to be taken seriously by anyone who uses > Windows (hands up anyone who knows a Windows user), "scratch your own > itch" is not really going to cut it, IMHO. I'm used to getting that > line when talking to 2 developer obscure projects that have a userbase > of a half a dozen, but for a project like PostgreSQL, the "they tell > you to do it yourself" brush is one we do NOT want to get tarred with. > > If we don't have the resources to cope with a Vista port immediately > then so be it. If it's low priority, so be it. However, lets not > appear to deride as unnecessary that which we cannot immediately > provide a solution to. That's small time project mentality. Well, the same issue has come up with the subproject that I work on, namely Slony-I, and the nature of things seems much the same. *I* don't use Windows, haven't got any relevant build environment, and, organizationally, really couldn't care less if PostgreSQL or Slony-I runs on Windows or not, as Windows isn't a relevant platform. Asking me about Windows support in *any* context is pretty much useless; as far as I'm concerned, Windows support requires finding someone who has that particular itch. It turns out that there are people with a Windows itch, and I haven't turned away patches to provide Windows support due to its irrelevance to me. No, I'm pleased enough to see that come in. But if you present Windows-related issues to me, I see nothing improper in saying "scratch your own itch." I'm *not* the right one to help, and the community is large enough that I don't see any problem with that. -- select 'cbbrowne' || '@' || 'cbbrowne.com'; http://linuxfinances.info/info/advocacy.html Rules of the Evil Overlord #196. "I will hire an expert marksman to stand by the entrance to my fortress. His job will be to shoot anyone who rides up to challenge me." <http://www.eviloverlord.com/> ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Marc Evans <Marc@SoftwareHackery.Com> writes:
> On Tue, 19 Sep 2006, Tom Lane wrote:
>> Hmph. You got any ON INSERT triggers or rules on that table? I can't
>> think of anything else that would interfere with data getting stored.
> No INSERT triggers. I do have a BEFORE DELETE trigger, and a pile of
> FOREIGN KEY items (which work kinda like an INSERT trigger).
Hard to see how those could be related --- but it's even harder to
credit that the INSERT would get past the parser with an explicit
reference to the new column and then not store it. I think maybe
something is applying an UPDATE to the row and losing the new value
at that point. Are any of the FKs non-default actions (ON ... SET NULL
or some such that would try to alter data instead of just erroring)?
Also, can you check the cmin field of that row and see if it's greater
than zero?
regards, tom lane
On Tue, 19 Sep 2006, Tom Lane wrote:
> Marc Evans <Marc@SoftwareHackery.Com> writes:
>> On Tue, 19 Sep 2006, Tom Lane wrote:
>>> Hmph. You got any ON INSERT triggers or rules on that table? I can't
>>> think of anything else that would interfere with data getting stored.
>
>> No INSERT triggers. I do have a BEFORE DELETE trigger, and a pile of
>> FOREIGN KEY items (which work kinda like an INSERT trigger).
>
> Hard to see how those could be related --- but it's even harder to
> credit that the INSERT would get past the parser with an explicit
> reference to the new column and then not store it. I think maybe
> something is applying an UPDATE to the row and losing the new value
> at that point. Are any of the FKs non-default actions (ON ... SET NULL
> or some such that would try to alter data instead of just erroring)?
> Also, can you check the cmin field of that row and see if it's greater
> than zero?
It is zero for the inserted row. Other rows often have a value of 11. The
complete FK and TRIGGER list is shown here:
Foreign-key constraints:
"audit_logs_audit_format_id_fkey" FOREIGN KEY (audit_format_id) REFERENCES audit_formats(id) ON DELETE RESTRICT
"audit_logs_audit_log_type_id_fkey" FOREIGN KEY (audit_log_type_id) REFERENCES audit_log_types(id) ON DELETE
RESTRICT
"audit_logs_audit_log_type_id_fkey1" FOREIGN KEY (audit_log_type_id) REFERENCES audit_log_types(id) ON DELETE
RESTRICT
"audit_logs_customer_id_fkey" FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE RESTRICT
"audit_logs_customer_region_id_fkey" FOREIGN KEY (customer_region_id) REFERENCES customer_regions(id) ON DELETE
RESTRICT
"audit_logs_sdp_id_fkey" FOREIGN KEY (sdp_id) REFERENCES sdps(id) ON DELETE RESTRICT
Triggers:
audit_log_delete_trigger BEFORE DELETE ON audit_logs FOR EACH ROW EXECUTE PROCEDURE audit_log_delete_restrict()
Any suggested tricks for seeing additional debug information or even
roaming through gdb, to try to figure this out?
Thanks again - Marc
I wrote:
> ... I think maybe
> something is applying an UPDATE to the row and losing the new value
> at that point. Are any of the FKs non-default actions (ON ... SET NULL
> or some such that would try to alter data instead of just erroring)?
I've been able to reproduce a problem that may or may not be Marc's
problem, but it's definitely a bug:
regression=# create table foo(f1 int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
CREATE TABLE
regression=# create table bar(f1 int references foo on delete set null);
CREATE TABLE
regression=# insert into foo values(1);
INSERT 0 1
regression=# insert into bar values(1);
INSERT 0 1
regression=# delete from foo;
DELETE 1
regression=# select * from bar;
f1
----
(1 row)
regression=# alter table bar add column f2 int;
ALTER TABLE
regression=# insert into foo values(1);
INSERT 0 1
regression=# insert into bar values(1,2);
INSERT 0 1
regression=# select * from bar;
f1 | f2
----+----
|
1 | 2
(2 rows)
regression=# delete from foo;
DELETE 1
regression=# select * from bar;
f1 | f2
----+----
|
|
(2 rows)
regression=#
f2 should clearly not have gotten set to null there. I believe the
problem is that we have a stale cached plan for the ON DELETE SET NULL
referential action. Still another reason why we need a plan
invalidation mechanism :-(
regards, tom lane
Marc Evans <Marc@SoftwareHackery.Com> writes:
> Any suggested tricks for seeing additional debug information or even
> roaming through gdb, to try to figure this out?
Is the problem reproducible enough that you can watch it under gdb?
In that case it shouldn't be that hard to narrow it down. I gathered
from your original statement that you couldn't reproduce it reliably.
I'd start with ExecInsert() and see if it's being passed correct info
or not, then work backwards or forwards depending.
regards, tom lane
On Tue, 19 Sep 2006, Tom Lane wrote: > Marc Evans <Marc@SoftwareHackery.Com> writes: >> Any suggested tricks for seeing additional debug information or even >> roaming through gdb, to try to figure this out? > > Is the problem reproducible enough that you can watch it under gdb? > In that case it shouldn't be that hard to narrow it down. I gathered > from your original statement that you couldn't reproduce it reliably. > > I'd start with ExecInsert() and see if it's being passed correct info > or not, then work backwards or forwards depending. Yes, 100% reproducable within the context of that I have only seen it when I have a pile of records. I have not come up with a simple-case reproduction yet (the foo table for example), though it appears that you may have. I will dive into gdb and see what I can find. Thanks! - Marc
> So... > > If you're not a PostgreSQL Win32 port dev, and *don't know* what they're > up to as far as Vista, why respond to the Q? Or why respond "fix it > yourself" instead of "ask this guy" or "nobody here will know yet" or > "post your query on -ports or -hackers". > Precisely. My point is not that people *should* care about Win32, or that some coercive system should be put into place to force devs onto RFEs, or even that we should commit to having something ready at all ever. It's a point of apparent attitude. Responding with a useless answer is *worse* than simply ignoring the question. I am not a Win32 user (at least not on servers), but if I wanted to know if Vista compatibility was being worked on getting "if you want it, go do it" would be even less useful than an effort to convince me to run the DB on a *nix back end. I'd rather have someone tell me how and why to migrate to a better OS. > Frankly, I too could care less about PG on Vista. Longhorn isn't due > until Vista SP1, so PG support has a long time to go before it's a real > concern. But then I didn't try to answer the question. > Same here. It's a matter of apparent attitude of the community to outsiders or new users. Even with something like future Win32 support, I'd rather see people being told "that issue is not important to our project because x, y and z" than "go do it yourself". Anyway, I seem to have kicked up a bit of a hornet's nest here so I'll shut up now. - Naz.
On Tue, 2006-09-19 at 10:26 -0400, Tom Lane wrote: > Naz Gassiep <naz@mira.net> writes: > > For something like Vista > > compatibility, if you want to be taken seriously by anyone who uses > > Windows (hands up anyone who knows a Windows user), "scratch your own > > itch" is not really going to cut it, IMHO. > > I was responding to someone who is obviously a Windows beta tester and > therefore presumably has more clue than the average Windows-oid --- > asking for a patch didn't seem unreasonable. But for arguments like the > above, I will happily say "apparently you've confused me with someone > who gives a damn about Windows". > > regards, tom lane Where can I buy a little plastic statue of Tom Lane for my dashboard?
Andrew Kelly wrote: > On Tue, 2006-09-19 at 10:26 -0400, Tom Lane wrote: >> Naz Gassiep <naz@mira.net> writes: >>> For something like Vista >>> compatibility, if you want to be taken seriously by anyone who uses >>> Windows (hands up anyone who knows a Windows user), "scratch your own >>> itch" is not really going to cut it, IMHO. >> I was responding to someone who is obviously a Windows beta tester and >> therefore presumably has more clue than the average Windows-oid --- >> asking for a patch didn't seem unreasonable. But for arguments like the >> above, I will happily say "apparently you've confused me with someone >> who gives a damn about Windows". >> >> regards, tom lane > > > Where can I buy a little plastic statue of Tom Lane for my dashboard? You mean the one with the hula skirt? -- Until later, Geoffrey Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
Am 2006-09-19 21:26:16, schrieb Naz Gassiep:
> The "scratch your own itch" line can only be pushed so far, if it is
> being said by a developer who works on a project that desires to be
> taken seriously by professionals in industry. For minor features, yes,
> perhaps it could be argued that the core team could ignore certain
> issues, and just wait for a patch. For something like Vista
> compatibility, if you want to be taken seriously by anyone who uses
> Windows (hands up anyone who knows a Windows user), "scratch your own
> itch" is not really going to cut it, IMHO. I'm used to getting that line
> when talking to 2 developer obscure projects that have a userbase of a
> half a dozen, but for a project like PostgreSQL, the "they tell you to
> do it yourself" brush is one we do NOT want to get tarred with.
But who sponsor a Vista machine? (Dualboot is no solution)
Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)