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 t
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 auth
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 t
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. I
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=emu&br=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
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
> x = 0 '\0'
>
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 st
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
>
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 didn
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 given
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 se
-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
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 fo
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 we
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 which
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 b
-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
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 rea
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 t
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 perf
-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
-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 fairl
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 goo
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 m
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
>>> progres
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 l
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
stemmin
"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 whic
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 t
>>> 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 ben
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 a
-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
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 ac
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 variabl
"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 o
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 y
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
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
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 parame
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
55 matches
Mail list logo
