On Thursday, May 18, 2017, Robert Haas wrote:
> My experience with this area has led
> me to give up on the idea of complete uniformity as impractical, and
> instead look at it from the perspective of "what do we absolutely have
> to ban in order for this to be sane?".
I could agree to something
On 2017/05/19 15:16, Thomas Munro wrote:
> On Fri, May 19, 2017 at 5:51 PM, Amit Langote
> wrote:
>> I saw in the latest patch that now ExecSetupTriggerTransitionState() looks
>> at mtstate->mt_partition_dispatch_info when setting up the transition
>> conversion map. In the case where it's non-NU
On Fri, May 19, 2017 at 5:51 PM, Amit Langote
wrote:
> I saw in the latest patch that now ExecSetupTriggerTransitionState() looks
> at mtstate->mt_partition_dispatch_info when setting up the transition
> conversion map. In the case where it's non-NULL, you may have realized
> that mt_transition_t
On Fri, May 19, 2017 at 11:05 AM, Michael Paquier
wrote:
> On Thu, May 18, 2017 at 1:43 PM, Thomas Munro
> wrote:
>> On Thu, May 11, 2017 at 1:48 PM, Michael Paquier
>> wrote:
>>> I had my eyes on the WAL sender code this morning, and I have noticed
>>> that walsender.c is not completely consist
On 2017/05/19 14:01, Thomas Munro wrote:
> On Fri, May 19, 2017 at 1:38 AM, Kevin Grittner wrote:
>> On Thu, May 18, 2017 at 5:16 AM, Amit Langote
>> wrote:
>>
>>> Do we need to update documentation? Perhaps, some clarification on the
>>> inheritance/partitioning behavior somewhere.
>>
>> Yeah,
Hi,
While testing table synchronization in logical replication, I found
that multiple table synchronizations for a subscription are processed
serially due to lock wait.
I setup pgbench tables on publisher (scalefactor = 1000) and on
subscriber, and truncated these tables on subscriber, and then c
On Fri, May 19, 2017 at 1:38 AM, Kevin Grittner wrote:
> On Thu, May 18, 2017 at 5:16 AM, Amit Langote
> wrote:
>
>> Do we need to update documentation? Perhaps, some clarification on the
>> inheritance/partitioning behavior somewhere.
>
> Yeah, I think so.
Here is an attempt at documenting the
On 2017/05/19 1:09, Dilip Kumar wrote:
> On Wed, May 17, 2017 at 2:07 PM, amul sul wrote:
>>> I would suggest "non-zero positive", since that's what we are using in
>>> the documentation.
>>>
>>
>> Understood, Fixed in the attached version.
>
> Why non-zero positive? We do support zero for the r
On Fri, May 19, 2017 at 1:16 PM, Higuchi, Daisuke
wrote:
> The reason of this problem is that sending 'show transaction_read_only' is
> failed.
> 'show' must be in uppercase letters because the streaming replication
> protocol only accepts capital letters.
> In psql and libpq applications that d
On 2017/05/19 11:02, Peter Eisentraut wrote:
> On 5/18/17 19:07, Thomas Munro wrote:
>> To make normal dump/restore preserve the order, we could either make
>> it *always* write create-then-attach, or do it only if required. I'd
>> vote for doing it only if required because of different column ord
Hello,
I found a problem with libpq connection failover.
If primary_conninfo in recovery.conf has 'target_session_attrs=read-write', the
standby fails to start.
How to reproduce the bug:
1. Prepare two standby (standby_1, standby_2) for one master.
On standby_1, primary_conninfo in recove
Hi,
> * 10 Beta Release Notes:
> https://www.postgresql.org/docs/devel/static/release-10.html
Just a minute thing, but changing of hot_standby default value is not fully
noted in release-10.sgml.
Please find the attached patch.
---
Thanks and best regards,
Dang Minh Huong
NEC Solution Innova
Hello,
At Thu, 18 May 2017 10:16:35 -0400, Robert Haas wrote
in
> On Wed, May 17, 2017 at 6:58 AM, Masahiko Sawada
> wrote:
> > I think the above changes can solve this issue but It seems to me that
> > holding AccessExclusiveLock on pg_subscription by DROP SUBSCRIPTION
> > until commit could
2017-05-19 3:14 GMT+02:00 Peter Eisentraut :
> On 5/15/17 14:34, Pavel Stehule wrote:
> > Now, I when I working on plpgsql_check, I have to check function
> > parameters. I can use fn_vargargnos and out_param_varno for list of
> > arguments and related varno(s). when I detect some issu
On Fri, May 19, 2017 at 12:17 PM, Bossart, Nathan wrote:
> Just in case it was missed among the discussion, I’d like to point out that
> v5 of the patch includes the “ERROR if ANALYZE not specified” change.
As long as I don't forget...
+VACUUM vactst (i);
Looking at the tests of v5, I think tha
Hello, thank you for the reply.
At Thu, 18 May 2017 20:48:44 -0400, Peter Eisentraut
wrote in
<343d4cdb-e25d-867d-2830-6502eca4d...@2ndquadrant.com>
> On 5/10/17 04:38, Kyotaro HORIGUCHI wrote:
> > Hi. While I read the documentation I found the following
> > description about some columns in pg
On 5/18/17, 8:03 PM, "Tom Lane" wrote:
>”Bossart, Nathan" writes:
>> On 5/18/17, 6:12 PM, "Michael Paquier" wrote:
>>> Fine for me as well. I would suggest to split the patch into two parts
>>> to ease review then:
>>> - Rework this error handling for one relation.
>>> - The main patch.
>>
>> I’
"Bossart, Nathan" writes:
> On 5/18/17, 6:12 PM, "Michael Paquier" wrote:
>> Fine for me as well. I would suggest to split the patch into two parts
>> to ease review then:
>> - Rework this error handling for one relation.
>> - The main patch.
> I’d be happy to do so, but I think part one would b
On 5/18/17, 6:12 PM, "Michael Paquier" wrote:
> Fine for me as well. I would suggest to split the patch into two parts
> to ease review then:
> - Rework this error handling for one relation.
> - The main patch.
I’d be happy to do so, but I think part one would be pretty small, and almost
all of
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> > One thing I'm worried is that people here might become more conservative
> against change once the final version is released.
>
> Any redesign after release would finish by bein
On Wed, Apr 12, 2017 at 5:31 AM, Simon Riggs wrote:
> On 22 March 2017 at 02:50, Masahiko Sawada wrote:
>
>> When using logical replication, I ran into a situation where the
>> pg_stat_replication.state is not updated until any wal record is sent
>> after started up. For example, I set up logical
I wrote:
> Curiously, there are other enum declarations that don't get the phony
> extra indentation. I traced through it a bit and eventually found that
> the difference between OK and not OK is that the declarations that don't
> get messed up look like "typedef enum enumlabel ...", ie the proble
On 5/18/17 11:11, Noah Misch wrote:
> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is past due for
> your status update. Please reacquaint yourself with the policy on open item
> ownership[1] and then reply immediately. If I do not hear from you by
> 2017-05-19 16:00 UTC, I will tr
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> On Thu, May 18, 2017 at 11:30 PM, Robert Haas wrote:
> > Because why?
>
> Because it is critical to let the user know as well *why* an error happened.
> Imagine that this feature
On Wed, May 17, 2017 at 1:30 AM, Robert Haas wrote:
> On Sat, May 13, 2017 at 7:27 AM, Amit Kapila wrote:
>> On Fri, May 12, 2017 at 9:14 AM, Tom Lane wrote:
>>> Robert Haas writes:
On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada
wrote:
> ... I'd like to propose to change relat
On Fri, May 19, 2017 at 11:01 AM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut
>> The problem is that if we decide to change the behavior mid-beta, then we'll
>> only have the rest of beta to find
On Thu, May 18, 2017 at 1:43 PM, Thomas Munro
wrote:
> On Thu, May 11, 2017 at 1:48 PM, Michael Paquier
> wrote:
>> I had my eyes on the WAL sender code this morning, and I have noticed
>> that walsender.c is not completely consistent with the PID lookups it
>> does in walsender.c. In two code pa
On 5/18/17 19:07, Thomas Munro wrote:
> To make normal dump/restore preserve the order, we could either make
> it *always* write create-then-attach, or do it only if required. I'd
> vote for doing it only if required because of different column order,
> because I don't want to see 1,000 partitions
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut
> The problem is that if we decide to change the behavior mid-beta, then we'll
> only have the rest of beta to find out whether people will like the other
> behavior.
>
> I would ai
On 5/17/17 01:26, Masahiko Sawada wrote:
> While reading documentation I found refresh_option syntax of ALTER
> SUBSCRIPTION in documentation is not correct.
>
> ALTER SUBSCRIPTION ... REFRESH PUBLICATION WITH (refresh_option value [, ...]
> )
> should be changed to
> ALTER SUBSCRIPTION ... REFRE
On Fri, May 19, 2017 at 9:54 AM, Peter Eisentraut
wrote:
> On 5/12/17 13:25, Masahiko Sawada wrote:
>>> postgres=# alter subscription sub set publication pub refresh;
>>> NOTICE: removed subscription for table public.t1
>>> NOTICE: removed subscription for table public.t2
>>> ALTER SUBSCRIPTION
On 5/15/17 14:34, Pavel Stehule wrote:
> Now, I when I working on plpgsql_check, I have to check function
> parameters. I can use fn_vargargnos and out_param_varno for list of
> arguments and related varno(s). when I detect some issue, I am using
> refname. It is not too nice now, b
On Fri, May 19, 2017 at 10:00 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Fri, May 19, 2017 at 9:06 AM, Michael Paquier
>> wrote:
>>> I am fine with an ERROR if a column list is specified without ANALYZE
>>> listed in the options. But that should happen as well for the case
>>> where onl
On 5/17/17 13:19, Tom Lane wrote:
> I agree with Robert's point that major redesign of the feature on the
> basis of one complaint isn't necessarily the way to go. Since the
> existing behavior is already out in beta1, let's wait and see if anyone
> else complains. We don't need to fix it Right T
Michael Paquier writes:
> On Fri, May 19, 2017 at 9:06 AM, Michael Paquier
> wrote:
>> I am fine with an ERROR if a column list is specified without ANALYZE
>> listed in the options. But that should happen as well for the case
>> where only one relation is listed.
> Perhaps this could be changed
On 5/12/17 13:25, Masahiko Sawada wrote:
>> postgres=# alter subscription sub set publication pub refresh;
>> NOTICE: removed subscription for table public.t1
>> NOTICE: removed subscription for table public.t2
>> ALTER SUBSCRIPTION
>>
>> I think - in publication too ,we should provide NOTICE m
On 2017/05/19 3:06, Robert Haas wrote:
> On Tue, May 16, 2017 at 8:19 PM, Amit Langote
> wrote:
>> Thanks for the review. I updated the comments.
>
> I found several more places that also needed to be updated using 'git
> grep'. Committed with various additions.
Thanks a lot.
Regards,
Amit
On 5/10/17 04:38, Kyotaro HORIGUCHI wrote:
> Hi. While I read the documentation I found the following
> description about some columns in pg_stat_bgwriter.
>
> https://www.postgresql.org/docs/devel/static/monitoring-stats.html#pg-stat-bgwriter-view
>
> This table shows cluster-global values, not
The issues with the different column orders in the regression test
database also revealed that logical replication table syncing was broken
for that case. Here is a fix and a test.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Trai
On Thu, May 18, 2017 at 11:30 PM, Robert Haas wrote:
> On Thu, May 18, 2017 at 7:06 AM, Michael Paquier
> wrote:
>> FWIW, I am of the opinion to not have an implementation based on any
>> SQLSTATE codes, as well as not doing something similar to JDBC.
>> Keeping things simple is one reason, a sec
On Fri, May 19, 2017 at 9:06 AM, Michael Paquier
wrote:
> I am fine with an ERROR if a column list is specified without ANALYZE
> listed in the options. But that should happen as well for the case
> where only one relation is listed.
Perhaps this could be changed for 10? Changing the behavior in
On Fri, May 19, 2017 at 12:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> Ugh, really? Are we sure that the current behavior is anything other
>> than a bug?
Point was raised already upthread by me ince, which is what lead me to
the reasoning of my last argument:
https://www.postgresql.org/mes
Peter Eisentraut wrote:
> On 5/18/17 16:21, Thomas Munro wrote:
> > That's because if you attach a partition with a different column
> > ordering,
>
> Is it intentional and sensible to allow that in the first place? Or was
> it just inherited from inheritance?
I think it was deliberately allowed
On Fri, May 19, 2017 at 10:53 AM, Peter Eisentraut
wrote:
> On 5/18/17 16:21, Thomas Munro wrote:
>> That's because if you attach a partition with a different column
>> ordering,
>
> Is it intentional and sensible to allow that in the first place? Or was
> it just inherited from inheritance?
Can
On 5/18/17 16:21, Thomas Munro wrote:
> That's because if you attach a partition with a different column
> ordering,
Is it intentional and sensible to allow that in the first place? Or was
it just inherited from inheritance?
> pg_dump dumps it with a normal CREATE TABLE ... PARTITION OF
> ... co
Piotr Stefaniak writes:
> On 2017-05-17 23:46, Tom Lane wrote:
>> ... Much of what
>> I'm seeing with this version is randomly different decisions about
>> how far to indent comments
> pgindent doesn't set the -c indent option ("The column in which comments
> on code start."), so indent uses the
On 2017-05-15 10:34:02 -0400, Peter Eisentraut wrote:
> On 5/10/17 09:12, Michael Paquier wrote:
> > Looking at 0001 and 0002... So you are correctly blocking nextval()
> > when ALTER SEQUENCE holds a lock on the sequence object. And
> > concurrent calls of nextval() don't conflict. As far as I can
On 2017-05-18 18:13, Tom Lane wrote:
> Piotr Stefaniak writes:
>> That, I assume, would be me. Coincidentally, I'm about to push my fixes
>> upstream (FreeBSD). Before that happens, my changes can be obtained from
>> https://github.com/pstef/freebsd_indent and tested, if anyone wishes.
>
> I spen
On 2017-05-17 23:46, Tom Lane wrote:
> I hacked around that by putting back a detab/entab step at the end
> using the existing subroutines in pgindent. That about halved the
> size of the diff, but it's still too big to post. Much of what
> I'm seeing with this version is randomly different decis
On Fri, May 19, 2017 at 7:21 AM, Peter Eisentraut
wrote:
> But this is a bit more suspicious:
>
> Original:
>
> Table "public.mlparted11"
> Column | Type | Collation | Nullable | Default
> +-+---+--+-
> b | integer | | not nu
Peter Eisentraut writes:
> When you dump out the regression test database and load it back in, a
> few tables end up with different column orders:
> ...
> This table is part of a lengthy inheritance chain, so this might be
> intentional or too hard to fix. This behavior goes back to 9.2 and
> pos
Re: Peter Eisentraut 2017-05-18
<7a4d3b0f-78da-2a5b-7f3b-8b3509c1e...@2ndquadrant.com>
> If we had a typo or something in that code, the build farm should have
> caught it by now.
>
> I would try compiling with lower -O and see what happens.
Trying -O0 now.
Re: Andres Freund 2017-05-18 <2017051
On 05/18/2017 12:31 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2017-05-18
I'll commit that, barring objections. If you can verify that it fixes the
problem before that, that'd be great, otherwise I guess we'll find out some
time after the commit.
Please go ahead, I don't think I have on
When you dump out the regression test database and load it back in, a
few tables end up with different column orders:
Original:
Table "public.f_star"
Column | Type | Collation | Nullable | Default
+--+---+--+-
class | charact
On 5/18/17 10:11, Tom Lane wrote:
> Well, that's just wacko. Somehow sequence.c's init_params() must
> be falling down on the job in selecting the right seqform->seqmin,
> but I'm darned if I see anything that's either wrong or potentially
> machine-dependent in that code. It almost looks like it
On 2017-05-18 10:11:48 -0400, Tom Lane wrote:
> Christoph Berg writes:
> > *** 34,44
> > --- 34,47
> > CREATE SEQUENCE sequence_test7 AS bigint;
> > CREATE SEQUENCE sequence_test8 AS integer MAXVALUE 10;
> > CREATE SEQUENCE sequence_test9 AS integer INCREMENT BY -1;
> > + ERROR
On Tue, May 16, 2017 at 8:19 PM, Amit Langote
wrote:
> Thanks for the review. I updated the comments.
I found several more places that also needed to be updated using 'git
grep'. Committed with various additions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
On 2017-05-18 11:57:57 +0300, Konstantin Knizhnik wrote:
> From my own experience I found out that PG_TRY/PG_CATCH mechanism is not
> providing proper cleanup (unlike C++ exceptions).
Right, simply because there's no portable way to transparently do so.
Would be possible on elf glibc platforms, bu
Hi,
On 2017-05-18 19:00:09 +0300, Marina Polyakova wrote:
> > Here's v2 of the patches. Changes from v1:
>
> And here there's v3 of planning and execution: common executor steps for all
> types of cached expression.
I've not followed this thread, but just scanned this quickly because it
affects
Piotr Stefaniak writes:
> That, I assume, would be me. Coincidentally, I'm about to push my fixes
> upstream (FreeBSD). Before that happens, my changes can be obtained from
> https://github.com/pstef/freebsd_indent and tested, if anyone wishes.
I spent a little bit of time on portability testing,
Here's v2 of the patches. Changes from v1:
And here there's v3 of planning and execution: common executor steps for
all types of cached expression.
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres CompanyFrom 5e89221251670526eb2b5750868ac73eee48f10b M
On Wed, May 17, 2017 at 2:07 PM, amul sul wrote:
>> I would suggest "non-zero positive", since that's what we are using in
>> the documentation.
>>
>
> Understood, Fixed in the attached version.
Why non-zero positive? We do support zero for the remainder right?
--
Regards,
Dilip Kumar
Enterpri
On 2017-05-18 10:48:48 +0300, Heikki Linnakangas wrote:
> If that's all that prevents it from working, by all means let's fix it. I
> think this should do it, although I don't have a system to test it on:
Yes, that's what I thought about doing too.
> It adds a few instructions to check that on a
On Fri, May 19, 2017 at 12:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> Ugh, really? Are we sure that the current behavior is anything other
>> than a bug? The idea that VACUUM foo (a) implies ANALYZE doesn't
>> really sit very well with me in the first place. I'd be more inclined
>> to rej
On Mon, May 15, 2017 at 03:28:14AM +, Noah Misch wrote:
> On Mon, May 08, 2017 at 06:27:30PM +0900, Masahiko Sawada wrote:
> > I encountered a situation where DROP SUBSCRIPTION got stuck when
> > initial table sync is in progress. In my environment, I created
> > several tables with some data o
Robert Haas writes:
> Ugh, really? Are we sure that the current behavior is anything other
> than a bug? The idea that VACUUM foo (a) implies ANALYZE doesn't
> really sit very well with me in the first place. I'd be more inclined
> to reject that with an ERROR complaining that the column list c
On Thu, May 18, 2017 at 2:45 AM, Masahiko Sawada wrote:
> On Thu, May 18, 2017 at 3:19 PM, Michael Paquier
> wrote:
>> On Thu, May 18, 2017 at 2:59 PM, Masahiko Sawada
>> wrote:
>>> It seems to me that it's not good idea to forcibly set ANALYZE in
>>> spite of ANALYZE option is not specified.
On Thu, May 18, 2017 at 2:52 AM, Dilip Kumar wrote:
> Most of the queries show decent improvement, however, Q14 shows
> regression at work_mem = 4MB. On analysing this case, I found that
> number of pages_fetched calculated by "Mackert and Lohman formula" is
> very high (1112817) compared to the a
On Thu, May 18, 2017 at 7:06 AM, Michael Paquier
wrote:
> FWIW, I am of the opinion to not have an implementation based on any
> SQLSTATE codes, as well as not doing something similar to JDBC.
> Keeping things simple is one reason, a second is that the approach
> taken by libpq is correct at its r
On Wed, May 17, 2017 at 6:57 AM, Amit Kapila wrote:
> +1. Why not similar behavior for any other statements executed in
> this module by do_sql_command?
The other cases are not quite the same situation. It would be good to
accept interrupts in all cases, but there's no problem with a session
co
On Wed, May 17, 2017 at 6:58 AM, Masahiko Sawada wrote:
> I think the above changes can solve this issue but It seems to me that
> holding AccessExclusiveLock on pg_subscription by DROP SUBSCRIPTION
> until commit could lead another deadlock problem in the future. So I'd
> to contrive ways to redu
Christoph Berg writes:
> *** 34,44
> --- 34,47
> CREATE SEQUENCE sequence_test7 AS bigint;
> CREATE SEQUENCE sequence_test8 AS integer MAXVALUE 10;
> CREATE SEQUENCE sequence_test9 AS integer INCREMENT BY -1;
> + ERROR: MINVALUE (-9223372036854775808) is out of range for seque
On Thu, May 18, 2017 at 1:53 AM, Jeff Davis wrote:
> For instance, it makes little sense to have individual check
> constraints, indexes, permissions, etc. on a hash-partitioned table.
> It doesn't mean that we should necessarily forbid them, but it should
> make us question whether combining rang
hey Vaishnavi
>
> I think GUC's name can be something like "multiple_query_execution" and
> setting it ON/OFF will be better. I think others will also come up with
> some suggestions here as the current name doesn't go well with other
> existing GUCs.
>
Thank you very much for the suggestion multi
On Thu, May 18, 2017 at 5:16 AM, Amit Langote
wrote:
> Do we need to update documentation? Perhaps, some clarification on the
> inheritance/partitioning behavior somewhere.
Yeah, I think so.
> -Assert((enrmd->reliddesc == InvalidOid) != (enrmd->tupdesc == NULL));
> +Assert((enrmd->reli
The patch fixed the problem, thanks a lot.
Regards,
Sveinn.
On fim 18.maí 2017 01:53, Amit Langote wrote:
> On 2017/05/18 10:49, Amit Langote wrote:
>> On 2017/05/18 2:14, Dilip Kumar wrote:
>>> On Wed, May 17, 2017 at 7:41 PM, wrote:
(gdb) bt
#0 0x0061ab1b in list_nth ()
On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar wrote:
> On Wed, May 17, 2017 at 3:15 PM, Amit Kapila wrote:
>>> Earlier I thought that option1 is better but later I think that this
>>> can complicate the situation as we are firing first BR update then BR
>>> delete and can change the row multiple t
On Thu, May 18, 2017 at 5:05 PM, Tsunakawa, Takayuki
wrote:
> So, how about trying connection to the next host when the class code is
> neither 28, 3D, nor 42?
>
> Honestly, I'm not happy with this approach, for a maintenance reason that
> others are worried about. Besides, when the connection
On 2017/05/18 7:13, Thomas Munro wrote:
> On Wed, May 17, 2017 at 7:42 PM, Thomas Munro
> wrote:
>> On Wed, May 17, 2017 at 6:04 PM, Amit Langote
>> wrote:
>>> targetRelInfo should instead be set to mtstate->rootResultRelInfo that was
>>> set in ExecInitModifyTable() as described above, IOW, as f
Re: Heikki Linnakangas 2017-05-18
> I'll commit that, barring objections. If you can verify that it fixes the
> problem before that, that'd be great, otherwise I guess we'll find out some
> time after the commit.
Please go ahead, I don't think I have online access to a m68k machine.
(It got demot
On 15.05.2017 18:31, Robert Haas wrote:
On Wed, May 10, 2017 at 12:11 PM, Konstantin Knizhnik
wrote:
Robert, can you please explain why using TRY/CATCH is not safe here:
This is definitely not a safe way of using TRY/CATCH.
This has been discussed many, many times on this mailing list befor
On Thu, Apr 6, 2017 at 6:37 AM, Robert Haas wrote:
>
>> There's a relevant comment in 0006, build_joinrel_partition_info()
>> (probably that name needs to change, but I will do that once we have
>> settled on design)
>> + /*
>> +* Construct partition keys for the join.
>> +*
>> +* An
I've been analyzing a reported regression case between a 9.5 plan and
a 9.6 plan. I tracked this down to the foreign key join selectivity
code, specifically the use_smallest_selectivity code which is applied
to outer joins where the referenced table is on the outer side of the
join.
A vastly simpl
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
> Takayuki
> Done. I'll examine whether we can use SQLSTATE.
I tried conceivable errors during connection. Those SQLSTATEs are as follows:
[transient error (after which you may want to
Ahoj
viz http://blog.cleverelephant.ca/2017/05/great-postgresql.html
Pavel
On 05/17/2017 10:39 PM, Christoph Berg wrote:
Not sure if a lot of people still care about m68k, but it's still one
of the unofficial Debian ports (it used to be the first non-x86 port
done decades ago):
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
On 05/18/2017 10:17 AM, Daniel Gustafsson wrote:
Spotted while reading code, patch attached.
Applied, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Spotted while reading code, patch attached.
cheers ./daniel
typo-json.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
88 matches
Mail list logo
