On Sat, Nov 8, 2014 at 5:40 PM, David Rowley wrote:
> Please find attached another small fix. This time it's just a small typo in
> the README, and just some updates to some, now outdated docs.
Speaking about the feature... The index operators are still named with
"minmax", wouldn't it be better t
On Sat, Nov 8, 2014 at 6:24 PM, Andres Freund wrote:
> On 2014-11-08 17:49:30 -0500, Robert Haas wrote:
>> Patch 2 adds support for GRANT and REVOKE to the event trigger
>> mechanism. I wonder if it's a bad idea to make the
>> ddl_command_start/end events fire for DCL. We discussed a lot of
>> t
On Sat, Nov 8, 2014 at 4:35 PM, Andres Freund wrote:
>> > I don't understand why this is particularly difficult to regresssion
>> > test. It actually is comparatively simple?
>>
>> If it is, great. I previously wrote this email:
>>
>> http://www.postgresql.org/message-id/CA+TgmoZ=vzrijmxlkqi_v0jg
On 2014-11-08 17:49:30 -0500, Robert Haas wrote:
> Patch 2 adds support for GRANT and REVOKE to the event trigger
> mechanism. I wonder if it's a bad idea to make the
> ddl_command_start/end events fire for DCL. We discussed a lot of
> these issues when this patch originally went in, and I think
On Sat, Nov 8, 2014 at 1:05 PM, Andres Freund wrote:
>> There's nothing to keep you from exposing the parse trees to
>> C functions that can live in an extension, and you can do all of this
>> deparsing there.
>
> Not really. There's some core functions that need to be touched. Like
> most of the
Andreas Joseph Krogh writes:
> Hi. Â When working with Oracle it is possible to catch constraint-violations
> caused by triggers using JDBC, but it seems this isn't possible using PG, see
> this thread:
> https://github.com/impossibl/pgjdbc-ng/issues/111#issuecomment-62276464
I'm not exactly
On 2014-11-08 12:10:48 -0800, Josh Berkus wrote:
> On 11/07/2014 05:29 PM, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> >> Of course, this will lead to LOTs of additional vacuuming ...
> >
> > There's a trade-off here: more vacuuming I/O usage for less disk space
> > used. How stressed your cus
On 2014-11-08 10:42:15 -0500, Robert Haas wrote:
> On Sat, Nov 8, 2014 at 4:37 AM, Andres Freund wrote:
> > I don't understand why this is particularly difficult to regresssion
> > test. It actually is comparatively simple?
>
> If it is, great. I previously wrote this email:
>
> http://www.post
On 11/08/2014 04:19 PM, Ross Reedstrom wrote:
I've no opinion on the not respecting aliases aspect of this, but both
the hstore and json emtpy keys case breaks the format: it's duplicate keys
that collapse to a single value, and expected keynames are missing.
The insidious bit about this bug th
I've no opinion on the not respecting aliases aspect of this, but both
the hstore and json emtpy keys case breaks the format: it's duplicate keys
that collapse to a single value, and expected keynames are missing.
The insidious bit about this bug though is that it works fine during testing
with th
On 07/11/14 22:02, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Kevin Grittner wrote:
I think most people have always assumed that
BEGIN starts the transaction and that is the point at
which the snapshot is obtained.
But there is so much evidence to the contr
On 06/11/14 15:00, Kevin Grittner wrote:
Álvaro Hernández Tortosa wrote:
There has been two comments which seem to state that changing this
may introduce some performance problems and some limitations when you
need to take out some locks. I still believe, however, that current
behavior i
Hi. When working with Oracle it is possible to catch constraint-violations
caused by triggers using JDBC, but it seems this isn't possible using PG, see
this thread:
https://github.com/impossibl/pgjdbc-ng/issues/111#issuecomment-62276464 For
check of FK-violations the protocol supports this
On 11/07/2014 05:29 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> Of course, this will lead to LOTs of additional vacuuming ...
>
> There's a trade-off here: more vacuuming I/O usage for less disk space
> used. How stressed your customers really are about 1 GB of disk space?
These customers
On 8.11.2014 15:40, Katharina Büchse wrote:
> I'm sorry if I repeated myself too often, I somehow started answering
> at the end of your mail and then went up... I promise to do this
> better next time.
Nah, no problem. Better say something twice than not at all ;-)
However, I see you've responde
On Sat, Nov 8, 2014 at 12:13 PM, Jon Erdman
wrote:
>
> So, I was trying to use mustache.js in PG by defining a V8 function that
> imports it. Older versions worked fine, but in newer versions they use a
> class factory and I can't figure out how to reference the mustache stuff that
> it creates
Oh, some more fun: a RowExpr that's labeled with a named composite type
(rather than RECORD) has the same issue of not respecting aliases.
Continuing previous example with table "foo":
regression=# create view vv as select * from foo;
CREATE VIEW
regression=# select row_to_json(q) from vv q;
ro
On 2014-11-08 12:30:29 -0500, Robert Haas wrote:
> On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund wrote:
> >> Putting half of it into core wouldn't fix that, it would just put a
> >> lot more maintenance burden on core developers.
> >
> > Imo stuff that can't be done sanely outside core needs to b
On 11/08/2014 12:40 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/08/2014 12:14 PM, Tom Lane wrote:
That would be my druthers. But given the lack of complaints, maybe we
should just stick to the more-backwards-compatible behavior until someone
does complain. Thoughts?
Wouldn't that woul
Andrew Dunstan writes:
> On 11/08/2014 12:14 PM, Tom Lane wrote:
>> That would be my druthers. But given the lack of complaints, maybe we
>> should just stick to the more-backwards-compatible behavior until someone
>> does complain. Thoughts?
> Wouldn't that would mean we might not pick up the
On 11/08/2014 12:14 PM, Tom Lane wrote:
I assume that's what you would propose for just the stable branches, and
that going forward we'd always use the aliases from the RTE?
That would be my druthers. But given the lack of complaints, maybe we
should just stick to the more-backwards-compatible
On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund wrote:
>> Putting half of it into core wouldn't fix that, it would just put a
>> lot more maintenance burden on core developers.
>
> Imo stuff that can't be done sanely outside core needs to be put into
> core if it's actually desired by many users. A
Tom Lane
> Andrew Dunstan writes:
>> I assume that's what you would propose for just the stable branches, and
>> that going forward we'd always use the aliases from the RTE?
>
> That would be my druthers. But given the lack of complaints, maybe we
> should just stick to the more-backwards-compa
On 2014-11-08 12:07:41 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
> >> Adding a similar
> >> level of burden to support a feature with a narrow use-case seems like
> >> a nonstarter from here.
>
> > I don't understand this statement. In my exp
Andrew Dunstan writes:
> On 11/08/2014 11:24 AM, Tom Lane wrote:
>> That seems like a pretty silly move: it wouldn't actually fix anything,
>> and it would break cases that perhaps are acceptable to users today.
> What evidence do you have that it might be acceptable to today's users?
> The only
Got radio silence on this question in -general, and upon reflection I think it
might be a -hacker level question. I'm not sure who actually implemented PLV8,
but I think it might take someone at or near that level to answer.
If not, sorry for the noise. Thanks!
If anyone wants to try to reprod
Andres Freund writes:
> On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
>> Adding a similar
>> level of burden to support a feature with a narrow use-case seems like
>> a nonstarter from here.
> I don't understand this statement. In my experience the lack of a usable
> replication solution that all
On 11/08/2014 11:24 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/08/2014 09:26 AM, Robert Haas wrote:
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either.
I confirm that Tom
Robert Haas wrote:
>> 3. Should long transactions which are rolled back be logged as well?
>
> Yes.
+1
>> 4. We log the statement when exceeding log_min_duration_statement, but
>> for transactions, that does not make a lot of sense, or should the last
>> statement be logged? I don't think that
On 2014-11-08 11:52:43 -0500, Tom Lane wrote:
> Adding a similar
> level of burden to support a feature with a narrow use-case seems like
> a nonstarter from here.
I don't understand this statement. In my experience the lack of a usable
replication solution that allows temporary tables and major v
Robert Haas writes:
> If it were a question of writing this code once and being done with
> it, that would be unobjectionable in my view. But it isn't.
> Practically every change to gram.y is going to require a corresponding
> change to this stuff. As far as I can see, nobody except me has
> com
Robert Haas writes:
> On Sat, Nov 8, 2014 at 1:09 AM, mariem wrote:
>> I'm aware of ruleutils.c which I think is a good tool but I don't think it's
>> appropriate as it takes the parse tree as input.
> "Parse", "Rewrite", and "Plan" are distinct stages. ruleutils.c takes
> the tree that results
Andrew Dunstan writes:
> On 11/08/2014 09:26 AM, Robert Haas wrote:
>> I'm not sure whether this is safe enough to back-patch, but it seems
>> like we should probably plan to back-patch *something*, because the
>> status quo isn't great either.
> I confirm that Tom's patch does indeed fix my test
On Sat, Nov 8, 2014 at 6:17 AM, Petr Jelinek wrote:
> Honestly, I am still not convinced that the centralized sequence server with
> no local caching is something we should be optimizing for as that one will
> suffer from performance problems anyway. And it can ignore the last_value
> input from p
On Sat, Nov 8, 2014 at 4:37 AM, Andres Freund wrote:
> I don't understand why this is particularly difficult to regresssion
> test. It actually is comparatively simple?
If it is, great. I previously wrote this email:
http://www.postgresql.org/message-id/CA+TgmoZ=vzrijmxlkqi_v0jg4k4leapmwusc6rwx
On 11/08/2014 09:26 AM, Robert Haas wrote:
On Fri, Nov 7, 2014 at 11:27 PM, Tom Lane wrote:
Thoughts?
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either.
I confirm that Tom'
On Sat, Nov 8, 2014 at 5:35 AM, Petr Jelinek wrote:
> That's not what I said. I am actually ok with adding the LSN if people see
> it useful.
> I was just wondering if we can make the record smaller somehow - 24bytes per
> txid is around 96GB of data for whole txid range and won't work with pages
On Sat, Nov 8, 2014 at 1:09 AM, mariem wrote:
> Hi Tom,
>>If you don't need that, why are you insistent on extracting the
>>information from a plan tree?
>
> I need to resolve expressions and apply rewrite rules before I reverse the
> query plan to a query.
>
>>It seems far simpler to me to make u
On Fri, Nov 7, 2014 at 11:27 PM, Tom Lane wrote:
> Thoughts?
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enter
On 5 November 2014 17:32, Heikki Linnakangas wrote:
> Why does sequence_alloc need the current value? If it's a "remote" seqam,
> the current value is kept in the remote server, and the last value that was
> given to this PostgreSQL server is irrelevant.
>
> That irks me with this API. The method
On Sat, Nov 8, 2014 at 12:45 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> Here are more thoughts among those lines looking at the current state of
>> the patch 4 that introduces the infrastructure of the whole feature. This
>> would make possible in-memory manipulation of jsonb containe
On 2014-11-07 17:20:44 -0800, Josh Berkus wrote:
> On 11/07/2014 04:43 PM, Alvaro Herrera wrote:
> > This says that the live multixact range goes from 123 million to 162
> > million; roughly 40 million values. (The default value for
> > vacuum_multixact_freeze_table_age is 150 million, which is wh
On 2014-11-07 16:09:44 -0800, Josh Berkus wrote:
> On 11/05/2014 11:15 AM, Josh Berkus wrote:
> > On 11/05/2014 10:40 AM, Jim Nasby wrote:
> >> Can you post the contents of pg_multixact/members/?
> >
> > Well, not as of last week, obviously.
> >
> > https://gist.github.com/jberkus/d05db3629e8c898
On 08/11/14 03:10, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:26 PM, Petr Jelinek wrote:
My main problem is actually not with having tuple per-seqAM, but more
with the fact that Heikki does not want to have last_value as compulsory
column/parameter. How is the new AM then supposed to know wher
On 11/08/2014 12:35 AM, Petr Jelinek wrote:
>>
>> Do you think it'd be simple to provide a blocking, transactional
>> sequence allocator via this API? i.e. gapless sequences, much the same
>> as typically implemented with SELECT ... FOR UPDATE on a counter table.
>>
>> It might be more digestible s
On 08/11/14 03:05, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:07 PM, Petr Jelinek wrote:
but we can't have everything there
as there are space constraints, and LSN is another 8 bytes and I still want
to have some bytes for storing the "origin" or whatever you want to call it
there, as that's t
On 2014-11-07 21:41:17 -0500, Robert Haas wrote:
> On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >
> >> Here are more thoughts among those lines looking at the current state of
> >> the patch 4 that introduces the infrastructure of the whole feature. This
>
On Sat, Nov 8, 2014 at 8:56 AM, Alvaro Herrera
wrote:
>
> I just pushed this, after some more minor tweaks. Thanks, and please do
> continue testing!
>
Please find attached another small fix. This time it's just a small typo in
the README, and just some updates to some, now outdated docs.
Kind
48 matches
Mail list logo
