On 16 October 2012 18:29, Tom Lane wrote:
> Or maybe better, invent a level of indirection like a "sequence access
> method" (comparable to index access methods) that provides a compatible
> set of substitute functions for sequence operations. If you want to
> override nextval() for a sequence,
On 17 October 2012 21:25, Josh Berkus wrote:
>
>> It is not meant to be a full implementation of application level queuing
>> system though but just the capture, persisting and distribution parts
>>
>> Using this as an "application level queue" needs a set of interface
>> functions to extract the
Hello,
Using PostgreSQL 9.2.1 on Windows, I am facing a strange character set issue
with a UTF-8 database.
Maybe this is expected, but want to be sure that I am not missing something.
On Windows, I have created a database with:
ENCODING = 'UTF-8'
LC_COLLATE = 'English_United States.1252'
On 17 October 2012 11:26, Hannu Krosing wrote:
> LOGGED ONLY TABLE is very technical description of realisation - I'd
> prefer it to work as mush like a table as possible, similar to how VIEW
> currently works - for all usages that make sense, you can simply
> substitute it for a TABLE
>
> QUEUE
Hello,
Using PostgreSQL 9.2.1 on Windows, I am facing a strange character set issue
with a UTF-8 database.
Maybe this is expected, but want to be sure that I am not missing something.
On Windows, I have created a database with:
ENCODING = 'UTF-8'
LC_COLLATE = 'English_United States.1252'
Hello. My colleague found that pg_stat_replication.sync_state
shows false state for some condition.
This prevents Pacemaker from completing fail-over that could
safely be done.
The point is in walsender.c, pg_stat_get_wal_senders() below, (as
of REL9_2_1)
1555:if (walsnd->pid != 0)
1556:
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 code change is completely wrong.
> > Give me a bit to sort this out.
>
> I'm having trouble seeing a wa
On Wed, Oct 17, 2012 at 11:43 PM, Alvaro Herrera
wrote:
> Uh, the patch you posted keeps the pg_get_function_identity_arguments
> call in dumpFunc, but there is now also a new one in getFuncs. Do we
> need to remove the second one?
It could be done, but unfortunately we cannot use the value comp
Simon Riggs writes:
> Not sure how it is cleaner when we have to have trigger stuff hanging
> around to make one object pretend to be another. That also creates a
> chain of dependency which puts this into the future, rather than now.
Yes, that part isn't cleaner at all. The part where we have a
Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)
In particular, we made a couple of changes over sveral releases back
in the authentication config, that we shou
On 18 October 2012 12:20, Magnus Hagander wrote:
> 2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
> syntax deprecated but still mapping to the new one. Has it been there
> long enough that we should start throwing an error for ident on unix?
Any reason to remove? Having tw
On Thu, Oct 18, 2012 at 1:32 PM, Simon Riggs wrote:
> On 18 October 2012 12:20, Magnus Hagander wrote:
>
>> 2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
>> syntax deprecated but still mapping to the new one. Has it been there
>> long enough that we should start throwing a
On 18 October 2012 12:37, Magnus Hagander wrote:
> On Thu, Oct 18, 2012 at 1:32 PM, Simon Riggs wrote:
>> On 18 October 2012 12:20, Magnus Hagander wrote:
>>
>>> 2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
>>> syntax deprecated but still mapping to the new one. Has it b
On 18 October 2012 12:20, Magnus Hagander wrote:
> Since Simon stirred up a hornets nest suggesting deprecation of a
> number of features, I figured I'd take it one step further and suggest
> removal of some previously deprecated features :)
I'm laughing at the analogy that angry and unintellige
At 2012-09-25 01:46:18 +0200, and...@2ndquadrant.com wrote:
>
> The attached patch fixes this issue. Haven't looked at the other one
> in detail yet.
Here are tests for both bugs. They currently fail with HEAD.
Note that the first test now uses PREPARE instead of the SELECTs in the
original examp
On 18 October 2012 12:56, Abhijit Menon-Sen wrote:
> At 2012-09-25 01:46:18 +0200, and...@2ndquadrant.com wrote:
>>
>> The attached patch fixes this issue. Haven't looked at the other one
>> in detail yet.
>
> Here are tests for both bugs. They currently fail with HEAD.
>
> Note that the first tes
Andres Freund wrote:
> On Thursday, October 18, 2012 06:12:02 AM Kevin Grittner wrote:
>> I'm having trouble seeing a way to make this work without
>> rearranging the code for concurrent drop to get to a state where
>> it has set indisvalid = false, made that visible to all processes,
>> and ensu
Simon Riggs wrote:
> On 18 October 2012 12:20, Magnus Hagander wrote:
>
> > Since Simon stirred up a hornets nest suggesting deprecation of a
> > number of features, I figured I'd take it one step further and suggest
> > removal of some previously deprecated features :)
>
> I'm laughing at the a
On 10/17/2012 07:25 PM, Tom Lane wrote:
I'm fairly annoyed by the entire tenor of this conversation, because
the people who are hollering the loudest seem to be people who have
never actually touched any of the rules code, but nonetheless seem
prepared to tell those of us who have what to spen
On 16 October 2012 15:26, Jan Wieck wrote:
> This means that the transition time from the existing, trigger based
> approach to the new WAL based mechanism will see both technologies in
> parallel, which is no small thing to support.
So, you're talking about a shim between the two in order to use
Hitoshi Harada writes:
> If OOM happens during expand_table() in hash_search_with_hash_value()
> for RelationCacheInsert,
What OOM? expand_table is supposed to return without doing anything
if it can't expand the table. If that's not happening, that's a bug
in the hash code.
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 complete them and mark it as "Ready For Committer"
> or what else can
On Thu, Oct 18, 2012 at 5:42 PM, Kyotaro HORIGUCHI
wrote:
> Hello. My colleague found that pg_stat_replication.sync_state
> shows false state for some condition.
>
> This prevents Pacemaker from completing fail-over that could
> safely be done.
>
> The point is in walsender.c, pg_stat_get_wal_send
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 the problem (which is the
>> need for catalog metadata at a point in time to make sense of heap
>> tuples), without describing th
On 18 October 2012 12:43, Simon Riggs wrote:
> On 18 October 2012 12:20, Magnus Hagander wrote:
>
>> Since Simon stirred up a hornets nest suggesting deprecation of a
>> number of features, I figured I'd take it one step further and suggest
>> removal of some previously deprecated features :)
>
>
On Tue, Oct 16, 2012 at 1:29 PM, Tom Lane wrote:
> In particular, the reason proposing a hook first seems backwards is that
> if we have a catalog-level representation that some sequences are local
> and others not, we should be using that to drive the determination of
> whether to call a substitu
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 change it for 9.3.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
Robert Haas writes:
> On Tue, Oct 16, 2012 at 1:29 PM, Tom Lane wrote:
>> Or maybe better, invent a level of indirection like a "sequence access
>> method" (comparable to index access methods) that provides a compatible
>> set of substitute functions for sequence operations. If you want to
>> ov
On Thu, Oct 18, 2012 at 9:49 AM, Peter Geoghegan wrote:
> On 16 October 2012 15:26, Jan Wieck wrote:
>> This means that the transition time from the existing, trigger based
>> approach to the new WAL based mechanism will see both technologies in
>> parallel, which is no small thing to support.
>
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, thanks. Committed.
>> >
>> > I found one typo. The attac
On 18 October 2012 16:18, Christopher Browne wrote:
> A "shim" adds complexity, but retains the "upgrade across versions"
> use case, and reduces the need to keep supporting elder versions of
> Slony.
Right. Upgrading across major versions is likely to continue to remain
a very important use-case
Joel Jacobson wrote:
> On Wed, Oct 17, 2012 at 11:43 PM, Alvaro Herrera
> wrote:
> > Uh, the patch you posted keeps the pg_get_function_identity_arguments
> > call in dumpFunc, but there is now also a new one in getFuncs. Do we
> > need to remove the second one?
>
> It could be done, but unfortu
Joel Jacobson wrote:
> Hi Joachim,
>
> Attached, please find new patch. Test unchanged.
This was committed, as discussed in the original patch's thread.
It would be great if reviewers could reply to the email that submits the
patch, instead of creating a thread of their own. It helps keep thing
I wrote:
> Hitoshi Harada writes:
>> If OOM happens during expand_table() in hash_search_with_hash_value()
>> for RelationCacheInsert,
> What OOM? expand_table is supposed to return without doing anything
> if it can't expand the table. If that's not happening, that's a bug
> in the hash code.
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 the problem (which is the
> >> need for catalog metadata at a
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 change it for 9.3.
Hm, but the bug is said to happen only in 9
On 18 October 2012 16:08, Robert Haas wrote:
> To make
> it even better, add some generic options that can be passed through to
> the underlying handler.
Agreed
>> Or maybe better, invent a level of indirection like a "sequence access
>> method" (comparable to index access methods) that provide
On 18 October 2012 16:15, Tom Lane wrote:
> But I'd want to see a pretty
> bulletproof argument why overriding *only* nextval is sufficient
> (and always will be) before accepting a hook for just nextval. If we
> build an equivalent amount of functionality piecemeal it's going to
> be a lot ugli
Greg Stark escribió:
> On Tue, Oct 16, 2012 at 9:47 PM, Peter Geoghegan
> wrote:
> > The patch will now been marked "ready for committer". Does this need
> > doc changes, in light of what is arguably a behavioural difference?
> > You only mentioned release notes.
>
> I'm happy to look at this on
Tomas Vondra wrote:
> Hi,
>
> thanks for the review. I'll look into that in ~2 weeks, once the
> pgconf.eu
> is over.
Excellent. Please submit the updated version to the upcoming commitfest
when you have it. I'm marking this patch Returned with Feedback.
Many thanks to Shigeru Hanada for the re
Tomas Vondra wrote:
> Also, I've realized the last interval may not be logged at all - I'll
> take a look into this in the next version of the patch.
I didn't see any later version of this patch posted anywhere. I guess
it'll have to wait until the next commitfest. Please fix the remaining
issu
On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander wrote:
> Since Simon stirred up a hornets nest suggesting deprecation of a
> number of features, I figured I'd take it one step further and suggest
> removal of some previously deprecated features :)
>
> In particular, we made a couple of changes ov
On 16 October 2012 21:47, Peter Geoghegan wrote:
> The same basic strategy for sizing the tuplesort memtuples array in
> also exists in tuplestore. I wonder if we should repeat this there? I
> suppose that that could follow later.
Incidentally, the basis of this remark is commit 2689abf0, where T
This patch doesn't seem to be going anywhere, sadly. Since we're a bit
late in the commitfest and this patch hasn't seen any activity for a
long time, I'll mark it as returned-with-feedback. I hope one or both
versions are resubmitted (with additional fixes?) for the next
commitfest, and that the
Daniel, I assume you are submitting an updated version based on the
feedback that has been provided. I will mark this patch returned with
feedback in the current CF; please submit the next version to CF3.
Thanks to the (rather numerous!) reviewers.
--
Álvaro Herrerahttp://www.2n
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 title 'Some title'
or
\C 'Some title'
psql emits the text:
Robert Haas writes:
> On Thu, Oct 18, 2012 at 7:20 AM, Magnus Hagander wrote:
>> 2. ident-over-unix-sockets was renamed to "peer" in 9.1, with the old
>> syntax deprecated but still mapping to the new one. Has it been there
>> long enough that we should start throwing an error for ident on unix?
On Thu, Oct 18, 2012 at 9:22 AM, Alvaro Herrera
wrote:
> Daniel, I assume you are submitting an updated version based on the
> feedback that has been provided. I will mark this patch returned with
> feedback in the current CF; please submit the next version to CF3.
Thank you for reminding me, so
On 10/17/2012 04:25 PM, Tom Lane wrote:
...Now having said that, I would definitely like to see rules in their
current form go away eventually. But not without a substitute.
Triggers are not a complete replacement, and no amount of wishful
thinking makes them so.
...
Perhaps it would be more p
On Thu, 2012-10-18 at 12:19 -0300, 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
On Tue, Oct 16, 2012 at 9:31 PM, Heikki Linnakangas
wrote:
> On 15.10.2012 19:31, Fujii Masao wrote:
>>
>> On Mon, Oct 15, 2012 at 11:27 PM, Heikki Linnakangas
>> wrote:
>>>
>>> On 15.10.2012 13:13, Heikki Linnakangas wrote:
Oh, I didn't remember that we've documented the specific
On Thu, Oct 18, 2012 at 6:46 AM, Andrew Dunstan wrote:
>
> On 10/17/2012 07:25 PM, Tom Lane wrote:
>
>>
>> I'm fairly annoyed by the entire tenor of this conversation, because
>> the people who are hollering the loudest seem to be people who have
>> never actually touched any of the rules code, bu
On 10/18/2012 04:43 AM, Simon Riggs wrote:
On 18 October 2012 12:20, Magnus Hagander wrote:
Since Simon stirred up a hornets nest suggesting deprecation of a
number of features, I figured I'd take it one step further and suggest
removal of some previously deprecated features :)
I'm laughin
Simon,
> It's hard to work out how to reply to this because its just so off
> base. I don't agree with the restrictions you think you see at all,
> saying it politely rather than giving a one word answer.
You have inside knowledge of Hannu's design. I am merely going from his
description *on thi
Boszormenyi Zoltan escribió:
> Hi,
>
> this is the latest one, fixing a bug in the accounting
> of per-statement lock timeout handling and tweaking
> some comments.
Tom, are you able to give this patch some more time on this commitfest?
(If not, I think it would be fair to boot it to CF3; this i
Alvaro Herrera writes:
> Boszormenyi Zoltan escribió:
>> this is the latest one, fixing a bug in the accounting
>> of per-statement lock timeout handling and tweaking
>> some comments.
> Tom, are you able to give this patch some more time on this commitfest?
I'm still hoping to get to it, but I'
Alexander Korotkov escribió:
> > 4. It looks like the randomization is happening while trying to compare
> > the penalties. I think it may be more readable to separate those two
> > steps; e.g.
> >
> > /* create a mapping whether randomization is on or not */
> > for (i = FirstOffsetNumber; i
Heikki, would you be able to give this patch a look and perhaps commit
it?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
Jeff Davis escribió:
> On Sat, 2012-08-18 at 18:10 +0400, Alexander Korotkov wrote:
> >
> > Thanks! There is a separate patch for adjacent. I've reworked adjacent
> > check in order to make it more clear.
>
> I am taking a look at this patch now. A few quick comments:
> * I tried some larger tes
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.)
--
Álvaro Herrerahttp://www.2ndQuadrant.
On Thu, Oct 18, 2012 at 2:33 PM, Josh Berkus wrote:
>> I should also add that this is an switchable sync/asynchronous
>> transactional queue, whereas LISTEN/NOTIFY is a synchronous
>> transactional queue.
>
> Thanks for explaining.
New here, I missed half the conversation, but since it's been bro
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 code change is completely wrong.
>> > Give me a bit
On 10/18/2012 07:33 PM, Josh Berkus wrote:
Simon,
It's hard to work out how to reply to this because its just so off
base. I don't agree with the restrictions you think you see at all,
saying it politely rather than giving a one word answer.
You have inside knowledge of Hannu's design.
Actua
On 10/18/2012 08:36 PM, Claudio Freire wrote:
The CREATE QUEUE command, in fact, could be creating
such a channel. The channel itself won't be WAL-only, just
the messages going through it. This (I think) would solve locking issues.
Hmm. Maybe we should think of implementing this as REMOTE TABL
On Tue, Oct 16, 2012 at 2:12 PM, Stafford, David x78061
wrote:
> On Mon, 15 Oct 2012 10:21:18 -0700, Robert Haas wrote:
>> Yeah, I think the functionality that we need is pretty much there
>> already today. What we need to do is to get the syntax to a point
>> where people can write the code the
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
> - unique constraints don't make sense
> - inde
On Thu, Oct 11, 2012 at 07:17:28AM -0400, Noah Misch wrote:
> On Tue, Oct 02, 2012 at 01:58:40PM -0400, Noah Misch wrote:
> > > > On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane wrote:
> > > >> There's also the big-picture question of whether we should just get rid
> > > >> of fuzzy comparisons in the g
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.
On Wed, Oct 17, 2012 at 3:55 PM, ichbinrene wrote:
> I'm experiencing the exact same issue:
>
> PostgreSQL 9.1.6 on i686-pc-linux-gnu, compil
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, people might have second thoughts
On Wed, Oct 17, 2012 at 7:25 PM, Tom Lane wrote:
> Josh Berkus writes:
>> I would tend to say "well, they're not hurting anyone, why not keep
>> them?" Except that we're gathering an increasing number of features
>> (RETURNING, FDWs, CTEs, Command triggers) which don't work well together
>> with
Alvaro Herrera writes:
> Here's the final version. I think this is ready to go in.
I got around to reviewing this today. I'm pretty seriously annoyed at
the definition of dlist_delete: it should *not* require the list header.
The present coding simply throws away one of the primary advantages o
This patch seems to have been neglected by both its submitter and the
reviewer. Also, Simon said he was going to set it
returned-with-feedback on his last reply, but I see it as needs-review
still in the CF app. Is this something that is going to be reconsidered
and resubmitted for the next commi
I've noticed, doing some reporting queries once, that index scans fail
to saturate server resources on compute-intensive queries.
Problem is, just after fetching a page, postgres starts computing
stuff before fetching the next. This results in I/O - compute - I/O -
compute alternation that results
Tom Lane escribió:
> Alvaro Herrera writes:
> > Here's the final version. I think this is ready to go in.
>
> I got around to reviewing this today. I'm pretty seriously annoyed at
> the definition of dlist_delete: it should *not* require the list header.
> The present coding simply throws away
2012-10-18 20:08 keltezéssel, Tom Lane írta:
Alvaro Herrera writes:
Boszormenyi Zoltan escribió:
this is the latest one, fixing a bug in the accounting
of per-statement lock timeout handling and tweaking
some comments.
Tom, are you able to give this patch some more time on this commitfest?
I
On 10/18/2012 01:11 PM, Daniel Farina wrote:
Here's another use case that in my history with RULES that didn't seem
to pan out so well: In my recollection, one way to use rules is to
retarget operations that happen against a view and move them to a
table, and as I recall to make this work as on
Alvaro Herrera writes:
> Oops. I mentioned this explicitely somewhere in the discussion. I
> assumed you had seen that, and that you would have complained had you
> found it objectionable.
Sorry, I've been too busy to pay very much attention to this patch.
>> I think we should remove the head
Well, it'd be nice to be able to rewrite a query referring to a table
to still refer to that same table, but you can't, because you get
infinite recursion.
If that was possible it would be quite easy to express any row/column level
security policies with it.
If you could do that, it'd presumab
On 18 October 2012 21:22, Alvaro Herrera wrote:
> This patch seems to have been neglected by both its submitter and the
> reviewer. Also, Simon said he was going to set it
> returned-with-feedback on his last reply, but I see it as needs-review
> still in the CF app. Is this something that is g
On Thu, Oct 18, 2012 at 5:30 PM, Claudio Freire wrote:
> Backward:
>
>QUERY PLAN
> --
> GroupAggregat
On Thu, 2012-10-18 at 13:20 +0200, Magnus Hagander wrote:
> In particular, we made a couple of changes over sveral releases back
> in the authentication config, that we should perhaps consider
> finishing by removing the old stuff now?
>
> 1. krb5 authentication. We've had gssapi since 8.3 (which
On Thu, 2012-10-18 at 12:38 -0400, Tom Lane wrote:
> I think the argument that it causes user confusion is a fairly strong
> one, though.
What is confusing, IMO, is changing the hba syntax all the time.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On Thu, Oct 18, 2012 at 10:36 PM, Robert Haas wrote:
> Sadly, the situation on Windows doesn't look so good. I
> don't remember the exact numbers but I think it was something like 40
> or 60 or 80 times slower on the Windows box one of my colleagues
> tested than it is on Linux.
Do you happen to
On Thu, Oct 18, 2012 at 1:55 PM, Andrew Dunstan wrote:
>
> On 10/18/2012 01:11 PM, Daniel Farina wrote:
>
>> Here's another use case that in my history with RULES that didn't seem
>> to pan out so well: In my recollection, one way to use rules is to
>> retarget operations that happen against a vie
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 of interest in deprecation is only
> as
On Thu, Oct 18, 2012 at 6: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
Marco Nenciarini writes:
> Please find the attached refreshed patch (v2) which fixes the loose ends
> you found.
I've started looking at this patch, and the first thing I notice is that
the syntax doesn't work. It's ambiguous, and this:
%left JOIN CROSS LEFT FULL RIGHT INNER_P NATURAL
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.
FWIW, MySQL calls this exact concep
I wrote:
> Or we could go back to using ARRAY here --- that should be safe since
> ARRAY is already fully reserved.
Ugh ... no, that doesn't work, because ARRAY[...] is allowed in c_expr
and hence b_expr. So the ambiguity would still be there. We'd need a
different fully-reserved keyword to go t
On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane wrote:
> I wrote:
>> Hitoshi Harada writes:
>>> If OOM happens during expand_table() in hash_search_with_hash_value()
>>> for RelationCacheInsert,
>
> the palloc-based allocator does throw
> errors. I think that when that was designed, we were thinking t
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 tra
91 matches
Mail list logo
