satoshi nagayasu wrote:
I'm trying to use PAM auth on PostgreSQL, but I still cannot
get success on PAM auth (with PG813 and RHEL3).
pg_hba.conf has
hostpamtest all 0.0.0.0/0 pam
/etc/pam.d/postgresql is
#%PAM-1.0
auth required pam_stack.so
On 6/20/06, Tom Lane [EMAIL PROTECTED] wrote:
One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory. The overhead costs would be so
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 20 June 2006 00:02
To: Peter Eisentraut; pgsql-hackers@postgresql.org
Subject: [HACKERS] CVS HEAD busted on Windows?
I notice buildfarm member snake is unhappy:
The program
Albe,
Albe Laurenz wrote:
/etc/pam.d/system-auth probably uses pam_unix.so to authenticate.
Does the user exist on the machine and have the password you try?
Yes, I have same user name on my linux box and postgresql,
and they have same password (now).
You could add 'debug' to the
On Mon, 2006-06-19 at 21:35 -0400, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Come to think of it I wonder whether there's anything to be gained by using
smaller files for tables. Instead of 1G files maybe 256M files or something
like that to reduce the hit of fsyncing a file.
On Tue, 2006-06-20 at 00:18 -0400, Tom Lane wrote:
One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory. The overhead costs would
On Mon, 2006-06-19 at 19:36 -0400, Theo Schlossnagle wrote:
The idea of having intelligently placed dtrace probes in Postrgres
would allow us
...
to troubleshoot[ing] obtuse production
problems. That, to me, is exciting stuff.
[paraphrased by SR]
I very much agree with the requirement
Indeed, I've been wondering lately if we shouldn't resurrect
LET_OS_MANAGE_FILESIZE and make that the default on systems with
largefile support. If nothing else it would cut down on open/close
overhead on very large relations.
I'd still put some limit on the filesize, else you cannot
Hi all
Just a note that pltcl is now passing regression tests on Unixware.
For some unexplained reason, it did'nt pass with tcl-8.5 but is ok with
tcl -8.4.13.
build farm build script updated accordingly.
My next try will be python.
Regards
--
Olivier PRENANT Tel:
Satoshi Nagayasu wrote:
Albe,
Albe Laurenz wrote:
/etc/pam.d/system-auth probably uses pam_unix.so to authenticate.
Does the user exist on the machine and have the password you try?
Yes, I have same user name on my linux box and postgresql,
and they have same password (now).
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 20 June 2006 00:02
To: Peter Eisentraut; pgsql-hackers@postgresql.org
Subject: [HACKERS] CVS HEAD busted on Windows?
I notice buildfarm member snake is unhappy:
Andrew Dunstan wrote:
don't use system auth. PAM can authenticate from many sources, not just
the system password files. LDAP is a commonly used source.
The reason why I'm trying to use PAM, is I need a feature
to account lock-out after N-times login failures on PG,
like pam_tally module.
I'm
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 20 June 2006 12:12
To: Dave Page
Cc: Tom Lane; Peter Eisentraut; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CVS HEAD busted on Windows?
1. it's nothing to do with upgrading - I saw this also and
Simon Riggs wrote:
On Tue, 2006-06-20 at 00:18 -0400, Tom Lane wrote:
One idea that comes to mind is to have a compile time option to record
the palloc __FILE__ and _LINE__ in every AllocChunk header. Then it
would not be so hard to identify the culprit while trawling through
memory.
Alvaro Herrera said:
That seems mostly the hard way to me, because our memory management
scheme is *not* based around thou shalt free() what thou malloc()ed.
You'd need a tool that understood about resetting memory contexts
(recursively) to get anywhere at all in analyzing such a trace.
Of
On Mon, Jun 19, 2006 at 05:14:15PM -0400, Chris Browne wrote:
[EMAIL PROTECTED] (Robert Lor) writes:
For DTrace, probes can be enabled using a D script. When the probes
are not enabled, there is absolutely no performance hit whatsoever.
That seems inconceivable.
In order to have a way
Andrew Dunstan wrote:
Alvaro Herrera said:
That seems mostly the hard way to me, because our memory management
scheme is *not* based around thou shalt free() what thou malloc()ed.
You'd need a tool that understood about resetting memory contexts
(recursively) to get anywhere at all in
Satoshi Nagayasu wrote:
Andrew Dunstan wrote:
don't use system auth. PAM can authenticate from many sources, not just
the system password files. LDAP is a commonly used source.
The reason why I'm trying to use PAM, is I need a feature
to account lock-out after N-times login failures on PG,
On Tue, Jun 20, 2006 at 12:18:32AM -0400, Tom Lane wrote:
Another thing to consider is that the proximate location of the palloc
is frequently *not* very useful. For instance, if your memory is
getting eaten by lists, all the palloc traces will point at
new_tail_cell(). Not much help. I
Simon Riggs [EMAIL PROTECTED] writes:
So we would use the async properties of sync, but not the file range
support?
That's the part of it that looked potentially useful to me, anyway.
I don't see any value for us in syncing just part of a file, because
we don't have enough disk layout knowledge
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes:
Indeed, I've been wondering lately if we shouldn't resurrect
LET_OS_MANAGE_FILESIZE and make that the default on systems with
largefile support. If nothing else it would cut down on open/close
overhead on very large relations.
I'd
Tom Lane [EMAIL PROTECTED] writes:
Another thing to consider is that the proximate location of the palloc
is frequently *not* very useful. For instance, if your memory is
getting eaten by lists, all the palloc traces will point at
new_tail_cell(). Not much help. I don't know what to do
Robert Lor [EMAIL PROTECTED] writes:
Yes, I'm proposing user-space probes (aka User Statically-Defined Tracing -
USDT). USDT provides a high-level abstraction so the application can expose
well defined probes without the user having to know the detailed
implementation. For example, instead
Tom Lane [EMAIL PROTECTED] writes:
Indeed, I've been wondering lately if we shouldn't resurrect
LET_OS_MANAGE_FILESIZE and make that the default on systems with
largefile support. If nothing else it would cut down on open/close
overhead on very large relations.
I'd still put some
Greg Stark [EMAIL PROTECTED] writes:
What would be useful is instrumenting high level calls that can't be traced
without application guidance. For example, inserting a dtrace probe for each
SQL and each plan node. That way someone could get the same info as EXPLAIN
ANALYZE from a production
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
What would be useful is instrumenting high level calls that can't be traced
without application guidance. For example, inserting a dtrace probe for each
SQL and each plan node. That way someone could get the same info
Hello folks,
Initdb seems to barf on me during the pg_authid bit. Below are the specifics.
Please ask if you need anything else. The build is CVS -HEAD.
Initdb output:
[EMAIL PROTECTED]:bin/initdb
The files belonging to this database system will be owned by user pgsql.
This user must also
ohp@pyrenet.fr writes:
Just a note that pltcl is now passing regression tests on Unixware.
For some unexplained reason, it did'nt pass with tcl-8.5 but is ok with
tcl -8.4.13.
AFAICT there is no tcl 8.5 yet; there is an alpha release tcl8.5a4
which is stated to still be under active feature
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Could we set that as an option for each memory context when we create
it? All or nothing seems too extreme for me for most cases.
What most cases? There is only one case -- there is a big leak and you
want to find out where.
Wade Klaver [EMAIL PROTECTED] writes:
Initdb seems to barf on me during the pg_authid bit. Below are the
specifics.
Please ask if you need anything else. The build is CVS -HEAD.
Are you sure it's a clean build? make distclean and trying again is
often the first thing to try when seeing
A bug reported by Josh Drake, crashes 8.1 and CVS HEAD:
Test case is:
create table pk (id bigserial primary key);
insert into pk values (DEFAULT);
insert into pk values (DEFAULT);
insert into pk values (DEFAULT);
update pk set id = max(id) + 2;
-- SEGV
simple eh? :-)
The backtrace on HEAD
Tom Lane wrote:
Lines 509-512 of contrib/dblink/expected/dblink.out read:
-- this should fail because there is no open transaction
SELECT dblink_exec('myconn','DECLARE xact_test CURSOR FOR SELECT * FROM foo');
ERROR: sql error
DETAIL: ERROR: cursor xact_test already exists
The error message
Hi Tom,
On Tue, 20 Jun 2006, Tom Lane wrote:
Date: Tue, 20 Jun 2006 12:42:24 -0400
From: Tom Lane [EMAIL PROTECTED]
To: ohp@pyrenet.fr
Cc: pgsql-hackers list pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pltcl -- solved
ohp@pyrenet.fr writes:
Just a note that pltcl is now passing
In pursuit of eliminating some redundant gettimeofday() calls, I just
tried to change struct Port's session_start field to TimestampTz,
which necessitated including utils/timestamp.h in libpq/libpq-be.h.
That caused things to blow up real good :-(. The problem is that
backend/libpq/md5.c includes
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, I was led to notice this while examining the current buildfarm
failure report from osprey,
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ospreydt=2006-06-17%2004:00:16
I haven't really looked at the buildfarm before -- I might be
Simon Riggs wrote:
This needs to work on Linux and Windows, minimum, also.
The proposed solution will work on Linux Windows if they similar
facility that the macros can map to. Otherwise, the macros stay as
no-ops and will not affect those platforms at all.
It's obviously impossible to
Tom Lane wrote:
Note to Andrew: would it make sense for the larger log files to be split
out as linked pages in a buildfarm report?
regards, tom lane
I will put it on the TODO list.
cheers
andrew
---(end of
Alvaro Herrera [EMAIL PROTECTED] writes:
update pk set id = max(id) + 2;
I'm fairly sure this query is illegal per spec. There are ancient
discussions in the archives about whether aggregates in an UPDATE target
list can have a consistent interpretation or not. We never found one,
but never
* Tom Lane ([EMAIL PROTECTED]) wrote:
libpgport (ie, move 'em to src/port). Moving them would lose some CVS
history but would probably be the cleanest thing in the long run.
Comments?
Time to consider something other than CVS...? In the end, personally
I'd rather have it be cleaner than the
Greg Stark wrote:
It seems pointless to me to expose things like lwlock_acuire that map 1-1 to C
function calls like LWLockAcquire. They're useless except to people who
understand what's going on and if people know the low level implementation
details of Postgres they can already trace those
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
update pk set id = max(id) + 2;
I'm fairly sure this query is illegal per spec. There are ancient
discussions in the archives about whether aggregates in an UPDATE target
list can have a consistent interpretation or not. We
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
update pk set id = max(id) + 2;
I'm fairly sure this query is illegal per spec. There are ancient
discussions in the archives about whether aggregates in an UPDATE target
list can have a consistent interpretation or not. We never
Looks like the distclean may have done it. I thought I had already, but who
knows.
Thanks.
-Wade
On Tuesday 20 June 2006 09:51, Tom Lane wrote:
Wade Klaver [EMAIL PROTECTED] writes:
Initdb seems to barf on me during the pg_authid bit. Below are the
specifics. Please ask if you need
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
update pk set id = max(id) + 2;
I'm fairly sure this query is illegal per spec. There are ancient
discussions in the archives about whether aggregates in an UPDATE target
list can have a consistent interpretation or not. We never
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
libpgport (ie, move 'em to src/port). Moving them would lose some CVS
history but would probably be the cleanest thing in the long run.
Comments?
Time to consider something other than CVS...? In the end, personally
I'd rather
Alvaro Herrera [EMAIL PROTECTED] writes:
A workaround of sorts would be to mention the origin of the files being
moved, so that an interested person can look it up via the Attic.
Yeah, that should be sufficient. The history is actually still there,
just attached to the old file location.
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I haven't really looked at the buildfarm before -- I might be blind, but
I couldn't figure out how to see the regression.diff file.
It's on the cited page, if you scroll down far enough.
OK, I'm officially blind (so much for that lasik
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
It looks to me like the diffs are consistent with the idea that the
test is using a copy of dblink that predates this patch ...
I would think that the diffs would be significantly larger if that were
the case. In fact, when was
Tom Lane [EMAIL PROTECTED] writes:
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
It looks to me like the diffs are consistent with the idea that the
test is using a copy of dblink that predates this patch ...
I would think that the diffs would be significantly larger if that were
Tom Lane wrote:
What's even more interesting is that there are now three later runs of
HEAD on osprey, and none of them failed. So unless Remi's been fooling
with the environment on that machine, this was a one-shot irreproducible
failure. That's disturbing in a different way ...
Joe Conway wrote:
...the BEGIN statement returned successfully as usual, but for some
reason left (PQtransactionStatus(conn) != PQTRANS_IDLE), causing
dblink_open() to start a transaction and later complete it on line 454.
Oops, I meant ... some reason left (PQtransactionStatus(conn) ==
Oswaldo Hernandez just reported this in the pgsql-es-ayuda list.
Basically, a conversion between UTF8 and windows_1250 can crash the
server.
I recall a bug around this general code but I don't recall it being able
to provoke a PANIC.
To reproduce, create a cluster with UTF-8 encoding and locale
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm fairly sure this query is illegal per spec. There are ancient
discussions in the archives about whether aggregates in an UPDATE target
list can have a consistent interpretation or not. We never found one,
but never got around to
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm fairly sure this query is illegal per spec. There are ancient
discussions in the archives about whether aggregates in an UPDATE target
list can have a consistent interpretation or not. We never found one,
but
Alvaro Herrera wrote:
To reproduce, you using a non-C locale is (es_ES works for me).
*blush* Sorry, I rewrote this phrase and obviously didn't reread it
very carefully :-) It means that you must use a non-C locale.
--
Alvaro Herrera
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I was trying to work around limitations with partitioning of tables
using constraint exclusion, when I ran across this little oddity:
I think you're under a misimpression about the syntax behavior of ORDER
BY and UNION. Per spec, ORDER BY
Alvaro Herrera [EMAIL PROTECTED] writes:
Note that the PO file for the spanish translation is written in Latin1,
not UTF8. So I can adventure that the server is trying to recode a
string which is originally in Latin1, but assuming it is UTF-8, to
Win1250.
Yeah, this is a known problem ---
After twelve years of using the domain candle.pha.pa.us, I have moved to
a new domain that is easier to remember, momjian.us.
New email address: [EMAIL PROTECTED]
New web site: http://momjian.us
The domain candle.pha.pa.us will continue to function indefinitely, but
if you
Alvaro Herrera [EMAIL PROTECTED] wrote
But the problem (or at last a part of the problem) is not what context
each chunk is allocated in, but where did a given chunk come from (where
was it allocated), Which is why saving __FILE__/__LINE__ is useful.
Agreed. Maybe we should not clutter
59 matches
Mail list logo
