2010/6/7 Greg Stark :
> On Mon, Jun 7, 2010 at 7:33 PM, Peter Eisentraut wrote:
>> I have developed a patch that partially implements the "functional
>> dependency" feature
>
> Nice! :)
>
I like this idea too. It can simplify some queries and I believe - it
is very good marketing bonus for us.
P
I found contrib/dblink leaks a connection or a small amout of memory
when dblink_connect() ends with a duplicate connection name error.
We should disconnect the connection before raise any ERRORs.
Patch attached.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
dblink-connection-le
Folks;
It is an announcement that pg_lesslog 1.4.2 beta is now available for
PostgreSQL 9.0 beta2. You can download the latest file from
http://pgfoundry.org/projects/pglesslog/
This is only for PosrgreSLQ 9.0 beta 2. Please do not use this
against older version of PostgreSQL. For 8.3 and 8.
itag...@postgresql.org (Takahiro Itagaki) wrote:
> Fix dblink to treat connection names longer than NAMEDATALEN-2 (62 bytes).
> Now long names are adjusted with truncate_identifier() and NOTICE messages
> are raised if names are actually truncated.
>
> Modified Files:
> --
> pgsq
Hi,
I've ported pg_lesslog to PostgreSQL 9.0 and I'm testing it.
I'm not successful to produce the following WAL records.
XLOG_HEAP_INIT_PAGE
XLOG_BTREE_REUSE_PAGE
XLOG_GIST_PAGE_DELETE
XLOG_RELMAP_UPDATE
Any suggestions are welcome.
Thank you very much;
--
Koichi Suzuki
--
Sent via
Fujii Masao writes:
> Hmm.. is it worth going back to my proposal?
I don't recall exactly what proposal you might be referring to, but
I'm hesitant to put any large amount of work into hacking .pgpass
processing for this. The whole business of replication authorization
is likely to get revisited
On Tue, Jun 8, 2010 at 12:01 PM, Tom Lane wrote:
> Fujii Masao writes:
>> But I think that we don't need to specify other than the wildcard
>> in the database field of .pgpass to use the replication-specific
>> password if the replication-specific user is supplied in .pgpass.
>> So the current co
Peter Eisentraut writes:
> I have developed a patch that partially implements the "functional
> dependency" feature that allows some columns to be omitted from the
> GROUP BY clause if it can be shown that the columns are functionally
> dependent on the columns in the group by clause and therefore
Fujii Masao writes:
> But I think that we don't need to specify other than the wildcard
> in the database field of .pgpass to use the replication-specific
> password if the replication-specific user is supplied in .pgpass.
> So the current code is enough for me. Am I missing something?
You're loo
On Tue, Jun 8, 2010 at 12:42 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan wrote:
>>> I tried this with a database name of "replication" in the .pgpass file,
>>> which matches what we need to use in pg_hba.conf, but it failed miserably,
>>> and only
(2010/06/08 11:28), Stephen Frost wrote:
> For the sake of clarity..
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> OK, it was too implementation-specific.
>
> No, that wasn't the problem. There isn't an actual implementation yet
> for it to be too-specific on. The problem is that proposin
For the sake of clarity..
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> OK, it was too implementation-specific.
No, that wasn't the problem. There isn't an actual implementation yet
for it to be too-specific on. The problem is that proposing a change to
the catalog without figuring out what it
(2010/06/08 11:15), Robert Haas wrote:
> 2010/6/7 KaiGai Kohei:
>> Our headache is on functions categorized to middle-threat. It enables to
>> leak the given arguments using error messages. Here are several ideas,
>> but they have good and bad points.
>
> I think we are altogether off in the weeds
* Robert Haas (robertmh...@gmail.com) wrote:
> 2010/6/7 KaiGai Kohei :
> > Our headache is on functions categorized to middle-threat. It enables to
> > leak the given arguments using error messages. Here are several ideas,
> > but they have good and bad points.
>
> I think we are altogether off in
2010/6/7 KaiGai Kohei :
> Our headache is on functions categorized to middle-threat. It enables to
> leak the given arguments using error messages. Here are several ideas,
> but they have good and bad points.
I think we are altogether off in the weeds here. We ought to start
with an implementatio
(2010/06/08 10:17), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> Perhaps, pg_proc takes a new flag to represent it.
>
> Without an actual well-formed approach for dealing with this which
> requires it, it's far too soon to be asking for changes in the catalog
* Peter Eisentraut (pete...@gmx.net) wrote:
> This is frequently requested by MySQL converts (and possibly others).
I'd certainly love to see it- but let's not confuse people by implying
that it would actually act the way MySQL does. It wouldn't, because
what MySQL does is alot closer to 'distinc
* Hitoshi Harada (umi.tan...@gmail.com) wrote:
> I don't see why it should be allowed. I see the insist that y must be
> unique value so it is ok to be ungrouped but the point of discussion
> is far from that; Semantically y is not grouping key.
Ignoring the fact that it's terribly useful- isn't i
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> If we were actually going in this direction we'd
> want to write a much better WAL-text-dump tool than we have, and then
> in principle somebody could sanitize the text output before shipping
> it off. But going through a large volume of data that way could
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Perhaps, pg_proc takes a new flag to represent it.
Without an actual well-formed approach for dealing with this which
requires it, it's far too soon to be asking for changes in the catalog.
Please stop suggesting individual maybe-this-would-h
(2010/06/08 9:46), Tom Lane wrote:
> KaiGai Kohei writes:
>> In this case, is it unnecessary to expose the given argument in
>> the error message (from security perspective), isn't it?
>
> Yes, if all you care about is security and not usability, that looks
> like a great solution. We're *not* d
On Tue, Jun 8, 2010 at 1:46 AM, Tom Lane wrote:
> KaiGai Kohei writes:
>> In this case, is it unnecessary to expose the given argument in
>> the error message (from security perspective), isn't it?
>
> Yes, if all you care about is security and not usability, that looks
> like a great solution.
On Sat, Jun 5, 2010 at 8:16 AM, Randy Solomonson wrote:
> I have a system that uses C methods as functions in a Postgres
> database. When I try to run gdb with my user account I get this:
> ptrace: Operation not permitted
>
> It looks like a permission thing. It seemed to work when I ran gdb as
>
2010/6/8 Peter Eisentraut :
> I have developed a patch that partially implements the "functional
> dependency" feature that allows some columns to be omitted from the
> GROUP BY clause if it can be shown that the columns are functionally
> dependent on the columns in the group by clause and therefo
(2010/06/08 9:23), KaiGai Kohei wrote:
> (2010/06/07 21:56), Stephen Frost wrote:
>> * Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
>>> WHERE should do it:
>>>
>>> SELECT * FROM secrets_view WHERE username = 'neighbor' AND
>>> password::integer = 1234;
>>> ERROR: invalid input s
KaiGai Kohei writes:
> In this case, is it unnecessary to expose the given argument in
> the error message (from security perspective), isn't it?
Yes, if all you care about is security and not usability, that looks
like a great solution. We're *not* doing it.
regards, to
Joseph Adams wrote:
By the way, just curious: why can't the internal representation of an
enum just be an INT starting from 0 by default, like in C? That would
make a heck of a lot more sense, in my opinion. It might also allow
users to do things like this in the future:
Please review
Dave Cramer wrote:
> I noted on line 169 that max_avail is still an int ? Where else would
> it be having problems ?
It should not a problem because the local variable only stores byte
size in a page. It will be at most only BLCKSZ (=8192).
I wonder why you had "ERROR: value ... is out of rang
(2010/06/07 21:56), Stephen Frost wrote:
> * Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
>> WHERE should do it:
>>
>> SELECT * FROM secrets_view WHERE username = 'neighbor' AND
>> password::integer = 1234;
>> ERROR: invalid input syntax for integer: "neighborssecretpassword"
>>
(2010/06/07 20:53), Heikki Linnakangas wrote:
> On 07/06/10 14:06, Stephen Frost wrote:
>> * Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
>>> The big difference is what information can be obtained, not how fast it
>>> can be obtained.
>>
>> Actually, I disagree. Time required to
Tom Lane wrote:
If we were actually going in this direction we'd
want to write a much better WAL-text-dump tool than we have, and then
in principle somebody could sanitize the text output before shipping
it off. But going through a large volume of data that way could be
pretty impractical. Also
Hello hackers,
I would like to share some my thoughts about usage of multidimensional
indexes for queries which deal with ordinal unidimensional data types. I
think that gist indexes (especially with knngist) can produce great benefit
for complex multi-criterion queries.
Let's consider come exampl
Hi hackers,
I found that some parameters of GiST implementation are builin in the code.
For example, following can be found in the backend/utils/adt/tsgistidx.c:
#define SIGLENINT 31/* >121 => key will toast, so it will not
work
* !!! */
#define SIGL
Hello Hackers!
I have extended my patch by introducing levenshtein_less_equal function.
This function have additional argument max_d and stops calculating when
distance exceeds max_d. With low values of max_d function works much faster
than original one.
The example of original levenshtein functi
I have a system that uses C methods as functions in a Postgres
database. When I try to run gdb with my user account I get this:
ptrace: Operation not permitted
It looks like a permission thing. It seemed to work when I ran gdb as
the "postgres" user. I would like to continue running postgres as th
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Hm, that is an excellent point. The WAL trace would actually be a
>> lot superior in terms of being able to figure out what went wrong.
>> But I don't quite see how we tell people "either keep xmin or keep
>> your old WAL". Also, for production site
Tom Lane wrote:
> "Kevin Grittner" writes:
>> The best thought I've had so far is that if someone kept WAL
>> files long enough the evidence might be in there somewhere
>
> Hm, that is an excellent point. The WAL trace would actually be a
> lot superior in terms of being able to figure ou
Tom Lane wrote:
> If we were actually going in this direction we'd want to write a
> much better WAL-text-dump tool than we have, and then in principle
> somebody could sanitize the text output before shipping it off.
I wouldn't think this would be practical unless there was a way to
scan the
On Mon, Jun 7, 2010 at 5:16 PM, Joseph Adams wrote:
> I don't know if the JSON datatype will be a contrib module or built-in
> yet, but if it were contrib, would it still be better to use fixed
> OIDs anyway?
Part of the point is that EXPLAIN (FORMAT JSON) should return json, so
this needs to be
"Kevin Grittner" writes:
> ... my perspective is that it would be A Good Thing if it could
> just be turned on when needed. If you have recurring bug that can
> be arranged, but in those cases you have other options; so I'm
> assuming you want this kept because it is primarily of forensic
> value
Excerpts from Joseph Adams's message of lun jun 07 17:16:12 -0400 2010:
> > However, for a built-in enum type, I agree with Robert's solution of
> > just #define-ing fixed OIDs for the values of the type.
>
> I don't know if the JSON datatype will be a contrib module or built-in
> yet, but if it
On Mon, Jun 7, 2010 at 7:33 PM, Peter Eisentraut wrote:
> I have developed a patch that partially implements the "functional
> dependency" feature
Nice! :)
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
On Fri, May 28, 2010 at 9:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, May 28, 2010 at 12:07 AM, Joseph Adams
>> wrote:
>>> I learned that to return an enum value from C, one needs to return the
>>> OID of the right row of the pg_enum table. I eventually managed to
>>> write the code
Florian Pflug wrote:
On Jun 7, 2010, at 12:45 , Andres Freund wrote:
On Monday 07 June 2010 12:37:13 Pierre C wrote:
On Sunday 30 May 2010 18:29:31 Greg Stark wrote:
On Sun, May 30, 2010 at 4:54 AM, Tom Lane wrote:
I read through that thread and couldn't find much
Fujii Masao writes:
> This commit changed walsender so that it doesn't call set_ps_display() if
> update_process_title = off.
Yeah. The idea is to not waste time on a useless snprintf() call when the
GUC is turned off.
> On the other hand, walreceiver doesn't check
> update_process_title. Thoug
Tom Lane wrote:
This doesn't look amazingly unlike the current JSON output,
and to the extent that we have to add more quoting to it, it's
going to look even more like the JSON output.
I don't know about that; here's the JSON one:
EXPLAIN (FORMAT JSON) SELECT * FROM customers WHERE customer
I have developed a patch that partially implements the "functional
dependency" feature that allows some columns to be omitted from the
GROUP BY clause if it can be shown that the columns are functionally
dependent on the columns in the group by clause and therefore guaranteed
to be unique per group
> It's because of the potential for bugs in this area, that I'd propose
> just quoting everything (except numeric values) as in my original
> patch.
I don't see a problem with this.
I supported YAML output because I find it easier to read and copy&paste
than the other outputs. This is still the
On mån, 2010-06-07 at 12:56 -0500, Jaime Casanova wrote:
> On Mon, Jun 7, 2010 at 2:23 AM, Peter Eisentraut wrote:
> >
> > The N'' syntax is in the SQL standard,
> >
>
> I didn't know that, do you know what paragraph is it? i can't find it
Look for .
--
Sent via pgsql-hackers mailing list (pg
On Mon, Jun 7, 2010 at 2:23 AM, Peter Eisentraut wrote:
>
> The N'' syntax is in the SQL standard,
>
I didn't know that, do you know what paragraph is it? i can't find it
--
Jaime Casanova www.2ndQuadrant.com
Soporte y capacitación de PostgreSQL
--
Sent via pgsql-hackers mailing list
Greg Smith writes:
> The complaints about YAML taking up too much vertical space are
> understandable, but completely opposite of what I care about. I can
> e-mail a customer a YAML plan and it will survive to the other side and
> even in a reply back to me. Whereas any non-trivial text forma
Florian Weimer wrote:
It has been claimed before that YAML is a superset of JSON, so why
can't the YAML folks use the existing JSON output instead?
Because JSON just crosses the line where it feels like there's so much
markup that people expect a tool is necessary to read it, which has
alw
* Mike Toews (mwto...@gmail.com) wrote:
> I know I can either embed a non-SQL command in the SQL file or add
> --set ON_ERROR_STOP =1 to the command arguments, however I'd like a
> simpler command interface (just like there is -q / --quiet for QUIET).
> Could I suggest a new command-line option -r
* Tom Lane:
> Egad ... this is supposed to be an easily machine-generatable format?
Perhaps you could surround all strings with "" in the generator, and
escape all potentially special characters (which seems to include some
whitespace even in quoted strings, unfortunately)?
It has been claimed b
Hey hackers,
I routinely run SQL scripts using pgsql -f myscript.sql. If there is
an error mid-way in a large script file, due to the default
ON_ERROR_STOP=0, I see repeated "ERROR: current transaction is
aborted, commands ignored until end of transaction block" until the
end of the script. Often
Tom Lane wrote:
Why don't we improve the code, instead? In particular make
libpqrcv_connect() do
- snprintf(conninfo_repl, sizeof(conninfo_repl), "%s replication=true",
conninfo);
+ snprintf(conninfo_repl, sizeof(conninfo_repl), "%s database=replication
replication=true", connin
I noted on line 169 that max_avail is still an int ? Where else would
it be having problems ?
Dave
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Fujii Masao writes:
> On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan wrote:
>> I tried this with a database name of "replication" in the .pgpass file,
>> which matches what we need to use in pg_hba.conf, but it failed miserably,
>> and only worked when I used a wildcard for the database name in t
On 7 June 2010 15:56, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>> I don't think the above would be particularly hard to implement myself,
>> but if it becomes a really big deal, we can certainly punt by simply
>> quoting anything containing an indicator (the special characters above).
>
>
"Greg Sabino Mullane" writes:
> I don't think the above would be particularly hard to implement myself,
> but if it becomes a really big deal, we can certainly punt by simply
> quoting anything containing an indicator (the special characters above).
I would go with that. The quoting rules you
Robert Haas wrote:
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane wrote:
Tom Lane wrote:
I don't think the above would be particularly hard to implement myself,
but if it becomes a really big deal, we can certainly punt by simply
quoting anything containing an indicator (the special
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane wrote:
> Tom Lane wrote:
> I don't think the above would be particularly hard to implement myself,
> but if it becomes a really big deal, we can certainly punt by simply
> quoting anything containing an indicator (the special characters above).
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom Lane wrote:
...
> Egad ... this is supposed to be an easily machine-generatable format?
>
> If it's really as broken as the above suggests, I think we should
> rip it out while we still can.
Heh ... not like you to shrink from a challenge.
"Greg Sabino Mullane" writes:
> The rules should be:
> Requires quoting only if the first character:
> & * ! | > ' " % @ ` #
> Same as above, but no quoting if the second character is "safe":
> - ? :
> Always requires quoting:
> ":" "#" aka ': ' ' #'
> Always requires quoting
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Dean Rasheed wrote:
...
> So the current code in escape_yaml() is inadequate for producing valid
> YAML. I think it would have to also consider at least the following
> characters as special "-" ":" "[" "]" "{" "}" "," "\"" "'"
> "|" "*"
On Fri, Jun 4, 2010 at 7:17 AM, Tom Lane wrote:
> Log Message:
> ---
> Add current WAL end (as seen by walsender, ie, GetWriteRecPtr() result)
> and current server clock time to SR data messages. These are not currently
> used on the slave side but seem likely to be useful in future, and
Hi,
When an error is found in the WAL streamed from the master, a warning
message is repeated without interval forever in the standby. This
consumes CPU load very much, and would interfere with read-only queries.
To fix this problem, we should add a sleep into emode_for_corrupt_record()
or somewhe
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> WHERE should do it:
>
> SELECT * FROM secrets_view WHERE username = 'neighbor' AND
> password::integer = 1234;
> ERROR: invalid input syntax for integer: "neighborssecretpassword"
>
> Assuming that username = 'neighbor' is evalu
On Jun 7, 2010, at 12:45 , Andres Freund wrote:
> On Monday 07 June 2010 12:37:13 Pierre C wrote:
>>> On Sunday 30 May 2010 18:29:31 Greg Stark wrote:
On Sun, May 30, 2010 at 4:54 AM, Tom Lane wrote:
> I read through that thread and couldn't find much discussion of
> alternative CRC i
On 07/06/10 14:06, Stephen Frost wrote:
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
The big difference is what information can be obtained, not how fast it
can be obtained.
Actually, I disagree. Time required to acquire the data does matter.
Depends on the magnitude, o
Heikki,
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> The big difference is what information can be obtained, not how fast it
> can be obtained.
Actually, I disagree. Time required to acquire the data does matter.
> Imagine a table that holds username/passwords for users.
On Monday 07 June 2010 12:37:13 Pierre C wrote:
> > On Sunday 30 May 2010 18:29:31 Greg Stark wrote:
> >> On Sun, May 30, 2010 at 4:54 AM, Tom Lane wrote:
> >> > I read through that thread and couldn't find much discussion of
> >> > alternative CRC implementations --- we spent all our time on argu
On Sunday 30 May 2010 18:29:31 Greg Stark wrote:
On Sun, May 30, 2010 at 4:54 AM, Tom Lane wrote:
> I read through that thread and couldn't find much discussion of
> alternative CRC implementations --- we spent all our time on arguing
> about whether we needed 64-bit CRC or not.
SSE4.2 has a h
On 07/06/10 10:30, KaiGai Kohei wrote:
> (2010/06/07 15:48), Heikki Linnakangas wrote:
>> There's many side channels like exposing row counts in EXPLAIN and
>> statistics and timing attacks, that are not as critical, because they
>> don't let expose all data, and the attacker can't accurately choos
Daniel Farina writes:
> Some of this code was linked with the server, and so reading the node
> using Postgres' parser was easy. Otherwise, a small parser needed be
> written for external projects. Perhaps a slightly more ideal state of
> affairs would be:
>
> * These hooks to acquire the syntacti
(2010/06/07 15:48), Heikki Linnakangas wrote:
> On 07/06/10 06:06, Stephen Frost wrote:
>> Also, perhaps I'm not being paranoid enough, but all this concern over
>> error cases really doesn't really worry me that much. The amount of
>> data one could acquire that way is pretty limited.
>
> It's no
On sön, 2010-06-06 at 21:13 -0500, Jaime Casanova wrote:
> On Thu, May 13, 2010 at 11:00 PM, Tom Lane wrote:
> > Jaime Casanova writes:
> >> On Thu, May 13, 2010 at 10:52 PM, Tom Lane wrote:
> >>> Actually, the lexer translates N'foo' to NCHAR 'foo' and then the
> >>> grammar treats that just li
On Wed, May 26, 2010 at 6:02 PM, Tatsuo Ishii wrote:
> I'm thinking about exporting the raw parser and related modules as a C
> library. Though this will not be an immediate benefit of PostgreSQL
> itself, it will be a huge benefit for any PostgreSQL
> applications/middle ware those need to parse
78 matches
Mail list logo
