On Tue, Mar 11, 2014 at 5:19 AM, Peter Geoghegan wrote:
> On Mon, Mar 10, 2014 at 4:19 AM, Alexander Korotkov
> wrote:
> > Here it is.
>
> So it looks like what you have here is analogous to the other problems
> that I fixed with both GiST and GIN. That isn't surprising, and this
> does fix my t
On Mon, Mar 10, 2014 at 5:14 PM, Christian Kruse
wrote:
> On 09/03/14 12:15, Amit Kapila wrote:
>> [...] due to which the message it displays seems to be
>> incomplete. Message it displays is as below:
>>
>> LOG: process 1800 still waiting for ShareLock on transaction 679 after
>> 1014.000
>> m
Hi,
On 11/03/14 13:23, Amit Kapila wrote:
> [… snip …]
> So I think it's better to leave logging it as you have done in
> patch.
Agreed.
> […]
> 2. Name new functions as
> MultiXactIdWaitExtended()/XactLockTableWaitExtended()
> or MultiXactIdWaitEx()/XactLockTableWaitEx().
> You can find some
On 10 March 2014 23:44, Tom Lane wrote:
> Unfortunately, while testing it I noticed that there's a potentially
> fatal backwards-compatibility problem, namely that the "COPY n" status
> gets printed on stdout, which is the same place that COPY OUT data is
> going. While this isn't such a big prob
From: "Tom Lane"
"MauMau" writes:
To put the question in other words, is it safe to load a multi-threaded
PL
library in the single-threaded backend process, if the PL only calls SPI
in
the main thread?
When it breaks, we're not going to be concerned.
I may not understand your nuance. Wh
Hi,
I am trying to figure out when disk is used to store intermediate results
while performing joins in postgres.
According my findings using 'explain analyse ' only merge sort uses disk.
Can anyone please throw some more light on this?
Thanks,
Parul
On Tue, Mar 11, 2014 at 12:23 AM, Prakash Itnal wrote:
> Can someone confirm is this really an issue? or any reasons for missing
> rows?
Well, your database is definitely getting corrupted somehow. But
there's no information in your email which would enable someone to
guess how.
I blogged on th
On 03/11/2014 01:24 PM, Parul Lakkad wrote:
Hi,
I am trying to figure out when disk is used to store intermediate results
while performing joins in postgres.
According my findings using 'explain analyse ' only merge sort uses disk.
Can anyone please throw some more light on this?
Hash joins w
MauMau escribió:
> Hi, Amit san,
>
> I'm replying to your previous email. I wanted to reply to your
> latest mail below, but I removed it from my mailer by mistake.
>
> http://www.postgresql.org/message-id/CAA4eK1LAg6ndZdWLb5e=Ep5DzcE8KZU=JbmO+tFwySYHm2ja=q...@mail.gmail.com
>
> Do you know how
On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown wrote:
> Hi,
>
> I've noticed that "db_user_namespace" has had the following note
> attached to it since 2002:
>
> "This feature is intended as a temporary measure until a complete
> solution is found. At that time, this option will be removed."
>
> It w
Magnus Hagander writes:
> On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown wrote:
>> It will be 12 years this year since this "temporary measure" was
>> added. I'm just wondering, is there any "complete solution" that
>> anyone had in mind yet? Or should this just be deprecated?
> I'd say +1 to remo
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown wrote:
> >> It will be 12 years this year since this "temporary measure" was
> >> added. I'm just wondering, is there any "complete solution" that
> >> anyone had in mind y
"MauMau" writes:
> From: "Tom Lane"
>> When it breaks, we're not going to be concerned.
> I may not understand your nuance. Which of the following do you mean?
> * PL/Java's design is dangerous in terms of the mixture of single- and
> multi-threading, and we cannot be 100% sure whether there'
Magnus Hagander writes:
> On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane wrote:
>> Are you claiming there are no users, and if so, on what evidence?
> I am claiming that I don't think anybody is using that, yes.
> Based on the fact that I have *never* come across it on any system I've
> come across
Rajeev rastogi writes:
> On 10 March 2014 23:44, Tom Lane wrote:
>> Unfortunately, while testing it I noticed that there's a potentially
>> fatal backwards-compatibility problem, namely that the "COPY n" status
>> gets printed on stdout, which is the same place that COPY OUT data is
>> going. Whi
On 03/11/2014 09:57 AM, Tom Lane wrote:
Magnus Hagander writes:
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane wrote:
Are you claiming there are no users, and if so, on what evidence?
I am claiming that I don't think anybody is using that, yes.
Based on the fact that I have *never* come across i
* Andrew Dunstan (and...@dunslane.net) wrote:
> Or we try to make it work. I don't think the idea is inherently bad,
> and I know there are people (like ISPs) who would like to have it
> work properly. Maybe in these days when most people are on dedicated
> VMs this matters less, but I don't think
On 03/11/2014 12:37 PM, Stephen Frost wrote:
Isn't the other issue for ISPs essentially that we don't have row-level
security for our global catalogs? as in- we can't limit what's in
pg_authid to only those entries a given user should be able to see? I
don't think db_user_namespace addresses
On Mon, Mar 10, 2014 at 11:26 PM, Amit Kapila wrote:
> On Mon, Mar 10, 2014 at 11:37 PM, Robert Haas wrote:
>> Looks good, committed. However, I changed it so that
>> dsm_keep_segment() does not also perform the equivalent of
>> dsm_keep_mapping(); those are two separate operations.
>
> So are y
On 11 March 2014 03:41, Tom Lane wrote:
> Joe Conway writes:
>> I am probably missing something obvious, but why does the
>> AccessShareLock remain held on a table after a SELECT statement is
>> complete when in a transaction block?
>
> *Any* lock acquired by user command is held till end of tran
Tom Lane escribió:
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> > You are correct. pg_dump export reloptions using "WITH" clause of CREATE
> > TABLE statement. I.e.:
>
> > CREATE TABLE foo (
> > )
> > WITH (autovacuum_enabled=false, bdr.do_replicate=false);
>
> > So if this statement c
On Tue, Mar 11, 2014 at 10:56 PM, Simon Riggs wrote:
> On 11 March 2014 03:41, Tom Lane wrote:
> > Joe Conway writes:
> >> I am probably missing something obvious, but why does the
> >> AccessShareLock remain held on a table after a SELECT statement is
> >> complete when in a transaction block?
On 11 March 2014 17:29, Atri Sharma wrote:
>
>
>
> On Tue, Mar 11, 2014 at 10:56 PM, Simon Riggs wrote:
>>
>> On 11 March 2014 03:41, Tom Lane wrote:
>> > Joe Conway writes:
>> >> I am probably missing something obvious, but why does the
>> >> AccessShareLock remain held on a table after a SELE
On Tue, Mar 11, 2014 at 11:07 PM, Simon Riggs wrote:
> On 11 March 2014 17:29, Atri Sharma wrote:
> >
> >
> >
> > On Tue, Mar 11, 2014 at 10:56 PM, Simon Riggs
> wrote:
> >>
> >> On 11 March 2014 03:41, Tom Lane wrote:
> >> > Joe Conway writes:
> >> >> I am probably missing something obvious,
On 11 March 2014 17:26, Alvaro Herrera wrote:
> Tom Lane escribió:
>> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
>> > You are correct. pg_dump export reloptions using "WITH" clause of CREATE
>> > TABLE statement. I.e.:
>>
>> > CREATE TABLE foo (
>> > )
>> > WITH (autovacuum_enabled=false,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/11/2014 12:26 PM, Simon Riggs wrote:
> On 11 March 2014 03:41, Tom Lane wrote:
>> Joe Conway writes:
>>> I am probably missing something obvious, but why does the
>>> AccessShareLock remain held on a table after a SELECT statement
>>> is compl
On Mon, Mar 10, 2014 at 8:12 PM, Alvaro Herrera wrote:
> Gurjeet Singh wrote:
> > On Tue, Nov 26, 2013 at 12:37 PM, Tom Lane wrote:
> >
> > > Gurjeet Singh writes:
> > > > I was looking for ways to reduce the noise in Postgres make output,
> > > > specifically, I wanted to eliminate the "Nothing
On Tue, Mar 11, 2014 at 2:43 PM, Simon Riggs wrote:
>
> On 11 March 2014 17:26, Alvaro Herrera wrote:
> > Tom Lane escribió:
> >> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
writes:
> >> > You are correct. pg_dump export reloptions using "WITH" clause of
CREATE
> >> > TABLE statement. I.e.:
> >>
Simon Riggs writes:
> -1 to *requiring* validation for table-level options for exactly the
> same reasons we no longer validate custom GUCs.
Well, that is an interesting analogy, but I'm not sure how much it applies
here. In the case of a GUC, you can fairly easily validate it once the
module do
Hackers,
In the 9.3.3 updates, we added three new GUCs to control multixact
freezing. This was an unprecented move in my memory -- I can't recall
ever adding a GUC to a minor release which wasn't backwards
compatibility for a security fix. This was a mistake.
What makes these GUCs worse is that
Where, if anywhere, is the current documentation for writing or using a
logical decoding output plugin consumer thingy?
I'm trying to find my way into it ...
src/backend/replication/logical/logical.c, which textually contains most
of the functions that appear to interact with the test_decoding mo
Hi,
On 2014-03-11 15:57:39 -0400, Peter Eisentraut wrote:
> Where, if anywhere, is the current documentation for writing or using a
> logical decoding output plugin consumer thingy?
There's a pending patch for it. The corresponding commit is
http://git.postgresql.org/gitweb/?p=users/andresfreund/
Hello
I had to reduce allowed line style to single or double, because unicode
allows only combination single,double or single,thick
postgres=# \l
List of databases
Name| Owner | Encoding | Collate |Ctype| Access
privileges
---+
Sigh ...
Josh Berkus wrote:
> Further, there's no clear justification why these cannot be set to be
> the same as our other freeze ages (which our users also don't
> understand), or a constant calculated portion of them, or just a
> constant.
Calculated portion was my first proposal. The object
Josh Berkus wrote
> Hackers,
>
> In the 9.3.3 updates, we added three new GUCs to control multixact
> freezing. This was an unprecented move in my memory -- I can't recall
> ever adding a GUC to a minor release which wasn't backwards
> compatibility for a security fix. This was a mistake.
It pr
Hi all,
a quick question that just occured to me - do you plan to tweak the cost
estimation fot GIN indexes, in this patch?
IMHO it would be appropriate, given the improvements and gains, but it
seems to me gincostestimate() was not touched by this patch.
I just ran into this while testing some
Hi,
I've spent a few hours stress-testing this a bit - loading a mail
archive with ~1M of messages (with headers stored in a jsonb column) and
then doing queries on that. Good news - no crashes or any such issues so
far. The queries that I ran manually seem to return sane results.
The only proble
Josh Berkus writes:
> On 03/11/2014 06:57 AM, Tom Lane wrote:
>> Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always
>> has been. I'm just expecting lots of push-back if we try. And it's kind
>> of hard to resist push-back when you don't have a substitute to offer.
> Yeah
On Tue, Mar 11, 2014 at 3:58 PM, Tomas Vondra wrote:
> ERROR: index row size 1416 exceeds maximum 1352 for index "gin_idx"
All index AMs have similar restrictions.
> A good example of such header is "dkim-signature" which basically
> contains the whole message digitally signed with DKIM. The
On 11 March 2014 18:33, Tom Lane wrote:
> Simon Riggs writes:
>> -1 to *requiring* validation for table-level options for exactly the
>> same reasons we no longer validate custom GUCs.
>
> Well, that is an interesting analogy, but I'm not sure how much it applies
> here. In the case of a GUC, yo
Andrew Dunstan writes:
> The docs say:
> db_user_namespace causes the client's and server's user name
> representation to differ. Authentication checks are always done with
> the server's user name so authentication methods must be configured
> for the server's user name, not the
On 03/11/2014 07:41 PM, Tom Lane wrote:
Andrew Dunstan writes:
The docs say:
db_user_namespace causes the client's and server's user name
representation to differ. Authentication checks are always done with
the server's user name so authentication methods must be configured
On Tue, Mar 11, 2014 at 4:41 PM, Peter Geoghegan wrote:
> I think that in practice the
> general recommendation will be that when indexing at the "top level",
> use jsonb_hash_ops. When indexing nested items, use the more flexible
> default GIN opclass. That seems like a pretty smart trade-off to
On 03/11/2014 06:57 AM, Tom Lane wrote:
> Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always
> has been. I'm just expecting lots of push-back if we try. And it's kind
> of hard to resist push-back when you don't have a substitute to offer.
Yeah, what we really need is enc
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar commands. This doesn't seem simple to
enforce (if we supported partial indexes on sy
Andrew Dunstan writes:
> On 03/11/2014 09:37 PM, Tom Lane wrote:
>> In particular, I'd like to see an exclusion that prevents local users
>> from having the same name as any global user, so that we don't have
>> ambiguity in GRANT and similar commands. This doesn't seem simple to
>> enforce (if w
So I'll admit to using it, only in "toy" setups...
I use it with trust and ident, on local connections though, not password
I try to keep my laptops clean of mysqld, and I use PG. And only on my
laptop/PC, I make a database for every user... And every "app" get's a
userid, and a schema
On 03/11/2014 11:06 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar commands. This doesn
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane wrote:
> But not sure how to define a unique
> index that allows (joe, db1) to coexist with (joe, db2) but not with
> (joe, 0).
>
and why you want that restriction? when you login you need to specify
the db, right? if you don't specify the db then is the
On 03/11/2014 11:50 PM, Jaime Casanova wrote:
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane wrote:
But not sure how to define a unique
index that allows (joe, db1) to coexist with (joe, db2) but not with
(joe, 0).
and why you want that restriction? when you login you need to specify
the db, rig
On 11 March 2014 19:52, Tom Lane wrote:
> After sleeping on it, I'm inclined to think we should continue to not
> print status for COPY TO STDOUT. Aside from the risk of breaking
> scripts, there's a decent analogy to be made to SELECT: we don't print
> a status tag for that either.
It is correc
On Tue, Mar 11, 2014 at 10:52 PM, Andrew Dunstan wrote:
>
> On 03/11/2014 11:50 PM, Jaime Casanova wrote:
>>
>> On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane wrote:
>>>
>>> But not sure how to define a unique
>>> index that allows (joe, db1) to coexist with (joe, db2) but not with
>>> (joe, 0).
>>>
On Thu, Mar 6, 2014 at 10:15 PM, Kohei KaiGai wrote:
> 2014-03-06 18:17 GMT+09:00 Haribabu Kommi :
>> I will update you later regarding the performance test results.
>>
I ran the performance test on the cache scan patch and below are the readings.
Configuration:
Shared_buffers - 512MB
cache_sca
Andrew Dunstan wrote
> On 03/11/2014 11:50 PM, Jaime Casanova wrote:
>> On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane <
> tgl@.pa
> > wrote:
>>> But not sure how to define a unique
>>> index that allows (joe, db1) to coexist with (joe, db2) but not with
>>> (joe, 0).
>>>
>> and why you want that res
Tom Lane-2 wrote
> Unfortunately, while testing it I noticed that there's a potentially
> fatal backwards-compatibility problem, namely that the "COPY n" status
> gets printed on stdout, which is the same place that COPY OUT data is
> going. While this isn't such a big problem for interactive use,
2014-03-12 7:10 GMT+01:00 David Johnston :
> Tom Lane-2 wrote
> > Unfortunately, while testing it I noticed that there's a potentially
> > fatal backwards-compatibility problem, namely that the "COPY n" status
> > gets printed on stdout, which is the same place that COPY OUT data is
> > going. Wh
Thanks for your efforts!
> Head patched
> Diff
> Select - 500K772ms2659ms-200%
> Insert - 400K 3429ms 1948ms 43% (I am
> not sure how it improved in this case)
> delete - 200K
On Wed, Mar 12, 2014 at 5:26 PM, Kouhei Kaigai wrote:
> Thanks for your efforts!
>> Head patched
>> Diff
>> Select - 500K772ms2659ms-200%
>> Insert - 400K 3429ms 1948ms 43% (I am
>> no
On Tue, Mar 11, 2014 at 2:59 PM, Amit Kapila wrote:
> On Mon, Mar 10, 2014 at 1:13 PM, Haribabu Kommi
> wrote:
>> On Mon, Mar 10, 2014 at 4:24 PM, Amit Kapila wrote:
>>> On Mon, Mar 10, 2014 at 5:58 AM, Wang, Jing
>>> wrote:
>>> > Enclosed is the patch to implement the requirement that issue l
On Tue, Mar 11, 2014 at 2:32 PM, Christian Kruse
wrote:
> On 11/03/14 13:23, Amit Kapila wrote:
>> Could you please once check (if you are comfortable doing so) wherever
>> this patch is passing tuple, whether it is okay to pass it based on
>> visibility
>> rules, else I will again verify it once
60 matches
Mail list logo
