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, thou
2012/10/18 Alvaro Herrera :
> Kohei KaiGai escribió:
>> The revised patch fixes the problem that Daen pointed out.
>
> Robert, would you be able to give this latest version of the patch a
> look?
>
> (KaiGai, does it still apply cleanly? If not, please submit a rebased
> version.)
>
I confirmed I c
On 18 October 2012 19:48, Simon Riggs wrote:
> On 18 October 2012 10:20, Andres Freund 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
>>> > the code, and I think my actual
On 16 October 2012 04:49, Peter Eisentraut 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 wanted.
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 Ri
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 locally but all insert got through
WAL
and are replayed as real inserts on slave side.
Sorry for delayed response.
On 2012/10/11, at 5:28, Tom Lane 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 dump/reload
> scenarios,
On Thursday, October 18, 2012 8:49 PM Fujii Masao wrote:
On Wed, Oct 17, 2012 at 8:46 PM, Amit Kapila 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
>> > wrote:
>> >> Ok,
On 10/18/2012 09:18 PM, Christopher Browne wrote:
On Thu, Oct 18, 2012 at 2:56 PM, Hannu Krosing 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 having no data
- uni
On 18 October 2012 18:33, Josh Berkus 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 would be re
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 t
- Цитат от 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 locally
On Fri, Oct 19, 2012 at 5:46 PM, Kyotaro HORIGUCHI
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! This looks good to me.
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 us
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
s
On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu wrote:
> 2012/10/16 2:40, Jeff Janes wrote:
>>
>> On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
>>>
>>> Satoshi Nagayasu writes:
(2012/10/14 13:26), Fujii Masao wrote:
>
> The tracing lwlock usage seems to still cause a smal
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 wrote:
> On Tuesday, September 04, 2012 12:42 AM Jeff Janes wrote:
> On Mon, Sep 3, 2012 at 7:15 AM, Amit kapila wrote:
>>> This patch is based on below Todo Item:
>>
>>> Consider adding buffers the background writer finds reusable to the free
>>> list
2012/10/19 4:36, Robert Haas wrote:
On Tue, Oct 16, 2012 at 11:31 AM, Satoshi Nagayasu 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 aircraft. If it did
2012/10/19 23:48, Fujii Masao wrote:
On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu wrote:
2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
Satoshi Nagayasu writes:
(2012/10/14 13:26), Fujii Masao wrote:
The tracing lwlock usage seems to still ca
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, in
On Thu, Oct 18, 2012 at 11:20 AM, Andres Freund wrote:
> On Thursday, October 18, 2012 04:47:12 PM Robert Haas wrote:
>> On Tue, Oct 16, 2012 at 7:30 AM, Andres Freund
> wrote:
>> > On Thursday, October 11, 2012 01:02:26 AM Peter Geoghegan wrote:
>> >> The design document [2] really just explains
On 19 October 2012 17:19, Robert Haas 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 patch to teach ps
On Friday, October 19, 2012 06:38:30 PM Robert Haas wrote:
> On Thu, Oct 18, 2012 at 11:20 AM, Andres Freund
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 built the first
On Friday, October 19, 2012 06:41:27 PM Peter Geoghegan wrote:
> On 19 October 2012 17:19, Robert Haas 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
Satoshi Nagayasu 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 understanding, not
On Friday, October 19, 2012 06:41:27 PM Peter Geoghegan wrote:
> On 19 October 2012 17:19, Robert Haas 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
On Fri, Oct 19, 2012 at 11:52 AM, Satoshi Nagayasu 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.
Frankly, I th
On 19 October 2012 19:01, Andres Freund 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 http://www.2ndQuadrant
> 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, W
On Fri, Oct 19, 2012 at 2:01 PM, Andres Freund wrote:
> On Friday, October 19, 2012 06:41:27 PM Peter Geoghegan wrote:
>> On 19 October 2012 17:19, Robert Haas wrote:
>> > Rushabh Lathia of the EnterpriseDB development team and I have been
>> > doing some testing of the extended query protocol an
On Thu, Oct 18, 2012 at 12:31 PM, Murphy, Kevin 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 use:
>
> \pset
Kevin Grittner escribió:
> Tom Lane 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 experience
On Thu, Oct 18, 2012 at 11:19 AM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Oct 16, 2012 at 10:31 AM, Guillaume Lelarge
>> 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 think it's probably a good idea to
2012/10/20 2:45, Tom Lane wrote:
> Satoshi Nagayasu 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
Hitoshi Harada writes:
> On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane 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 testable. I think moving up the
>> expa
Robert Haas writes:
> On Fri, Oct 19, 2012 at 2:01 PM, Andres Freund 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
--
Sent via pgsql-hackers mailing lis
On Fri, Oct 19, 2012 at 7:17 AM, Shigeru HANADA
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 public schema, as o
Andres Freund 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:
http://www.postgresql.org/mail
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.
Or
On Friday, October 19, 2012 09:05:30 PM Tom Lane wrote:
> Andres Freund 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 EXECUTE " producti
On Fri, Oct 19, 2012 at 11:40 AM, Tom Lane wrote:
> Hitoshi Harada writes:
>> On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane 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 def
On Fri, Oct 19, 2012 at 10:29 AM, Andrew Dunstan 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 one-liner. However.
Andrew Dunstan 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 base type of th
Hitoshi Harada 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 just-completed insertion
r
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 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 having a colum
On Thu, Oct 18, 2012 at 3:18 PM, Gezeala M. Bacuño II 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 and try to
repr
Andrew Dunstan 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 to give
Robert Haas 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 this:
> FOREI
On 16 October 2012 12:30, Andres Freund 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 follows are my thoughts
On Fri, Oct 19, 2012 at 5:48 PM, Tom Lane 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
> at-least-one-match semantics
On Friday, October 19, 2012 09:55:10 PM Tom Lane wrote:
> FOREIGN KEY (foo, EACH ELEMENT OF bar) REFERENCES ...
>
> which is certainly more verbose than just "ELEMENT" but I think it
> makes it clearer that each array element is required to have a match
> separately. If we ever implemente
> 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, b
Claudio Freire writes:
> What about something more generic?
> CREATE TABLE ( [()] REFERENCES
> [()] )
> Meaning, if is missing, it's taken = , if not,
> it's the result of that expression the one that references the target
> table.
Doesn't seem terribly sensible as a column constraint: a
Andres Freund 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:
CREATE TABLE t1
On 19 October 2012 22:03, Josh Berkus 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.
--
Peter Geogh
On 10/19/2012 04:40 PM, Tom Lane wrote:
Andrew Dunstan 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'
Robert Haas writes:
> On Fri, Oct 19, 2012 at 2:01 PM, Andres Freund 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.
> I didn't think it
Hi,
On Friday, October 19, 2012 10:53:06 PM Peter Geoghegan wrote:
> On 16 October 2012 12:30, Andres Freund 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* kind-of releva
Andres Freund 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 that misjudgment. W
On Saturday, October 20, 2012 12:05:15 AM Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Oct 19, 2012 at 2:01 PM, Andres Freund
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
> >> m
On Saturday, October 20, 2012 12:37:54 AM Tom Lane wrote:
> Andres Freund 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 mig
Jeremy Evans 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 went to restore
On Sat, Oct 20, 2012 at 1:03 AM, Satoshi Nagayasu wrote:
> 2012/10/19 23:48, Fujii Masao wrote:
>>
>> On Wed, Oct 17, 2012 at 12:31 AM, Satoshi Nagayasu
>> wrote:
>>>
>>> 2012/10/16 2:40, Jeff Janes wrote:
On Sun, Oct 14, 2012 at 9:43 AM, Tom Lane wrote:
>
>
> Satoshi
On Fri, Oct 19, 2012 at 6:05 PM, Tom Lane 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, indeed. We came up
On 10/19/2012 09:05 PM, Robert Haas wrote:
On Fri, Oct 19, 2012 at 6:05 PM, Tom Lane 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 exten
Andres Freund 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 the current query
On Friday, October 19, 2012 9:15 PM Jeff Janes wrote:
On Tue, Sep 4, 2012 at 6:25 AM, Amit kapila wrote:
> On Tuesday, September 04, 2012 12:42 AM Jeff Janes wrote:
> On Mon, Sep 3, 2012 at 7:15 AM, Amit kapila wrote:
>>> This patch is based on below Todo Item:
>>
>>> Consider adding buffers the
At 2012-10-15 10:28:17 -0400, robertmh...@gmail.com wrote:
>
> > Is there any concise description that applies? […]
>
> I don't think there is. I think we need to replace those counters
> with something better. The status quo is quite bizarre.
Fair enough. Do you have any ideas?
I see two poss
On 10/19 06:55, Tom Lane wrote:
> Jeremy Evans 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 S
Hi,
I was trying to create foreign key constraints on a sub-column of a
composite-type column, but couldn't find a way to do it. After asking around on
IRC, it seems like this isn't supported in PostgreSQL.
I wanted to do something like:
create type profile as (account_id integer);
This patch adds \watch to psql. It is much like the unix equivalent,
defaulting to every 2 seconds, and allowing you optionally specify a number
of seconds.
I will add this to the commit fest app.
Thanks,
Will Leinweber
Example:
psql (9.3devel, server 9.1.4)
Type "help" for help.
will=# \watch
75 matches
Mail list logo
