On Sat, Nov 8, 2014 at 8:56 AM, Alvaro Herrera alvhe...@2ndquadrant.com
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
On 2014-11-07 21:41:17 -0500, Robert Haas wrote:
On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On 08/11/14 03:05, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:07 PM, Petr Jelinek p...@2ndquadrant.com 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
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 standalone,
On 08/11/14 03:10, Robert Haas wrote:
On Fri, Nov 7, 2014 at 7:26 PM, Petr Jelinek p...@2ndquadrant.com 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
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/d05db3629e8c898664c4
I
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 what
On Sat, Nov 8, 2014 at 12:45 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On 5 November 2014 17:32, Heikki Linnakangas hlinnakan...@vmware.com 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
On Fri, Nov 7, 2014 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us 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:
On Sat, Nov 8, 2014 at 1:09 AM, mariem mariem.benfad...@gmail.com 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
On Sat, Nov 8, 2014 at 5:35 AM, Petr Jelinek p...@2ndquadrant.com 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
On 11/08/2014 09:26 AM, Robert Haas wrote:
On Fri, Nov 7, 2014 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us 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.
On Sat, Nov 8, 2014 at 4:37 AM, Andres Freund and...@2ndquadrant.com 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:
On Sat, Nov 8, 2014 at 6:17 AM, Petr Jelinek p...@2ndquadrant.com 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
Andrew Dunstan and...@dunslane.net 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 8, 2014 at 1:09 AM, mariem mariem.benfad...@gmail.com 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.
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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
On 11/08/2014 11:24 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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.
Andres Freund and...@2ndquadrant.com 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
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
Andrew Dunstan and...@dunslane.net 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
On 2014-11-08 12:07:41 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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.
Tom Lane t...@sss.pgh.pa.us
Andrew Dunstan and...@dunslane.net 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
On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund and...@2ndquadrant.com 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
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
Andrew Dunstan and...@dunslane.net 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
On 11/08/2014 12:40 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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?
On 2014-11-08 12:30:29 -0500, Robert Haas wrote:
On Sat, Nov 8, 2014 at 12:20 PM, Andres Freund and...@2ndquadrant.com 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
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;
On Sat, Nov 8, 2014 at 12:13 PM, Jon Erdman
postgre...@thewickedtribe.net 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
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 responded
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 not
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
On 06/11/14 15:00, Kevin Grittner wrote:
Álvaro Hernández Tortosa a...@8kdata.com 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
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
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
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
On 2014-11-08 10:42:15 -0500, Robert Haas wrote:
On Sat, Nov 8, 2014 at 4:37 AM, Andres Freund and...@2ndquadrant.com 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:
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 customers
Andreas Joseph Krogh andr...@visena.com 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
On Sat, Nov 8, 2014 at 1:05 PM, Andres Freund and...@2ndquadrant.com 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
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 4:35 PM, Andres Freund and...@2ndquadrant.com 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:
On Sat, Nov 8, 2014 at 6:24 PM, Andres Freund and...@2ndquadrant.com 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
On Sat, Nov 8, 2014 at 5:40 PM, David Rowley dgrowle...@gmail.com 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,
48 matches
Mail list logo
