[GENERAL] Migration from Symfoware to PostgreSQL-Constructor functions

2013-08-04 Thread sachin kotwal 
Hello

While migrating small application from Symfoware to PostgreSQL.
There are some constructor functions in Symfoware.
Which I unable to execute in Symfoware database.

If anyone knows how to execute constructor functions in Symfoware.
how to see list of system tables, functions, view and user defined tables,
functions, views.
Please reply. 



-
Thanks and Regards,

Sachin Kotwal
NTT-DATA-OSS Center (Pune)
--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Migration-from-Symfoware-to-PostgreSQL-Constructor-functions-tp5766203.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Migration from Symfoware to PostgreSQL-Constructor functions

2013-08-04 Thread Jayadevan M 
Hi,
System tables,  views and most of the metadata can be retrieved from these
views -
http://www.postgresql.org/docs/9.2/static/information-schema.html
Regards,
Jayadevan


On Sun, Aug 4, 2013 at 2:48 PM, sachin kotwal  wrote:

> Hello
>
> While migrating small application from Symfoware to PostgreSQL.
> There are some constructor functions in Symfoware.
> Which I unable to execute in Symfoware database.
>
> If anyone knows how to execute constructor functions in Symfoware.
> how to see list of system tables, functions, view and user defined tables,
> functions, views.
> Please reply.
>
>
>
> -
> Thanks and Regards,
>
> Sachin Kotwal
> NTT-DATA-OSS Center (Pune)
> --
> View this message in context:
> http://postgresql.1045698.n5.nabble.com/Migration-from-Symfoware-to-PostgreSQL-Constructor-functions-tp5766203.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [GENERAL] Exit code -1073741819

2013-08-04 Thread Craig Ringer 
On 08/04/2013 02:41 AM, Carlos Henrique Reimer wrote:
> Hi,
> 
> I have a Windows box running Windows Server 2003 Enterprise Edition
> Service Pack 2 with PostgreSQL 8.2.23 and getting a server crash while
> trying to select a table:
> 
> select * from "TOTALL.tt_est" where assina=' kdkd' ;
> 
> Dumping the table with pg_dump or creating indexes in this table produce
> the same error.
> 
> 2013-07-30 21:35:47 LOG:  server process (PID 2004) exited with exit
> code -1073741819

This looks like an invalid memory access error. This could be caused by
practically anything - hardware issues, malware hook DLLs, drivers,
antivirus, you name it.

You're using PostgreSQL 8.2, so honestly your first step is probably
"just upgrade". 8.2 is old and unsupported
(www.postgresql.org/support/versioning/), so there's very little point
investigating a bug until it can be reproduced in a current version.

Can you `pg_dump` your database? If so, follow the upgrade instructions
in the documentation to get onto a current, supported version.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] xlog min recovery request ... is past current point ...

2013-08-04 Thread Michael Paquier 
On Fri, Aug 2, 2013 at 11:33 PM, Alberto Bussolin <
alberto.busso...@edistar.com> wrote:

> Hi,
> i was testing a point in time recovery on a postgres 9.1.9.
>
> When processing the xlog i found out these log messages (on postgres.log):
>
> postgres@postgres[[local]]  FATAL:  the database system is starting up
> @[]  LOG:  restored log file "0002026B00D5" from archive
> @[]  LOG:  redo starts at 26B/D50049F0
> @[]  WARNING:  xlog min recovery request 26B/EB529C40 is past current
> point 26B/D5758198
> @[]  CONTEXT:  writing block 0 of relation base/2831418/257279491_vm  xlog
> redo insert: rel 1663/1425752962/2572579716; tid 3235/118
>
> The restore procedure completed correctly and all the data was restored.
>
> May i ignore this warning or is it something i didn't realise?
>
Similar problem on the VM relations has been reported before:
http://www.postgresql.org/message-id/4f53c562.5060...@enterprisedb.com
This is harmless, and by looking at the git log history this warning has
not been fixed as it is not that straight-forward.
Regards,
-- 
Michael

Re: [GENERAL] Why are stored procedures looked on so negatively?

2013-08-04 Thread Craig Ringer 
On 08/02/2013 09:18 PM, Merlin Moncure wrote:
> On Fri, Aug 2, 2013 at 1:49 AM, Chris Travers  wrote:
>> Here's my $0.02
>>
>> Stored procedures have a bunch of problems historically.  Part of this is
>> because the interface traditionally is pretty spartan, and partly because
>> some people take them too far.
>>
>> The first issue is that if you have a stored procedure which takes 2
>> arguments and you need to extend it to three, then you have to change every
>> call in the calling application.  This can create a maintenance problem.
>> Variadic functions help somewhat but there are limits to what a variadic
>> function can do here.
> 
> This is true of most popular languages. 

I think part of the issue is that people tend to consider stored
procedures part of the application's internal implementation where you
just change all the call sites when you change the function.

Normally stored proc are really more like a library API - something
that's a bit of a pain to change due to asynchronous updates of apps and
interface, multiple interface users, etc.

If you think about them that way the question "should this be done in
apps or in a stored proc" must be asked for each individual procedure.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Re: Postgres 9.2.4 for Windows (Vista) Dell Vostro 400, re-installation failure PLEASE CAN SOMEONE HELP!! (nearly fixed)

2013-08-04 Thread BladeOfLight16 
On Sat, Aug 3, 2013 at 7:16 AM, Alban Hertroys  wrote:

> They are cluster specific, as the roles are stored in the database. If you
> switch between different data directories, that means you're switching the
> available roles as well. And their details, such as passwords. You're also
> switching between configurations, such as pg_hba.conf.
>
> Where it gets confusing a bit here is that there's usually also an OS
> postgres user, but that user is used to run the postgres server/service
> with limited credentials and not to log into the database. On Windows,
> apparently postgres is run under a standard network service account
> instead, which serves the same purpose.
>
> Now, if you connect to the database without specifying a role-name to
> connect as, the standard tools (psql, pg_dump, etc. Don't know about
> pgAdmin) take your user account name and try to use that for the database
> login role, making it look like there's a relation between OS users and
> database users, but that's not actually the case (although there's an
> authentication option in pg_hba.conf to require such a relation).
>

Sounds about right. I can definitely confirm that it's run as NETWORK
SERVICE and that psql, by default, tries to connect as the current username.

Anyhow, I'm betting you will need to reset the password in your existing
data directory, Mr. Brearly. First of all, make sure you have an entire
back up of the data directory you want to get data from. (Hopefully, you
have this already from before you were making all these changes.) Then
start PostgreSQL with the data directory with your data. (If this is what
you've configured the service to do within the registry, that's fine.)
Next, follow the instructions in the FAQ:
http://wiki.postgresql.org/wiki/FAQ#I_lost_the_database_password._What_can_I_do_to_recover_it.3F.
(Also see this DBA StackExchange question for some Windows specific advice
on reloading the config:
http://dba.stackexchange.com/questions/19643/how-do-i-reset-the-postgres-password-for-postgresql-on-windows.)
See the 
documentationon
configuring the pg_hba.conf file; this file is inside your data
directory somewhere. I suspect the best way to do this is to add a line of
the form "local  *database  user  auth-method*" with *auth-method* as
trust, of course. (Could someone confirm?) Also, do your password reset
from the command line using psql; this eliminates some complexities and
uncertainty regarding PgAdmin in case it doesn't work.

If this works as expected, you'll be able to access your data. Good luck.

Re: [GENERAL] Migration from Symfoware to PostgreSQL-Constructor functions

2013-08-04 Thread raghu ram 
> how to see list of system tables, functions, view and user defined tables,
> functions, views.
>
>
You can get more details from below URL:

Extracting META information from PostgreSQL
(INFORMATION_SCHEMA)



Thanks & Regards
Raghu Ram

[GENERAL] Bottlenecks with large number of relation segment files

2013-08-04 Thread Amit Langote 
Hello,

I am looking the effect of having large number of relation files under
$PGDATA/base/ (for example, in cases where I choose lower segment size
using --with-segsize). Consider a case where I am working with a large
database with large relations, for example a database similar in size
to what "pgbench -i -s 3500" would be.

May the routines in fd.c become bottleneck with a large number of
concurrent connections to above database, say something like "pgbench
-j 8 -c 128"? Is there any other place I should be paying attention
to?

-- 
Amit Langote


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Re: Postgres 9.2.4 for Windows (Vista) Dell Vostro 400, re-installation failure PLEASE CAN SOMEONE HELP!! (nearly fixed)

2013-08-04 Thread Thomas Kellerer 
Stephen Brearley, 02.08.2013 11:40:
> I can change my registry reference to point to D:\..\9.2\data or 
> D:\..\9.2\data_old without any (apparently) undesirable consequences, 
> but I just can’t see my tables in the system, which makes me think I need to 
> do more than this. 

Why don't you use the official way to re-configure the Windows service and use 
pg_ctl unregister and pg_ctl register 
to make it use the correct data directory. There is no need to manually change 
the registry.

> I am unable to rename \data to move all my old files wholesale into that 
> folder, as Windows won’t let me, 
> but if I move \base which appears to have all the database in it (and is 
> about double the size in my old dataset), 
> I get the same result, I can’t see my tables.

I you can't move the directory it means it is still be used/locked by another 
process. I always use ProcessExplorer (or ProcessExplorer, both from 
www.sysinternals.com - now Microsoft) to be indispensable to figure out which 
process is locking a file.
  
> I realise Thomas at least will frown most deeply at these ‘operations’, 
> though they often work as a low-tech solution in many programs. 

I do change the registry manually myself that's not the point. But I only do it 
if there is no tool support for it. 
Changing the windows service is much easier done through pg_ctl and ensures 
that nothing is forgotten. 

Thomas




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general