On Fri, Oct 16, 2009 at 1:08 AM, Jesse Morris wrote:
> I went back to the version that supposedly initially fixed this issue,
> but I couldn't get it to work either. So I think the DACL adjustment
> code was always broken. The DACL stuff that both Cygwin and Active
> Perl use to simulate *nix f
Hi,
I've noticed I can't run vacuumdb with ALL FULL VERBOSE and FREEZE.
The error returned is:
vacuumdb: vacuuming of database "killingcupid.co.uk" failed: ERROR:
syntax error at or near "FREEZE"
LINE 1: VACUUM FULL VERBOSE FREEZE;
The commands I used are:
vacuumdb -afFv
vacuumdb --all --full
2009/10/16 Thom Brown :
> Hi,
>
> I've noticed I can't run vacuumdb with ALL FULL VERBOSE and FREEZE.
>
> The error returned is:
>
> vacuumdb: vacuuming of database "killingcupid.co.uk" failed: ERROR:
> syntax error at or near "FREEZE"
> LINE 1: VACUUM FULL VERBOSE FREEZE;
>
> The commands I used a
Thom Brown wrote:
> This is either a bug in vacuumdb with it not using the correct order,
> or postgres shouldn't be paying attention to the order of the
> keywords. In any case, it doesn't work. I've searched the postgres
> FAQs, TODO and mailing list archives, but can't find a mention of
> this
2009/10/16 Heikki Linnakangas :
> Thom Brown wrote:
>> This is either a bug in vacuumdb with it not using the correct order,
>> or postgres shouldn't be paying attention to the order of the
>> keywords. In any case, it doesn't work. I've searched the postgres
>> FAQs, TODO and mailing list archiv
Thom Brown wrote:
> Thanks Heikki. You probably already know, but remember to prevent it
> using FREEZE at all for 8.5+ as according to the documentation it's
> being deprecated.
It's been documented as deprecated since 8.2, in favor of the
vacuum_freeze_max_age option. However, it's still widely
2009/10/16 Heikki Linnakangas :
> Thom Brown wrote:
>> Thanks Heikki. You probably already know, but remember to prevent it
>> using FREEZE at all for 8.5+ as according to the documentation it's
>> being deprecated.
>
> It's been documented as deprecated since 8.2, in favor of the
> vacuum_freeze_
Ok... I compiled 8.2.14 and 8.3.8 with the same configure options. They
both segfaut when doing the authentication. Note that when I use -W
option with psql everything works ok. I went back to 8.4.1 enabled the
max debug level then re-tested and got the info below in the log. I went
to line 769 in
Both actually...
When just the "return" is commented out the routine goes into a loop and
the following shows up in the logs...
LOG:
could not receive data from client: Connection reset by peer
LOG:
could not receive data from client: Connection reset by peer
LOG:
could not receive data from cl
The following bug has been logged online:
Bug reference: 5122
Logged by: Muris Pucic
Email address: t...@multicom.ba
PostgreSQL version: 8.2
Operating system: Vista
Description:Subqueries - inner select statement bug
Details:
Hi,
If we have two simple tables:
TABL
The following bug has been logged online:
Bug reference: 5123
Logged by: Andrey
Email address: and...@ulab.ru
PostgreSQL version: 8.4.1-x86_64
Operating system: RHEL5-x86_64
Description:bug in window function "last_value"
Details:
EXAMPLE:
CREATE TABLE t
(
id ser
On Fri, Oct 16, 2009 at 6:39 AM, Heikki Linnakangas
wrote:
> Thom Brown wrote:
>> This is either a bug in vacuumdb with it not using the correct order,
>> or postgres shouldn't be paying attention to the order of the
>> keywords. In any case, it doesn't work. I've searched the postgres
>> FAQs,
Andrey wrote:
> select id, first_value(id) over(order by id), last_value(id) over(order by
> id) from t;
>
> RESULT:
> id | first_value | last_value
> +-+
> 1 | 1 | 1
> 2 | 1 | 2
> 3 | 1 | 3
> (3 rows)
>
>
2009/10/16 Robert Haas :
> The fact that this is order-sensitive is just a trap for the unwary
> anyway. I wonder if we ought to implement a flexible options syntax
> like we did for EXPLAIN and COPY, though since I don't know of any new
> options that are needed here maybe it's not worth it.
>
>
Muris Pucic wrote:
> -- The query below works, even though there is no column "first_name" in
> TABLE2. This should return an error but it does not, it returns all rows
> from TABLE1. This query should not evaluate correctly even when aliases are
> not used because it can be misleading.
>
> SELECT
"Muris Pucic" writes:
> -- The query below works, even though there is no column "first_name" in
> TABLE2. This should return an error but it does not, it returns all rows
> from TABLE1. This query should not evaluate correctly even when aliases are
> not used because it can be misleading.
> SELE
Heikki Linnakangas writes:
> Andrey wrote:
>> select id, first_value(id) over(order by id), last_value(id) over(order by
>> id) from t;
>>
>> RESULT:
>> id | first_value | last_value
>> +-+
>> 1 | 1 | 1
>> 2 | 1 | 2
>> 3 |
2009/10/16 Tom Lane :
> Heikki Linnakangas writes:
>> Andrey wrote:
>>> select id, first_value(id) over(order by id), last_value(id) over(order by
>>> id) from t;
>>>
>>> RESULT:
>>> id | first_value | last_value
>>> +-+
>>> 1 | 1 | 1
>>> 2 |
Pedro Gimeno wrote:
> Tom Lane wrote:
>
>> This could be addressed by having the postmaster report its $PGDATA
>> value in the pg_ping response, but I would be against that on
>> security grounds. We don't let nonprivileged users know where
>> PGDATA is, why would we make the information availab
On Fri, Oct 16, 2009 at 10:33 AM, Kevin Grittner
wrote:
> Pedro Gimeno wrote:
>> Tom Lane wrote:
>>
>>> This could be addressed by having the postmaster report its $PGDATA
>>> value in the pg_ping response, but I would be against that on
>>> security grounds. We don't let nonprivileged users kno
Robert Haas wrote:
> Well, then Tom's idea of using a random number seems pretty solid no
> matter how you slice it. Maybe a UUID.
A random number is looking like the best option. I'm not sure why I'd
want to generate a perfectly good 128 bit random number and then throw
away six of the bits
Well, we certainly are not going to break pq_recvbuf in such a
fundamental way as that ;-). I think that the more likely place
to work around this is going to be in pam_passwd_conv_proc() in
src/backend/libpq/auth.c. In particular, I see that when it gets
a NULL from recv_password_packet (which i
"Kevin Grittner" writes:
> Robert Haas wrote:
>> Well, then Tom's idea of using a random number seems pretty solid no
>> matter how you slice it. Maybe a UUID.
> A random number is looking like the best option. I'm not sure why I'd
> want to generate a perfectly good 128 bit random number and
Tom Lane wrote:
> I was envisioning just using PostmasterRandom() (after initializing
> the seed from time(NULL) as we do now). I don't think we need a
> super-wide random number.
Fine with me. Just that and CanAcceptConnections in the response?
It seems like pg_ping (client utility and re
"Kevin Grittner" writes:
> It seems like pg_ping (client utility and related postmaster support)
> should be a discrete patch. Improvements to pg_ctl and init scripts
> would come later, as separate patches?
Sounds sane to me. Alternatively, do the postmaster support and make
the presumably-min
Tom Lane wrote:
> Alternatively, do the postmaster support and make the
> presumably-minor pg_ctl mods to use it, and then a standalone
> pg_ping utility could come later. I'm not sure how big the utility
> would be, but surely bigger than the delta in pg_ctl.
Bigger than the delta for *just
"Douglas, Ryan" writes:
> Program terminated with signal 11, Segmentation fault.
> #0 0x00559624 in pam_passwd_conv_proc ()
> Missing separate debuginfos, use: debuginfo-install
> audit-libs-1.7.13-1.fc11.x86_64
> (gdb) bt
> #0 0x00559624 in pam_passwd_conv_proc ()
> #1 0x7
On Fri, Oct 16, 2009 at 04:45:55PM +0300, Heikki Linnakangas wrote:
> Andrey wrote:
> > select id, first_value(id) over(order by id), last_value(id) over(order by
> > id) from t;
> >
> > RESULT:
> > id | first_value | last_value
> > +-+
> > 1 | 1 |
"Douglas, Ryan" writes:
> I added some logging statements in the pam_passwd_conv_proc function and
> it gets as far as checking if the password is null then returning
> PAM_CONV_ERR.
That's what I would expect to happen if you don't use -W in psql.
What I suspect is happening with the MS KDC is t
Muris Pucic wrote:
> -- The query below works, even though there is no column "first_name" in
> TABLE2. This should return an error but it does not, it returns all rows
> from TABLE1. This query should not evaluate correctly even when aliases are
> not used because it can be misleading.
>
> SELEC
"Douglas, Ryan" writes:
> Any tips on using gdb to step through the code?
If you set pre_auth_delay to 30s or so in postgresql.conf, it'll
slow things down enough so that you can get the backend's PID from
"ps" and then attach to it with gdb. Then set a breakpoint at
pam_passwd_conv_proc, contin
David Fetter writes:
> I think what the OP was expecting was to have the last value be 3
> instead of changing. This is at least a POLA violation.
[ shrug... ] It's what the spec requires, as far as anybody here
can tell. As Hitoshi-san already noted, we do point out in our
docs that last_valu
I added some logging statements in the pam_passwd_conv_proc function and
it gets as far as checking if the password is null then returning
PAM_CONV_ERR.
if (strlen(appdata_ptr) == 0)
{
char *passwd;
sendAuthRequest(pam_port_cludge, AUTH_REQ_P
Any tips on using gdb to step through the code?
[postg...@va-mp-db02 ~]$ file /usr/local/pgsql/bin/postgres
/usr/local/pgsql/bin/postgres: ELF 64-bit LSB executable, x86-64,
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
2.6.18, not stripped
Pg Log ---
<[unkno...@[u
On Fri, Oct 16, 2009 at 11:08 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Well, then Tom's idea of using a random number seems pretty solid no
>> matter how you slice it. Maybe a UUID.
>
> A random number is looking like the best option. I'm not sure why I'd
> want to generate a perfect
I wrote:
> The best idea I can come up with is that the conv_proc is being called
> with zero messages and is dumping core because it tries to print the
> contents of msg[0]. However, it's far from clear why libpam would
> bother to call it with zero messages.
Hah --- found it. (Man, it is so ni
2009/10/16 Tom Lane :
> I wrote:
>> The best idea I can come up with is that the conv_proc is being called
>> with zero messages and is dumping core because it tries to print the
>> contents of msg[0]. However, it's far from clear why libpam would
>> bother to call it with zero messages.
>
> Hah -
Robert Haas wrote:
> UUIDs throw away 6 bits?
http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
> -Original Message-
> From: Dave Page [mailto:dp...@pgadmin.org]
> Sent: Friday, October 16, 2009 2:14 AM
> To: Jesse Morris
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] Re: BUG #5065: pg_ctl start fails as
administrator,
> with "could not locate matching postgres executable"
>
>
On Fri, Oct 16, 2009 at 2:04 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> UUIDs throw away 6 bits?
>
> http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29
How about that. You learn something new every day.
...Robert
--
Sent via pgsql-bugs mailing list (pg
"Douglas, Ryan" writes:
>You were right. According to the trace msg[0] is null.
Hah. This must be triggered by something Active Directory does that
a KDC doesn't, because I'm still not seeing it here. But anyway the
problem is clear now, we have to avoid referencing msg[0] when num_msg
is z
On Fri, Oct 16, 2009 at 01:28:57PM -0400, Tom Lane wrote:
> David Fetter writes:
> > I think what the OP was expecting was to have the last value be 3
> > instead of changing. This is at least a POLA violation.
>
> [ shrug... ] It's what the spec requires, as far as anybody here
> can tell. As
Tom,
You were right. According to the trace msg[0] is null.
(gdb) set follow-fork-mode child
(gdb) c
Continuing.
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5a6c2b77b0 (LWP 23208)]
0x00580cf4 in pam_passw
It works like champ... cool.. thanks.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Friday, October 16, 2009 4:15 PM
To: Douglas, Ryan
Cc: Magnus Hagander; pgsql-bugs
Subject: Re: [BUGS] BUG #5121: Segmentation Fault when using pam w/ krb5
"Douglas, Ryan" writes:
The following bug has been logged online:
Bug reference: 5124
Logged by: malu
Email address: maluulam_l...@yahoo.com.mx
PostgreSQL version: 8.3
Operating system: windows xp proffeional
Description:visualizacion de registros
Details:
Hola que tal, buen dia, veran est
45 matches
Mail list logo
