Hi,
Attached does:
Index childRTindex;
AppendRelInfo *appinfo;
-/* Open rel if needed; we already have required locks */
+/* Open rel if needed; we already have acquired locks */
if (childOID != parentOID)
newrelation = heap_open(childOID, NoLock);
else
On 2 April 2015 at 22:23, Robert Haas wrote:
> On Thu, Apr 2, 2015 at 5:02 PM, Andres Freund wrote:
>>> I think the upshot is that INSTEAD OF triggers work in a particular way
>>> because that's what is needed to support updatable views. If triggers
>>> on tables should behave differently, maybe
Thanks for your input, Noah.
On Fri, Apr 3, 2015 at 3:22 PM, Noah Misch wrote:
> Each Windows patch should cover all Windows build systems; patches that fix a
> problem in the src/tools/msvc build while leaving it broken in the GNU make
> build are a bad trend. In this case, I expect you'll need
On Fri, Apr 3, 2015 at 5:57 AM, Alvaro Herrera wrote:
> You added this in the worker loop processing each table:
>
> /*
> * Check for config changes before processing each collected
> table.
> */
> if (got_SIGHUP)
>
Each Windows patch should cover all Windows build systems; patches that fix a
problem in the src/tools/msvc build while leaving it broken in the GNU make
build are a bad trend. In this case, I expect you'll need few additional
changes to cover both.
On Thu, Apr 02, 2015 at 06:30:02PM +0900, Micha
On Fri, Apr 3, 2015 at 12:56 PM, Fujii Masao wrote:
> The first patch looks good to me basically. But I have one comment:
> shouldn't we expose pg_malloc_extended as a global function like
> we did pg_malloc? Some frontends might need to use it in the future.
Yes, it makes sense as the other funct
On Thu, Feb 12, 2015 at 4:02 PM, Michael Paquier
wrote:
> On Wed, Feb 11, 2015 at 2:13 AM, Robert Haas wrote:
>>
>> On Mon, Feb 9, 2015 at 7:02 AM, Michael Paquier
>> wrote:
>> > On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao
>> > wrote:
>> >> MemoryContextAllocExtended() was added, so isn't it ti
> "Robert" == Robert Haas writes:
Robert> I think this is really nice work, so I have committed this
Robert> version. I made a few fairly minor changes, hopefully without
Robert> breaking anything in the process:
Robert> - I adjusted things for recent commits around INT{32,63}_{MIN_MAX}
At 2015-04-03 00:33:10 +0300, hlinn...@iki.fi wrote:
>
> I came up with the attached.
I like it very much.
src/port/Makefile has (note src/srv):
+# pg_crc32c_sse42.o and its _src.o version need CFLAGS_SSE42
+pg_crc32c_sse42.o: CFLAGS+=$(CFLAGS_SSE42)
+pg_crc32c_sse42_srv.o: CFLAGS+=$
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -881,9 +881,11 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } |
UNLOGGED ] TABLE [ IF NOT EXI
toast., which can be used to control the behavior of the
table's secondary TOAST table, if any
(se
Hi,
my compiler complains about unused variable nblkno in _hash_splitbucket
in no-assert build. It looks like relic of commit ed9cc2b5d which
removed the only use of that variable besides the Assert.
Looking at the code:
nblkno = start_nblkno;
Assert(nblkno == BufferGetBlockNu
On Thu, Apr 2, 2015 at 11:21 PM, Robert Haas wrote:
> On Thu, Apr 2, 2015 at 5:34 PM, Peter Geoghegan wrote:
>> I think it's explained by the pre-check for sorted input making the
>> number of comparisons exactly n -1. As I pointed out to Tomas, if you
>> put a single, solitary unsorted element a
On Thu, Apr 2, 2015 at 11:21 PM, Robert Haas wrote:
>> The changes that Andrew
>> took issue with are utterly insignificant.
>
> Great. Then you will be utterly indifferent to which version gets committed.
*shrug*
You were the one that taught me to be bureaucratically minded about
keeping code
On Thu, Apr 2, 2015 at 5:33 PM, Heikki Linnakangas wrote:
> It was added in gcc 4.2. That's good enough for me.
I think it's fine to have optional optimizations that require gcc >=
4.2, as long as older platforms don't break outright.
>>> We have a buildfarm animal that still uses gcc 2.95.3, wh
On Thu, Apr 2, 2015 at 5:34 PM, Peter Geoghegan wrote:
> I think it's explained by the pre-check for sorted input making the
> number of comparisons exactly n -1. As I pointed out to Tomas, if you
> put a single, solitary unsorted element at the end, the abbreviated
> version is then 8x faster (ma
On Thu, Apr 2, 2015 at 8:17 PM, Robert Haas wrote:
> On Fri, Feb 20, 2015 at 3:57 PM, Tomas Vondra
> wrote:
>> I've spent a fair amount of testing this today, and when using the
>> simple percentile_disc example mentioned above, I see this pattern:
>>
>> master
On Thu, Apr 2, 2015 at 5:02 PM, Andres Freund wrote:
>> I think the upshot is that INSTEAD OF triggers work in a particular way
>> because that's what is needed to support updatable views. If triggers
>> on tables should behave differently, maybe it should be a separate
>> trigger type. Maybe it
On 2015-04-02 16:42:43 -0400, Peter Eisentraut wrote:
> On 4/2/15 11:50 AM, Dean Rasheed wrote:
> > Well actually the fact that the code is structured that way is
> > somewhat academic. INSTEAD OF triggers on views don't support WHEN
> > conditions -- deliberately so, since it would be difficult to
Michael Paquier wrote:
> So, attached are two patches:
> - 0001 enables SIGHUP tracking in do_autovacuum(), which is checked
> before processing one table. I reused avl_sighup_handler for the
> worker, renaming it av_sighup_handler..
> - 0002 is the patch to add log_autovacuum_min_duration as a re
On 4/2/15 11:50 AM, Dean Rasheed wrote:
> Well actually the fact that the code is structured that way is
> somewhat academic. INSTEAD OF triggers on views don't support WHEN
> conditions -- deliberately so, since it would be difficult to know in
> general what to do if the trigger didn't fire. So E
On Sun, Mar 29, 2015 at 2:20 PM, Fabien COELHO wrote:
>> Here is a small v2 update:
>
> v3, just a rebase.
Thanks for working on this. I see it's already registered in the
2015-06 CF, and will have a look at when we get there.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterp
On 4/2/15 4:32 AM, Jan Urbański wrote:
>
> Peter Eisentraut writes:
>
>> On 2/12/15 7:28 AM, Jan Urbański wrote:
>>> For the sake of discussion, here's a patch to prevent stomping on
>>> previously-set callbacks, racy as it looks.
>>>
>>> FWIW, it does fix the Python deadlock and doesn't cause th
On Thu, Apr 2, 2015 at 4:24 PM, Petr Jelinek wrote:
>> Thanks. I actually pushed a fix for that about 25 minutes ago;
>> hopefully that is all that is needed.
>
> Ok, the git.pg.org was somewhat behind. It did fix it for me when I tested
> it locally.
OK, that's good to know. So far the buildfa
On Sun, Mar 29, 2015 at 2:20 PM, Fabien COELHO wrote:
>> Here is a v5.
>
> Here is v6, just a rebase.
Committed with minor stylistic fixes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On 02/04/15 22:22, Robert Haas wrote:
On Thu, Apr 2, 2015 at 4:21 PM, Petr Jelinek wrote:
On 02/04/15 21:21, Robert Haas wrote:
On Thu, Apr 2, 2015 at 2:07 PM, Robert Haas wrote:
I think this is really nice work, so I have committed this version. I
made a few fairly minor changes, hopefull
On Thu, Apr 2, 2015 at 4:21 PM, Petr Jelinek wrote:
> On 02/04/15 21:21, Robert Haas wrote:
>> On Thu, Apr 2, 2015 at 2:07 PM, Robert Haas wrote:
>>>
>>> I think this is really nice work, so I have committed this version. I
>>> made a few fairly minor changes, hopefully without breaking anything
On 02/04/15 21:21, Robert Haas wrote:
On Thu, Apr 2, 2015 at 2:07 PM, Robert Haas wrote:
I think this is really nice work, so I have committed this version. I
made a few fairly minor changes, hopefully without breaking anything
in the process:
- I adjusted things for recent commits around INT
Robert Haas writes:
> On Thu, Apr 2, 2015 at 3:59 PM, Tom Lane wrote:
>> Perhaps the difference has to do with whether pg_am's pg_class tuple is
>> on a page that hasn't got enough room for a HOT update? But I definitely
>> tried it several times and consistently got the same failure before.
>
On Thu, Apr 2, 2015 at 3:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 2, 2015 at 2:55 PM, Tom Lane wrote:
>>> Actually, now that I think it through, the "could not open relation"
>>> error is pretty odd in itself. If we are trying to open pg_am using
>>> a stale catalog snapshot,
Robert Haas writes:
> On Thu, Apr 2, 2015 at 2:55 PM, Tom Lane wrote:
>> Actually, now that I think it through, the "could not open relation"
>> error is pretty odd in itself. If we are trying to open pg_am using
>> a stale catalog snapshot, it seems like we ought to reliably find its
>> old pg_
On Thu, Apr 2, 2015 at 2:07 PM, Robert Haas wrote:
> I think this is really nice work, so I have committed this version. I
> made a few fairly minor changes, hopefully without breaking anything
> in the process:
>
> - I adjusted things for recent commits around INT{32,63}_{MIN_MAX}.
> - I removed
On Thu, Apr 2, 2015 at 2:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 2, 2015 at 2:40 PM, Tom Lane wrote:
>>> However, I'm having second thoughts about whether we've fully diagnosed
>>> this. Three out of the four failures we've seen in the buildfarm reported
>>> "cache lookup fa
On Fri, Feb 20, 2015 at 3:57 PM, Tomas Vondra
wrote:
> I've spent a fair amount of testing this today, and when using the
> simple percentile_disc example mentioned above, I see this pattern:
>
> master patched speedup
>-
Robert Haas writes:
> On Thu, Apr 2, 2015 at 2:40 PM, Tom Lane wrote:
>> However, I'm having second thoughts about whether we've fully diagnosed
>> this. Three out of the four failures we've seen in the buildfarm reported
>> "cache lookup failed for access method 403", not "could not open relati
On Thu, Apr 2, 2015 at 2:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 2, 2015 at 12:54 PM, Tom Lane wrote:
>>> It looks to me like an appropriate fix would be as attached; thoughts?
>
>> Hmm, that fix doesn't reach as far as what I did. My proposal would
>> regard a catalog snaps
Robert Haas writes:
> On Thu, Apr 2, 2015 at 12:54 PM, Tom Lane wrote:
>> It looks to me like an appropriate fix would be as attached; thoughts?
> Hmm, that fix doesn't reach as far as what I did. My proposal would
> regard a catalog snapshot as immediately stale, so if we're asked for
> a cata
On Sun, Mar 22, 2015 at 10:55 PM, Amit Khandekar wrote:
> On 17 March 2015 at 19:12, Robert Haas wrote:
>> On Tue, Mar 17, 2015 at 1:33 AM, Amit Khandekar
>> wrote:
>> > I think we either have to retain the knowledge that the worker has
>> > crashed
>> > using some new field, or else, we should
On Sun, Mar 22, 2015 at 6:12 AM, Fabien COELHO wrote:
> When running with low rate, the --progress is only printed when there is
> some activity, which makes it quite irregular, including some catching up
> with stupid tps figures.
>
> Shame on me for this "feature" (aka bug) in the first place.
>
On Wed, Mar 25, 2015 at 3:45 PM, Jim Nasby wrote:
> I see 3 settings that allow people to accidentally shoot themselves in the
> foot; fsync, wal_sync_method and full_page_writes.
Those aren't even the top three in my experience, let alone the only three.
--
Robert Haas
EnterpriseDB: http://www
On Wed, Mar 25, 2015 at 9:46 PM, Fabrízio de Royes Mello
wrote:
> http://www.postgresql.org/message-id/ca+tgmozm+-0r7h0edpzzjbokvvq+gavkchmno4fypveccw-...@mail.gmail.com
I like the idea of the feature a lot, but the proposal to which you
refer here mentions some problems, which I'm curious how yo
On Thu, Apr 2, 2015 at 12:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 1, 2015 at 7:05 PM, Tom Lane wrote:
>>> I've not fully tracked it down, but I think that the blame falls on the
>>> MVCC-snapshots-for-catalog-scans patch; it appears that it's trying to
>>> read pg_am's pg_cla
On Wed, Apr 1, 2015 at 11:48:37AM -0400, Bruce Momjian wrote:
> This should return something like 16.000... (per Oracle
> output at the URL above, float4 has 6 significant digits on my compiler)
> but I can't seem to figure how to get printf() to round non-fractional
> parts. I am afr
On Tue, Mar 24, 2015 at 3:03 AM, Andrew Gierth
wrote:
> So here's the latest (and, hopefully, last) version:
>
> - adds diagnostic output from numeric_abbrev_abort using the trace_sort
>GUC
>
> - fixed Datum cs. uint32 issues in hash_uint32
>
> - added a short comment about excess-k represe
On 04/02/2015 12:42 PM, Alvaro Herrera wrote:
David Fetter wrote:
I haven't checked yet, but could this be because people aren't using
--enable-depend with ./configure ?
BTW --- No, this can't be the answer; --enable-depend is meant to help
with recompiling after updating the source tree, but
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Apr 2, 2015 at 12:53 AM, Stephen Frost wrote:
> > Clearly, further testing and documentation is required and I'll be
> > getting to that over the next couple of days, but it's pretty darn late
> > and I'm currently getting libpq undef
Alvaro Herrera writes:
> Kyotaro HORIGUCHI wrote:
>> The line prefixed by '!' looks inverted.
> You're absolutely right. My mistake. Pushed your patch, thanks.
Don't see any such commit from here?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Robert Haas writes:
> On Wed, Apr 1, 2015 at 7:05 PM, Tom Lane wrote:
>> I've not fully tracked it down, but I think that the blame falls on the
>> MVCC-snapshots-for-catalog-scans patch; it appears that it's trying to
>> read pg_am's pg_class entry with a snapshot that's too old, possibly
>> bec
David Fetter wrote:
> I haven't checked yet, but could this be because people aren't using
> --enable-depend with ./configure ?
BTW --- No, this can't be the answer; --enable-depend is meant to help
with recompiling after updating the source tree, but lack of it cannot
cause any failures (assumin
Kyotaro HORIGUCHI wrote:
> Hi, this is a bug in the commit 0d831389749a3baaced7b984205b9894a82444b9 .
>
> It allows vucuum freeze to be skipped and inversely lets regular
> vacuum wait for lock. The attched patch fixes it.
>
>
> In table_recheck_autovac, vacuum options are determined as followin
On Mon, Mar 23, 2015 at 9:46 PM, Peter Geoghegan wrote:
> On Mon, Mar 23, 2015 at 2:41 PM, Andrew Gierth
> wrote:
>> Peter> As I said, I don't really consider that my patch is a rewrite,
>> Peter> especially V4, which changes nothing substantive except removing
>> Peter> 32-bit support.
>>
>>
On 2015-04-02 12:05:13 -0400, Robert Haas wrote:
> On Wed, Mar 25, 2015 at 3:21 PM, Ryan Pedela wrote:
> > On Wed, Mar 25, 2015 at 11:59 AM, Alvaro Herrera
> > wrote:
> >> * Should we prohibit DDL from within event triggers?
> >
> > Please don't prohibit DDL unless there is a really, really good
On Wed, Mar 25, 2015 at 3:21 PM, Ryan Pedela wrote:
> On Wed, Mar 25, 2015 at 11:59 AM, Alvaro Herrera
> wrote:
>> * Should we prohibit DDL from within event triggers?
>
> Please don't prohibit DDL unless there is a really, really good reason to do
> so. I have several use cases in mind for event
On Wed, Mar 25, 2015 at 9:55 AM, Peter Geoghegan wrote:
> Attached patch adds DatumGetUInt32() around the hash_any() and
> hash_uint32() calls within varlena.c. These should have been in the
> original abbreviated keys commit. Mea culpa.
Committed. Sorry for the delay; I'm still catching up from
On 2015-04-02 20:57:24 +0530, Abhijit Menon-Sen wrote:
> At 2015-04-02 17:58:23 +0300, hlinn...@iki.fi wrote:
> >
> > We're only using inline assembly to force producing SSE 4.2 code, even
> > when -msse4.2 is not used. That feels wrong.
>
> Why? It feels OK to me (and to Andres, per earlier discu
On Thu, Apr 2, 2015 at 11:54 AM, Andres Freund wrote:
> On 2015-04-02 10:42:58 -0400, Robert Haas wrote:
>> On Tue, Mar 31, 2015 at 12:15 PM, Andres Freund wrote:
>> >> > I'm tempted to just prefix our limits with PG_ and define them
>> >> > unconditionally, including appropriate casts to our typ
On 2015-04-02 10:42:58 -0400, Robert Haas wrote:
> On Tue, Mar 31, 2015 at 12:15 PM, Andres Freund wrote:
> >> > I'm tempted to just prefix our limits with PG_ and define them
> >> > unconditionally, including appropriate casts to our types.
> >>
> >> I don't have a better idea.
> >
> > Will push
On 2 April 2015 at 14:59, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Apr 1, 2015 at 1:56 PM, Tom Lane wrote:
>>> It would absolutely *not* be reasonable for WHEN conditions for triggers
>>> on tables to work completely differently than they do for triggers on
>>> views. That ship's sailed
At 2015-04-02 17:58:23 +0300, hlinn...@iki.fi wrote:
>
> We're only using inline assembly to force producing SSE 4.2 code, even
> when -msse4.2 is not used. That feels wrong.
Why? It feels OK to me (and to Andres, per earlier discussions about
exactly this topic). Doing it this way allows the bina
On 04/02/2015 12:39 PM, Abhijit Menon-Sen wrote:
At 2015-03-25 19:18:51 +0200, hlinn...@iki.fi wrote:
I think we'll need a version check there. […]
You want to write that or should I?
I'm not familiar with MSVC at all, so it would be nice if you did it.
Thinking more about the configure ch
On Wed, Mar 25, 2015 at 10:07 PM, Tatsuo Ishii wrote:
>>> Fix committed/pushed from master to 9.2. 9.1 declares it as a static
>>> function.
>>
>> Er, is that a good idea to back-patch that? Normally routine specs are
>> maintained stable on back-branches, and this is just a cosmetic
>> change.
>
On Wed, Mar 25, 2015 at 6:11 AM, Amit Kapila wrote:
> I am facing an issue in case we need to create many segments for
> large inheritance hierarchy. Attached patch fixes the problem for me.
Sigh. You'd think I'd be able to write a 30-line patch without
introducing not one but two stupid bugs.
On Tue, Mar 31, 2015 at 12:15 PM, Andres Freund wrote:
>> > I'm tempted to just prefix our limits with PG_ and define them
>> > unconditionally, including appropriate casts to our types.
>>
>> I don't have a better idea.
>
> Will push that.
I'd appreciate it if you could do this soon. I like to
Robert Haas writes:
> On Wed, Apr 1, 2015 at 1:56 PM, Tom Lane wrote:
>> It would absolutely *not* be reasonable for WHEN conditions for triggers
>> on tables to work completely differently than they do for triggers on
>> views. That ship's sailed.
> Clue me in, because I'm confused. If no tri
On Wed, Apr 1, 2015 at 1:56 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2015-04-01 13:29:33 -0400, Tom Lane wrote:
>>> WHEN won't help; if there are any INSTEAD OF triggers, no insert will
>>> happen, whether the triggers actually fire or not.
>
>> Well, right now it doesn't work at all. It
On Thu, Apr 2, 2015 at 3:07 AM, Amit Kapila wrote:
> On Wed, Apr 1, 2015 at 6:11 PM, Robert Haas wrote:
>> On Wed, Apr 1, 2015 at 7:30 AM, Amit Kapila
>> wrote:
>> >> Also, the new code to propagate
>> >> XactLastRecEnd won't work right, either.
>> >
>> > As we are generating FATAL error on term
On Thu, Apr 2, 2015 at 2:36 AM, Amit Kapila wrote:
>> If I'm not confused, it would be the other way around. We would run
>> the initPlan in the master backend *first* and then the rest in the
>> workers.
>
> Either one of us is confused, let me try to describe my understanding in
> somewhat more
On Thu, Apr 2, 2015 at 12:53 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>> > REVOKE'ing access *without* removing the permissions checks would defeat
>> > the intent of these changes, which is to allow an administrator to grant
>> > the ability for
On Wed, Apr 1, 2015 at 7:05 PM, Tom Lane wrote:
> I've been able to reproduce this. The triggering event seems to be that
> the "VACUUM FULL pg_am" in vacuum.sql has to happen while another backend
> is starting up. With a ten-second delay inserted at the bottom of
> PerformAuthentication(), it'
On 10 February 2015 at 21:43, Andres Freund wrote:
> On 2015-02-10 22:06:34 +0900, Michael Paquier wrote:
> > On Tue, Feb 10, 2015 at 9:46 PM, Andres Freund
> > wrote:
> >
> > > Yea, it really looks like the above commit is to "blame". The new xmin
> > > tracking infrastructure doesn't know abou
On Thu, Apr 2, 2015 at 01:44:59AM -0400, Noah Misch wrote:
> On Wed, Apr 01, 2015 at 10:49:01PM -0400, Bruce Momjian wrote:
> > On Sat, Jan 10, 2015 at 02:53:13PM -0500, Tom Lane wrote:
> > > While looking at fe-auth.c I noticed quite a few places that weren't
> > > bothering to make error message
On 03/26/2015 11:37 PM, Ilia Ivanicki wrote:
*Abstract:*
Currently support for microvacuum is implemented only for BTree index. But
GiST index is so useful and widely used for user defined datatypes instead
of btree. During index search it reads page by page. Every tuple on the
page in buffer mar
Hi, all!
I have sent GSoC proposal
(http://postgresql.nabble.com/GSoC-2015-proposal-Support-for-microvacuum-for-GiST-td5843638.html)
about week ago and I haven't received any feedback. So I'm a bit
confused.
Is the idea of proposal not actual for community or maybe too small
for GSoC project?
I do
At 2015-03-25 19:18:51 +0200, hlinn...@iki.fi wrote:
>
> I think we'll need a version check there. […]
>
> You want to write that or should I?
I'm not familiar with MSVC at all, so it would be nice if you did it.
> How do you like this latest version of the patch otherwise?
I'm sorry, but I'm s
Hi all,
(Adding Peter and Heikki in CC for awareness)
Please find attached a WIP patch to support TAP tests with MSVC. The
tests can be kicked with this command:
vcregress tapcheck
There are a couple of things to note with this patch, and I would like
to have some input for some of those things:
On Thu, Apr 2, 2015 at 5:35 PM, Craig Ringer wrote:
> I started bisecting from e6df2e1 (stamp 9.4beta1, good) to 095d401 (bad).
> The problem revision appears to be 9402869:
>
> commit 9402869
> Author: Heikki Linnakangas
> Date: Sat Jan 17 01:14:32 2015 +0200
>
> Advance backend's advertis
Peter Eisentraut writes:
> On 2/12/15 7:28 AM, Jan Urbański wrote:
>> For the sake of discussion, here's a patch to prevent stomping on
>> previously-set callbacks, racy as it looks.
>>
>> FWIW, it does fix the Python deadlock and doesn't cause the PHP segfault...
>
> I don't think this patch wou
auto-updatable view work just for postgresql-9.3 and above (for other version
you still need to define DELETE/UPDATE trigger).
what i see is we just trying to have a work around either with BEFORE/AFTER
trigger or with auto-updatable view
in stright forwad/normale way is just to define INSTEAD
I started bisecting from e6df2e1 (stamp 9.4beta1, good) to 095d401 (bad).
The problem revision appears to be 9402869:
commit 9402869
Author: Heikki Linnakangas
Date: Sat Jan 17 01:14:32 2015 +0200
Advance backend's advertised xmin more aggressively.
which is somewhat logical given the cr
2015-01-26 16:46 GMT+01:00 Pavel Stehule :
>
>
> 2015-01-26 16:14 GMT+01:00 Tom Lane :
>
>> Pavel Stehule writes:
>> > 2015-01-26 14:02 GMT+01:00 Marko Tiikkaja :
>> > I am thinking, so solution
>>
>> > /* if we are doing RAISE, don't report its location */
>> > if (estate->err_text == r
On Wed, Apr 1, 2015 at 6:11 PM, Robert Haas wrote:
>
> On Wed, Apr 1, 2015 at 7:30 AM, Amit Kapila
wrote:
> >> Also, the new code to propagate
> >> XactLastRecEnd won't work right, either.
> >
> > As we are generating FATAL error on termination of worker
> > (bgworker_die()), so won't it be handl
80 matches
Mail list logo
