Hi, all hackers,
I can startup database using command /usr/local/pgsql/bin/postmaster -D
/usr/local/pgsql/data.
But when I debug it using gdb and set args -D /usr/local/pgsql/data, it can't startup
database. it says;
FATAL: Database postgres does not exist in the system catalog.
Is there any

Hi all.
I have read some codes on transaction abort
operation. When the transaction abort, it seem that
all the tuples related in the transaction have not been deal with. it XMIN
equals to the tuple create transaction
ID. ItsXMAX equals null. Of cource ,It make some records on
the

Is it just the password that expires or the account? The comment for
valid until says the password is valid until that time. However, one of
the examples says the account is valid until that time.
---(end of broadcast)---
TIP 6: Have you searched

On Mon, Mar 17, 2003 at 17:35:10 +0800,
Jinqiang Han [EMAIL PROTECTED] wrote:
Hi, all hackers,
I can startup database using command /usr/local/pgsql/bin/postmaster -D
/usr/local/pgsql/data.
But when I debug it using gdb and set args -D /usr/local/pgsql/data, it can't
startup database. it

Teodor Sigaev [EMAIL PROTECTED] writes:
gmake[4]: *** No rule to make target `../lib/typename.o', needed by `ecpg'. Stop.
Yeah, me too. I think the correct fix is '../lib' should become '../ecpglib'
in ecpg/preproc/Makefile, but am waiting on Michael to confirm.

Bruno Wolff III [EMAIL PROTECTED] writes:
Is it just the password that expires or the account? The comment for
valid until says the password is valid until that time. However, one of
the examples says the account is valid until that time.
Given the current implementation, I think it's correct

1. the userid isn't deleted or anything like that.
2. validuntil is only checked in password authentication methods; if you
are able to connect via a non-password auth method (eg IDENT) then it's
not checked.
I've never been quite sure whether #2 is a bug or a feature, though.
Without

On Fri, 14 Mar 2003, Steve Crawford wrote:
One thing that would be great from a user's perspective (and which might
reduce the volume of support questions as well) is to uniquely number all
errors as in:
Error 1036: the foo could not faz the fleep
I agree with the unique codes.
It does make

I thought of something I'd overlooked in my original proposal for error-
handling upgrades: what about reporting where an error occurs in a PL
function?
Currently, plpgsql has a hack that prints a separate WARNING giving
the error location, but this is pretty darn ugly. It should be part of
the

Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Gregory Stark wrote:
Just some fixups

On the SQL list earlier today, I posted the following, and Josh Berkus
rightfully told me to post it here
I was looking for the source for this a month or so back, and couldn't
find
it. I needed similar stuff.
If someone could guide me, I **MIGHT** find the round tuit's for it for
7.4.

Tom Lane writes:
* Backend's ReadyForQuery message (Z message) should carry an indication
of current transaction status (idle/in transaction/in aborted transaction)
so that frontend need not guess at state. Perhaps also indicate
autocommit status.
If we do this, could we get rid of the

On Tue, Mar 18, 2003 at 09:02:51 +0800,
Jinqiang Han [EMAIL PROTECTED] wrote:
Bruno Wolff III,
Did you notice that postmaster is a link to postgres. So argv[0] is postgres
not postmaster...
I wonder if postmaster.c is still in use. It is really weird.
argv[0] gets set from

Folks,
I'm currently working on an implementation of cursors that can function
outside the transaction that created them (the SQL spec calls them
holdable cursors). I can see 2 main ways to implement this:
(1) During the transaction that created the holdable cursor, don't do
anything special.

On Mon, Mar 17, 2003 at 09:48:34PM -0500, Neil Conway wrote:
(2) Use MVCC to ensure that the snapshot of the database that the
transaction had is still valid, even after the transaction itself has
committed.
What about opening a pseudo-transaction that exists only to serve the
cursor? That

On Mon, 2003-03-17 at 22:01, Alvaro Herrera wrote:
What about opening a pseudo-transaction that exists only to serve the
cursor?
What exactly do you mean by a pseudo-transaction?
Keep in mind we don't have nested transactions (yet?), and that the
holdable cursor needs to be accessible both

On Mon, Mar 17, 2003 at 10:26:07PM -0500, Neil Conway wrote:
On Mon, 2003-03-17 at 22:01, Alvaro Herrera wrote:
What about opening a pseudo-transaction that exists only to serve the
cursor?
What exactly do you mean by a pseudo-transaction?
Assign an xid, create the transaction (create a

On Mon, 2003-03-17 at 20:48, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
If we do this, could we get rid of the messy autocommit GUC option and
handle autocommit in the client?
Hmm ... that's a thought ... not very backwards-compatible with 7.3,
but I think I like it better

Hackers,
I've been looking at what is involved into making nested transactions
possible. So far I've identified the following things. Please comment.
Additions are welcome.
Resource Management
---
We will create and select a new memory context for each subtransaction.
This

Hi - there is a problem with PQescapeBytea for Win32. Since libpq is a DLL,
all memory allocated from within the DLL needs to be freed from within the
dll.
PQescapeBytea allocates memory, but there is no function call back into the
DLL to free this memory. This causes heap corruption when the

Bruce Momjian [EMAIL PROTECTED] writes:
Why don't you like (1)? It seems fine to me, and I don't see how we are
magically going to do any better in the future.
The restrictions of (1) seem pretty obvious to me ... but I don't
see any prospect of doing better in the near future, either.

Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Jeroen T. Vermeulen wrote:
On Sat, Feb

Peter Eisentraut [EMAIL PROTECTED] writes:
... So the application already knows
that foo is the table and a is the column. So if the application
wants to know about details on the column a, it can execute
SELECT whatever FROM pg_attribute, pg_class WHERE relname = 'foo' AND attname = 'a';

Attached is a committed patch to add a recommendation for ANALYZE after
restore. It is a shame we only have vacuumdb -a to do analyze _and_
vacuum, and no analyze-only option.
---
Tom Lane wrote:
mlw [EMAIL PROTECTED]

Tom Lane writes:
Yes, Dave did answer --- basically, he's happy with not providing any
column identity data in the cases where it's not obvious what the answer
should be. And in particular he doesn't want the mechanism to drill
down into view definitions (which is less than obviously right

I think (1) is fine. When I used Informix, we did lots of huge cursors
that we pulled from for reports, and they consumed huge amounts of RAM
before we could do a fetch --- and we expected that. It doesn't seem
worth adding complexity to avoid that, especially since even if (2) was
done, there

Yes, I am aware of that limitation. If you link libpq as a
Multithreaded DLL, it will not link libc into each DLL, but have only
one libc that can free from anywhere.
Is that acceptable or do we need a Win32 specific memory free function?

Can someone comment on this bug report?
---
[EMAIL PROTECTED] wrote:
Jiri Langr ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Deallocating of