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.

-----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.

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/

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&amp;aid=1000733&amp;group_id=1000007&amp;atid=126

-----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

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:

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/

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."

# 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

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:

-----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

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/&gt;

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/

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

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/&quot; 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/&gt;

---------------------------(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

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)

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