On Wed, Mar 12, 2014 at 01:58:14PM -0700, Peter Geoghegan wrote:
> The use case you describe here doesn't sound like something similar to
> full text search. It sounds like something identical.
>
> In any case, let's focus on what we have right now. I think that the
> indexing facilities proposed
On Mon, Dec 9, 2013 at 11:27:28AM -0500, Robert Haas wrote:
> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote:
> > But the other usages seem to be in assorted utilities, which
> > will need to do it right for themselves. initdb.c's walkdir() seems to
> > have it right and might be a reasonable mo
On 13 March 2014 02:14, Robert Haas wrote:
>> I'm not sure why this is being blocked. This is a community
>> contribution that seeks to improve everybody's options. Blocking it
>> does *nothing* to prevent individual extensions from providing
>> table-level options - we give them freedom to do wh
On Thu, Mar 13, 2014 at 12:16 AM, Robert Haas wrote:
> On Tue, Mar 11, 2014 at 3:53 AM, Amit Kapila wrote:
>> Places where tuple info not available
>>
>> LOG: process 5788 still waiting for ShareLock on transaction 679 after
>> 1014.000
>> ms
>> CONTEXT: while attempting to operate in relatio
On 13 Mar 2014 01:36, "Stephen Frost" wrote:
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > This thread badly needs a more informative Subject line.
>
> Agreed.
>
> > But, yeah: do people think the referenced commit fixes a bug bad enough
> > to deserve a quick update release? If so, why? Multip
Hi all,
Shouldn't the "ALTER" statements below raise an exception?
fabrizio=# CREATE TABLE foo(bar SERIAL PRIMARY KEY);
CREATE TABLE
fabrizio=# SELECT relname, reloptions FROM pg_class WHERE relname ~ '^foo';
relname | reloptions
-+
foo |
foo_bar_seq |
foo
On Wed, Mar 12, 2014 at 9:38 PM, Simon Riggs wrote:
> On 12 March 2014 22:58, Robert Haas wrote:
>> I don't like the idea of using reloptions to let people attach
>> arbitrary unvalidated settings to tables.
>
> I respect your opinion. If you disagree, don't use them. Same as is
> possible for RU
On 12 March 2014 22:58, Robert Haas wrote:
> I don't like the idea of using reloptions to let people attach
> arbitrary unvalidated settings to tables.
I respect your opinion. If you disagree, don't use them. Same as is
possible for RULEs etc.
> I consider the way things
> work with GUCs to be
Joshua D. Drake wrote
> On 03/12/2014 06:15 PM, Tom Lane wrote:
>> Robert Haas <
> robertmhaas@
> > writes:
>>> Discuss.
>>
>> This thread badly needs a more informative Subject line.
>>
>
> No kidding. Or at least a link for goodness sake. Although the
> pgsql-packers list wasn't all that help
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This thread badly needs a more informative Subject line.
Agreed.
> But, yeah: do people think the referenced commit fixes a bug bad enough
> to deserve a quick update release? If so, why? Multiple reports of
> problems in the field would be a good reason
Josh Berkus escribió:
> On 03/12/2014 03:58 PM, Robert Haas wrote:
> > I don't like the idea of using reloptions to let people attach
> > arbitrary unvalidated settings to tables. I consider the way things
> > work with GUCs to be a bug, not a feature, and definitely not
> > something I want to pr
On 03/12/2014 06:15 PM, Tom Lane wrote:
Robert Haas writes:
Discuss.
This thread badly needs a more informative Subject line.
No kidding. Or at least a link for goodness sake. Although the
pgsql-packers list wasn't all that helpful either.
What I know is that we have a known in the wil
Robert Haas writes:
> Discuss.
This thread badly needs a more informative Subject line.
But, yeah: do people think the referenced commit fixes a bug bad enough
to deserve a quick update release? If so, why? Multiple reports of
problems in the field would be a good reason, but I've not seen suc
Robert Haas writes:
> On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund wrote:
>> Except that we don't have the infrastructure to perform such checks
>> (neither partial, nor expression indexes, no exclusion constraints) on
>> system tables atm. So it's not a entirely trivial thing to do.
> I'm pro
On 03/12/2014 04:52 PM, Thom Brown wrote:
> On 12 March 2014 23:17, Michael Paquier wrote:
>> On Thu, Mar 13, 2014 at 5:45 AM, Thom Brown wrote:
>>> I'm not clear on why would dropping an active replication slot would
>>> solve disk space problems related to WAL. I thought it was inactive
>>> sl
On 03/12/2014 03:58 PM, Robert Haas wrote:
> I don't like the idea of using reloptions to let people attach
> arbitrary unvalidated settings to tables. I consider the way things
> work with GUCs to be a bug, not a feature, and definitely not
> something I want to propagate into every other area of
Hello,
> On 03/12/2014 09:36 AM, Ashoke wrote:
> > Hi,
> >
> >I am working on adding a functionality to PostgreSQL. I need to parse
> >the XML format query plan (produced by PostgreSQL v9.3) and save it in
> >a simple data structure (say C structure). I was wondering if
...
> The only
On the pgsql-packagers list, there has been some (OT for that list)
discussion of whether commit 9a57858f1103b89a5674f0d50c5fe1f756411df6
is sufficiently serious to justify yet another immediate minor release
of 9.3.x. The relevant questions seem to be:
1. Is it really bad?
2. Does it affect a l
On 12 March 2014 23:17, Michael Paquier wrote:
> On Thu, Mar 13, 2014 at 5:45 AM, Thom Brown wrote:
>> On 12 March 2014 19:00, Josh Berkus wrote:
>>> All:
>>>
>>> I was just reading Michael's explanation of replication slots
>>> (http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highli
On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund wrote:
>> Isn't this just a case of creating a suitable operator and an exclusion
>> constraint? Defining the constraint in BKI might require extra
>> infrastructure, but it should be possible.
>
> Except that we don't have the infrastructure to perf
Hi,
On 13/03/14 03:27, Fujii Masao wrote:
> Committed!
Thank you very much!
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
pgpkDoVMmXIL4.pgp
Description: PGP signature
On Wed, Mar 12, 2014 at 11:16 PM, Tom Lane wrote:
> Julien Tachoires writes:
>> A customer has reported us a strange behaviour regarding a rowtype
>> column with a domain subfield:
>
> Rowtypes in general do not support defaults for component fields.
And what about adding a TODO item?
Support def
On Thu, Mar 13, 2014 at 5:45 AM, Thom Brown wrote:
> On 12 March 2014 19:00, Josh Berkus wrote:
>> All:
>>
>> I was just reading Michael's explanation of replication slots
>> (http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/)
>> and realized there was somet
On Wed, Mar 12, 2014 at 5:30 PM, Heikki Linnakangas
wrote:
> Ok, great. Committed!
Awesome.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On Mon, Mar 10, 2014 at 9:33 PM, Alvaro Herrera
wrote:
> I haven't touched pg_dump yet, but if this proposed design sits well
> with everyone, my intention is that the dump output will contain the
> pg_register_option_namespace() calls necessary so that a table
> definition will be able to do the
Oops. Of course shouldn't try and change how INSERT works. Latest version
attached.
♜
update_delete_order_by_limit_v2.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On 12.3.2014 22:43, Peter Geoghegan wrote:
> On Wed, Mar 12, 2014 at 2:30 PM, Tomas Vondra wrote:
>> I think that's unfounded assumption. Many users actually have very
>> little control over the documents or queries - a nice example may be the
>> mail archive, with headers stored in a hstore/jsonb
* Tomas Vondra (t...@fuzzy.cz) wrote:
> So I think it's quite difficult to give simple and exact explanation in
> the docs, other than "there are limits, but it's difficult to say when
> you hit them".
Arrays have more-or-less the same issue...
Thanks,
Stephen
signature
On 12.3.2014 21:55, Josh Berkus wrote:
> Andrew, Peter:
>
> Just so I'm clear on the limits here, lemme make sure I understand this:
>
> a) GIN indexing is limited to ~~1500chars
The exact message I get is this:
ERROR: index row size 1944 exceeds maximum 1352 for index "tmp_idx"
so it's 1352B.
On Wed, Mar 12, 2014 at 2:30 PM, Tomas Vondra wrote:
> I think that's unfounded assumption. Many users actually have very
> little control over the documents or queries - a nice example may be the
> mail archive, with headers stored in a hstore/jsonb. I have absolutely
> no control over the header
On 12.3.2014 21:58, Peter Geoghegan wrote:
>
> The use case you describe here doesn't sound like something similar to
> full text search. It sounds like something identical.
I think this very depends on the definition of full text search.
> In any case, let's focus on what we have right now. I t
On 03/04/2014 01:58 PM, Amit Kapila wrote:
On Mon, Mar 3, 2014 at 7:57 PM, Heikki Linnakangas
wrote:
On 02/16/2014 01:51 PM, Amit Kapila wrote:
On Wed, Feb 5, 2014 at 5:29 PM, Heikki Linnakangas
wrote:
Thanks. I have to agree with Robert though that using the pglz encoding when
we're just
On 12.3.2014 20:40, Peter Geoghegan wrote:
> On Wed, Mar 12, 2014 at 6:20 AM, Tomas Vondra wrote:
>> I'm still not sure how would that look. Does that mean I'd have to
>> create multiple GIN indexes - one for each possible key or
>> something like that? Can you give an example?
>
> It could mean
Hi,
Here's an updated patch. I had to push the LIMIT processing into ModifyTable
to make the behaviour sane in parallel scenarios. As usual, please ignore if
you're busy with 9.4. I will work on better docs and more tests from now on
and am preparing to make a solid case for adding this.
On 03/12/2014 04:58 PM, Peter Geoghegan wrote:
In any case, let's focus on what we have right now. I think that the
indexing facilities proposed here are solid. In any case they do not
preclude working on better indexing strategies as the need emerges.
I quite agree, didn't mean to suggest o
On Wed, Mar 12, 2014 at 1:37 PM, Andrew Dunstan wrote:
> One major use case for using treeish data types in the first place is that
> you don't know when you're designing the database exactly what shape the
> data will be. If you don't know that, then how are you supposed to know what
> in it will
Andrew, Peter:
Just so I'm clear on the limits here, lemme make sure I understand this:
a) GIN indexing is limited to ~~1500chars
b) The "value", which includes everything other than the top level set
of keys, is one item as far as GIN is concerned.
Therefore: we are limited to indexing JSON wh
On 12 March 2014 19:00, Josh Berkus wrote:
> All:
>
> I was just reading Michael's explanation of replication slots
> (http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/)
> and realized there was something which had completely escaped me in the
> pre-commit di
On 03/12/2014 04:10 PM, Peter Geoghegan wrote:
On Wed, Mar 12, 2014 at 11:57 AM, Oleg Bartunov wrote:
Also, GiST index is faster for create/update operations. I really hope we will
improve jsonb indexing in the next one-two releases. For now I'd suggest people
index expressional indexes to ind
On Thu, Mar 13, 2014 at 12:10 AM, Peter Geoghegan wrote:
> On Wed, Mar 12, 2014 at 11:57 AM, Oleg Bartunov wrote:
>> Also, GiST index is faster for create/update operations. I really hope we
>> will
>> improve jsonb indexing in the next one-two releases. For now I'd suggest
>> people
>> index e
On 03/12/2014 12:34 PM, Robert Haas wrote:
>>> Urgh. That error message looks susceptible to improvement. How about:
>>> >>
>>> >> replication slot "%s" cannot be dropped because it is currently in use
>> >
>> > I think that'd require duplicating some code between acquire and drop,
>> > but how a
On 03/12/2014 12:26 PM, Andres Freund wrote:
> On 2014-03-12 12:23:01 -0700, Josh Berkus wrote:
>> On 03/12/2014 12:03 PM, Andres Freund wrote:
It seems like there's no way for a DBA to drop slots from the master if
it's rapidly running out of disk WAL space without doing a restart, and
>
On Wed, Mar 12, 2014 at 11:57 AM, Oleg Bartunov wrote:
> Also, GiST index is faster for create/update operations. I really hope we will
> improve jsonb indexing in the next one-two releases. For now I'd suggest
> people
> index expressional indexes to index just interesting keys or use GiST.
Whe
On Wed, Mar 12, 2014 at 6:20 AM, Tomas Vondra wrote:
> I'm still not sure how would that look. Does that mean I'd have to create
> multiple GIN indexes - one for each possible key or something like that?
> Can you give an example?
It could mean that you're obliged to create multiple indexes, yes.
On Wed, Mar 12, 2014 at 3:25 PM, Andres Freund wrote:
> On 2014-03-12 15:18:04 -0400, Robert Haas wrote:
>> On Wed, Mar 12, 2014 at 3:03 PM, Andres Freund
>> wrote:
>> > Hi,
>> >
>> > On 2014-03-12 12:00:25 -0700, Josh Berkus wrote:
>> >> I was just reading Michael's explanation of replication s
On 2014-03-07 17:54:32 +0200, Heikki Linnakangas wrote:
> So there are some unexplained differences there, but based on these results,
> I'm still OK with committing the patch.
So, I am looking at this right now.
I think there are some minor things I'd like to see addressed:
1) I think there nee
On 2014-03-12 12:23:01 -0700, Josh Berkus wrote:
> On 03/12/2014 12:03 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2014-03-12 12:00:25 -0700, Josh Berkus wrote:
> >> I was just reading Michael's explanation of replication slots
> >> (http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-high
On 2014-03-12 15:18:04 -0400, Robert Haas wrote:
> On Wed, Mar 12, 2014 at 3:03 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2014-03-12 12:00:25 -0700, Josh Berkus wrote:
> >> I was just reading Michael's explanation of replication slots
> >> (http://michael.otacoo.com/postgresql-2/postgres-9-4-fea
On 03/12/2014 12:03 PM, Andres Freund wrote:
> Hi,
>
> On 2014-03-12 12:00:25 -0700, Josh Berkus wrote:
>> I was just reading Michael's explanation of replication slots
>> (http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/)
>> and realized there was something
On Wed, Mar 12, 2014 at 3:03 PM, Andres Freund wrote:
> Hi,
>
> On 2014-03-12 12:00:25 -0700, Josh Berkus wrote:
>> I was just reading Michael's explanation of replication slots
>> (http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/)
>> and realized there was
* Josh Berkus (j...@agliodbs.com) wrote:
> On 03/12/2014 11:25 AM, Stephen Frost wrote:
> > * Josh Berkus (j...@agliodbs.com) wrote:
> >> Local superusers (maybe this concept needs another name) would be able
> >> to do the following things in a *single* database:
> >>
> >> 1 change permissions for
Hi,
On 2014-03-12 12:00:25 -0700, Josh Berkus wrote:
> I was just reading Michael's explanation of replication slots
> (http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/)
> and realized there was something which had completely escaped me in the
> pre-commit d
On 03/12/2014 11:40 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 03/12/2014 02:09 PM, Josh Berkus wrote:
>>> Well, if you really want my "I want a pony" list:
>>>
>>> Local superusers (maybe this concept needs another name) would be able
>>> to do the following things in a *single* database:
All:
I was just reading Michael's explanation of replication slots
(http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/)
and realized there was something which had completely escaped me in the
pre-commit discussion:
select pg_drop_replication_slot('slot_1');
E
Also, GiST index is faster for create/update operations. I really hope we will
improve jsonb indexing in the next one-two releases. For now I'd suggest people
index expressional indexes to index just interesting keys or use GiST.
On Wed, Mar 12, 2014 at 5:15 PM, Tomas Vondra wrote:
> On 12 Březen
On Tue, Mar 11, 2014 at 3:53 AM, Amit Kapila wrote:
> Places where tuple info not available
>
> LOG: process 5788 still waiting for ShareLock on transaction 679 after
> 1014.000
> ms
> CONTEXT: while attempting to operate in relation "public"."idx_t1" of
> database
> "postgres"
The way the c
On Wed, Mar 12, 2014 at 8:05 PM, Ashutosh Dhundhara <
ashutoshdhundh...@yahoo.com> wrote:
> Hello all,
> I am Ashutosh Dhundhara from Thapat University, Patiala-India presently
> pursuing Bachelors degree in Computer Science and Engineering.
> This year I wish to work for PostgreSQL under the flag
Hello all,
I am Ashutosh Dhundhara from Thapat University, Patiala-India presently
pursuing Bachelors degree in Computer Science and Engineering.
This year I wish to work for PostgreSQL under the flagship of GSoC 2014. So
please help regarding this. I have a few questions :
1) Do I have to choos
Andrew Dunstan writes:
> On 03/12/2014 02:09 PM, Josh Berkus wrote:
>> Well, if you really want my "I want a pony" list:
>>
>> Local superusers (maybe this concept needs another name) would be able
>> to do the following things in a *single* database:
>>
>> 1 change permissions for other users o
Robert Haas writes:
> On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane wrote:
>> My inclination now (see later traffic) is to suppress the
>> status report when the COPY destination is the same as pset.queryFout
>> (ie, a simple test whether the FILE pointers are equal). This would
>> suppress the sta
On 03/12/2014 11:25 AM, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
>> Local superusers (maybe this concept needs another name) would be able
>> to do the following things in a *single* database:
>>
>> 1 change permissions for other users on that database and its objects
>
> Wh
On Tue, Feb 25, 2014 at 1:03 PM, Rajeev rastogi
wrote:
> On 04 February 2014 14:38, Myself wrote:
>
>>
>> On 4th February 2014, Christian kruse Wrote:
>> > On 04/02/14 12:38, Fujii Masao wrote:
>> > > ISTM that the phrase "Request queue" is not used much around the
>> lock.
>> > > Using the phrase
* Josh Berkus (j...@agliodbs.com) wrote:
> Local superusers (maybe this concept needs another name) would be able
> to do the following things in a *single* database:
>
> 1 change permissions for other users on that database and its objects
What about "bypass" permissions, ala what superuser does
On 03/12/2014 02:09 PM, Josh Berkus wrote:
On 03/12/2014 12:22 AM, Magnus Hagander wrote:
On Mar 12, 2014 1:46 AM, "Josh Berkus" wrote:
Yeah, what we really need is encapsulated per-DB users and local
superusers. I think every agrees that this is the goal, but nobody
wants to put in the work
MauMau escribió:
> The "raw" link only gave the mail in text format. I hoped to import
> the mail into Windows Mail on Windows Vista, but I couldn't.
You might need to run a conversion process by which you transform the
raw file (in mbox format) into EML format or whatever it is that Windows
Mai
On 03/12/2014 07:42 PM, Alexander Korotkov wrote:
Preparation we do in startScanKey requires knowledge of estimate size of
posting lists/trees. We do this estimate by traversal to leaf pages. I
think gincostestimate is expected to be way more cheap. So, we probably
need so more rough estimate the
On 03/12/2014 12:22 AM, Magnus Hagander wrote:
> On Mar 12, 2014 1:46 AM, "Josh Berkus" wrote:
>> Yeah, what we really need is encapsulated per-DB users and local
>> superusers. I think every agrees that this is the goal, but nobody
>> wants to put in the work to implement a generalized solution.
On Tue, Mar 11, 2014 at 4:16 PM, Andres Freund wrote:
> Could you perhaps commit the attached patch fixing the issues you
> mentioned?
I committed this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-ha
On Wed, Mar 12, 2014 at 1:52 PM, Alexander Korotkov
wrote:
>> * This patch added a triConsistent function for array and tsvector
>> opclasses. Were you planning to submit a patch to do that for the rest of
>> the opclasses, like pg_trgm? (it's getting awfully late for that...)
>
> Yes. I can try t
On Wed, Mar 12, 2014 at 8:02 PM, Heikki Linnakangas wrote:
> On 02/26/2014 11:25 PM, Alexander Korotkov wrote:
>
>> On Thu, Feb 27, 2014 at 1:07 AM, Alexander Korotkov > >wrote:
>>
>> On Thu, Feb 20, 2014 at 1:48 PM, Heikki Linnakangas <
>>> hlinnakan...@vmware.com> wrote:
>>>
>>> On 02/09/2014
On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane wrote:
> David Johnston writes:
>> Tom Lane-2 wrote
>>> 1. Treat this as a non-backwards-compatible change, and document that
>>> people have to use -q if they don't want the COPY tag in the output.
>>> I'm not sure this is acceptable.
>
>> I've mostly u
On Wed, Mar 12, 2014 at 8:29 PM, Heikki Linnakangas wrote:
> On 03/12/2014 12:09 AM, Tomas Vondra wrote:
>
>> 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 improvem
On Wed, Mar 12, 2014 at 12:45 PM, Heikki Linnakangas
wrote:
> On 03/12/2014 06:26 PM, Robert Haas wrote:
>> On Tue, Mar 11, 2014 at 3:14 PM, Josh Berkus wrote:
>>> 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'
Jeff Janes writes:
> On Wed, Mar 12, 2014 at 7:42 AM, Tom Lane wrote:
>> We've seen sporadic reports of that sort of behavior for years, but no
>> developer has ever been able to reproduce it reliably. Now that you've
>> got a reproducible case, do you want to poke into it and see what's going
>
On 03/12/2014 06:26 PM, Robert Haas wrote:
On Tue, Mar 11, 2014 at 3:14 PM, Josh Berkus wrote:
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
co
On Wed, Mar 12, 2014 at 7:42 AM, Tom Lane wrote:
> Kouhei Kaigai writes:
> > WARNING: pgstat wait timeout
> > WARNING: pgstat wait timeout
> > WARNING: pgstat wait timeout
> > WARNING: pgstat wait timeout
>
> > Once I got above messages, write performance is dramatically
> > degraded, even t
On 03/12/2014 12:09 AM, Tomas Vondra wrote:
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 pa
On Tue, Mar 11, 2014 at 3:14 PM, Josh Berkus wrote:
> 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
David Johnston writes:
> Tom Lane-2 wrote
>> 1. Treat this as a non-backwards-compatible change, and document that
>> people have to use -q if they don't want the COPY tag in the output.
>> I'm not sure this is acceptable.
> I've mostly used copy to with files and so wouldn't mind if STDOUT had t
On 02/26/2014 11:25 PM, Alexander Korotkov wrote:
On Thu, Feb 27, 2014 at 1:07 AM, Alexander Korotkov wrote:
On Thu, Feb 20, 2014 at 1:48 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
On 02/09/2014 12:11 PM, Alexander Korotkov wrote:
I've rebased catalog changes with last master.
Rajeev rastogi writes:
> 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 f
On 12 Březen 2014, 14:54, Kouhei Kaigai wrote:
> It is another topic from the main thread,
>
> I noticed the following message under the test cases that
> takes heavy INSERT workload; provided by Haribabu.
>
> [kaigai@iwashi ~]$ createdb mytest
> [kaigai@iwashi ~]$ psql -af ~/cache_scan.sql mytest
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Magnus Hagander writes:
> > You could COPY over the hba file or sometihng like that :) Or just
> > pg_read_binary_file() on the files in another database, which is accessible
> > through SQL as well.
>
> More directly, he could alter pg_authid to make him
Magnus Hagander writes:
> On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane wrote:
>> A local user with the superuser privilege would not be able to log into
>> another database, because superuser doesn't give you any extra privilege
>> until you've logged in.
>>
>> Yeah, as superuser you could still br
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane wrote:
> > I share your doubts as to how useful such a concept actually is, but
> > it'd work if we had real local users.
>
>
> It can also do interesting things like ALTER SYSTEM, replication, backups,
> e
On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane wrote:
> Magnus Hagander writes:
> >> Yeah, what we really need is encapsulated per-DB users and local
> >> superusers. I think every agrees that this is the goal, but nobody
> >> wants to put in the work to implement a generalized solution.
>
> > Encap
Magnus Hagander writes:
>> Yeah, what we really need is encapsulated per-DB users and local
>> superusers. I think every agrees that this is the goal, but nobody
>> wants to put in the work to implement a generalized solution.
> Encapsulated would probably be the doable part. But local superuser
Jaime Casanova writes:
> 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?
So that if I say "GRANT SELECT ON mytable TO joe", it's una
Kouhei Kaigai writes:
> WARNING: pgstat wait timeout
> WARNING: pgstat wait timeout
> WARNING: pgstat wait timeout
> WARNING: pgstat wait timeout
> Once I got above messages, write performance is dramatically
> degraded, even though I didn't take detailed investigation.
> I could reproduce i
Julien Tachoires writes:
> A customer has reported us a strange behaviour regarding a rowtype
> column with a domain subfield:
Rowtypes in general do not support defaults for component fields.
> Is build_column_default() the right place to handle that case ?
It's unlikely that this is simple t
It is another topic from the main thread,
I noticed the following message under the test cases that
takes heavy INSERT workload; provided by Haribabu.
[kaigai@iwashi ~]$ createdb mytest
[kaigai@iwashi ~]$ psql -af ~/cache_scan.sql mytest
\timing
Timing is on.
--cache scan select 5 million
create
On 03/12/2014 09:36 AM, Ashoke wrote:
Hi,
I am working on adding a functionality to PostgreSQL. I need to
parse the XML format query plan (produced by PostgreSQL v9.3) and save
it in a simple data structure (say C structure). I was wondering if
PostgreSQL already had any parsing functions
Hi,
I am working on adding a functionality to PostgreSQL. I need to parse
the XML format query plan (produced by PostgreSQL v9.3) and save it in a
simple data structure (say C structure). I was wondering if PostgreSQL
already had any parsing functions implemented that I can use to do the XML
pa
On 12 Březen 2014, 0:51, Peter Geoghegan wrote:
> 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
On 2014-03-12 10:03:42 -0300, Alvaro Herrera wrote:
> 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
> >
On 12 Březen 2014, 0:41, Peter Geoghegan wrote:
> 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.
Yes, I know and I have no problem with restrictions in general. You may
run
Hi,
A customer has reported us a strange behaviour regarding a rowtype
column with a domain subfield:
test=# CREATE DOMAIN my_int_not_null_1 AS INTEGER DEFAULT 1 NOT NULL;
CREATE DOMAIN
test=# CREATE TYPE my_int_rowtype AS (
test(# f1 INTEGER,
test(# f2 my_int_not_null_1
test(# );
CRE
From: Murtuza Mukadam
Date: Sat, Mar 8, 2014 at 1:56 PM
Subject: Re: [HACKERS] git-review: linking commits to review discussion in git
To: Heikki Linnakangas
Cc: pgsql-hackers@postgresql.org
Hi Heikki
We have linked git commits and reviews in a web interface. If you
enter a commit hash, you wi
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't seem
On 03/12/2014 02:05 PM, Robert Haas wrote:
On Wed, Mar 12, 2014 at 4:23 AM, Heikki Linnakangas
wrote:
The attached patch doesn't apply any more, but it looks like this
issue still exists.
Fixed.
Did you forget to push?
Yep. Pushed now.
- Heikki
--
Sent via pgsql-hackers mailing list (p
1 - 100 of 107 matches
Mail list logo
