On Saturday, October 20, 2012 11:07 PM Jeff Janes wrote:
On Fri, Oct 19, 2012 at 11:00 PM, Amit kapila amit.kap...@huawei.com
wrote:
Robert wrote an accounting patch a while ago that tallied how often a
buffer was cleaned but then reclaimed for the same page before being
evicted. But
Hi,
Now that the (at least as far as I know) last ordering problem in
pg_dump has been solved [1], I'm going to attempt resurrecting this old
thread.
It seemed to me that the biggest objections to this patch in the old
discussions were directed at the implementation, which I have tried to
Robert Haas robertmh...@gmail.com writes:
The problems with MERGE are mostly around concurrency, as far as I can
tell. I can't see why RULEs would have anything to do with it -
except that I don't see how MERGE can sanely support rules, and even
if we find a way to make it do that, anyone
Hello
I should to search distinct values based on similarity
postgres=# explain select nazobce, nazobce - 'Benešov' from obce
order by nazobce - 'Benešov' limit 10
;
QUERY PLAN
On Thu, Oct 18, 2012 at 2:19 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Kohei KaiGai escribió:
The revised patch fixes the problem that Daen pointed out.
Robert, would you be able to give this latest version of the patch a
look?
Yeah, sorry I've been completely sidelined this
On Mon, Oct 22, 2012 at 8:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The problems with MERGE are mostly around concurrency, as far as I can
tell. I can't see why RULEs would have anything to do with it -
except that I don't see how MERGE can sanely
Simon Riggs wrote:
Greg Stark st...@mit.edu wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Isn't there an even more serious problem, namely that this
assumes *all* transactions are serializable?
Do you mean in terms of the serializable transaction isolation level,
or something else?
I haven't
Magnus, all,
* Magnus Hagander (mag...@hagander.net) wrote:
On Thu, Oct 18, 2012 at 5:59 PM, Robert Haas robertmh...@gmail.com wrote:
That seems like a sufficiently long deprecation window, but is gssapi
a full substitute for krb5? I don't really have a strong opinion on
this, not being a
On 10/22/2012 10:18 AM, Robert Haas wrote:
On Sun, Oct 21, 2012 at 11:02 AM, Martijn van Oosterhout
klep...@svana.org wrote:
It bugs me every time you have to jump through hoops and get red
warnings for an unknown CA, whereas no encryption whatsoever is treated
as fine while being actually
On 10/12/12 3:44 PM, Stephen Frost wrote:
wrt future-proofing, I don't like the #-of-iterations approach. There
are a number of examples of how to deal with multiple encryption types
being supported by a protocol, I'd expect hash'ing could be done in the
same way. For example, Negotiate,
On Sun, Oct 21, 2012 at 6:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Phil Sorber p...@omniti.com writes:
Here is the new patch. I renamed the utility from pg_ping to pingdb to
go along with the naming convention of src/bin/scripts.
Uh, no, that's not a step forward. Leaving out a pg prefix
2012/10/22 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
but using DISTINCT breaks KNN searching optimization
postgres=# explain select distinct nazobce, nazobce - 'Benešov' from
obce order by nazobce - 'Benešov' limit 10
Don't hold your breath. There are two
2012/10/22 Tom Lane t...@sss.pgh.pa.us:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the table-constraint case
On 10/22/2012 12:08 PM, Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the table-constraint case
On Monday, October 22, 2012 06:08:32 PM Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the
Robert Haas robertmh...@gmail.com writes:
The documentation lists several documented limitations that I would
like to analyze a little bit. First, it says that row-level security
policies are not applied on UPDATE or DELETE. That sounds downright
dangerous to me. Is there some really
On 10/22/2012 12:13 PM, Andres Freund wrote:
On Monday, October 22, 2012 06:08:32 PM Tom Lane wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we
Hi all,
I would appreciate some help or comments on this topic...
Is this the wrong mailing list to ask such question?
Seb
On 10/18/2012 10:15 AM, Sebastien FLAESCH wrote:
Hello,
Using PostgreSQL 9.2.1 on Windows, I am facing a strange character set
issue
with a UTF-8 database.
Maybe this is
On 10/22/2012 12:53 PM, Sebastien FLAESCH wrote:
[Issues with unquoted utf8 identifiers in Windows 1252 locale]
I suspect this has something to do with the fact that non-quoted
identifiers
are converted to lowercase, and because my LC_CTYPE is English_United
States.1252,
the conversion to
On Mon, Oct 22, 2012 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
but using DISTINCT breaks KNN searching optimization
postgres=# explain select distinct nazobce, nazobce - 'Benešov' from
obce order by nazobce - 'Benešov' limit 10
Don't hold
On Mon, Oct 22, 2012 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The documentation lists several documented limitations that I would
like to analyze a little bit. First, it says that row-level security
policies are not applied on UPDATE or DELETE.
On Mon, Oct 22, 2012 at 10:57 AM, Andrew Dunstan and...@dunslane.net wrote:
On 10/22/2012 10:18 AM, Robert Haas wrote:
On Sun, Oct 21, 2012 at 11:02 AM, Martijn van Oosterhout
klep...@svana.org wrote:
It bugs me every time you have to jump through hoops and get red
warnings for an unknown
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If
On Mon, Oct 22, 2012 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I tested, and indeed this seems to work:
CREATE TABLE t1 (c int[] WHERE EACH ELEMENT REFERENCES t2);
and it's perfectly sensible from an English-grammar standpoint too.
If we take that, how would we spell the
[I'm replying to Robert's message only because it is the latest on
the thread; I'm actually kinda replying to the whole thread in
general.]
When catching up on a backlog, one would hope that any thread
comprising more than 5% of said backlog would be more constructive.
:-(
As someone coming in
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 22, 2012 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Don't hold your breath. There are two ways the system could implement
the DISTINCT clause: either sort and uniq, or hashaggregate.
hashaggregate will destroy any input ordering, so
On Thu, Oct 18, 2012 at 7:42 PM, Claudio Freire klaussfre...@gmail.com wrote:
Fun. That didn't take long.
With the attached anti-sequential scan patch, and effective_io_concurrency=8:
QUERY PLAN
On Fri, Oct 12, 2012 at 10:47 PM, Stephen Frost sfr...@snowman.net wrote:
* Marko Kreen (mark...@gmail.com) wrote:
As it works only on connect
time, it can actually be secure, unlike user switching
with SET ROLE.
I'm guessing your issue with SET ROLE is that a RESET ROLE can be issued
On 10/19/12 1:26 PM, Josh Berkus wrote:
What I'm saying is, we'll get nowhere promoting an application queue
which is permanently inferior to existing, popular open source software.
My advice: Forget about the application queue aspects of this. Focus
on making it work for replication and
On Mon, Oct 22, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not thrilled with the inconsistency either, but given the
constraints we're under, it seems like the best we can do. (I feel,
as Andrew does, that shoving WHERE into the table-constraint syntax
would not be an
Robert Haas robertmh...@gmail.com writes:
Well, I think if that's the best we can do, you original proposal of
ditching the column constraint syntax altogether might be for the
best. I wasn't too excited about that before, but I think having two
different syntaxes is going to be even worse.
2012/10/22 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 22, 2012 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Don't hold your breath. There are two ways the system could implement
the DISTINCT clause: either sort and uniq, or hashaggregate.
2012/10/22 Robert Haas robertmh...@gmail.com:
On Thu, Oct 18, 2012 at 2:19 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Kohei KaiGai escribió:
The revised patch fixes the problem that Daen pointed out.
Robert, would you be able to give this latest version of the patch a
look?
Yeah,
I could find out a case to cause Assert() failure during investigation of RLS...
postgres=# CREATE TABLE t1 (x int, y text);
CREATE TABLE
postgres=# CREATE RULE _RETURN AS ON SELECT TO t1 DO INSTEAD SELECT
1 AS x, 'aaa'::text AS y;
CREATE RULE
postgres=# SELECT * FROM t1;
x | y
---+-
1 |
On Wed, Oct 10, 2012 at 4:24 PM, Marko Kreen mark...@gmail.com wrote:
The SCRAM looks good from the quick glance.
SCRAM does have weakness - the info necessary to log in
as client (ClientKey) is exposed during authentication
process.
IOW, the stored auth info can be used to log in as client,
if
On Fri, Oct 19, 2012 at 2:55 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
As you can see, in the case of rewrite it takes us back 7 1/2 years. I know
this is a *very* rough measure, but it still tends to indicate to me
On Sun, Oct 21, 2012 at 5:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
I don't see a problem at all with providing the snakeoil cert. In
fact, it's quite useful.
I see a problem with enabling it by default. Because it makes people
think they are more
On Mon, Oct 22, 2012 at 4:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Don't hold your breath. There are two ways the system could implement
the DISTINCT clause: either sort and uniq, or hashaggregate.
hashaggregate will destroy any input ordering, so there's no value in
using the index as
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Merlin Moncure
Sent: Monday, October 22, 2012 6:54 PM
To: Robert Haas
Cc: Andrew Dunstan; Josh Berkus; Daniel Farina; pgsql-
hack...@postgresql.org
Subject: Re:
On Wed, Oct 17, 2012 at 7:48 PM, Christopher Browne cbbro...@gmail.com wrote:
Well, replication is arguably a relevant case.
For Slony, the origin/master node never cares about logged changes - that
data is only processed on replicas. Now, that's certainly a little weaselly
- the log data
Kohei KaiGai kai...@kaigai.gr.jp writes:
postgres=# CREATE TABLE t1 (x int, y text);
CREATE TABLE
postgres=# CREATE RULE _RETURN AS ON SELECT TO t1 DO INSTEAD SELECT
1 AS x, 'aaa'::text AS y;
CREATE RULE
postgres=# SELECT * FROM t1;
x | y
---+-
1 | aaa
(1 row)
postgres=#
41 matches
Mail list logo
