Hi all,
Recently solving a design problem for a friend, an idea crossed my mind.
Is it possible for an established connection to backend, to switch user on the
fly, if proper credentials are supplied?
If this can be done, it would avoid initialization penalty of a new conenction
and many
-Original Message-
From: Justin Clift [mailto:[EMAIL PROTECTED]]
Sent: 27 January 2003 02:38
To: Dave Page
Cc: PostgreSQL Hackers Mailing List; PostgreSQL Cygwin Mailing List
Subject: Re: [CYGWIN] Have a PG 7.3.1 Windows (cygwin) easy
installer... now what to do with it?
While waiting an application using the PostgreSQL database, I've
come in the need of an On Commit Trigger. As you know such trigger
doesn't not exist currently in the postgresql but I was wondering if it
would be possible to add, maybe in a future version, or if I can obtain
something
Dave Page wrote:
snip
No real stress there, as I'm really sure the pgAdmin team and
yourself
will be able to give pointers on how to make that work properly. :)
Step 1 is use an MSI compliant setup package.
Ok, do you have any recommendations? Using M$ Visual anything isn't
an option,
Michael,
Michael Meskes writes:
On Thu, Jan 23, 2003 at 02:40:33PM +0530, Shridhar
Daithankar[EMAIL PROTECTED] wrote:
I would like to use ECPG as it is relatively easy to code. However my
application is multithreaded and also uses connecion pools.
I'm afraid it needs some work to
On Mon, Jan 27, 2003 at 11:52:18AM +, Lee Kindness wrote:
Content-Description: message body text
Michael,
...
I've spent a bit of time on making ecpg thread safe over Christmas,
while it's not finished i'm sure the attached patch is at least useful
and a step in the right direction.
-Original Message-
From: Justin Clift [mailto:[EMAIL PROTECTED]]
Sent: 27 January 2003 11:51
To: Dave Page
Cc: PostgreSQL Hackers Mailing List; PostgreSQL Cygwin Mailing List
Subject: Re: [CYGWIN] Have a PG 7.3.1 Windows (cygwin) easy
installer... now what to do with it?
From: [EMAIL PROTECTED] (Bogdan)
Newsgroups: comp.databases.postgresql.questions
Subject: help with I/O statistics in 7.3.1
NNTP-Posting-Host: 12.98.224.90
Message-ID: [EMAIL PROTECTED]
I can't make configuration to get filesystem blocks in/out
to show valid data.
Im only getting 0/0 all the
Michael Meskes writes:
On Mon, Jan 27, 2003 at 11:52:18AM +, Lee Kindness wrote:
I've spent a bit of time on making ecpg thread safe over Christmas,
while it's not finished i'm sure the attached patch is at least useful
and a step in the right direction.
Thanks a lot. I have no
On 27 Jan 2003 at 14:06, Lee Kindness wrote:
Michael Meskes writes:
On Mon, Jan 27, 2003 at 11:52:18AM +, Lee Kindness wrote:
I've spent a bit of time on making ecpg thread safe over Christmas,
while it's not finished i'm sure the attached patch is at least useful
and a step
Shridhar Daithankar [EMAIL PROTECTED] writes:
Is it possible for an established connection to backend, to switch user on the
fly, if proper credentials are supplied?
Are you looking for SET SESSION AUTHORIZATION?
regards, tom lane
---(end of
Shridhar Daithankar writes:
On 27 Jan 2003 at 14:06, Lee Kindness wrote:
Michael Meskes writes:
Thanks a lot. I have no experience in multithreaded software development
so I cannot completely check your patch but it surely looks good. Shall
I commit it, or will you? I think we
On 27 Jan 2003 at 9:16, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
Is it possible for an established connection to backend, to switch user on the
fly, if proper credentials are supplied?
Are you looking for SET SESSION AUTHORIZATION?
I went thr
When using the FE/BE, how do I retrieve the table name for a
given column? Say I had the following
SQL:
Select c.id, c.name,
d.phone from Members c, Addresses d where c.id 200
From the docs of the FE/BE, I would see that the fields are
named id, name, phone but how do I find out the
Michael Meskes [EMAIL PROTECTED] writes:
- Is it neccessary to patch c.h for ecpg?
If you commit that part, it will be reverted forthwith (especially the
hardwired #define HAVE_PTHREAD_H ;-)).
Keep the thread hacking on the client side, please. Isn't there one of
the ecpg/include/ files that
So unless I parse the SQL statement myself, I can't tell anything about
the source table? To find out uniqueness, indexes, etc for fields in a
source table, I need the table name and have to execute queries against
pg_attribute and pg_indexes. But since the FE/BE doesn't return to me
the source
On Mon, Jan 27, 2003 at 02:06:26PM +, Lee Kindness wrote:
- Not sure with the version numbering but I can fix that later.
As discussed on pgsql-hackers after the 7.3 release any binary
incompatible library change needs a major version number increase.
Sorry, I was not precise enough.
On Mon, Jan 27, 2003 at 09:30:50AM -0500, Tom Lane wrote:
Michael Meskes [EMAIL PROTECTED] writes:
- Is it neccessary to patch c.h for ecpg?
If you commit that part, it will be reverted forthwith (especially the
hardwired #define HAVE_PTHREAD_H ;-)).
Keep the thread hacking on the client
On Mon, 27 Jan 2003, Shridhar Daithankar wrote:
I went thr http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-set-session-
authorization.html to get what it is. I didn't have an idea of such thing.
Back to the topic, yes, pretty much except for few differences.
1) It says 'The session
Reggie Burnett [EMAIL PROTECTED] writes:
When talking about expressions,views, or any other construct that could
combine values from multiple tables I think it is reasonable to provide
null as the table name. Any one or any process requesting the table
name has to understand that not all SQL
Michael Meskes [EMAIL PROTECTED] writes:
Keep the thread hacking on the client side, please. Isn't there one of
the ecpg/include/ files that would be suitable?
Yes, there is. Better make that there are. There is a file called
extern.h both in preproc as well as in lib and each file in the
Well, certainly the driver could parse the sql and extract what it
thinks is the table name. It just seems quite foreign to me to have a
database engine go through the motions of determining column location
and have ready access to all the metadata for all the columns in a
resultset and then
Has anyone seen this behavior? It's corrupted a production database.
ERROR: heap_mark4update: (am)invalid tid
WARNING: Error occurred while executing PL/pgSQL function issuewomaterial
WARNING: line 40 at SQL statement
---(end of broadcast)---
ps - this is on 7.3.1. It never happened on 7.2.3...
- Original Message -
From: Ned Lilly [EMAIL PROTECTED]
To: PostgreSQL Hackers [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 11:04 AM
Subject: [HACKERS] urgent: db corruption - invalid TIDs?
Has anyone seen this behavior? It's
Ned Lilly wrote:
Has anyone seen this behavior? It's corrupted a production database.
Hi Ned,
Just as information filler, which version of PostgreSQL, and which
operating system?
:-)
Regards and best wishes,
Justin Clift
ERROR: heap_mark4update: (am)invalid tid
WARNING: Error occurred
Tom Lane wrote:
Bogdan [EMAIL PROTECTED] writes:
I can't make configuration to get filesystem blocks in/out
to show valid data.
Im only getting 0/0 all the time.
Is that functionality available in postgres 7.3.1 ???
That is just printing what getrusage() tells it. Complain to your
I don't know if this is terribly helpful, but the message was around in
7.2.x, look at src/backend/access/heap/heapam.c around line 1808 (or
1823 in the 7.3.x code)
That said, I've not seen it before, perhaps you can expand upon what
your function is doing?
Robert Treat
On Mon, 2003-01-27 at
We've done a bit more digging, and think we understand the problem. Looks like 7.3.1
is just now taking advantage of a performance flag that has been ignored up to now.
The error message is a bit unclear.
When we close this out internally, we'll document our findings to the list. So, in
Is there a TODO here? I like the idea of not writing pg_controldata, or
at least allowing it not to be read, perhaps with a pg_resetxlog flag so
we can cleanly recover from a corrupt pg_controldata if the WAL files
are OK.
We don't want to get rid of the WAL file rename optimization because
Bradley Baetz [EMAIL PROTECTED] writes:
Hmm. OK, I poked through the code a bit more, and I think I now realise
why we were talking across each other. I've attached a 'patch' which
gets the mergejoin counts down to something reasonable.
I've just committed a significant set of changes in the
On Mon, 27 Jan 2003, Antti Haapala wrote:
For an INSERT command, the tag is INSERT oid rows, where rows
is the number of rows inserted, and oid is the object ID of the
inserted row if rows is 1, otherwise oid is 0.
Wouldn't it be nice to add here
If table doesn't
My idea on this after chat with Dave was to add a GUC option that puts
the schema.table.column name as the default column label, rather than
just the column name. (That's so easy, I think even I could do it.) If
they over-ride it with AS, or if it is an aggregate or FROM subquery, we
just
--On Monday, January 27, 2003 15:49:06 -0500 Bruce Momjian
[EMAIL PROTECTED] wrote:
My idea on this after chat with Dave was to add a GUC option that puts
the schema.table.column name as the default column label, rather than
just the column name. (That's so easy, I think even I could do it.)
Bruce Momjian writes:
However, the server log messages stating an IPv6 socket was not made is
only printed if the binary supports IPv6. The message seems to be a
compromise between those who wanted a separate IPv6 GUC/flag and those
who wanted it to silently fail on IPv6.
I'm not sure.
Bruce Momjian writes:
I do have a problem with MKS toolkit, which is a commerical purchase.
I would like to avoid reliance on that, though Jan said he needed their
bash.
I don't believe that quite yet. Jan said the regression test script
crashes Cygwin's bash, but how come it has never
Bruce Momjian [EMAIL PROTECTED] writes:
My idea on this after chat with Dave was to add a GUC option that puts
the schema.table.column name as the default column label, rather than
just the column name.
And will you quotify things so that names containing dots, spaces, etc
are unambiguous?
I
Larry Rosenman wrote:
--On Monday, January 27, 2003 15:49:06 -0500 Bruce Momjian
[EMAIL PROTECTED] wrote:
My idea on this after chat with Dave was to add a GUC option that puts
the schema.table.column name as the default column label, rather than
just the column name. (That's so
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
My idea on this after chat with Dave was to add a GUC option that puts
the schema.table.column name as the default column label, rather than
just the column name.
And will you quotify things so that names containing dots, spaces,
On Mon, 2003-01-27 at 15:50, Larry Rosenman wrote:
--On Monday, January 27, 2003 15:49:06 -0500 Bruce Momjian
[EMAIL PROTECTED] wrote:
My idea on this after chat with Dave was to add a GUC option that puts
the schema.table.column name as the default column label, rather than
just the
Peter Eisentraut wrote:
Bruce Momjian writes:
However, the server log messages stating an IPv6 socket was not made is
only printed if the binary supports IPv6. The message seems to be a
compromise between those who wanted a separate IPv6 GUC/flag and those
who wanted it to silently
I have read all my email while I was in Altanta. I don't think I will
have time to apply any outstanding patches for a week or so from Japan.
I will try tomorrow, but I have to polish my presentations too.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
On Tue, 28 Jan 2003, Christopher Kings-Lynne wrote:
I just noticed you can do this:
create table blah (
a not null references test on delete set null
)
Should that be prevented? It shouldn't be too hard to test for really...
Maybe, although I don't think the spec prevents it. In
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I just noticed you can do this:
create table blah (
a not null references test on delete set null
)
Should that be prevented?
It already does. Or did you mean disallow the declaration? I can't see
anything in SQL92 that recommends
I just checked and pg_dump -d _doesn't_ place the INSERT's in a
transsaction. Seems it should, and perhaps add a:
SET autocommit TO 'on'
as well. Of course, that SET would fail when restoring to prior
releases, but they don't have autocommit off anyway so it can be
ignored. Comments?
As part of the training class I did, some people tested what happens
when the client allocates tons of memory to store a result and aborts.
What we found was that though elog was properly called:
elog(COMMERROR, pq_recvbuf: recv() failed: %m);
(I think that was the message.) the
Folks,
I've been following this discussion, but I still haven't seen a definitive
list of patches included in 7.2.4. Where can I find one?
--
-Josh Berkus
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL
Due to my error, log_min_error messages went into 7.3.X with the wrong
default, and the wrong listed options.
This fixes the bug in CVS current and 7.3.X. Patch attached.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
However, the server log messages stating an IPv6 socket was
not made is
only printed if the binary supports IPv6. The message seems to be a
compromise between those who wanted a separate IPv6 GUC/flag and those
who wanted it to silently fail on IPv6.
I'm not sure. Those who
Christopher Kings-Lynne wrote:
However, the server log messages stating an IPv6 socket was
not made is
only printed if the binary supports IPv6. The message seems to be a
compromise between those who wanted a separate IPv6 GUC/flag and those
who wanted it to silently fail on
That is _exactly_ how it has to be done.
---
Neil Conway wrote:
On Mon, 2003-01-27 at 20:19, Bruce Momjian wrote:
I had someone on the IPv6 IRC channel interested, but haven't seen any
patch yet. It isn't that hard to
Neil Conway [EMAIL PROTECTED] writes:
If we cleanly split the Postgres-specific code from the stuff that's
been imported from BIND, shouldn't it be easy to import new versions,
and thus get IPv6 support for free?
IIRC, the issue was that we'd painfully hammered out a set of preferred
I/O
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
If we cleanly split the Postgres-specific code from the stuff that's
been imported from BIND, shouldn't it be easy to import new versions,
and thus get IPv6 support for free?
IIRC, the issue was that we'd painfully hammered out a set
Bruce Momjian [EMAIL PROTECTED] writes:
As part of the training class I did, some people tested what happens
when the client allocates tons of memory to store a result and aborts.
What we found was that though elog was properly called:
elog(COMMERROR, pq_recvbuf: recv() failed: %m);
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
As part of the training class I did, some people tested what happens
when the client allocates tons of memory to store a result and aborts.
What we found was that though elog was properly called:
elog(COMMERROR, pq_recvbuf:
Bruce Momjian [EMAIL PROTECTED] writes:
Why is COMMERROR not doing the longjump like ERROR?
Because it's defined to be like LOG.
A more useful reply might be that I'm not sure it's safe to abort in the
client I/O routines.
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Why is COMMERROR not doing the longjump like ERROR?
Because it's defined to be like LOG.
A more useful reply might be that I'm not sure it's safe to abort in the
client I/O routines.
Well, if we get an I/O error, I can't imagine
Peter Eisentraut wrote:
Justin Clift writes:
The advantages to having the Win32 port be natively compatible with
Visual Studio is that it already is (no toolset-porting work needed
there),
You're missing a couple of points here. First, the MS Visual whatever
compiler can also be used with a
Bruce Momjian [EMAIL PROTECTED] writes:
Well, if we get an I/O error, I can't imagine why we would continue
doing anything --- are any of those recoverable?
Well, that's what's not clear --- it's hard to tell if a write failure
is a hard error or just transient. If we make like elog(ERROR),
Well, setting query_cancel then seems like a logical solution because it
will exit at a reasonable point, hopefully. Right now we have
statement_timeout and that exits at a give time, but I suppose it
doesn't exit while data is transfering, so it may be different.
Already fixed ... one of those things where per-db connection limits would
have been helpful :(
On Sat, 25 Jan 2003, Dave Cramer wrote:
Warning: pg_connect() unable to connect to PostgreSQL server: FATAL 1:
Sorry, too many clients already in
60 matches
Mail list logo
