On Wed, Jan 6, 2010 at 11:13 PM, Mike Landis wrote:
> Can you please stop displaying the email addresses on bug reports? It's one
> thing to require an email address - it's another thing entirely to publish
> it for spam address harvesting bots.
>
> This is an example page...
> http://archives.po
"Mike Landis" writes:
> When I execute the following SQL:
> "SELECT COUNT(*) FROM information_schema.tables WHERE table_name='proxies'"
> in the PGAdmmin 1.10.0, rev 7945-7946 query tool, I get "1" (the correct
> answer). When I run the exact same SQL in a C program, I get a result set
> with o
Robert Haas escribió:
> On Wed, Jan 6, 2010 at 11:13 PM, Mike Landis wrote:
> > Can you please stop displaying the email addresses on bug reports? It's one
> > thing to require an email address - it's another thing entirely to publish
> > it for spam address harvesting bots.
> >
> > This is an ex
mich...@x054:[/data/home/
michael]ls -ld /
drwxr-xr-x 27 root system 4096 Jan 04 17:20 /
mich...@x054:[/data/home/michael]ls -ld /usr
drwxr-xr-x 43 root system 4096 Jan 05 13:40 /usr
mich...@x054:[/data/home/michael]ls -ld /usr/local
drwxr-xr-x 19 root system
Michael Felt writes:
> I suppose I could turn on audit and see if it is trying to access a hard
> coded directory. But, in any case, I would update the error message to at
> least mention the directory name it is having issues with.
Well, the problem is what to print? The failure we are trying t
Well, there is an argument that a system call is using to get somewhere?
Even if it is a number, it is something. I could do an ncheck or whatever to
at least find what it is calling.
As I am not at all familiar with the code - just give me source to debug,
and I'll work from that.
On Thu, Jan 7,
Michael Felt writes:
> On Thu, Jan 7, 2010 at 3:35 PM, Tom Lane wrote:
>> Well, the problem is what to print? The failure we are trying to report
>> is exactly that we *can't get* the name of the directory.
> Well, there is an argument that a system call is using to get somewhere?
getcwd() has
Takahiro Itagaki writes:
> I found pgbench sometimes receives responces of "UPDATE 0" from HEAD server.
> When I re-tested pgbench with 8.4.2 server, all of the results were "UPDATE
> 1".
> Are there known issues in HEAD for concurrent updates?
I suspect it might have something to do with the re
mich...@x054:[/data/prj/postgresql-8.4.2/src]grep cwd */*.c
Well, unless you redefine it...
port/exec.c:#define getcwd(cwd,len) GetCurrentDirectory(len, cwd)
port/exec.c:charcwd[MAXPGPATH],
port/exec.c:if (!getcwd(cwd, MAXPGPATH))
port/exec.c:join_path_compo
On Thu, Jan 7, 2010 at 9:16 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Wed, Jan 6, 2010 at 11:13 PM, Mike Landis wrote:
>> > Can you please stop displaying the email addresses on bug reports? It's
>> > one
>> > thing to require an email address - it's another thing entirely to publ
On Thu, Jan 7, 2010 at 10:00 AM, Michael Felt wrote:
> mich...@x054:[/data/prj/postgresql-8.4.2/src]grep cwd */*.c
> Well, unless you redefine it...
> port/exec.c:#define getcwd(cwd,len) GetCurrentDirectory(len, cwd)
If you look at the context of this #define you'll see that it only
applies to W
I wrote a simple program - just calling getcwd() and I added some extra text
to exec.c - to know where it is at. You should recognize it.
mich...@x054:[/data/home/michael]ls -l /usr/local/pgsql/bin/mytest
-rwx--1 root system 4793 Jan 07 15:39
/usr/local/pgsql/bin/mytest
mich...
I turned on audit - it continues to say michael as user for accountability.
Notice: su changes to /home/postgres and initdb changes to
/usr/local/pgsql/bin
FS_Chdirmichael OK Thu Jan 07 16:06:35 2010
su Global
change current directory to: /hom
Robert Haas writes:
> I have to say that the error message that is produced by the above
> test case could easily send one looking in the wrong direction, and
> could perhaps stand to be improved. Could we just do getcwd() once,
> bail out if it fails, and then stash the results, rather than
> co
Michael Felt writes:
> I ran my test program with larger and smaller MAXPGPATH constants. 2046
> (1023 * 2) was the largest I tested and it worked fine. When it was shorted
> the call failed. I did not test the error message.
[ scratches head... ] This seems to be misbehavior of getcwd() itself,
Try the following, where
mystring is an extension of std::string...
mystring sql( "SELECT COUNT(*) FROM information_schema.tables
WHERE table_name='proxies' ");
int
GetIntFromSQL(
mystring& sql )
{
// if there's more than one
record in the ResultSet, still only retu
On Thu, Jan 7, 2010 at 7:51 AM, Mike Landis wrote:
> Try the following, where mystring is an extension of std::string...
It seems to me this would be a lot easier if you could attach a
complete program that someone could just compile, instead of code
fragments that are missing unspecified include
On Thu, Jan 7, 2010 at 11:39 AM, Tom Lane wrote:
> Robert Haas writes:
>> I have to say that the error message that is produced by the above
>> test case could easily send one looking in the wrong direction, and
>> could perhaps stand to be improved. Could we just do getcwd() once,
>> bail out i
On Tue, Oct 6, 2009 at 8:38 PM, Matthew Byrne wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5098
> Logged by: Matthew Byrne
> Email address: matt...@hairybrain.co.uk
> PostgreSQL version: 8.4.1
> Operating system: Linux x86_64 (Ubuntu 9.04)
> Descript
Robert Haas writes:
> On Thu, Jan 7, 2010 at 11:39 AM, Tom Lane wrote:
>> How does that help? We still can't print the directory name.
> Well, as it is, it looks like the failure of getcwd() might be an
> incidental problem, and the inability to find postgres was what sunk
> the ship. In fact,
Pick a database and table that exists, configure
the string cconstants, compile and run the attached cpp, get 0 instead of
1 (that you get in pgAdmin...
Where's can I download the libpq source? Maybe I can find and/or
fix the problem myself.
#include
#include // on Vista
#include// f
Mike Landis wrote:
>
>
> Pick a database and table that exists, configure
> the string cconstants, compile and run the attached cpp, get 0 instead of
> 1 (that you get in pgAdmin...
You realize that information_schema only shows you tables that have
permissions on, right? Make sure you're using
Mike Landis wrote:
Pick a database and table that exists, configure the string
cconstants, compile and run the attached cpp, get 0 instead of 1 (that
you get in pgAdmin...
Where's can I download the libpq source? Maybe I can find and/or fix
the problem myself.
Your program works fine for m
On Thu, Jan 7, 2010 at 7:31 PM, Mark Kirkwood
wrote:
> Mike Landis wrote:
>>
>> Pick a database and table that exists, configure the string cconstants,
>> compile and run the attached cpp, get 0 instead of 1 (that you get in
>> pgAdmin...
>>
>> Where's can I download the libpq source? Maybe I can
Takahiro Itagaki writes:
> I found pgbench sometimes receives responces of "UPDATE 0" from HEAD server.
> When I re-tested pgbench with 8.4.2 server, all of the results were "UPDATE
> 1".
> Are there known issues in HEAD for concurrent updates?
There are now :-(. I've committed a fix that I thi
Tom Lane wrote:
> Takahiro Itagaki writes:
> > I found pgbench sometimes receives responces of "UPDATE 0" from HEAD server.
> > When I re-tested pgbench with 8.4.2 server, all of the results were "UPDATE
> > 1".
> > Are there known issues in HEAD for concurrent updates?
>
> There are now :-(.
i am learning to use reply all, but having reply go to the list by default,
rather than the last person that replies might be useful as well.
On Thu, Jan 7, 2010 at 4:08 PM, Robert Haas wrote:
> On Thu, Jan 7, 2010 at 9:16 AM, Alvaro Herrera
> wrote:
> > Robert Haas escribió:
> >> On Wed, Jan 6
(I forgot to cc -bugs...)
Mike Landis wrote:
Two things strike me as odd about that...
1) What's the logic behind the owner of a table not automatically
getting a readonly privilege like SELECT?
Owner always has select on a table they have created.
2) I think it would be more logical to ref
Mike Landis wrote:
At 09:09 PM 1/7/2010, you wrote:
I suspect they do not. Its all in the permissions.
There's no user account control enabled on this Vista machine,
therefore effectively wide open, hence different platform behavior or
at least a difference between the behavior in pgAdmin
29 matches
Mail list logo
