Thread: Beta2 - A Late Announcement
Morning all ...
Just a quick announcement that 7.3Beta2 is now up and available
for download.
This beta requires a dump/reload from the pervious one, as several
of the fixes touch on the system catalogs.
Changes include, but are not restricted to:
- Change default privileges for languages and functions to be
PUBLIC USAGE and PUBLIC EXECUTE, respectively.
- Add missing correction of sublevelsup when pulling up a
subquery.
- in HeapTupleSelfUpdated case, executor should not return the
tuple as successfully marked, because in fact it's been deleted.
- Disallow VACUUM, ANALYZE, TRUNCATE on temp tables belonging to
other backends.
- Get rid of bogus use of heap_mark4update in reindex operations
- In UpdateStats(), don't bother to update the pg_class row if it
already contains the correct statistics.
- RelationClearRelation must reset rd_targblock and update
rd_nblocks even when dealing with a nailed-in-cache relation
- Replace pg_attribute.attisinherited with attislocal and
attinhcount columns, to allow more correct behavior in
multiple-inheritance cases.
- Bring SIMILAR TO and SUBSTRING into some semblance of
conformance with the SQL99 standard.
- Move most of the error checking for foreign-key constraints out
of parse analysis and into the execution code
- Provide an upgrade strategy for dump files containing functions
declared with OPAQUE.
- Fix PPC s_lock operations to work correctly on multi-CPU
machines.
- Introduce a well-defined promotion hierarchy for
numeric datatypes
- and many many more changes ...
We ask everyone that can to download and test this new beta, and
report any bugs to pgsql-bugs@postgresql.org ...
Downloads are available through any PostgreSQL FTP Mirror site.
Thanks ...
Hi,
Just downloaded 7.3b2 and it all compiled and installed ok on my MacOSX
10.2.1 machine.
However, when I try and upload a dump file from my 7.2.2 server I get the
following problem:
....
....
CREATE FUNCTION
You are now connected as new user admin.
dyld: /usr/local/pgsql7.3/bin/postmaster Undefined symbols:
_get_temp_rel_by_physicalname
_xlateSqlType
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost
LOG: server process (pid 4077) was terminated by signal 5
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing shared memory and
semaphores
[Ads-Mac:database_stuff/BugasBase/dumps] adam% LOG: database system was
interrupted at 2002-09-30 10:40:44 BST
LOG: checkpoint record is at 0/84E3B4
LOG: redo record is at 0/84E3B4; undo record is at 0/0; shutdown TRUE
LOG: next transaction id: 552; next oid: 25164
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: redo starts at 0/84E3F4
LOG: ReadRecord: record with zero length at 0/8983B4
LOG: redo done at 0/898390
LOG: database system is ready
Is this a problem with my setup or with the beta?
Thanks
adam
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Adam Witney <awitney@sghms.ac.uk> writes:
> Just downloaded 7.3b2 and it all compiled and installed ok on my MacOSX
> 10.2.1 machine.
> However, when I try and upload a dump file from my 7.2.2 server I get the
> following problem:
> dyld: /usr/local/pgsql7.3/bin/postmaster Undefined symbols:
> _get_temp_rel_by_physicalname
> _xlateSqlType
Got any PL-language functions in that dump? How about user-defined C
functions? What this looks like is trying to load a shared library
that is out of date (ie, for some release prior to 7.3). I'm thinking
you have an absolute path in some CREATE FUNCTION command that is
pointing to an older release.
> server closed the connection unexpectedly
That's annoying; it looks like the Darwin dynamic loader is aborting
the process instead of returning a failure code. I wonder whether
we can get it to behave more sanely?
regards, tom lane
On 30/9/02 3:35 pm, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > Adam Witney <awitney@sghms.ac.uk> writes: >> Just downloaded 7.3b2 and it all compiled and installed ok on my MacOSX >> 10.2.1 machine. > >> However, when I try and upload a dump file from my 7.2.2 server I get the >> following problem: > >> dyld: /usr/local/pgsql7.3/bin/postmaster Undefined symbols: >> _get_temp_rel_by_physicalname >> _xlateSqlType > > Got any PL-language functions in that dump? How about user-defined C > functions? What this looks like is trying to load a shared library > that is out of date (ie, for some release prior to 7.3). I'm thinking > you have an absolute path in some CREATE FUNCTION command that is > pointing to an older release. Ahh yes, it is failing just as it is trying to create the plpgsql_call_handler ready for adding the PL/pgSQL language, which includes a hard coded path to plpgsql.so If I manually changed the path to the newly complied plpgsql.so would that be ok? >> server closed the connection unexpectedly > > That's annoying; it looks like the Darwin dynamic loader is aborting > the process instead of returning a failure code. I wonder whether > we can get it to behave more sanely? Ugh... Out of my depth! :-) I will try the above and let you know. adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Adam Witney <awitney@sghms.ac.uk> writes:
> Ahh yes, it is failing just as it is trying to create the
> plpgsql_call_handler ready for adding the PL/pgSQL language, which includes
> a hard coded path to plpgsql.so
> If I manually changed the path to the newly complied plpgsql.so would that
> be ok?
I'd recommend editing the dump to use path
'$libdir/plpgsql'
which is the preferred setup going forward --- it's
installation-independent because the backend will automatically add
the correct library-directory path and shared-library extension.
createlang has created languages this way since 7.2, but dumps loaded
from prior releases probably still have hardcoded paths in them :-(
regards, tom lane
On 30/9/02 3:57 pm, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > Adam Witney <awitney@sghms.ac.uk> writes: >> Ahh yes, it is failing just as it is trying to create the >> plpgsql_call_handler ready for adding the PL/pgSQL language, which includes >> a hard coded path to plpgsql.so > >> If I manually changed the path to the newly complied plpgsql.so would that >> be ok? > > I'd recommend editing the dump to use path > '$libdir/plpgsql' > which is the preferred setup going forward --- it's > installation-independent because the backend will automatically add > the correct library-directory path and shared-library extension. > > createlang has created languages this way since 7.2, but dumps loaded > from prior releases probably still have hardcoded paths in them :-( Yup, I just manually changed the path to the language library and those errors disappeared. This was dumped from 7.2.2 but the paths were hardcoded. Thanks for your help Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Adam Witney <awitney@sghms.ac.uk> writes: > [ bad shared library causes backend coredump on OS X ] This patch seems to suppress the coredump: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/port/dynloader/darwin.c.diff?r1=1.5&r2=1.6 However, instead of a somewhat-useful error message on postmaster stderr, you now get only "no message available". This sucks :-(. Apparently, asking not to crash overrides the default error handler that prints the useful error message before crashing. I applied the patch anyway, since a backend crash is considerably more Not Acceptable than not telling you why the shlib can't be loaded. But getting the error message too would be much better. Apparently, if we want the message too, we have to create a 'linkEdit' hook to print it --- see http://developer.apple.com/techpubs/macosx/DeveloperTools/MachORuntime/5rt_api_reference/_Object_Fil_e_Functions.html for some pointers. Any OSX users care to code up the error-printing routine? regards, tom lane