Moving the -admin, please don't reply to -hackers on this.
On Fri, 2004-07-30 at 00:04, Coloring Graph wrote:
> I am has some trouble when connect to 7.5 devel PostgreSQL server,
> see belows
>
> my setup:
> ===
> os=Windows2000
> server version=the non-MSI snapshot at
> htt
I am has some trouble when connect to 7.5 devel PostgreSQL server, see belows
my setup:===os=Windows2000server version=the non-MSI snapshot at http://www.hagander.net/pgsql/win32snap/ has been "downgraded" to the latest known working snapshot
path=c:\postgres\bin;c:\postgres\l
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
> Mark Kirkwood wrote:
> > I was wondering about this point - might it not be just as reasonable
> > for the copied file to *be* an exact image of pg_control? Then a very
> > simple variant of pg_controldata (or maybe even just adding switches to
> > pg_
Gaetano Mendola wrote:
Well but a default line will be in the postgresql.conf, you'll insert the
dbname in the default one ?
That is an option. I'm not sure I should clutter the log file with the
database name for every log entry, but then again, autovacuum does work
on the system tables and it
On Thu, 22 Jul 2004, K-Sudhakaran wrote:
Hi Sudhakaran,
I'm not sure if I missunderstand you, but I think the feature you're
describing is foreign keys ...
If it's not, please try to describe it in more detail.
Greeetings, Klaus
>
> Hi/Hello Postgres Team!
>
> Me Sudhakaran, working for a soft
Mark Kirkwood wrote:
> I was wondering about this point - might it not be just as reasonable
> for the copied file to *be* an exact image of pg_control? Then a very
> simple variant of pg_controldata (or maybe even just adding switches to
> pg_controldata itself) would enable the relevant info
>>> 2. It's even more likely that it would be there but have
>>> unpleasantly small implementation limits. AFAICT your
>>> proposal requires a separate message queue per backend, which
>>> is probably going to stress any conventionally-configured
>>> SysV facility.
>
>> Not at all. One message
Tom Lane wrote:
> > ftok() on pg_control or something in the clusters data directory was my
> > intention. (Again, just one message queue)
>
> Doesn't work; you have to be able to cope with collisions with
> previously existing queue IDs ... so in practice the queue ID has to
> be treated as quasi
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> 2. It's even more likely that it would be there but have
>> unpleasantly small implementation limits. AFAICT your
>> proposal requires a separate message queue per backend, which
>> is probably going to stress any conventionally-configured
>> Sy
Matthew T. O'Connor wrote:
Gaetano Mendola wrote:
I don't have idea about the database involved, I suggest:
Performing: VACUUM ANALYZE "dbame"."public"."current_connection"
or
Performing: VACUUM ANALYZE "public"."current_connection"@"dbname"
I know that I will know the database on the very next lin
Magnus Hagander wrote:
> On top of this, we create a SystemV message queue used to pass down
> extended signals (should be supported on all systems that support sysv
> shared mem, and we require that..). We'd use the PID of the receiving
> backend as the message type, and pass the signal number as
Hi/Hello Postgres Team!
Me Sudhakaran, working for a software R&D institution located in Bangalore
city of India.
I feel that, if a table (entity) inherits another parent table(entity),
the primary key should be unique accross all the inherited tables. That is
the real inheritance otherwise I fe
Gaetano Mendola wrote:
I don't have idea about the database involved, I suggest:
Performing: VACUUM ANALYZE "dbame"."public"."current_connection"
or
Performing: VACUUM ANALYZE "public"."current_connection"@"dbname"
I know that I will know the database on the very next line, but sometimes
is too lat
Hi all,
We are a bunch(about 10)of enthusiastic software
engineers from Bangalore who strongly believe in
opensource.
We are currently looking at the prospect of improving
the PostgreSQL to the enterprise level. At first we
would like to take PostgreSQL atleast to the level of
Oracle 7i or 8i. W
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Also, I need to be sure that pg_dumpall is enough, and I don't need to make
> sure I issue a checkpoint before the pg_dumpall or anything.
I think if you're using PITR you don't use pg_dump you just tar up the PGDATA
directory.
Of course you
> > We invent something we could call "extended signals" that are valid
> > only in pgsql.
>
> This would be handy, but I dislike your proposal of
> implementing it using SysV message queues.
>
> 1. Yes, the message facility should theoretically be there if
> shmem and semaphores are there, bu
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
PL/sh is OK, but both PL/Ruby and PL/Java play around with Warn_restart.
Are they using it to fake try/catch behavior? If so, see later thread
about moving to a simple set of try/catch macros.
I currently have this up and seemi
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The crash people are getting in initdb is due to the 1.19 revision to
> pgtz.c. Not sure why yet...looking into it...
Unfortunate behavior when probing pre-1970 dates, maybe?
regards, tom lane
---(end
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> PL/sh is OK, but both PL/Ruby and PL/Java play around with Warn_restart.
Are they using it to fake try/catch behavior? If so, see later thread
about moving to a simple set of try/catch macros.
I currently have this up and seemingly working for the
Am Sonntag, 25. Juli 2004 01:48 schrieb Tom Lane:
> One issue is that it may break existing PLs that override Warn_restart,
> since the semantics of doing that will have changed a bit. We can
> easily fix the PLs that are in our own CVS, but what are the
> implications for other PLs such as PL/R a
On Thu, Jul 29, 2004 at 09:58:54AM -0400, Tom Lane wrote:
> Right. The last bit (FINALLY executes whether or not a CATCH block
> re-throws) seemed too messy to handle in my little macros, so I'm
> planning on leaving it out. But I'm open to the idea if anyone has
> a clever implementation thoug
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> We invent something we could call "extended signals" that are valid only
> in pgsql.
This would be handy, but I dislike your proposal of implementing it
using SysV message queues.
1. Yes, the message facility should theoretically be there if shmem a
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> ...Or I could try. Yes, the "finally" block is executed after executing
> the "catch" block if an exception was caught, or when leaving the "try"
> block if there wasn't. That includes both normal completion and uncaught
> exceptions.
Right. T
Joe Conway <[EMAIL PROTECTED]> writes:
> This is especially a problem when the cleanup needs to be done inside
> the embedded interpreter. I found that with R, I had to throw an error
> in the R interpreter in order to allow the interpreter to clean up its
> own state. That left me with code lik
The crash people are getting in initdb is due to the 1.19 revision to
pgtz.c. Not sure why yet...looking into it...
Merlin
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Hello Folks,
Don't know whether this is the right group to post the question, but at
installing an application that uses Postgres, I get the following message:
ERROR: Load of file /usr/lib/pgsql/plpgsql.so failed:
/usr/lib/pgsql/plpgsql.so: undefined symbol: xlateSqlType
The calling command is:
On Thu, Jul 29, 2004 at 12:10:12AM -0400, Alvaro Herrera Munoz wrote:
> (The "finally" block, AFAIU, is executed whether an exception was raised
> or not, so it serves as cleanup for try and catch blocks. Somebody more
> knowledgeable in this OO matters may enlighten us better?)
...Or I could t
Pierre Emmanuel Gros wrote:
In mysql, we can wrote a create table like CREATE TABLE t (i INT) ENGINE
= INNODB||BDB|;
where the storage engine is the innodb one. This allow to have
differents kind of storage format, and allow to easly implements memory
table or remote table. I try to make the sam
Hi all,
till today I was running in production one only
db so the autovacuum log was fine. Since today
I have two db but looking at the following line:
Performing: VACUUM ANALYZE "public"."current_connection"
I don't have idea about the database involved, I suggest:
Performing: VACUUM ANALYZE "dbam
I was wondering about this point - might it not be just as reasonable
for the copied file to *be* an exact image of pg_control? Then a very
simple variant of pg_controldata (or maybe even just adding switches to
pg_controldata itself) would enable the relevant info to be extracted
P.s : would
> >> So what you'd basically need is a separate signal to trigger that
> >> sort of exit, which would be easy ... if we had any spare
> signal numbers.
>
> > What about multiplexing it onto an existing signal? e.g. set a
> > shared-mem flag saying "exit after cancel" then send SIGINT?
>
> Pos
ï
This sounds very much like the known bug that has been
reported several times over the past couple of days on pgsql-hackers-win32.
We're working on tracking it down. At the moment, the non-MSI snapshot at http://www.hagander.net/pgsql/win32snap/
has been "downgraded" to the latest know
32 matches
Mail list logo
