On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan and...@dunslane.net wrote:
The docs state, w.r.t. $subject:
The password can be provided either in the primary_conninfo string
or in a separate ~/.pgpass file on the standby server.
I tried this with a database name of replication in the
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 not limited. It allows you to read all contents of the
On Wed, May 26, 2010 at 6:02 PM, Tatsuo Ishii is...@postgresql.org 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
On sön, 2010-06-06 at 21:13 -0500, Jaime Casanova wrote:
On Thu, May 13, 2010 at 11:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Thu, May 13, 2010 at 10:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, the lexer translates N'foo' to NCHAR
(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 not
Daniel Farina drfar...@acm.org 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
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 choose what
On Sunday 30 May 2010 18:29:31 Greg Stark wrote:
On Sun, May 30, 2010 at 4:54 AM, Tom Lane t...@sss.pgh.pa.us 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.
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 t...@sss.pgh.pa.us wrote:
I read through that thread and couldn't find much discussion of
alternative CRC implementations --- we spent all our time
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 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,
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 t...@sss.pgh.pa.us wrote:
I read through that thread and couldn't find much discussion of
alternative CRC
* 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 evaluated
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
On Fri, Jun 4, 2010 at 7:17 AM, Tom Lane t...@postgresql.org 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
-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 - : [ ] { } , \ '
| * . Technically, it would
Greg Sabino Mullane g...@turnstep.com 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:
:space space# aka ': ' ' #'
Always
-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. ;)
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane g...@turnstep.com 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
Robert Haas wrote:
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane g...@turnstep.com 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
Greg Sabino Mullane g...@turnstep.com 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
On 7 June 2010 15:56, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Sabino Mullane g...@turnstep.com 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
Fujii Masao masao.fu...@gmail.com writes:
On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan and...@dunslane.net 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
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
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,
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:
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
* 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 /
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
Greg Smith g...@2ndquadrant.com 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
On Mon, Jun 7, 2010 at 2:23 AM, Peter Eisentraut pete...@gmx.net 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
On mån, 2010-06-07 at 12:56 -0500, Jaime Casanova wrote:
On Mon, Jun 7, 2010 at 2:23 AM, Peter Eisentraut pete...@gmx.net 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 national character string literal.
--
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 copypaste
than the other outputs. This is still the
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.
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
Fujii Masao masao.fu...@gmail.com 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
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 t...@sss.pgh.pa.us wrote:
I read through that thread and
On Fri, May 28, 2010 at 9:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 28, 2010 at 12:07 AM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I learned that to return an enum value from C, one needs to return the
OID of the right row of the
On Mon, Jun 7, 2010 at 7:33 PM, Peter Eisentraut pete...@gmx.net 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:
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 were
Kevin Grittner kevin.gritt...@wicourts.gov 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
On Mon, Jun 7, 2010 at 5:16 PM, Joseph Adams joeyadams3.14...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
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.
I wouldn't think this would be practical unless there was a
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
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 the
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
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
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
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.
(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 acquire the
(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
Assuming
Dave Cramer p...@fastcrypt.com 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
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
KaiGai Kohei kai...@ak.jp.nec.com 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.
(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 syntax for
2010/6/8 Peter Eisentraut pete...@gmx.net:
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
On Sat, Jun 5, 2010 at 8:16 AM, Randy Solomonson ra...@solomonson.com 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
On Tue, Jun 8, 2010 at 1:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
KaiGai Kohei kai...@ak.jp.nec.com 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
(2010/06/08 9:46), Tom Lane wrote:
KaiGai Koheikai...@ak.jp.nec.com 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.
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
* 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 be
* 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 it
* 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
(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.
2010/6/7 KaiGai Kohei kai...@ak.jp.nec.com:
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
* Robert Haas (robertmh...@gmail.com) wrote:
2010/6/7 KaiGai Kohei kai...@ak.jp.nec.com:
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
(2010/06/08 11:15), Robert Haas wrote:
2010/6/7 KaiGai Koheikai...@ak.jp.nec.com:
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
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
(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 proposing a
On Tue, Jun 8, 2010 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan and...@dunslane.net wrote:
I tried this with a database name of replication in the .pgpass file,
which matches what we need to use in
Fujii Masao masao.fu...@gmail.com 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
Peter Eisentraut pete...@gmx.net 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
On Tue, Jun 8, 2010 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
Fujii Masao masao.fu...@gmail.com 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
75 matches
Mail list logo
