On Mon, Mar 9, 2015 at 11:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Heikki Linnakangas wrote:
Attached is a new patch version, fixing all the little things you listed. I
believe this is pretty much ready for commit. I'm going to read it through
myself one more time before
Sorry for the dealy, I've returned to this.
Performance:
I looked on the performance gain this patch gives. For several
on-memory joins, I had gains about 3% for merge join, 5% for hash
join, and 10% for nestloop (@CentOS6), for simple 1-level joins
with aggregation similar to what
On 10/03/15 10:54, Amit Kapila wrote:
On Tue, Mar 10, 2015 at 3:03 PM, Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com wrote:
Ok now I think I finally understand what you are suggesting - you are
saying let's go over whole page while tsmnexttuple returns something,
and do the
Hello,
I found no other problem including the performance issue in the
patch attached to the last mail as far as I can understand. So
I'll mark this as ready for commit after a few days with no
objection after this comments is addressed.
- If (BTScanPosIsPinned(so-currPos)).
As I mention
On Mon, Mar 9, 2015 at 7:26 PM, Andreas Karlsson andr...@proxel.se wrote:
- I do not like how \d handles the toast tablespace. Having TOAST in
pg_default and the table in another space looks the same as if there was
no TOAST table at all. I think we should always print both tablespaces
if
On 10/03/15 04:43, Amit Kapila wrote:
On Mon, Mar 9, 2015 at 3:08 PM, Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com wrote:
On 09/03/15 04:51, Amit Kapila wrote:
On Sat, Mar 7, 2015 at 10:37 PM, Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com
Double
* Stephen Frost (sfr...@snowman.net) wrote:
--- a/src/backend/catalog/system_views.sql
+++ b/src/backend/catalog/system_views.sql
@@ -414,6 +414,11 @@ CREATE RULE pg_settings_n AS
GRANT SELECT, UPDATE ON pg_settings TO PUBLIC;
+CREATE VIEW pg_file_settings AS
+ SELECT * FROM
On Tue, Mar 10, 2015 at 3:03 PM, Petr Jelinek p...@2ndquadrant.com wrote:
On 10/03/15 04:43, Amit Kapila wrote:
On Mon, Mar 9, 2015 at 3:08 PM, Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com wrote:
On 09/03/15 04:51, Amit Kapila wrote:
On Sat, Mar 7, 2015 at 10:37
Michael Paquier wrote:
On top of that, I had an extra look at this patch, testing pg_rewind
with OSX, Linux, MinGW-32 and MSVC. Particularly on Windows, I have
been able to rewind a node and to reconnect it to a promoted standby
using this utility compiled on both MinGW-32 and MSVC (nothing
On Sat, Mar 7, 2015 at 1:06 PM, Petr Jelinek p...@2ndquadrant.com wrote:
You still duplicate the type cache code, but many other array functions do
that too so I will not hold that against you. (Maybe somebody should write
separate patch that would put all that duplicate code into common
Kohei KaiGai wrote:
The attached patch revises error message when security label
is specified on unsupported object.
getObjectTypeDescription() may be better than oid of catalog.
Agreed.
postgres=# SECURITY LABEL FOR selinux ON ROLE kaigai
postgres-# IS 'system_u:object_r:unlabeled_t:s0';
On 10 March 2015 at 19:19, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
From the another point of view, the patch looks a bit large for
the gain (for me). Addition to it, it loops by many levels.
[mark_unique_joins()]
foreach (joinlist)
[eclassjoin_is_unique_join()]
Michael Paquier wrote:
Hi all,
Today while playing with some queries I bumped into the following thing:
=# with count_query as (select generate_series(0,1) as a) select b
from count_query, generate_series(1, count_query.a) as b;
b
---
1
(1 row)
=# with count_query as (select
The attached patch revises error message when security label
is specified on unsupported object.
getObjectTypeDescription() may be better than oid of catalog.
postgres=# SECURITY LABEL FOR selinux ON ROLE kaigai
postgres-# IS 'system_u:object_r:unlabeled_t:s0';
ERROR: sepgsql provider does not
Robert Haas wrote:
On Mon, Mar 9, 2015 at 7:26 PM, Andreas Karlsson andr...@proxel.se wrote:
I think we should allow moving the indexes for consistency. With this patch
we can move everything except for TOAST indexes.
It might make sense to always put the TOAST index with the TOAST
Hi all,
Today while playing with some queries I bumped into the following thing:
=# with count_query as (select generate_series(0,1) as a) select b
from count_query, generate_series(1, count_query.a) as b;
b
---
1
(1 row)
=# with count_query as (select generate_series(0,1) as a) select b
from
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote:
I found no other problem including the performance issue in the
patch attached to the last mail as far as I can understand. So
I'll mark this as ready for commit after a few days with no
objection after this comments is addressed.
On Mon, Mar 9, 2015 at 9:08 PM, Michael Paquier wrote:
On Mon, Mar 9, 2015 at 4:29 PM, Fujii Masao wrote:
Thanks for updating the patch! Attached is the refactored version of the
patch.
Fujii-san and I had a short chat about tuning a bit the PGLZ strategy
which is now PGLZ_strategy_default in
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
Today while playing with some queries I bumped into the following thing:
=# with count_query as (select generate_series(0,1) as a) select b
from count_query, generate_series(1, count_query.a) as b;
b
---
1
(1 row)
The above
On Sat, Mar 7, 2015 at 6:40 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
pg_shadow, pg_user and pg_group were added when role support was added,
specifically for backwards compatibility. I don't believe there was
ever discussion about keeping them because filtering
Andres Freund wrote:
Rebased (fair amount of trivial conflicts due to the copyright year
bump) and attached as -MC style format-patch. If you look at the content
of the patches you can see that the diff makes more sense now.
Ah --- I just realized that the change Peter is proposing from
Michael Paquier wrote:
On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
How do we go about getting these patches pushed?
I think that one of the last point raised (by Andres) was if the
Makefiles in src/bin should depend on pgxs.mk or not. FWIW, I think as
Michael Paquier wrote:
On Wed, Mar 11, 2015 at 10:06 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Now, the pushing plan was to have the stuff of pg_upgrade done in a
separate commit. Note that I am fine helping out wrapping up things
particularly on Windows if that helps.
I vote
On Tue, Mar 10, 2015 at 5:53 PM, Jim Nasby jim.na...@bluetreble.com wrote:
I don't think we need both array_offset and array_offset_start; can't both
SQL functions just call one C function?
Not if you want the opr_sanity tests to pass.
(But I'm seriously starting to wonder if that's actually a
I'm okay with any of the proposed designs or with dropping the idea. Closing
the loop on a few facts:
On Sat, Mar 07, 2015 at 04:34:41PM -0600, Jim Nasby wrote:
If we go that route, does it still make sense to explicitly use
repalloc_huge? It will just cut over to that at some point (128M?)
2015-03-11 0:24 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On the technical side, I do agree that the requirement to allocate and
zero an array for every new simple expression is unfortunate, but I'm
not convinced that repeatedly invoking the
On Tue, Mar 10, 2015 at 9:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Do we have consensus on doing this? Should we have the warning on
by default, or off?
I vote for defaulting the warning to off. If that proves
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
david.g.johns...@gmail.com wrote:
On Tue, Mar 10, 2015 at 9:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Do we have consensus on doing this? Should we have the warning
On Tue, Mar 10, 2015 at 12:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Andres Freund and...@anarazel.de writes:
On February 26, 2015 10:29:18 PM CET, Peter Eisentraut pete...@gmx.net
wrote:
My suggestion was to treat this like the standard_conforming_string
change. That is, warn for
On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
david.g.johns...@gmail.com wrote:
I would vote for Auto meaning On in the .0 release.
I don't think users will appreciate an auto
On Tue, Mar 10, 2015 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Was there any consideration given to whether ruleutils should start
printing NamedArgExprs with =? Or do we think that needs to wait?
I have to admit that I didn't consider that.
On Wed, Mar 11, 2015 at 12:00 PM, Peter Eisentraut pete...@gmx.net wrote:
Here is a rebase of my previous patch set. I have integrated the
various minor fixes from Michael and Andres. I have dropped moving
pg_standby, because no one seemed to like that.
I wasn't able to do anything with
Here is a rebase of my previous patch set. I have integrated the
various minor fixes from Michael and Andres. I have dropped moving
pg_standby, because no one seemed to like that.
I wasn't able to do anything with Michael's Mkvcbuild.pm patch, since
that appeared to include a significant
On Mon, Mar 9, 2015 at 9:08 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Mar 9, 2015 at 4:29 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Mar 5, 2015 at 10:08 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Mar 5, 2015 at 9:14 PM, Syed, Rahila
On Tue, Mar 10, 2015 at 8:07 PM, Michael Paquier wrote:
I'd rather vote for having the Windows-side stuff integrated with each
patch. Mind if I rebase what you just sent with the Windows things
added?
And here is the rebased series with the MSVC changes included for each
module in its
On Wed, Mar 11, 2015 at 10:06 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Michael Paquier wrote:
On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
How do we go about getting these patches pushed?
I think that one of the last point raised (by Andres)
On Mon, Mar 09, 2015 at 03:06:24PM -0400, Robert Haas wrote:
What I do care about
is that we as a project have to at some point be willing to begin
closing the spigot on new patches and focusing on polishing and
shipping the patches we've already got. I think it's perfectly
reasonable to
On Wed, Mar 11, 2015 at 3:44 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 03/10/2015 07:46 AM, Amit Kapila wrote:
Isn't it possible incase of async replication that old cluster has
some blocks which new cluster doesn't have, what will it do
in such a case?
Sure, that's certainly
On Sun, Mar 08, 2015 at 08:19:39PM +0900, Michael Paquier wrote:
So I am planning to seriously focus soon on this stuff, basically
using the TAP tests as base infrastructure for this regression test
suite. First, does using the TAP tests sound fine?
Yes.
On the top of my mind I got the
On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be added to it IMHO.
The = operator was deprecated for several years so it should not be too
controversial
Kevin Grittner kgri...@ymail.com wrote:
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp wrote:
Would you mind rewriting the comment there like this?
- /* The buffer is still pinned, but not locked. Lock it now. */
+ /* I still hold the pin on the buffer, but not locked. Lock it now. */
On 10/03/15 17:01, Pavel Stehule wrote:
2015-03-10 16:50 GMT+01:00 Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com mailto:robertmh...@gmail.com
writes:
Committed with a few documentation tweaks.
Was there any consideration given to
Tom Lane wrote:
Do we have consensus on doing this? Should we have the warning on
by default, or off?
This is the tough decision, isn't it. I had thought it would default to
off and people would only turn it on in their testing procedure prior to
the actual upgrade of the production systems,
2015-03-10 16:50 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be
Hello,
My function neeeds to call a third-party library which would create a state and
then that state should be kept for the duration of the current query. The
library can deallocate that state in a correct way.
I understand that fn_extra is normally used for this and usually the state is
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 19, 2015 at 3:15 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I am marking this as Ready For Committer, the patch is trivial and works
as expected, there is nothing to be added to it IMHO.
The = operator was deprecated for several
I wrote:
Andres Freund and...@anarazel.de writes:
On February 26, 2015 10:29:18 PM CET, Peter Eisentraut pete...@gmx.net
wrote:
My suggestion was to treat this like the standard_conforming_string
change. That is, warn for many years before changing.
I don't think scs is a good example to
On 3/10/15 1:12 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 12:45 PM, David G. Johnston
david.g.johns...@gmail.com wrote:
I would vote for Auto meaning On in the .0 release.
I don't think users will appreciate an auto value whose meaning might
Stephen, thanks for the comments.
Stephen Frost wrote:
I don't really care for how all the get_object_address stuff uses lists
for arguments instead of using straight-forward arguments, but it's how
it's been done and I can kind of see the reasoning behind it. I'm not
following why you're
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Anyway I'm not hot on changing anything here. It's a bit cumbersome an
interface to use, but it's not excessively exposed to the user unless
they use event triggers, and even then it is perfectly reliable anyhow.
Works for me.
Peter Eisentraut pete...@gmx.net writes:
Well, I point again to standards_conforming_strings: Leave the warning
off for one release (or more), then default to on for one (or more),
then change the behavior.
We can change the timeline, but I don't think the approach was unsound.
I'm not
On Tue, Mar 3, 2015 at 7:47 PM, Amit Kapila amit.kapil...@gmail.com wrote:
I have modified the patch to introduce a Funnel node (and left child
as PartialSeqScan node). Apart from that, some other noticeable
changes based on feedback include:
a) Master backend forms and send the planned stmt
On Mon, Dec 22, 2014 at 7:34 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Dec 22, 2014 at 5:50 AM, Robert Haas robertmh...@gmail.com wrote:
Looking over the latest patch, I think we could simplify the code so
that you don't need multiple FuzzyAttrMatchState objects. Instead of
creating
2015-03-10 19:50 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2015-03-10 15:30 GMT+01:00 Robert Haas robertmh...@gmail.com:
I am sure in agreement with the idea that it would be good to factor
out the common typecache code (for setting up my_extra).
On Tue, Mar 10, 2015 at 9:41 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
And perhaps make it an ereport also, with errcode etc.
Yeah, definitely.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
On Tue, Mar 10, 2015 at 3:43 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I have not good feeling about it too. If we would to enhance this are, we
probably need a specific flinfo field and flags to specify more precious the
context of cached informations. my_extra should be reserved for
On Tue, Mar 10, 2015 at 11:28 AM, Robert Haas robertmh...@gmail.com wrote:
I'm prepared to commit this version if nobody finds a problem with it.
It passes the additional regression tests you wrote.
Looks good to me. Thanks.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list
2015-03-10 15:30 GMT+01:00 Robert Haas robertmh...@gmail.com:
On Sat, Mar 7, 2015 at 1:06 PM, Petr Jelinek p...@2ndquadrant.com wrote:
You still duplicate the type cache code, but many other array functions
do
that too so I will not hold that against you. (Maybe somebody should
write
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 10, 2015 at 1:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Another possibility is to leave it on through beta testing with the intent
to turn it off before 9.5 final; that would give us more data about
whether there are real issues than we're
2015-03-10 19:02 GMT+01:00 Tom Lane t...@sss.pgh.pa.us:
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Presumably we are going to change it at some point; maybe we
should just do it rather than waiting another 5 years.
+1
It has been deprecated long
On Tue, Mar 10, 2015 at 2:32 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
1. funcname_signature_string
2. get_rule_expr
Thanks. Patch attached. I'll commit this if there are no objections.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Pavel Stehule pavel.steh...@gmail.com writes:
2015-03-10 15:30 GMT+01:00 Robert Haas robertmh...@gmail.com:
I am sure in agreement with the idea that it would be good to factor
out the common typecache code (for setting up my_extra). Any chance
we get a preliminary patch that does that
On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
This thread seems to have died off without any clear resolution. I'd
hoped somebody would try the patch on some nontrivial application to
see if it broke anything or caused any warnings, but it doesn't seem
like
Alex Hunsaker bada...@gmail.com writes:
On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This thread seems to have died off without any clear resolution. I'd
hoped somebody would try the patch on some nontrivial application to
see if it broke anything or caused any
On Mon, Mar 9, 2015 at 7:32 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Attached is a new patch version, fixing all the little things you listed.
I believe this is pretty much ready for commit. I'm going to read it
through myself one more time before committing, but I don't have anything
mind
At 2015-01-15 14:32:45 +0100, and...@2ndquadrant.com wrote:
What I am thinking of is that, currently, if you start the server for
initial loading with fsync=off, and then restart it, you're open to
data loss. So when the current config file setting is changed from off
to on, we should fsync
Hello,
If you manually set RPADDING 2 in trgm.h, then it will, but the
allocation probably should use LPADDING/RPADDING to get it right, rather
than assume the max values.
Yes you are right. For RPADDING = 2, the current formula is suitable but for
RPADDING =1, a lot of extra space is
On Tue, Mar 10, 2015 at 10:23 AM, Haribabu Kommi kommi.harib...@gmail.com
wrote:
On Tue, Mar 10, 2015 at 3:09 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
I have currently modelled it based on existing rescan for seqscan
(ExecReScanSeqScan()) which means it will begin the scan again.
On 3/10/15 10:53 AM, Jim Nasby wrote:
On 3/10/15 9:30 AM, Robert Haas wrote:
On Sat, Mar 7, 2015 at 1:06 PM, Petr Jelinek p...@2ndquadrant.com
wrote:
You still duplicate the type cache code, but many other array
functions do
that too so I will not hold that against you. (Maybe somebody should
On 03/10/2015 07:46 AM, Amit Kapila wrote:
On Mon, Mar 9, 2015 at 7:32 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Attached is a new patch version, fixing all the little things you listed.
I believe this is pretty much ready for commit. I'm going to read it
through myself one more time
On 3/10/15 2:43 PM, Pavel Stehule wrote:
There is not all that much commonality; many functions don't bother to
populate all of the ArrayMetaState fields because they don't need all of
them. (The ones you quote don't, in fact.) You are either going to end
up with a subroutine
Jim Nasby jim.na...@bluetreble.com writes:
That said, this pattern with fn_extra is repeated a lot, even just in
the backend (not counting contrib or extensions). It would be nice if
there was generic support for this.
What do you mean by generic support? Most of those functions are doing
On 2/22/15 5:19 AM, Pavel Stehule wrote:
2015-02-22 3:00 GMT+01:00 Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com:
On 28/01/15 08:15, Pavel Stehule wrote:
2015-01-28 0:01 GMT+01:00 Jim Nasby jim.na...@bluetreble.com
mailto:jim.na...@bluetreble.com
Hello,
I have some minor comments
The comments have been implemented in the attached patch.
I think that extra parenthesis should be used for the first expression
with BKPIMAGE_HAS_HOLE.
Parenthesis have been added to improve code readability.
Thank you,
Rahila Syed
On Mon, Mar 9, 2015 at
ERRCODE_FEATURE_NOT_SUPPORTED is suitable error code here.
Please see the attached one.
Thanks,
2015-03-11 4:34 GMT+09:00 Robert Haas robertmh...@gmail.com:
On Tue, Mar 10, 2015 at 9:41 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
And perhaps make it an ereport also, with errcode etc.
On Tue, Mar 10, 2015 at 10:30 PM, Stephen Frost sfr...@snowman.net wrote:
Yeah, it's simply because we can turn one into an implicit LATERAL, but
we can't do that for the other.
Ah, yes, thanks. I forgot that it was changed to an implicit LATERAL.
Just wondering where my mind was yesterday
Robert Haas robertmh...@gmail.com writes:
On the technical side, I do agree that the requirement to allocate and
zero an array for every new simple expression is unfortunate, but I'm
not convinced that repeatedly invoking the hook-function is a good way
to solve that problem. Calling the
On 3/9/15 9:43 PM, Sawada Masahiko wrote:
On Fri, Mar 6, 2015 at 11:07 AM, Jim Nasby jim.na...@bluetreble.com wrote:
On 3/2/15 10:58 AM, Sawada Masahiko wrote:
On Wed, Feb 25, 2015 at 4:58 PM, Jim Nasby jim.na...@bluetreble.com
wrote:
On 2/24/15 8:28 AM, Sawada Masahiko wrote:
According
Thank you for the correction.
At Wed, 4 Mar 2015 01:01:48 -0600, Jim Nasby jim.na...@bluetreble.com wrote
in 54f6addc.8030...@bluetreble.com
On 3/3/15 8:04 PM, Kyotaro HORIGUCHI wrote:
Note: The OID alias types don't sctrictly comply the transaction
isolation rules so do not use them
Hi, the attached is the v5 patch.
- Do feGetCurrentTimestamp() only when necessary.
- Rebased to current master
At Mon, 2 Mar 2015 20:21:36 +0900, Fujii Masao masao.fu...@gmail.com wrote in
cahgqgwg1tjhpg03ozgwokxt5wyd5v4s3hutgsx7rotbhhnj...@mail.gmail.com
On Tue, Feb 24, 2015 at 6:44 PM,
On Tue, Mar 10, 2015 at 10:48 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andres Freund wrote:
Rebased (fair amount of trivial conflicts due to the copyright year
bump) and attached as -MC style format-patch. If you look at the content
of the patches you can see that the diff makes
82 matches
Mail list logo
