Hi all,
apologize if this is a trivial question but I'd like to understand what values
are stored in the RelOptInfo-reltargetlist or, better, how I can check such
values in the information schema to understand what they refer to. I've tried
to look in the pg_attribute table but I was not able
Hi all,
http://archives.postgresql.org/pgsql-admin/2003-02/msg00301.php
I also try to address the same issue..
I run postmaster as postgres user and pg_hba.conf includes the following
entry:
local all dhanaraj pam
However, the authentication fails for
Dhanaraj M wrote:
Hi all,
http://archives.postgresql.org/pgsql-admin/2003-02/msg00301.php
I also try to address the same issue..
I run postmaster as postgres user and pg_hba.conf includes the
following entry:
local all dhanaraj pam
However, the
Andrew Dunstan wrote:
Dhanaraj M wrote:
The non-root user does not have the permission to read other unix
local user password.
I found two solutions:
1. usermod -K defaultpriv=Basic,file_dac_read postgres
- Gives privilege to read all files. This solution works. Is it the
right way
Zdenek Kotala wrote:
The problem what Dhanaraj tries to address is how to secure solve
problem with PAM and local user. Other servers (e.g. sshd) allow to
run master under root (with limited privileges) and forked process
under normal user. But postgresql
requires start as non-root user.
at least one of my buildfarm members (emu) is crashing on what seems
totally unrelated regression tests for a few days now:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=emubr=HEAD
it took me about 10 tries to reproduce that manually and I'm getting the
following stacktrace:
Luca Ferrari [EMAIL PROTECTED] writes:
apologize if this is a trivial question but I'd like to understand what
values
are stored in the RelOptInfo-reltargetlist or, better, how I can check such
values in the information schema to understand what they refer to. I've tried
to look in the
On Mon, August 20, 2007 19:52, Andrew Dunstan wrote:
I'd rather see an HBA fallback mechanism, which I suspect might overcome
most of the problems being encountered here.
I implemented a form of that once, so on local connections you could do
ident mapping with fallback to PAM or some other
Hi,
can anyone let me know that why Nested Loop path is not allowed if jointype
are JOIN_RIGHT or JOIN_FULL?
At match_unsorted_outer(), we having case where nestjoinOK = false if there
are
JOIN_RIGHT or JOIN_FULL.
match_unsorted_outer()
{
case JOIN_RIGHT:
case JOIN_FULL:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
at least one of my buildfarm members (emu) is crashing on what seems
totally unrelated regression tests for a few days now:
I was wondering about that ...
it took me about 10 tries to reproduce that manually and I'm getting the
following
Rushabh Lathia [EMAIL PROTECTED] writes:
can anyone let me know that why Nested Loop path is not allowed if jointype
are JOIN_RIGHT or JOIN_FULL?
How are you going to track which of the inner-relation rows never find a
join partner and hence need to be emitted on their own?
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
at least one of my buildfarm members (emu) is crashing on what seems
totally unrelated regression tests for a few days now:
I was wondering about that ...
it took me about 10 tries to reproduce that manually and I'm getting the
On 19-aug-2007, at 12:38, Tom Lane wrote:
Hack is the right word. People keep proposing variants of the idea
that the executor should optimize updates on the basis of examining
the query tree to see whether columns changed or not, and they're
always
wrong. You don't know what else might
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
as for len it seems to be 0:
#0 varbit_out (fcinfo=0x88c75000) at varbit.c:549
s = (VarBit *) 0x88c75000
result = 0x84d33128
r = 0x84d33128
sp = (bits8 *) 0x88c75000 Address 0x88c75000 out of bounds
Andrew Dunstan wrote:
Zdenek Kotala wrote:
The problem what Dhanaraj tries to address is how to secure solve
problem with PAM and local user. Other servers (e.g. sshd) allow to
run master under root (with limited privileges) and forked process
under normal user. But postgresql
requires
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
as for len it seems to be 0:
#0 varbit_out (fcinfo=0x88c75000) at varbit.c:549
s = (VarBit *) 0x88c75000
result = 0x84d33128
r = 0x84d33128
sp = (bits8 *) 0x88c75000 Address 0x88c75000
Here is the current 8.3 patch status:
http://developer.postgresql.org/index.php/Todo:PatchStatus
As you can see we have two major patches remaining, tsearch2 and HOT.
Tom is working on tsearch2 now and Paven just posted an updated HOT
patch. (Only the GIT (group index tuples) patch
Just FYI:
I took the latest snapshot CATALOG_VERSION_NO 200707251 and function
quote_literal throws an error:
# select quote_literal(1);
2007-08-20 18:50:17 PDT ERROR: function quote_literal(integer) does not
exist at character 8
2007-08-20 18:50:17 PDT HINT: No function matches the
Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
We show this as waiting for performance results. I am thinking we
should hold this for 8.4.
Agreed. I spent close to a week trying different benchmarks and
configurations and simple test cases on a test
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heikki Linnakangas wrote:
Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
We show this as waiting for performance results. I am thinking we
should hold this for 8.4.
Agreed. I spent close to a week trying
Heikki Linnakangas wrote:
Bruce Momjian wrote:
o Error correction for n_dead_tuples
This shows as waiting on another patch. Again, I am thinking to
keep it for 8.4.
It was waiting on the vacuum oldestxmin patch, which didn't make it to
8.3. I don't care for the patch
Attached is version 0.3 of the proposed PGparam extension to the libpq
API. I think we are wrapping up our changes in the short term and
will begin using our api for our internal projects. There were a lot
of changes and reorganizations, but the big features are that client
side geometry types
I'm debugging this problem with stalled transactions waiting on locks which
have already been granted and I'm puzzled by something. What is this PGPROC
entry from?
It's not a real process (pid is 0) and it's not garbage either (prev and next
both point to a real PGPROC entry, namely MyProc
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
We show this as waiting for performance results. I am thinking we
should hold this for 8.4.
Agreed. I spent close to a week trying different benchmarks and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
We show this as waiting for performance results. I am thinking we
should hold this
Gregory Stark wrote:
I'm debugging this problem with stalled transactions waiting on locks which
have already been granted and I'm puzzled by something. What is this PGPROC
entry from?
It's not a real process (pid is 0) and it's not garbage either (prev and next
both point to a real
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
We show this as waiting for performance results. I am thinking we
should hold this for 8.4.
Agreed. I spent
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
We show this as waiting for performance results. I am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alvaro Herrera wrote:
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
I guess my point is, if the patch looks good and does not appear to hurt
anything, why not apply it?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
\
I would expect a fairly static benchmark
Joshua D. Drake wrote:
I guess my point is, if the patch looks good and does not appear to hurt
anything, why not apply it? At least that way we can start to review the
progress of the feature itself as it starts to see use.
I don't think that's a very good criterion. We need to have
I've been lobbying management here for us to allocate some resources to testing
8.3 once it hits beta. If it is approved, it might happen on a time frame too
short to get much feedback before the tests, so I'm throwing the question out
here now: what would people like us to bang on?
The box
Joshua D. Drake wrote:
Alvaro Herrera wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
I guess my point is, if the patch looks good and does not appear to hurt
anything, why not apply it? At least that way we can start to review the
progress of the feature
Kevin Grittner wrote:
I've been lobbying management here for us to allocate some resources to
testing 8.3 once it hits beta. If it is approved, it might happen on a time
frame too short to get much feedback before the tests, so I'm throwing the
question out here now: what would people like
while playing with the binary transport of the money type we found
another bug. The following code segfaults the server on 8.3cvs:
select '3'::money * 2;
this was an accidental discovery by us but is the second serious bug
we found with the money type without looking very hard...probably
Kevin Grittner [EMAIL PROTECTED] writes:
When we first went to PostgreSQL our biggest problem was that dirty buffers
would accumulate in shared memory until a checkpoint, and then overrun the
controllers cache. This would cause disk reads to queue up behind the
writes, and queries which
On Mon, 20 Aug 2007 17:32:42 -0400
Merlin Moncure [EMAIL PROTECTED] wrote:
while playing with the binary transport of the money type we found
another bug. The following code segfaults the server on 8.3cvs:
select '3'::money * 2;
What does SELECT 2 * '3'::money; do? If that works try
What does SELECT 2 * '3'::money; do?
That works.
try changing 64 to 32 in the function cash_mul_int4
That also worked.
Datum
cash_mul_int4(PG_FUNCTION_ARGS)
{
Cashc = PG_GETARG_CASH(0);
/*int64 i = PG_GETARG_INT64(1);*/
int32 i =
Division segfaults server as well - SELECT '3'::money / 2 - for the same reason
multiplication did.
/* cash_div_int4()
* Divide cash by 4-byte integer.
*
*/
Datum
cash_div_int4(PG_FUNCTION_ARGS)
{
Cashc = PG_GETARG_CASH(0);
int64 i = PG_GETARG_INT64(1);
Hi developers,
I'm about to send mails to some of PostgreSQL developers to know their
profiles. This work is part of JPUG(Japan PostgreSQL Users Group)
activities. I believe the result will be used by JPUG for making a
future plan to encourage PostgreSQL developments. Please take a time
to answer
I've applied version 0.58 of the patch with a lot of further
editorializing. I feel fairly confident now in the code that interfaces
between tsearch and the rest of the system, but a lot of the
lowest-level guts of tsearch (mainly in src/backend/tsearch/*.c and
src/backend/utils/adt/ts*.c) left
Heikki Linnakangas [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
o Automatic adjustment of bgwriter_lru_maxpages
We show this as waiting for performance results. I am thinking we
should hold this for 8.4.
Agreed. I spent close to a week trying different benchmarks and
Tom Lane wrote:
I am quite confident that this commit broke the MSVC build, which seems
to need to know individually about each shared library ... Magnus,
can you do something about that? We'll see what other portability
problems emerge from the buildfarm.
You broke my shiny new MinGW
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Also, we need to decide what to do with contrib/tsearch2, which is
currently DOA because of conflicts with the new core code. We could
either rip it out entirely, or try to convert it into a compatibility
package. In view of the
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
(gdb) info locals
fcinfo = {flinfo = 0x84d33028, context = 0x0, resultinfo = 0x0,
isnull = 0 '\0', nargs = 1, arg = {2294763512, 16, 2377208416, 1,
...
(gdb) x/16x 0x88c75000 - 8
0x88c74ff8: 0x0020 0x Cannot access
Andrew Dunstan [EMAIL PROTECTED] writes:
You broke my shiny new MinGW and Cygwin buildfarm members too :-)
Yeah, I was just looking at that. I seem to recall that the
fu01.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
bleat is a symptom of a reference to a variable
Jignesh K. Shah [EMAIL PROTECTED] writes:
# select quote_literal(1);
2007-08-20 18:50:17 PDT ERROR: function quote_literal(integer) does not
exist at character 8
quote_literal(integer) never existed in any previous release, either.
What you are seeing is a side effect of the removal of
On Mon, 20 Aug 2007 20:00:47 -0400
Andrew Chernow [EMAIL PROTECTED] wrote:
What does SELECT 2 * '3'::money; do?
That works.
try changing 64 to 32 in the function cash_mul_int4
That also worked.
See submitted patch that fixes cash_send and cash_recv as well.
Patch:
Gregory Stark [EMAIL PROTECTED] writes:
I'm debugging this problem with stalled transactions waiting on locks which
have already been granted and I'm puzzled by something. What is this PGPROC
entry from?
I seem to recall that there's a dummy sentinel header in proc lists ...
is that what
Andrew Chernow [EMAIL PROTECTED] writes:
Division segfaults server as well - SELECT '3'::money / 2 - for the same
reason
multiplication did.
Yup. A quick scan doesn't show any other mistaken int32-int64
replacements in the file, but maybe someone wants to look closer?
Patch applied.
Tom Lane wrote:
The main thing that is lacking at the moment is documentation. The
stuff Bruce has been working on will be good introductory material,
but we've got basically zip in reference material. I'll do some work
on that over the next couple of days, but there's probably room for
Heikki Linnakangas [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
o Error correction for n_dead_tuples
This shows as waiting on another patch. Again, I am thinking to
keep it for 8.4.
It was waiting on the vacuum oldestxmin patch, which didn't make it to
8.3. I don't care for the patch
Bruce Momjian [EMAIL PROTECTED] writes:
Oleg and Teodor did provide reference documentation. You can see the
SGML here:
http://momjian.us/expire/textsearch/SGML/ref/
The SQL commands were in a state of flux so I haven't worked on them
yet. I can start now.
OK. I whacked around the
On Tue, 21 Aug 2007, ITAGAKI Takahiro wrote:
Does anyone have a way to measure the performance difference by
bgwriter_lru_xxx ? I have no performance results not only of the patch
but also of those parameters. I'd like to use those test cases to compare
manual and automatic tunings of lru
Tom Lane [EMAIL PROTECTED] wrote:
o Error correction for n_dead_tuples
Also, I'm still quite unhappy that the patch converts the tracking of
n_dead_tuples into a dead-reckoning system in which incremental changes
are continually applied without any feedback that'd prevent the value
from
55 matches
Mail list logo
