date:20130513

Re: [HACKERS] Proposal to add --single-row to psql

2013-05-13 Thread Peter Geoghegan

On Sun, May 12, 2013 at 1:18 PM, Jim Nasby j...@nasby.net wrote:
 FWIW, I've wanted the ability to plug into the parser not for an extension,
 but so that I could programmaticly enforce certain coding conventions.

Depending on the exact requirements, that probably wouldn't be too
difficult. It'd likely entail adding a hook for plugins to inspect raw
parse trees.

The pg_stat_statements core infrastructure changes for 9.2 added a
hook that allowed pg_stat_statements to inspect the post-parse
analysis (query) tree. That wouldn't be suitable for what you want,
though, because that tree loses many of the details that you are
likely to care about but are inconsequential to the semantics of the
query. For example, you couldn't tell from the post-parse analysis
tree if the query text was originally select all, the, columns from
table or select * from table.


-- 
Peter Geoghegan


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logging of PAM Authentication Failure

2013-05-13 Thread Kyotaro HORIGUCHI

Hello,

  auth_failed() in src/backend/libpq/auth.c intentionally logs nothing for
  STATUS_EOF status (ie, client closed the connection without responding).
  But it looks like the PAM code path doesn't have a way to return that
  status code, even when pam_passwd_conv_proc() knows that that's what
  happened, and intentionally printed no log message itself (around line
  1870 in HEAD).  If there's another response code we could return through
  the PAM layer, this could be fixed, and I think it should be.
 
 So if I get this correctly, does this mean the only thing that needs
 to be fixed is unnecessary logging or is there a problem with
 authentication exchange itself in case of PAM? Also, when you say PAM
 layer, is that pam_passwd_conv_proc() that needs to be able to return
 an alternative status code?

Following is the point server requests psql to send password when
PAM is enabled.

backend/libpq/auth.c:1861
   if (strlen(passwd) == 0)
   {
 /*
  * Password wasn't passed to PAM the first time around -
  * let's go ask the client to send a password, which we
  * then stuff into PAM.
  */
 sendAuthRequest(pam_port_cludge, AUTH_REQ_PASSWORD);
 passwd = recv_password_packet(pam_port_cludge);
 if (passwd == NULL)
 {
   /*
* Client didn't want to send password.  We
* intentionally do not log anything about this.
*/
   goto fail;
...
return PAM_CONV_ERR;


This code seems to me expecting for psql to send password without
closing current connnection.On the other hand psql does as
follows.

bin/psql/startup.c: 227
pset.db = PQconnectdbParams(keywords, values, true);
free(keywords);
free(values);

if (PQstatus(pset.db) == CONNECTION_BAD 
  PQconnectionNeedsPassword(pset.db) 
  password == NULL 
  pset.getPassword != TRI_NO)
{
  PQfinish(pset.db);
  password = simple_prompt(password_prompt, 100, false);
  new_pass = true;
}

psql at once disconnects the current connection and reconnects
with this new password, so pam_conv_err is observed in server.

It seems to be a kind of protocol-mimatching. Client should'nt
disconnect for password request or server should fit to what psql
does. Is this wrong?

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Fast promotion failure

2013-05-13 Thread Heikki Linnakangas

On 13.05.2013 06:07, Amit Kapila wrote:

On Monday, May 13, 2013 5:54 AM Kyotaro HORIGUCHI wrote:

Heikki said in the fist message in this thread that he suspected
the cause of the failure he had seen to be wrong TLI on whitch
checkpointer runs. Nevertheless, the patch you suggested for me
looks fixing it. Moreover (one of?) the failure from the same
cause looks fixed with the patch.

There were 2 problems:
1. There was some issue in walsender logic due to which after promotion in
some cases it hits assertion or error
2. During fast promotion, checkpoint gets created with wrong TLI

He has provided 2 different patches
fix-standby-promotion-assert-fail-2.patch and
fast-promotion-quick-fix.patch.
Among 2, he has already committed fix-standby-promotion-assert-fail-2.patch
(http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2ffa66f49
75c99e52984f7ee81b47d137b5b4751)

That's correct.

Is the point of this discussion that the patch may leave out some
glich about timing of timeline-related changing and Heikki saw an
egress of that?

AFAIU, the committed patch has some gap in overall scenario which is the
fast promotion issue.

Right, the fast promotion issue is still there.

Just to get us all on the same page again: Does anyone see a problem
with a fresh git checkout, with the fast-promotion-quick-fix.patch
applied?
(http://www.postgresql.org/message-id/51894942.4080...@vmware.com). If
you do, please speak up. As far as I know, the already-committed patch,
together with fast-promotion-quick-fix.patch, should fix all known
issues (*).

I haven't committed a fix for the issue I reported in this thread,
because I'm not 100% on what the right fix for it would be.
fast-promotion-quick-fix.patch seems to do the trick, but at least the
comments need to be updated, and I'm not sure if there some related
corner cases that it doesn't handle. Simon?

(*) Well, almost. This one is still pending:
http://www.postgresql.org/message-id/cab7npqrhucuud012gcb_taafrixx2wion_zfxqcvlurab8d...@mail.gmail.com

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

83 matches

Mail list logo