On Thu, May 28, 2009 at 2:07 PM, Peter Koczan wrote:
> On Thu, May 28, 2009 at 1:30 PM, Tom Lane wrote:
>> Peter Koczan writes:
>>> It was rather convenient to know that whatever Kerberos principal was
>>> used was going to be the database user.
>>
>> Isn
On Thu, May 28, 2009 at 1:30 PM, Tom Lane wrote:
> Peter Koczan writes:
>> It was rather convenient to know that whatever Kerberos principal was
>> used was going to be the database user.
>
> Isn't that still true? (Modulo the auth.c bug fix of course.) The only
On Wed, May 27, 2009 at 5:16 PM, Tom Lane wrote:
> What this still leaves us with is whether that change is a bad idea or
> not. I still think it's OK, but maybe Peter can point to something
> else.
I recompiled postgres with the auth.c patch.
This is only an issue if you are trying to connect
I don't know if it's much use now, but here you go.
On Wed, May 27, 2009 at 3:15 PM, Magnus Hagander wrote:
> We are certainly *supposed* to do that. And we have been doing that. So
> if that's not done, it's been broken in 8.4 (most likely by me).
>
> Peter, are you using gssapi or krb5? Only kr
> We should probably at least clarify this release note. Do you want
> to make an argument that this is a fundamental breakage and we need
> to revert it? If so, what's the argument?
Certainly.
It seems like with the changes in 8.4, krb5/gssapi auth looks for a
valid ticket, and if it finds one
The following bug has been logged online:
Bug reference: 4824
Logged by: Peter Koczan
Email address: pjkoc...@gmail.com
PostgreSQL version: 8.4beta2
Operating system: Red Hat Enterprise Linux 5.3
Description:KRB5/GSSAPI authentication fails when user != principal
> From: "Peter Koczan" <[EMAIL PROTECTED]>
> To: pgsql-bugs@postgresql.org
> Date: Wed, 23 Apr 2008 17:17:01 GMT
> Subject: BUG #4126: KRB5/GSSAPI authenication fails for multipart kerberos
> principals
>
> When trying to connect to an 8.3 server using a
The following bug has been logged online:
Bug reference: 4126
Logged by: Peter Koczan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Red Hat Enterprise Linux 5
Description:KRB5/GSSAPI authenication fails for multipart kerberos
principals
The following bug has been logged online:
Bug reference: 4092
Logged by: Peter Koczan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: Red Hat Enterprise Linux 5
Description:initdb fails if the xlog directory is the same as
[pg_data
> Hmm, crash inside getenv?? That's weird, that suggests something has
> clobbered the environment-strings data structure.
>
> [ pokes around in code... ] And behold, here's a smoking gun:
> pg_GSS_recvauth() is doing a putenv() with a string that it got from
> palloc(). The active context at th
> > No, we want a stack trace from the crash. You could attach gdb to the
> > child process after forking and before you provoke the crash; or arrange
> > for a core dump file to be produced and gdb that.
>
> I should be able to get that for you tomorrow, if we don't figure out
> the issue sooner.
> I think you misunderstand what is happening. The parent postmaster
> process is not restarting, because it did not crash. The crash is
> happening in a child process that is forked off by the postmaster to
> service a particular connection.
I see what you're saying, that it's one particular co
On Jan 25, 2008 4:31 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Can you get us a stack trace from that crash?
Here's the trace of the server process post-crash.
[EMAIL PROTECTED] ~]# gdb -p 24078
(gdb) bt
#0 0x006ac402 in __kernel_vsyscall ()
#1 0x0060801d in ___newselect_nocancel () from /lib/l
The following bug has been logged online:
Bug reference: 3902
Logged by: Peter Koczan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3RC2
Operating system: Red Hat Enterprise Linux 5
Description:Segmentation faults using GSSAPI authentication
Details
> Please share the ending with us, I'm really curious after following this
> thread :).
It turns out that it was part DBD::Pg and part our app (a big part). A
plugin for the app creates a separate db handle which listens, but
never does anything with the notifications. Apparently, the recv-q
clear
> Hm. To me it looks like the first psql session isn't prepared to gather
> async notifies (checking...) indeed, psql only checks for async notifies when
> issuing commands (you don't have to issue a NOTIFY in "Connection 1" to
> receive the pending notifies -- *any* request directed to the server
Hey, I found something that finally clears netstat's recv-q with async
notifies. I don't quite understand what's going on, so any
enlightenment would be greatly appreciated. As near as I can figure,
the client doesn't appear to read the notifies until it sends a notify
of its own. Then it reads all
On 8/9/07, Peter Koczan <[EMAIL PROTECTED]> wrote:
> On 8/6/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Peter Koczan" <[EMAIL PROTECTED]> writes:
> > > Here's my theory (and feel free to tell me that I'm full of
> > > it)...some
On 8/6/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Peter Koczan" <[EMAIL PROTECTED]> writes:
> > Here's my theory (and feel free to tell me that I'm full of it)...somehow, a
> > lot of notifies happened at once, or in a very short period of time, to t
| 19583 | 1703
(4 rows)
On 8/6/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Peter Koczan" <[EMAIL PROTECTED]> writes:
> > So, it looks like the app polls for async notifies every second.
> Hopefully
> > you can glean some insight from that
f the main window, so it looks
like if you have more than one main window open, update_reqs would
be called more often. That might have to be changed.
So, it looks like the app polls for async notifies every second. Hopefully
you can glean some insight from that.
Peter
On 8/3/07, Peter Kocz
I think the code is somehow interrupt based, but I don't know. I've
asked the primary maintainer of the program to look into this with me.
We should have more insight by early next week.
Peter
Tom Lane wrote:
"Peter Koczan" <[EMAIL PROTECTED]> writes:
This app
= 70400
PQfreemem(notify);
#else
Safefree(notify);
#endif
retsv = newRV(sv_2mortal((SV*)ret));
return retsv;
} /* end of dbd_db_pg_notifies */
On 8/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Peter Koczan" <[EMAIL PROTECTED]> writes:
> &g
ifies. They may not have happened at the same time, but it's a bit
perplexing that they all have the exact same amount of data in the queue.
Peter
On 8/2/07, Peter Koczan <[EMAIL PROTECTED]> wrote:
>
> I found something pretty interesting when running netstat's:
>
> Be
quick perusal of the other "notify interrupt" connections shows 13032 in
the Send-Q column. They all got into this state at the same time.
Peter
P.S. Thanks for the help, I really appreciate it.
On 8/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Peter Koczan <[EMAIL PRO
Tom Lane wrote:
1Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Peter Koczan wrote:
There is a problem where connections listening for asynchronous notifies
occasionally block for writing on ther server side and never finish,
Does the client read the async notifie
Heikki Linnakangas wrote:
Peter Koczan wrote:
There is a problem where connections listening for asynchronous notifies
occasionally block for writing on ther server side and never finish,
resulting in connections that always have the status "notify interrupt".
Apparently, this cau
The following bug has been logged online:
Bug reference: 3504
Logged by: Peter Koczan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: CentOS 4.5 Linux (RHEL 4), kernel 2.6.9-55.ELsmp
Description:Some listening sessions never return from
like a problem.
-------
Peter Koczan wrote:
The following bug has been logged online:
Bug reference: 3266
Logged by: Peter Koczan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: CentOS Linux 4.4 (
One more quick addendum...I tried this with non-SSL connections, and
this problem did *not* arise when using non-SSL connections.
Peter Koczan wrote:
Yes, #2829 seems quite similar to my plight. I did take a look through
the code tree and there appear to be checks for an EINTR status within
The following bug has been logged online:
Bug reference: 3266
Logged by: Peter Koczan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: CentOS Linux 4.4 (RHEL 4) running on Pentium 4
Description:SSL broken pipes kill the machine and fill
31 matches
Mail list logo
