Re: [HACKERS] proposal sql: labeled function params
2008/8/15 Hannu Krosing [EMAIL PROTECTED]:
On Fri, 2008-08-15 at 14:54 +0200, Pavel Stehule wrote:
2008/8/15 Peter Eisentraut [EMAIL PROTECTED]:
Am Thursday, 14. August 2008 schrieb Pavel Stehule:
I propose enhance current syntax that allows to specify label for any
function parameter:
fcename(expr [as label], ...)
fcename(colname, ...)
I would to allow same behave of custom functions like xmlforest function:
postgres=# select xmlforest(a) from foo;
xmlforest
---
a10/a
(1 row)
Do you have a use case for this outside of XML?
JSON and similar (custom) protocols
why not use a format string, or any other separate (sub)language ?
select json('[name:$1, age: $2]', name, age) from students;
because you have to write labels, where labels are equal with column
names. I would to add same comfort like SQL/XML functions.
Pavel
Hannu
--
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] proposal sql: labeled function params
Hello
2008/8/15 Hannu Krosing [EMAIL PROTECTED]:
On Fri, 2008-08-15 at 10:01 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Random googling shows me that Oracle appears to use a syntax like
name = value
This is actually a feature that I would like to see implemented soonish,
so if
anyone has input on the possible syntax consequences, please comment.
We've been over this territory before. The problem with name = value
is that it requires reserving a perfectly good user-defined operator name.
We could declare, that using operator = in function argument expression
requires parenthesis : func( a = (b = c) means param a with value
expression (b = c) nad just func((b = c)) means first param with value
(b=c)
or just use := operator?
select new_person(name := 'Smith') - it's simple and consistent with pl/pgsql.
the main use of named params is calling functions with default values,
and giving some params. there I'm more concerned about default args and
rules for finding right function in presence of functions with both
multiple args and default values for some.
create function f(a int) ...
create function f(a int, b int default 7)
create function f(text text)
and then calling f(4) - which one would it call
what about f('4')
Of course, we could also have default values without named params, and
just require keyword DEFAULT where we want default value :)
value AS name, on the other hand, accomplishes the same in a more
SQL-looking fashion with no new reserved word (since AS is already
fully reserved).
would it be more natural / SQL-like to use value AS name or name AS
value ?
it's question, because SQL wit AS clause don't specify value, it
specifies label.
Regards
Pavel
-
Hannu
--
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] [INTERFACES] ecpg 'set' failure using host vars
On Fri, Aug 15, 2008 at 08:47:49PM -0700, Bosco Rama wrote: [22245]: ecpg_execute line 13256: QUERY: set search_path to $1 with 1 parameter on connection ecpgconn [22245]: ecpg_execute line 13256: using PQexecParams [22245]: free_params line 13256: parameter 1 = myschema [22245]: ecpg_check_PQresult line 13256: Error: ERROR: syntax error at or near $1 LINE 1: set search_path to $1 Without checking the sources it seems as if PQexecParams is not able to handle a parameter in a set command. Can anyone confirm this? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [Fwd: [COMMITTERS] pgsql: probes.h is generated from probes.d, not pg_trace.d.]
While noticing this one, I also noticed we don't remove probes.h when we do clean in the msvc setup. We probably should, no? //Magnus Original Message Subject: [COMMITTERS] pgsql: probes.h is generated from probes.d, not pg_trace.d. Date: Sat, 16 Aug 2008 12:42:27 + (UTC) From: [EMAIL PROTECTED] (Magnus Hagander) To: [EMAIL PROTECTED] Log Message: --- probes.h is generated from probes.d, not pg_trace.d. Modified Files: -- pgsql/src/tools/msvc: Solution.pm (r1.43 - r1.44) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/tools/msvc/Solution.pm?r1=1.43r2=1.44) -- 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] Parsing of pg_hba.conf and authentication inconsistencies
Bruce Momjian wrote:
Magnus Hagander wrote:
To address Magnus' specific question, right now we store the pg_hba.conf
tokens as strings in the postmaster. I am fine with storing them in a
more native format and throwing errors for values that don't convert.
What would concern me is calling lots of 3rd party libraries from the
postmaster to validate items.
If I was unclear about that, that part was never part of what I
proposed. I'm only talking aobut parsing the syntax. The only external
calls in the code there now is the getaddrinfo calls to convert the IPs,
IIRC.
That seems safe to me. The use of strings for the pg_hba.conf content
was only for convenience; I can see the advantage of using a more
natural format.
Attached is the patch I have so far. The only extra it adds over today
is that it allows the use of ident authentication without explicitly
specifying sameuser when you want that.
Other than that, it moves code around to do the parsing in the
postmaster and the maching in the backend. This means that now if there
is a syntax error in the file on a reload, we just keep the old file
around still letting people log into the database. If there is a syntax
error on server startup, it's FATAL of course, since we can't run
without any kind of pg_hba.
It also changes a couple of error cases to explicitly state that support
for a certain auth method isn't compiled in, rather than just call it a
syntax error.
Comments?
//Magnus
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.167
diff -c -r1.167 auth.c
*** src/backend/libpq/auth.c 1 Aug 2008 11:41:12 - 1.167
--- src/backend/libpq/auth.c 16 Aug 2008 15:44:20 -
***
*** 211,217
if (status == STATUS_EOF)
proc_exit(0);
! switch (port-auth_method)
{
case uaReject:
errstr = gettext_noop(authentication failed for user \%s\: host rejected);
--- 211,217
if (status == STATUS_EOF)
proc_exit(0);
! switch (port-hba-auth_method)
{
case uaReject:
errstr = gettext_noop(authentication failed for user \%s\: host rejected);
***
*** 279,285
errmsg(missing or erroneous pg_hba.conf file),
errhint(See server log for details.)));
! switch (port-auth_method)
{
case uaReject:
--- 279,285
errmsg(missing or erroneous pg_hba.conf file),
errhint(See server log for details.)));
! switch (port-hba-auth_method)
{
case uaReject:
***
*** 1761,1767
/*
* Determine the username of the initiator of the connection described
* by port. Then look in the usermap file under the usermap
! * port-auth_arg and see if that user is equivalent to Postgres user
* port-user.
*
* Return STATUS_OK if yes, STATUS_ERROR if no match (or couldn't get info).
--- 1761,1767
/*
* Determine the username of the initiator of the connection described
* by port. Then look in the usermap file under the usermap
! * port-hba-usermap and see if that user is equivalent to Postgres user
* port-user.
*
* Return STATUS_OK if yes, STATUS_ERROR if no match (or couldn't get info).
***
*** 1799,1805
(errmsg(Ident protocol identifies remote user as \%s\,
ident_user)));
! if (check_ident_usermap(port-auth_arg, port-user_name, ident_user))
return STATUS_OK;
else
return STATUS_ERROR;
--- 1799,1805
(errmsg(Ident protocol identifies remote user as \%s\,
ident_user)));
! if (check_ident_usermap(port-hba-usermap, port-user_name, ident_user))
return STATUS_OK;
else
return STATUS_ERROR;
Index: src/backend/libpq/crypt.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/crypt.c,v
retrieving revision 1.74
diff -c -r1.74 crypt.c
*** src/backend/libpq/crypt.c 1 Jan 2008 19:45:49 - 1.74
--- src/backend/libpq/crypt.c 16 Aug 2008 15:44:20 -
***
*** 54,60
return STATUS_ERROR;
/* We can't do crypt with MD5 passwords */
! if (isMD5(shadow_pass) port-auth_method == uaCrypt)
{
ereport(LOG,
(errmsg(cannot use authentication method \crypt\ because password is MD5-encrypted)));
--- 54,60
return STATUS_ERROR;
/* We can't do crypt with MD5 passwords */
! if (isMD5(shadow_pass) port-hba-auth_method == uaCrypt)
{
ereport(LOG,
(errmsg(cannot use authentication method \crypt\ because password is MD5-encrypted)));
***
*** 65,71
* Compare with the encrypted or plain password depending on the
* authentication method being used for this connection.
*/
! switch (port-auth_method)
{
case uaMD5:
crypt_pwd = palloc(MD5_PASSWD_LEN + 1);
--- 65,71
* Compare with the encrypted or plain password depending on the
* authentication method being used for this
Re: [HACKERS] Parsing of pg_hba.conf and authentication inconsistencies
Magnus Hagander [EMAIL PROTECTED] writes: Other than that, it moves code around to do the parsing in the postmaster and the maching in the backend. How does that work in EXEC_BACKEND environments? regards, tom lane -- 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] proposal sql: labeled function params
Pavel Stehule [EMAIL PROTECTED] writes: or just use := operator? You're still commandeering an operator name that wasn't reserved before. This one doesn't even have the feeble excuse of being Oracle-compatible. regards, tom lane -- 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] [INTERFACES] ecpg 'set' failure using host vars
Michael Meskes [EMAIL PROTECTED] writes: Without checking the sources it seems as if PQexecParams is not able to handle a parameter in a set command. Can anyone confirm this? The backend only supports parameters in plannable statements, ie SELECT/INSERT/UPDATE/DELETE. (Possibly DECLARE CURSOR, I'm too lazy to check.) regards, tom lane -- 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] Parsing of pg_hba.conf and authentication inconsistencies
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Other than that, it moves code around to do the parsing in the postmaster and the maching in the backend. How does that work in EXEC_BACKEND environments? (Not tested yet, still on my TODO, but still) It will parse the file in the postmaster *and* in the backend. Thus, the safety that it won't reload on a broken file actually won't work since backends reload the configuration everytime they start, but you will still get the error/warning on reload. //Magnus -- 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] proposal sql: labeled function params
On Saturday 16 August 2008 09:38:41 Pavel Stehule wrote: because you have to write labels, where labels are equal with column names. I would to add same comfort like SQL/XML functions. Just a thought: You might be able to design this in some way to work on top of named parameter calling. Define a function with variadic arguments and allow passing arbitrary parameter names. Before you can use that to implement xmlforest in user space you need to work out the issue of passing arbitrary argument types. But that is also something that would be interesting for other purposes. -- 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] proposal sql: labeled function params
On Sat, 2008-08-16 at 08:44 +0200, Pavel Stehule wrote: Hello value AS name, on the other hand, accomplishes the same in a more SQL-looking fashion with no new reserved word (since AS is already fully reserved). would it be more natural / SQL-like to use value AS name or name AS value ? it's question, because SQL wit AS clause don't specify value, it specifies label. A label is the same thing as variable/attribute/argument name in all programming languages I can think of. Why do you need two kinds of argument names in postgreSQL ? maybe you are after something like keyword arguments in python ? http://docs.python.org/tut/node6.html#SECTION00672 keyword arguments are a way of saying that you don't know all variable names (or labels if you prefer) at function defining time and are going to pass them in when calling. It's kind of extended variadic argument, only with names and types for each extra arg. Of course we could extend this to have shortcut of passing in original variable or field names automatically, without you having to explicitly write it down that is fun(name) instead of fun(name=name) but I'm not sure it is actually a good idea. SQL in general has not been very terse language. But I sure would like to have the flexibility of keyword arguments in PostgreSQL . Regards Pavel - Hannu -- 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] Replay attack of query cancel
Magnus == Magnus Hagander [EMAIL PROTECTED] writes: [snip] I'm looking (at Magnus' suggestion) at implementing this. There appears to be only one significant obstacle; since the query cancel message is received _after_ forking a new backend, there has to be some mechanism for recording the new value of N on success. This is obviously fairly easy in the EXEC_BACKEND case, but it seems quite intrusive a change to have the non-EXEC_BACKEND case use shared memory as well. I can think of a couple of other ways to do it (e.g. some standard Unix pipe tricks) but I'm not sure of what portability assumptions are usually made. (I'm assuming that Windows always uses EXEC_BACKEND.) Ideas? (To sum up the previous discussion, this is the proposal as I understand it so far: 1. Servers that support secure cancels will report secure_cancel_key in the startup GUC settings; the value of this key is just randomness (presumably in hex for convenience). 2. The server accepts either the old-style or the secure cancel request from the client, but doesn't allow old-style requests once a valid secure request has been seen. 3. The client doesn't send secure cancel requests unless secure_cancel_key was reported. The client may or may not choose to send secure cancels based on whether SSL is in use; we can leave this decision up to the client in general, even if we make libpq use secure cancels only in the SSL case. The upshot is that replay protection is automatically available if both the client and server support it, and the client chooses to use it. The net protocol change is one new GUC and one new message format for the cancel message.) -- Andrew. -- 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] Patch: plan invalidation vs stored procedures
Hi We need plan invalidation fix in 8.3 also at least it would make migrating from 8.2 to 8.3 much more attractive. Currenlty we are having problems related to plan invalidation couple of times per week (mainly we have to let developers change their code before we release it into live databases but it feels like sitting on ticking bomb after previous downtime). Is it possible to get it into some official 8.3.x release or should we do it in house? Who should add it into september commitfest? Asko On Fri, Aug 15, 2008 at 2:13 PM, Martin Pihlak [EMAIL PROTECTED]wrote: Tom Lane wrote: Martin Pihlak [EMAIL PROTECTED] writes: Changing statement result type is also currently prohibited in StorePreparedStatement. There maybe good reasons for this, How about the SQL spec says so? Admittedly, it's a bit of a jump from views to prepared statements, but the spec is perfectly clear that altering a table doesn't alter any views dependent on it: SQL99 11.11 add column definition saith As you said it is a bit of a jump ... For one thing view definitions are persistent whereas statements are bound to be replanned sooner or later - reconnects etc. Disallowing replanning after invalidation just postpones it and meanwhile the cached plans are left unusable (cached plan must not change result). IMHO the problem should be left for the application to handle. Because this is where it will end up anyway. Attached is a patch that implements plan invalidation on function DROP, REPLACE and ALTER. Function oids used by the query are collected in analyze phase and stored in PlannedStmt. Only plans that reference the altered function are invalidated. The patch also enables replanning on result set change. regards, Martin -- 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] Replay attack of query cancel
Andrew Gierth wrote: There appears to be only one significant obstacle; since the query cancel message is received _after_ forking a new backend, there has to be some mechanism for recording the new value of N on success. This is obviously fairly easy in the EXEC_BACKEND case, but it seems quite intrusive a change to have the non-EXEC_BACKEND case use shared memory as well. I think you should look at making the memory used for this shared in both cases, EXEC_BACKEND and not. The only downside is that shared memory usage will grow a bit on a minor release, but it'll be tiny. The portability problems caused by any other trick you use to transmit the value is probably going to be a lot harder. 2. The server accepts either the old-style or the secure cancel request from the client, but doesn't allow old-style requests once a valid secure request has been seen. Hmm, I think there should be a way to turn off acceptance of old-style without necessarily requiring a new-style request. Otherwise, how are you protected from DoS if you have never sent a cancel request at all? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] Plugin system like Firefox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Le 12 août 08 à 18:41, Bruce Momjian a écrit : Are you proposing that we should introduce our own packaging system for such add-on components? Like CP(g)AN (which has been proposed before..)? Yes, pretty much. I imagine some kind of web interface or Java app (did I just say that?) that lists all plugins and when you choose one it downloads an object file appropriate for your operating system plus SQL scripts and somehow automatically installs them in the desired database. That is the kind of capability we need to really advance things. We would still allow source installs but for people wanting to try things out, I see no other alternative, and try things out == adoption. What is wrong with my proposal here: http://archives.postgresql.org/pgsql-hackers/2008-07/msg01098.php http://archives.postgresql.org/pgsql-hackers/2008-07/msg01116.php I tried to address binary distribution, PostgreSQL stamped packages, distributions packaging compliance (deb and rpm and etc), and ease of use at user level (a package embeds .so file(s) with any SQL you need). The proposal mention SQL level interface (create/drop/install package) and command-line tools to fetch from internet, build with pgxs and install the prepared package into the given database. The binary distribution is left to people in charge in my proposal, they are debian packagers, RPM ones like Devrim, or Win32 Installer team. Please tell me how far from a workable proposal I am... Regards, - -- dim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkinRGoACgkQlBXRlnbh1bkTOgCfT7xerFH6i5Q2g35djcYoYGLI 7bMAn2/WqGyzVwf/8KAacpo9QCuYxv+G =lZqK -END PGP SIGNATURE- -- 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] [PgFoundry] Unsigned Data Types
On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote: Here is the first pass at the unsigned data type I have been working on. I am planning on adding these to the September 2008 commitfest wiki page. The unsigned data type is not targeted for core, but for the uint PgFoundry project. Is the intention for the types to go into pg_catalog? It'd be nice if you could specify what schema they should be installed in. An uninstall would also be good. Thanks for doing this, I've wished we had uint types in the past, and I'm sure I will again in the future! -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] proposal sql: labeled function params
On Aug 15, 2008, at 1:20 PM, Hannu Krosing wrote: value AS name, on the other hand, accomplishes the same in a more SQL-looking fashion with no new reserved word (since AS is already fully reserved). would it be more natural / SQL-like to use value AS name or name AS value ? IMHO, *natural* would be name *something* value, because that's how every other language I've seen does it. SQL-like would be value AS name, but I'm not a fan of putting the value before the name. And I think value AS name will just lead to a ton of confusion. Since I think it'd be very unusual to do a = (b = c), I'd vote that we just go with =. Anyone trying to do a = b = c should immediately question if that would work. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
[HACKERS] Limitations on trigger functions
I came across this bug tonight: -- Function: pre_delete_main() CREATE FUNCTION pre_delete_main() RETURNS TRIGGER AS $BODY$BEGIN DROP TABLE bug_referring_table; RETURN OLD; END;$BODY$ LANGUAGE 'plpgsql' VOLATILE COST 100; -- Table: bug_referenced_table CREATE TABLE bug_referenced_table ( id integer NOT NULL, CONSTRAINT bug_referenced_table_pkey PRIMARY KEY (id) ) WITH (OIDS=FALSE); -- Trigger: on_pre_delete_main on bug_referenced_table CREATE TRIGGER on_pre_delete_main BEFORE DELETE ON bug_referenced_table FOR EACH ROW EXECUTE PROCEDURE pre_delete_main(); INSERT INTO bug_referenced_table VALUES (1); -- Table: bug_referring_table CREATE TABLE bug_referring_table ( main_id integer NOT NULL, CONSTRAINT bug_referring_table_main_id_fkey FOREIGN KEY (main_id) REFERENCES bug_referenced_table (id) MATCH SIMPLE ON UPDATE RESTRICT ON DELETE RESTRICT ) WITH (OIDS=FALSE); -- ERROR: cache lookup failed for constraint 19411 DELETE FROM bug_referenced_table WHERE id = 1; It seems the trigger list is calculated once, and does not reflect changes made by triggers in that list. Are there good reasons for doing that? Should that behavior be changed? The reason I wanted to do this was partitioning. By dropping the partitions in a trigger, I can make deleting look the same to the programmer with or without partitions. Because of this bug, the programmer will first need to determine if the delete will cascade normally (it does depending on which partition the record falls into) or if he needs to drop partition tables first. -Dan -- 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] Limitations on trigger functions
Dan Eloff [EMAIL PROTECTED] writes: It seems the trigger list is calculated once, and does not reflect changes made by triggers in that list. Are there good reasons for doing that? Should that behavior be changed? Yes. No. Don't hold your breath on this being considered a bug. regards, tom lane -- 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] Patch: plan invalidation vs stored procedures
Asko Oja [EMAIL PROTECTED] writes: Is it possible to get it into some official 8.3.x release This is not the kind of patch we put into stable branches. regards, tom lane -- 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] Replay attack of query cancel
Alvaro Herrera [EMAIL PROTECTED] writes: Andrew Gierth wrote: 2. The server accepts either the old-style or the secure cancel request from the client, but doesn't allow old-style requests once a valid secure request has been seen. Hmm, I think there should be a way to turn off acceptance of old-style without necessarily requiring a new-style request. Otherwise, how are you protected from DoS if you have never sent a cancel request at all? Assuming you were using SSL, it's hard to see how an attacker is going to get your cancel key without having seen a cancel request. However, I dislike Andrew's proposal above even without that issue, because it means *still more* changeable state that has to be magically shared between postmaster and backends. If we want to have a way for people to disable insecure cancels, we should just have a postmaster configuration parameter that does it. Also, this whole proposal has gotten far past what I'd consider a sanely back-patchable thing. Don't bother thinking about whether it will go into pre-8.4 code. regards, tom lane -- 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] Replay attack of query cancel
Tom == Tom Lane [EMAIL PROTECTED] writes: Andrew Gierth wrote: 2. The server accepts either the old-style or the secure cancel request from the client, but doesn't allow old-style requests once a valid secure request has been seen. Hmm, I think there should be a way to turn off acceptance of old-style without necessarily requiring a new-style request. Otherwise, how are you protected from DoS if you have never sent a cancel request at all? Tom Assuming you were using SSL, it's hard to see how an attacker is Tom going to get your cancel key without having seen a cancel Tom request. Tom However, I dislike Andrew's proposal above even without that Tom issue, because it means *still more* changeable state that has Tom to be magically shared between postmaster and backends. You get it for free; initialize N on the server side to 0, and accept old-style cancels only if it is still 0. (Require the first secure cancel to have N 0) -- Andrew. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
