On Fri, Oct 16, 2009 at 1:08 AM, Jesse Morris jmor...@coverity.com 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
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 thombr...@gmail.com:
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
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 heikki.linnakan...@enterprisedb.com:
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,
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 heikki.linnakan...@enterprisedb.com:
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
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
Both actually...
When just the return is commented out the routine goes into a loop and
the following shows up in the logs...
rdoug...@tacacs 10.0.20.38(47254) 2009-10-16 01:12:18.935 EDTLOG:
could not receive data from client: Connection reset by peer
rdoug...@tacacs 10.0.20.38(47254)
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:
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
On Fri, Oct 16, 2009 at 6:39 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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)
fist_value
2009/10/16 Robert Haas robertmh...@gmail.com:
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
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 * FROM
Muris Pucic t...@multicom.ba 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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 |
2009/10/16 Tom Lane t...@sss.pgh.pa.us:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Pedro Gimeno pgsql-...@personal.formauri.es 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
On Fri, Oct 16, 2009 at 10:33 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Pedro Gimeno pgsql-...@personal.formauri.es 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
Robert Haas robertmh...@gmail.com 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
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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us 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
Douglas, Ryan rdoug...@arbinet.com 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 ()
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 | 1
2 |
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 *
Douglas, Ryan rdoug...@arbinet.com 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
David Fetter da...@fetter.org 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
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,
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 ---
On Fri, Oct 16, 2009 at 11:08 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com 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
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 nice
2009/10/16 Tom Lane t...@sss.pgh.pa.us:
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.
Robert Haas robertmh...@gmail.com 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:
-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
The
On Fri, Oct 16, 2009 at 2:04 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com 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.
Douglas, Ryan rdoug...@arbinet.com 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]
On Fri, Oct 16, 2009 at 01:28:57PM -0400, Tom Lane wrote:
David Fetter da...@fetter.org 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
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
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
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
44 matches
Mail list logo
