Re: [BUGS] BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL
Matt you are absolutely right! The msysconf is not related... Yesterday I did some test and have seen that the access is working fine with postgres as long as the SSL mode is disable, as soon as I put it enabled then it crashes on shutdown Go figure!!! Any ideas? Annita -Ursprüngliche Nachricht- Von: Matt Taylor [mailto:m...@lindenelevator.com] Gesendet: Montag, 21. September 2009 23:07 An: Annita Veneti Cc: pgsql-bugs@postgresql.org Betreff: Re: [BUGS] BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL I think the msysconf error is not related to your issue: http://archives.postgresql.org/pgadmin-support/2002-01/msg00035.php Can you query data from the data source using MS Excel? Matt Annita Veneti wrote: > Matt first thanks for the reply, > > I have check the log and it says > > Relation »msysconf« existiert nicht (that it doesn’t exist. > > I know that there is a setting in the pgAdmin to postgre create the table if > it not there. > But I cannot find it , do you have any idea? > > > Annita > > > -Ursprüngliche Nachricht- > Von: Matt Taylor [mailto:m...@lindenelevator.com] > Gesendet: Freitag, 18. September 2009 17:47 > An: Annita Veneti > Cc: pgsql-bugs@postgresql.org > Betreff: Re: [BUGS] BUG #5063: MS Access crashes by quiting after linking > tables with PostgreSQL > > Have you tried turning on row versioning in the data source? > > Matt > > > Annita wrote: >> The following bug has been logged online: >> >> Bug reference: 5063 >> Logged by: Annita >> Email address: annita.ven...@qs-unisolution.com >> PostgreSQL version: 8 >> Operating system: Windows >> Description:MS Access crashes by quiting after linking tables with >> PostgreSQL >> Details: >> >> MS Access (2003,2007) crashes by closing down , after i have linked the >> tables of my postgreSQL database. I cannot find anything relevant with this >> problem. I have tried everything, the problem has to do with the >> postgredriver since this doesnt happen when i connect with MySql or SQL. >> >> CAN ANYONE HELP??? please??? >> > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5066: plperl issues with perl_destruct() and END blocks
On Mon, Sep 21, 2009 at 07:30:51PM -0400, Tom Lane wrote: > David Fetter writes: > > On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote: > >>> With connection poolers, backends can last quite awhile. Is it OK > >>> for the END block to run hours after the rest of the code? Yes. > >> This is an interesting point -- should END blocks be called on > >> DISCARD ALL? > > > ENOCLUE > > And in the same vein, should they be called inside a transaction, > or not? What if they fail? As I said in the original ticket, I'd be quite happy for plperl END blocks to have no access to postgres at all, other than warnings going to the log. The spi_* functions could return an error if postgres is being shutdown (perhaps they already would if perl_destruct is called late in the shutdown sequence). So transactions are mute. Also, perl_destruct() will catch any exceptions from END blocks. > I don't see any reason whatsoever that we couldn't just document this > as a Perl feature not supported in plperl. If you do something like > creating threads inside plperl, we're going to give you the raspberry > when you complain about it breaking. END blocks can perfectly well > go into the same category. Returning to my original use case, the NYTProf profiler needs END blocks to work otherwise the generated profile data will be corrupt. I don't see any reason not to add PL_exit_flags |= PERL_EXIT_DESTRUCT_END; to plperl_init_interp(), and for perl_destruct() to be called late in the shutdown sequence. Tim. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5072: User trying to drop an internally dependent object crashes server
The following bug has been logged online:
Bug reference: 5072
Logged by: Amit Khandekar
Email address: amit.khande...@enterprisedb.com
PostgreSQL version: 8.5devel
Operating system: All
Description:User trying to drop an internally dependent object
crashes server
Details:
If a DROP command is issued for an object that is actually a part of
internal implementation of another object, then the command crashes the
server.
For e.g. a rule with name "_RETURN" is internally created when a user
creates
a view. This object dependency is stored in pg_depend with deptype
DEPENDENCY_INTERNAL.
postgres=# CREATE VIEW fooview AS SELECT 'foo'::text;
CREATE VIEW
postgres=# DROP RULE "_RETURN" ON fooview;
server closed the connection unexpectedly
This probably means the server terminated abno
before or while processing the request.
The function object_address_present() in src/backend/catalog/dependency.c
assumes that the address list is always a non-NULL argument even though the
number of addresses can be zero. Whereas in the above scenario, the address
list is NULL. A simple address check such as below will fix this issue :
bool
object_address_present(const ObjectAddress *object,
const ObjectAddresses *addrs)
{
+ if (!addrs)
+ return false;
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5066: plperl issues with perl_destruct() and END blocks
On Mon, Sep 21, 2009 at 7:30 PM, Tom Lane wrote: > David Fetter writes: >> On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote: With connection poolers, backends can last quite awhile. Is it OK for the END block to run hours after the rest of the code? >>> >>> This is an interesting point -- should END blocks be called on >>> DISCARD ALL? > >> ENOCLUE > > And in the same vein, should they be called inside a transaction, > or not? What if they fail? > > I don't see any reason whatsoever that we couldn't just document this > as a Perl feature not supported in plperl. If you do something like > creating threads inside plperl, we're going to give you the raspberry > when you complain about it breaking. END blocks can perfectly well > go into the same category. If the changes are simple, as Tim seems to believe, exactly what do we lose by doing this? ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5066: plperl issues with perl_destruct() and END blocks
Robert Haas writes: > If the changes are simple, as Tim seems to believe, exactly what do we > lose by doing this? It's not simple. There are any number of issues that Tim has not addressed. The most obvious: *his* use case might not require database access in an END block, but that doesn't mean the next complainant won't want it. Another point that comes to mind is shared_preload_libraries: if plperl is loaded once in the postmaster, it seems entirely likely that the same END block would be executed in multiple backends after having been loaded only once. Again, while that might be okay for his particular use-case, it seems horribly dangerous for anything else. (The shared_preload_libraries case also destroys the most obvious implementation path, ie having plperl add an on_proc_exit callback at _PG_init time...) But my basic objection is that a PL is a device for executing code in functions. It has no business being used to cause "action at a distance" outside of those functions. If we go down this path we are going to regret it. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5066: plperl issues with perl_destruct() and END blocks
On Tue, Sep 22, 2009 at 10:13 AM, Tom Lane wrote:
> Robert Haas writes:
>> If the changes are simple, as Tim seems to believe, exactly what do we
>> lose by doing this?
>
> It's not simple. There are any number of issues that Tim has not
> addressed. The most obvious: *his* use case might not require database
> access in an END block, but that doesn't mean the next complainant won't
> want it.
Well, that's a reason why you might have to say no to the next
complainant, but not necessarily the current one.
> Another point that comes to mind is shared_preload_libraries: if plperl
> is loaded once in the postmaster, it seems entirely likely that the same
> END block would be executed in multiple backends after having been
> loaded only once. Again, while that might be okay for his particular
> use-case, it seems horribly dangerous for anything else.
Regular perl has the same problem, so any perl modules that are
counting on any other behavior are already broken.
$ perl -e 'fork(); END { print "hi\n" }'
hi
hi
> (The shared_preload_libraries case also destroys the most obvious
> implementation path, ie having plperl add an on_proc_exit callback
> at _PG_init time...)
Can't comment on that.
> But my basic objection is that a PL is a device for executing code in
> functions. It has no business being used to cause "action at a
> distance" outside of those functions. If we go down this path we are
> going to regret it.
I agree with that concern, but if this were already implemented the
way that Tim wants it, we would be unlikely to change it to the way
that it is now on that basis. In practice, I don't think anyone uses
END {} blocks for anything terribly elaborate, because it falls over.
They are however useful for things like dumping debugs or profiling
statistics, and I don't see much reason to prevent those sorts of
uses. I also think that to some degree the horse has already left the
barn on this one: if the Perl interpreter isn't being destroyed until
backend exit, that implies that you can ALREADY do all kinds of
horrible things, like setting global variables and reading them back
later. What happens if you call fork(), or pthread_create(), or
modify %SIG?
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL
No. You probably need someone more knowledgeable than myself! Now that you have narrowed down the problem, someone should be able to help. You will need to provide more details about your system. i.e. operating system, PostgreSQL server version, driver version (I assume ODBC), and MS Access version... Matt Annita Veneti wrote: Matt you are absolutely right! The msysconf is not related... Yesterday I did some test and have seen that the access is working fine with postgres as long as the SSL mode is disable, as soon as I put it enabled then it crashes on shutdown Go figure!!! Any ideas? Annita -Ursprüngliche Nachricht- Von: Matt Taylor [mailto:m...@lindenelevator.com] Gesendet: Montag, 21. September 2009 23:07 An: Annita Veneti Cc: pgsql-bugs@postgresql.org Betreff: Re: [BUGS] BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL I think the msysconf error is not related to your issue: http://archives.postgresql.org/pgadmin-support/2002-01/msg00035.php Can you query data from the data source using MS Excel? Matt Annita Veneti wrote: Matt first thanks for the reply, I have check the log and it says Relation »msysconf« existiert nicht (that it doesn’t exist. I know that there is a setting in the pgAdmin to postgre create the table if it not there. But I cannot find it , do you have any idea? Annita -Ursprüngliche Nachricht- Von: Matt Taylor [mailto:m...@lindenelevator.com] Gesendet: Freitag, 18. September 2009 17:47 An: Annita Veneti Cc: pgsql-bugs@postgresql.org Betreff: Re: [BUGS] BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL Have you tried turning on row versioning in the data source? Matt Annita wrote: The following bug has been logged online: Bug reference: 5063 Logged by: Annita Email address: annita.ven...@qs-unisolution.com PostgreSQL version: 8 Operating system: Windows Description:MS Access crashes by quiting after linking tables with PostgreSQL Details: MS Access (2003,2007) crashes by closing down , after i have linked the tables of my postgreSQL database. I cannot find anything relevant with this problem. I have tried everything, the problem has to do with the postgredriver since this doesnt happen when i connect with MySql or SQL. CAN ANYONE HELP??? please??? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5072: User trying to drop an internally dependent object crashes server
"Amit Khandekar" writes: > If a DROP command is issued for an object that is actually a part of > internal implementation of another object, then the command crashes the > server. How embarrassing --- evidently that specific code path never got tested. Fixed, thanks for the report! regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Problem installing Postgres 8.4.1
On Mon, Sep 21, 2009 at 3:23 PM, Christine Penner wrote: > At 11:57 AM 21/09/2009, you wrote: >> >> What error you get when you run initdb?? (Also what exact command you >> run?) > > The first time I just double clicked on the file initdb.exe. Just now I > tried to run it through the command prompt and go this, this is the same > stuff that was in the log file in the temp directory after I ran the > installer: > > C:\Program Files\PostgreSQL\8.4\bin>initdb.exe -D C:\PostgreSQL\8.4\data > The files belonging to this database system will be owned by user "User". > This user must also own the server process. > > The database cluster will be initialized with locale English_Canada.1252. > The default database encoding has accordingly been set to WIN1252. > The default text search configuration will be set to "english". > > fixing permissions on existing directory C:/PostgreSQL/8.4/data ... ok > creating subdirectories ... initdb: could not create directory > "C:/PostgreSQL": > File exists > initdb: removing contents of data directory "C:/PostgreSQL/8.4/data" > > C:\Program Files\PostgreSQL\8.4\bin> > > I deleted the PostgreSQL Directory that was there (empty) and tried again > and now it tells me that initdb.exe is not a valid win32 application It sort of sounds like you must've removed some component that initdb.exe needed but I'm not a Windows guy, so just speculating. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Requesting the Revision History
Dear sir,I am Nandagopal graduating M.E (Software Engg.,) in Anna University in INDIA.I am doing my final year project regarding software changes (using change classification technique)of open source projects.It will be helpfull to me if you send me the revision history of PostgreSQL.So please kindly send me the revision history(consisting of features changed). Thanks in advance, Regards, Nandagopal
Re: [BUGS] Requesting the Revision History
nanda gopal escreveu: > projects.It will be helpfull to me if you send me the revision history > of PostgreSQL.So please kindly send me the revision history(consisting > of features changed). > This is not a bug. Please don't post unrelated topics here. You can rsync our anonymous repository. rsync -qavzCH --delete anoncvs.postgresql.org::pgsql-cvs /tmp/pgcvs/ You can also browse it. http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/ -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
