On Sun, Aug 6, 2017 at 3:22 AM, Robert Haas wrote:
> All of (1)-(3) are legitimate user choices, although not everyone will
> make them. (4) is unfortunately the procedure recommended by our
> documentation, which is where the problem comes in. I think it's
> pretty lame that the documentation r
On Sat, Aug 12, 2017 at 8:46 PM, Michael Paquier
wrote:
> I have not investigated much this problem yet, but has somebody else
> seen those diffs?
Coming back to that... Downgrading down to 2.9.4+4+g3169602-1 is
proving to put things back the way they should. Even downgrading to
2.9.4+91+g872fea9
On Fri, Aug 11, 2017 at 9:08 PM, Robert Haas wrote:
>
> rhaas=# create table parent (a int) partition by list (a);
> CREATE TABLE
> rhaas=# create temp table child partition of parent for values in (1);
> CREATE TABLE
> rhaas=# explain verbose select * from parent;
>
On Fri, Aug 11, 2017 at 10:50 PM, Robert Haas wrote:
> On Fri, Aug 11, 2017 at 5:36 AM, Rushabh Lathia
> wrote:
> > Please find attach patch with the changes.
>
> I found the way that you had the logic structured in flagInhTables()
> to be quite hard to follow, so I rewrote it in the attached ve
On 12 August 2017 at 08:03, Andres Freund wrote:
> On 2017-08-02 16:35:17 -0400, Robert Haas wrote:
> > I actually think failover slots are quite desirable, especially now
> > that we've got logical replication in core. In a review of this
> > thread I don't see anyone saying otherwise. The deb
Hi all,
Recent commit 8d98819 has added a missing permissoin check to lo_put()
to make sure that the write permissions of the object are properly set
before writing to a large object. When studying the problem, we bumped
into the fact that it is possible to actually simplify those ACL
checks and r
On Sun, Aug 13, 2017 at 12:28 PM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>> Masahiko Sawada wrote:
>> > Hi all,
>> >
>> > In snapbuild.c file, there is a comment as follows.
>> >
>> >* NB: Because of that xmax can be lower than xmin, because we only
>> >* increase xmax when a catalo
On 14 August 2017 at 03:19, Peter Geoghegan wrote:
> On Thu, Aug 10, 2017 at 2:53 PM, Thomas Munro
> wrote:
> > The current regression tests, isolation tests and TAP tests are very
> > good (though I admit my experience with TAP is limited), but IMHO we
> > are lacking support for C-level unit t
On 2017/08/11 2:18, Robert Haas wrote:
On Thu, Aug 10, 2017 at 8:25 AM, Etsuro Fujita
wrote:
Here is a small patch for fixing a comment typo in plannodes.h: s/all the
partitioned table/all the partitioned tables/.
Committed.
Thank you.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hacke
Andres Freund writes:
> You both are obviously right. Another point of potential concern could
> be that we'd pretyt much fully rely on dsm/dht's being available, for
> the server to function correctly. Are we ok with that? Right now
> postgres still works perfectly well, leaving parallelism asid
On Mon, Aug 14, 2017 at 6:10 AM, AP wrote:
> On Fri, Aug 11, 2017 at 07:33:51AM +0530, Amit Kapila wrote:
>> On Thu, Aug 10, 2017 at 4:11 PM, AP wrote:
>> > mdstash=# select * from pgstathashindex('link_datum_id_idx');
>> > version | bucket_pages | overflow_pages | bitmap_pages | unused_pages |
Hi,
Since we're getting a bit into the weeds of a different topic, and since
I think it's an interesting feature, I'm detaching this into a separate
thread.
On 2017-08-12 23:37:27 -0400, Tom Lane wrote:
> >> On 2017-08-12 22:52:57 -0400, Robert Haas wrote:
> >>> I think it'd be pretty interesting
Hi,
Attached is a rebased version of the Generational context, originally
submitted with SlabContext (which was already committed into Pg 10).
The main change is that I've abandoned the pattern of defining a Data
structure and then a pointer typedef, i.e.
typedef struct GenerationContex
Hi,
On 2017-08-11 20:39:13 +1200, Thomas Munro wrote:
> Please find attached a new patch series.
Review for 0001:
I think you made a few long lines even longer, like:
@@ -1106,11 +1106,11 @@ pltcl_trigger_handler(PG_FUNCTION_ARGS,
pltcl_call_state *call_state,
Tcl_ListObjAppend
On Sun, Aug 13, 2017 at 2:22 PM, Andres Freund wrote:
> On 2017-08-13 16:55:33 -0400, Tom Lane wrote:
>> Peter Geoghegan writes:
>> > I think that it's useful for these things to be handled in an
>> > adversarial manner, in the same way that litigation is adversarial in
>> > a common law court. I
On 2017-08-13 17:43:10 -0400, Robert Haas wrote:
> On Sun, Aug 13, 2017 at 5:24 PM, Tom Lane wrote:
> >> I'd vote for including this in v10. There doesn't seem to be any
> >> downside to this: it's a no brainer to avoid our exploding hash table
> >> case when we can see it coming.
> >
> > Anybody
On Sun, Aug 13, 2017 at 3:05 PM, Tom Lane wrote:
> Not having heard anyone arguing against that, I'll go make it so,
> ie AtEOXact_CatCache is toast in all branches.
Great, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-ha
On Sun, Aug 13, 2017 at 5:24 PM, Tom Lane wrote:
>> I'd vote for including this in v10. There doesn't seem to be any
>> downside to this: it's a no brainer to avoid our exploding hash table
>> case when we can see it coming.
>
> Anybody else want to vote that way? For myself it's getting a bit l
Andres Freund writes:
> As a measure of last restart we could add a libpq workaround that forces
> a pqSocketCheck() at the right moment, while still establishing a
> connection. That's not good from an interruptability perspective, but
> better than blocking for the entire connection establishme
Thomas Munro writes:
> On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane wrote:
>> 1. check-hash-bucket-size-against-work_mem-2.patch from
>> https://www.postgresql.org/message-id/13698.1487283...@sss.pgh.pa.us
> +1
> I'd vote for including this in v10. There doesn't seem to be any
> downside to this:
On 2017-08-13 16:55:33 -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > I think that it's useful for these things to be handled in an
> > adversarial manner, in the same way that litigation is adversarial in
> > a common law court. I doubt that Noah actually set out to demoralize
> > anyone. H
"Augustine, Jobin" writes:
> Appears that patch is not helping.
> Errors like below are still appearing in the log
> ===
> 2017-08-11 12:22:35 UTC [2840]: [1-1] user=,db=,app=,client= FATAL: could
> not connect to the primary server: could not send data to server: Sock
Peter Geoghegan writes:
> I think that it's useful for these things to be handled in an
> adversarial manner, in the same way that litigation is adversarial in
> a common law court. I doubt that Noah actually set out to demoralize
> anyone. He is just doing the job he was assigned.
FWIW, I agree
On Fri, Jul 1, 2016 at 2:12 AM, I wrote:
> Currently the tuple returned by INSTEAD OF triggers on DELETEs is only
> used to determine whether to pretend that the DELETE happened or not, which
> is often not helpful enough; for example, the actual tuple might have been
> concurrently UPDATEd by ano
Andres Freund writes:
> On 2017-08-11 18:11:03 +0530, Augustine, Jobin wrote:
>> Appears that patch is not helping.
> That's too bad. Any chance you could install
> https://docs.microsoft.com/en-us/sysinternals/downloads/procmon and
> activate monitoring just for that phase? I think it can export
On Sun, Aug 13, 2017 at 12:57 PM, Andres Freund wrote:
> FWIW, I'm personally quite demotivated by this style of handling
> issues. You're essentially saying that any code change, even if it just
> increases exposure of a preexisting bug, needs to be handled by the
> committer of the exposing chan
Hi,
On 2017-08-11 18:11:03 +0530, Augustine, Jobin wrote:
> Appears that patch is not helping.
> Errors like below are still appearing in the log
> ===
> 2017-08-11 12:22:35 UTC [2840]: [1-1] user=,db=,app=,client= FATAL: could
> not connect to the primary server: coul
On 2017-08-11 20:56:22 -0700, Noah Misch wrote:
> > > If nobody volunteers, you could always resolve this by reverting 1e8a850
> > > and
> > > successors.
> >
> > I think you're blaming the victim. Our current theory about the cause
> > of this is that on Windows, WaitLatchOrSocket cannot be use
On Fri, Aug 11, 2017 at 08:56:22PM -0700, Noah Misch wrote:
> On Thu, Aug 10, 2017 at 09:59:40PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > On Tue, Aug 08, 2017 at 07:25:37PM -0400, Peter Eisentraut wrote:
> > >> I don't think I can usefully contribute to this. Could someone else
> > >>
Hi
2017-08-13 20:33 GMT+02:00 Fabien COELHO :
>
> Here is a v11.
>
> It is basically a simple rebase after Tom committed the "pgbench -M order"
> patch. It interfered because the compound command management also needs
> to delay part of the SQL command initialization. Some patch are luckier
> tha
On Thu, Aug 10, 2017 at 04:51:16AM +, Noah Misch wrote:
> On Mon, Aug 07, 2017 at 06:23:56PM -0400, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On 8/6/17 20:07, Peter Geoghegan wrote:
> > >> I've looked into this. I'll give an example of what keyword variants
> > >> there are for Greek,
On Thu, Aug 10, 2017 at 2:53 PM, Thomas Munro
wrote:
> The current regression tests, isolation tests and TAP tests are very
> good (though I admit my experience with TAP is limited), but IMHO we
> are lacking support for C-level unit testing. Complicated, fiddly
> things with many states, interac
Robert Haas writes:
> On Tue, Aug 8, 2017 at 10:48 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Aug 8, 2017 at 4:34 PM, Tom Lane wrote:
In the meantime, I think my vote would be to remove AtEOXact_CatCache.
>>> In all supported branches?
>> Whatever we do about this issue, I do
Here is a v11.
It is basically a simple rebase after Tom committed the "pgbench -M order"
patch. It interfered because the compound command management also needs
to delay part of the SQL command initialization. Some patch are luckier
than others:-)
Here is a v10:
- does not talk about ASCI
Andreas Seltenreich writes:
> Tom Lane writes:
>> I wonder if Andreas would be interested in trying the randomly-timed-
>> SIGTERM thing with sqlsmith.
> So far, most of the core dumps generated are Jeevan's assertion failing
> with backtraces through SearchCatCacheList. The rest is failing this
Hello Alik,
Now “a” does not have upper bound, that’s why on using iterative algorithm with a
>= 1 program will stuck on infinite loop because of following line of code:
double b = pow(2.0, s - 1.0);
Because after overflow “b” becomes “+Inf”.
Yep, overflow can happen.
So should upper b
Christoph Berg writes:
> Seems to be a gcc-7 problem affecting several packages on mips64el:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871514
Hm, unless there is a use of sigsetjmp earlier in that clamav
routine, I would not assume that that's the same issue. The bug
I suspect we are l
Christoph Berg writes:
> 10beta3 and 9.6.4 are both failing during initdb on mips64el on
> Debian/sid (unstable):
> All other architectures have succeeded, as well as the 9.6.4 build for
> Debian/stretch (stable) on mips64el. The difference might be the
> compiler version (6.3.0 vs 7.1.0).
It's h
Re: To PostgreSQL Hackers 2017-08-13
<20170813130127.g3tcyzzvuvlpz...@msg.df7cb.de>
> 10beta3 and 9.6.4 are both failing during initdb on mips64el on
> Debian/sid (unstable):
>
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0
> https
В Fri, 11 Aug 2017 14:05:08 -0400
Robert Haas пишет:
> On Thu, Aug 10, 2017 at 11:12 AM, Alexander Korotkov
> wrote:
> > These results look very cool!
> > I think CSN is eventually inevitable, but it's a long distance
> > feature. Thus, this optimization could make us a good serve before
> > we
Tom Lane writes:
> I wonder if Andreas would be interested in trying the randomly-timed-
> SIGTERM thing with sqlsmith.
So far, most of the core dumps generated are Jeevan's assertion failing
with backtraces through SearchCatCacheList. The rest is failing this
assertion:
TRAP: FailedAssertio
On Sun, Aug 13, 2017 at 5:21 PM, Amit Kapila
wrote:
> On Sat, Aug 12, 2017 at 10:34 AM, Haribabu Kommi
> wrote:
> >
> > On Tue, Aug 8, 2017 at 2:21 PM, Amit Kapila
> wrote:
> >>
> >> +typedef struct StorageAmRoutine
> >> +{
> >>
> >> In this structure, you have already covered most of the API's
On Fri, Aug 11, 2017 at 1:18 AM, Amit Kapila
wrote:
> On Wed, Aug 9, 2017 at 6:51 PM, Haribabu Kommi
> wrote:
> >
> >
> > + if (IsA(plan, Gather))
> > + ((Gather *) plan)->initParam = bms_intersect(plan->lefttree->extParam,
> > initSetParam);
> > + else if (IsA(plan, GatherMerge))
> > + ((Gather
10beta3 and 9.6.4 are both failing during initdb on mips64el on
Debian/sid (unstable):
https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.6&arch=mips64el&ver=9.6.4-1&stamp=1502374949&raw=0
https://buildd.debian.org/status/fetch.php?pkg=postgresql-10&arch=mips64el&ver=10%7Ebeta3-1&stamp=15
Hello Fabien,
>
> I think that this method should be used for a>1, and the other very rough one
> can be kept for parameter a in [0, 1), a case which does not make much sense
> to a mathematician as it diverges if unbounded.
Now “a” does not have upper bound, that’s why on using iterative algo
On 13/08/17 16:19, Thomas Munro wrote:
On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane wrote:
[...]
I'd vote for including this in v10. There doesn't seem to be any
downside to this: it's a no brainer to avoid our exploding hash table
case when we can see it coming.
But explosions are fun!
< duc
On Sat, Aug 12, 2017 at 10:34 AM, Haribabu Kommi
wrote:
>
> On Tue, Aug 8, 2017 at 2:21 PM, Amit Kapila wrote:
>>
>> On Tue, Jun 13, 2017 at 7:20 AM, Haribabu Kommi
>> wrote:
>> >
>> >
>> > On Fri, Oct 14, 2016 at 7:26 AM, Alvaro Herrera
>> >
>> > wrote:
>> >>
>> >> I have sent the partial patc
On Sat, Aug 12, 2017 at 10:31 AM, Haribabu Kommi
wrote:
>>
>> Why do we need to store handler function in TupleDesc? As of now, the
>> above patch series has it available in RelationData and
>> TupleTableSlot, I am not sure if instead of that keeping it in
>> TupleDesc is a good idea. Which all
48 matches
Mail list logo