From: pgsql-hackers-ow...@postgresql.org [pgsql-hackers-ow...@postgresql.org]
on behalf of Amit kapila [amit.kap...@huawei.com]
Sent: Monday, October 15, 2012 7:28 PM
To: robertmh...@gmail.com; j...@agliodbs.com
Cc: pgsql-hackers@postgresql.org
Subject: [HACKERS] Re: patch submission: truncate
Thank you for comment.
I think this patch should be applied for 9.2.2 and 9.1.7.
Looks good to me, though I don't think the source code comment needs
to be updated in the way the patch does.
Ok, the patch for walsender.c becomes 1 liner, quite simple.
However, I've forgotten to treat
Ouch! I'm sorry to have sent truly buggy version, please abandon
v2 patch sent just before.
Added include access/transam.h to syncrep.c and corrected the
name of XLByteEQ.
Thank you for comment.
I think this patch should be applied for 9.2.2 and 9.1.7.
Looks good to me, though I don't
On 18 October 2012 19:48, Simon Riggs si...@2ndquadrant.com wrote:
On 18 October 2012 10:20, Andres Freund and...@2ndquadrant.com wrote:
On Thursday, October 18, 2012 06:12:02 AM Kevin Grittner wrote:
Kevin Grittner wrote:
Hmm. The comment is probably better now, but I've been re-checking
On 16 October 2012 04:49, Peter Eisentraut pete...@gmx.net wrote:
On Mon, 2012-10-15 at 11:14 -0700, Josh Berkus wrote:
I'd be in favor of a warning on create index.
Only if you can turn it off, please.
But I don't think a warning is appropriate if the statement does exactly
what the user
On Fri, October 19, 2012 11:00, Kohei KaiGai wrote:
I confirmed I could apply the latest patch cleanly.
FWIW, I spent a few sessions (amounting to a few hours) trying to break, or get
past SET ROW LEVEL
SECURITY and have not yet succeeded. So far so good.
(I haven't looked at code)
Erik
On 10/19/2012 04:26 AM, Ants Aasma wrote:
On Thu, Oct 18, 2012 at 10:03 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
Hmm. Maybe we should think of implementing this as REMOTE TABLE, that
is a table which gets no real data stored locally but all insert got through
WAL
and are replayed as real
Sorry for delayed response.
On 2012/10/11, at 5:28, Tom Lane t...@sss.pgh.pa.us wrote:
So I think we can't remove that functionality just yet. What we could
do is adjust postgresql_fdw_validator to throw a WARNING that it's
deprecated. This wouldn't prevent it from being used during
On Thursday, October 18, 2012 8:49 PM Fujii Masao wrote:
On Wed, Oct 17, 2012 at 8:46 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Monday, October 15, 2012 3:43 PM Heikki Linnakangas wrote:
On 13.10.2012 19:35, Fujii Masao wrote:
On Thu, Oct 11, 2012 at 11:52 PM, Heikki Linnakangas
On 10/18/2012 09:18 PM, Christopher Browne wrote:
On Thu, Oct 18, 2012 at 2:56 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
* works as table on INSERTS up to inserting logical WAL record describing
the
insert but no data is inserted locally.
with all things that follow from the local table
On 18 October 2012 18:33, Josh Berkus j...@agliodbs.com wrote:
All we're discussing is moving a successful piece of software into
core, which has been discussed for years at the international
technical meetings we've both been present at. I think an open
viewpoint on the feasibility of that
Thursday, October 18, 2012 7:55 PM Alvaro Herrera wrote:
Amit Kapila wrote:
For the Patch, Trim trailing NULL columns, I have provided the
performance
data required
and completed the review. There are only few review comments which can
be
addressed.
So is it possible that I
- Цитат от Hannu Krosing (ha...@krosing.net), на 19.10.2012 в
14:17 - On 10/19/2012 04:26 AM, Ants Aasma wrote:
On Thu, Oct 18, 2012 at 10:03 PM, Hannu Krosing wrote:
Hmm. Maybe we should think of implementing this as REMOTE TABLE, that
is a table which gets no real data stored
On Fri, Oct 19, 2012 at 5:46 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Ouch! I'm sorry to have sent truly buggy version, please abandon
v2 patch sent just before.
Added include access/transam.h to syncrep.c and corrected the
name of XLByteEQ.
Thanks for updating the patch!
I've have a PostgreSQL database cluster that I've continually upgraded
from 7.1 to 9.1 without problems using pg_dumpall and psql. When
migrating to 9.2, I decided to change the default encoding for the
database cluster from SQL_ASCII to UTF8. When I went to restore my
database backup (created
On Oct 2 the latest crypto hash function was announced by NIST [1]. I suggest
that we include the new hash algorithm in pgcrypto for 9.3.
The Keccak site also has a reference implementation in C and Assembler [2]. It
may take some effort to integrate the reference implementation as it contains
On 10/18/2012 09:10 PM, Josh Berkus wrote:
Daniel,
I'm not going to disagree with that, I only feel it's reasonable to
ask why those who react so strongly against deprecation why they think
what they do, and receive a clinical response, because not everyone
has seen those use cases. My level
On Thu, Oct 18, 2012 at 04:58:20PM -0300, Alvaro Herrera wrote:
Here is version 22 of this patch. This version contains fixes to issues
reported by Andres, as well as a rebase to latest master.
I scanned this for obvious signs of work left to do. It contains numerous XXX
and FIXME comments.
On Tue, Sep 4, 2012 at 6:25 AM, Amit kapila amit.kap...@huawei.com wrote:
On Tuesday, September 04, 2012 12:42 AM Jeff Janes wrote:
On Mon, Sep 3, 2012 at 7:15 AM, Amit kapila amit.kap...@huawei.com wrote:
This patch is based on below Todo Item:
Consider adding buffers the background writer
2012/10/19 4:36, Robert Haas wrote:
On Tue, Oct 16, 2012 at 11:31 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
A flight-recorder must not be disabled. Collecting
performance data must be top priority for DBA.
This analogy is inapposite, though, because a flight recorder rarely
crashes the
2012/10/19 23:48, Fujii Masao wrote:
On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Satoshi Nagayasu sn...@uptime.jp writes:
(2012/10/14 13:26), Fujii Masao
Rushabh Lathia of the EnterpriseDB development team and I have been
doing some testing of the extended query protocol and have found a
case where it causes an assertion failure. Here's how to reproduce:
1. Apply the attached patch to teach psql how to use the extended
query protocol. Compile,
On Thu, Oct 18, 2012 at 11:20 AM, Andres Freund and...@2ndquadrant.com wrote:
On Thursday, October 18, 2012 04:47:12 PM Robert Haas wrote:
On Tue, Oct 16, 2012 at 7:30 AM, Andres Freund and...@2ndquadrant.com
wrote:
On Thursday, October 11, 2012 01:02:26 AM Peter Geoghegan wrote:
The design
On 19 October 2012 17:19, Robert Haas robertmh...@gmail.com wrote:
Rushabh Lathia of the EnterpriseDB development team and I have been
doing some testing of the extended query protocol and have found a
case where it causes an assertion failure. Here's how to reproduce:
1. Apply the attached
On Friday, October 19, 2012 06:38:30 PM Robert Haas wrote:
On Thu, Oct 18, 2012 at 11:20 AM, Andres Freund and...@2ndquadrant.com
wrote:
2) We need to decide whether a HEAP[1-2]_* record did catalog changes
when building/updating snapshots. Unfortunately we also need to do this
*before* we
On Friday, October 19, 2012 06:41:27 PM Peter Geoghegan wrote:
On 19 October 2012 17:19, Robert Haas robertmh...@gmail.com wrote:
Rushabh Lathia of the EnterpriseDB development team and I have been
doing some testing of the extended query protocol and have found a
case where it causes an
Satoshi Nagayasu sn...@uptime.jp writes:
Ok, I guess we have reached the consensus to have
some flight-recorder. Right?
I remain unconvinced. I think the argument that this will promote
novice understanding is complete hogwash: making any sense of
lwlock-level stats will require deep PG
On Friday, October 19, 2012 06:41:27 PM Peter Geoghegan wrote:
On 19 October 2012 17:19, Robert Haas robertmh...@gmail.com wrote:
Rushabh Lathia of the EnterpriseDB development team and I have been
doing some testing of the extended query protocol and have found a
case where it causes an
On Fri, Oct 19, 2012 at 11:52 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
I agree with that such performance instrument needs to be
improved if it has critical performance issue against
production environment. So, I'm still looking for a better
implementation to decrease performance impact.
On 19 October 2012 19:01, Andres Freund and...@2ndquadrant.com wrote:
Btw, do you plan to submit that psql patch at some point? I repeatedly wished
to be able to use the extended protocol without writing code or misusing
pgbench exactly to test stuff like this.
+1
--
Peter Geoghegan
If we describe a queue as something you put stuff in at one end and
get it out in same or some other specific order at the other end, then
WAL _is_ a queue when you use it for replication (if you just write to it,
then it is Log, if you write and read, it is Queue)
For that matter, WAL is a
On Fri, Oct 19, 2012 at 2:01 PM, Andres Freund and...@2ndquadrant.com wrote:
On Friday, October 19, 2012 06:41:27 PM Peter Geoghegan wrote:
On 19 October 2012 17:19, Robert Haas robertmh...@gmail.com wrote:
Rushabh Lathia of the EnterpriseDB development team and I have been
doing some
On Thu, Oct 18, 2012 at 12:31 PM, Murphy, Kevin murph...@email.chop.edu wrote:
It might be nice for psql to have a 'htmlcaption' boolean pset option that
would wrap the provided title/caption, if any, in a caption tag in the HTML
report output, when using html format.
Motivation:
When I
Kevin Grittner escribió:
Tom Lane t...@sss.pgh.pa.us wrote:
Also, it doesn't appear that we ever got around to preparing
documentation updates, but I think we definitely need some if
we're going to start throwing errors for things that used to be
allowed. Since Kevin has the most field
On Thu, Oct 18, 2012 at 11:19 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Robert Haas escribió:
On Tue, Oct 16, 2012 at 10:31 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Any comments on this?
I'm not sure I'd want to back-patch this, since it is a behavior
change, but I do
2012/10/20 2:45, Tom Lane wrote:
Satoshi Nagayasu sn...@uptime.jp writes:
Ok, I guess we have reached the consensus to have
some flight-recorder. Right?
I remain unconvinced. I think the argument that this will promote
novice understanding is complete hogwash: making any sense of
Hitoshi Harada umi.tan...@gmail.com writes:
On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not terribly comfortable with trying to use a PG_TRY block to catch
an OOM error - there are too many ways that could break, and this code
path is by definition not very
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 19, 2012 at 2:01 PM, Andres Freund and...@2ndquadrant.com wrote:
Simple fix attached.
Looks reasonable to me, but I'm not terribly familiar with this code.
Tom, any comments?
Will look shortly.
regards, tom lane
On Fri, Oct 19, 2012 at 7:17 AM, Shigeru HANADA
shigeru.han...@gmail.com wrote:
However, I'm not sure where that leaves us with respect to the original
goal of getting rid of use of that function name. Thoughts?
Sorry, I had misunderstood the problem :-(. In my proposal, postgresql_fdw
uses
Andres Freund and...@2ndquadrant.com writes:
Simple fix attached.
Are you sure this isn't just moving the failure conditions around?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 10/18/2012 10:26 PM, Tom Lane wrote:
Another possibility is to forget about the column constraint ELEMENT
REFERENCES syntax, and only support the table-constraint syntax with
ELEMENT inside the column list --- I've not checked, but I think that
syntax doesn't have any ambiguity problems.
On Friday, October 19, 2012 09:05:30 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Simple fix attached.
Are you sure this isn't just moving the failure conditions around?
Don't think so. Its not that easy to follow though...
The CREATE OptTemp TABLE create_as_target AS
On Fri, Oct 19, 2012 at 11:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not terribly comfortable with trying to use a PG_TRY block to catch
an OOM error - there are too many ways
On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
As you can see, in the case of rewrite it takes us back 7 1/2 years. I know
this is a *very* rough measure, but it still tends to indicate to me that
the maintenance burden isn't terribly high.
That's a pretty neat
Andrew Dunstan and...@dunslane.net writes:
I'm late to this party, so I apologize in advance if this has already
been considered, but do we actually need a special syntax? Can't we just
infer that we have one of these when the referring column is an array
and the referenced column is of the
Hitoshi Harada umi.tan...@gmail.com writes:
OK. Looks better. But nentries should be bogus a little now?
No, I think it's fine as is. Essentially this logic says attempt to
split when the new insertion would make us go over the target fill
factor, whereas the old logic split when the
On 10/19/2012 03:55 PM, Tom Lane wrote:
This thought also crystallizes something else that had been bothering me,
which is that ELEMENT alone is a pretty bad choice of syntax because
it entirely fails to make clear which of these semantics is meant.
I'm tempted to propose that we use
On Fri, Oct 19, 2012 at 3:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That doesn't get us any closer to having a working column-constraint
syntax unfortunately, because EACH is not a reserved word either
so EACH ELEMENT REFERENCES still isn't gonna work. I'm getting
more willing to give up on
On Thu, Oct 18, 2012 at 3:18 PM, Gezeala M. Bacuño II geze...@gmail.com wrote:
You may disable full_page_writes, but as you can see from my previous
post, disabling it did not do the trick. My zfs' USED property
continues to increase.
I think we need somebody to compile with WAL_DEBUG defined
Andrew Dunstan and...@dunslane.net writes:
On 10/19/2012 03:55 PM, Tom Lane wrote:
That doesn't get us any closer to having a working column-constraint
syntax unfortunately, because EACH is not a reserved word either
so EACH ELEMENT REFERENCES still isn't gonna work. I'm getting
more willing
Robert Haas robertmh...@gmail.com writes:
This is a little sneaky, but I presume you only get the grammar
conflict if you try to sneak the each or element or each element
or whatever-you-call-it designator in BEFORE the column name. So what
about just putting it afterwards? Something like
On 16 October 2012 12:30, Andres Freund and...@2ndquadrant.com wrote:
Here's the first version of the promised document. I hope it answers most of
the questions.
This makes for interesting reading.
So, I've taken a closer look at the snapshot building code in light of
this information. What
On Fri, Oct 19, 2012 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It looks like we could support
CREATE TABLE t1 (c int[] REFERENCES BY ELEMENT t2);
but (1) this doesn't seem terribly intelligible to me, and
(2) I don't see how we modify that if we want to provide
That's a pretty neat one-liner. However... in my view, the real cost
of rules is that they are hard to support as we add new features to
SQL. I believe we already decided to punt on making them work with
CTEs... and maybe one other case? I don't really remember the details
any more, but
Claudio Freire klaussfre...@gmail.com writes:
What about something more generic?
CREATE TABLE tname ( cname type [(expr)] REFERENCES t2name
[(t2expr)] )
Meaning, if expr is missing, it's taken expr = cname, if not,
it's the result of that expression the one that references the target
Andres Freund and...@2ndquadrant.com writes:
What about sticking a WHERE in there? I.e. FOREIGN KEY (foo, WHERE EACH
ELEMENT OF bar) ...
Well, we don't really need it in the table-constraint case. The
column-constraint case is the sticking point.
I tested, and indeed this seems to work:
On 19 October 2012 22:03, Josh Berkus j...@agliodbs.com wrote:
Unless the easiest way to implement MERGE is to extend RULEs.
FWIW, I'd say that's probably about the hardest possible way to
implement MERGE, assuming that we prioritise providing robust UPSERT
support, as I strongly feel we should.
On 10/19/2012 04:40 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 10/19/2012 03:55 PM, Tom Lane wrote:
That doesn't get us any closer to having a working column-constraint
syntax unfortunately, because EACH is not a reserved word either
so EACH ELEMENT REFERENCES still
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 19, 2012 at 2:01 PM, Andres Freund and...@2ndquadrant.com wrote:
Btw, do you plan to submit that psql patch at some point? I repeatedly wished
to be able to use the extended protocol without writing code or misusing
pgbench exactly to test
Hi,
On Friday, October 19, 2012 10:53:06 PM Peter Geoghegan wrote:
On 16 October 2012 12:30, Andres Freund and...@2ndquadrant.com wrote:
Here's the first version of the promised document. I hope it answers most
of the questions.
This makes for interesting reading.
Thanks.
Step 14 *is*
Andres Freund and...@2ndquadrant.com writes:
So as far as I can see the new logic is correct? A quick look test seems to
confirm that.
I think the real problem here is just that the code was trying to be too
specific, and while your version might be more correct it's not doing
anything to fix
On Saturday, October 20, 2012 12:05:15 AM Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 19, 2012 at 2:01 PM, Andres Freund and...@2ndquadrant.com
wrote:
Btw, do you plan to submit that psql patch at some point? I repeatedly
wished to be able to use the extended
On Saturday, October 20, 2012 12:37:54 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
So as far as I can see the new logic is correct? A quick look test
seems to confirm that.
I think the real problem here is just that the code was trying to be too
specific, and while
Jeremy Evans c...@jeremyevans.net writes:
I've have a PostgreSQL database cluster that I've continually upgraded
from 7.1 to 9.1 without problems using pg_dumpall and psql. When
migrating to 9.2, I decided to change the default encoding for the
database cluster from SQL_ASCII to UTF8. When I
On Sat, Oct 20, 2012 at 1:03 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
2012/10/19 23:48, Fujii Masao wrote:
On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu sn...@uptime.jp
wrote:
2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
On Fri, Oct 19, 2012 at 6:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's hard to visualize a use for this except for testing purposes, but
that might be sufficient reason to have it. One thing that would be
pretty cool is to be able to run the regression tests in extended
protocol.
Yes,
On 10/19/2012 09:05 PM, Robert Haas wrote:
On Fri, Oct 19, 2012 at 6:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's hard to visualize a use for this except for testing purposes, but
that might be sufficient reason to have it. One thing that would be
pretty cool is to be able to run the
Andres Freund and...@2ndquadrant.com writes:
On Saturday, October 20, 2012 12:05:15 AM Tom Lane wrote:
(such as the current query showing up in pg_cursors --- maybe we should
prevent that?)
I don't really see an argument for preventing that.
Well, the reason it seems peculiar to me is that
68 matches
Mail list logo
