On Fri, Dec 20, 2019 at 5:17 PM Prabhat Sahu
wrote:
> Hi,
>
> While testing this feature with parallel vacuum on "TEMPORARY TABLE", I
> got a server crash on PG Head+V36_patch.
>
>From the call stack, it is not clear whether it is related to a patch at
all. Have you checked your test with and w
On Sat, Dec 21, 2019 at 04:25:05PM -0500, Tom Lane wrote:
Nikolay Samokhvalov writes:
Here is what ORMs do:
select length('SELECT "column_name_1001", "column_name_1002",
"column_name_1003", "column_name_1004", "column_name_1005",
"column_name_1006", "column_name_1007", "column_name_1008",
"colu
On Sat, Dec 21, 2019 at 03:42:21PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Do we need a C comment to document why no whitespace is allowed
> > before it?
>
> Probably, else we may not remember next time somebody wants to
> change it.
Done, applied to master only.
--
Bruce Momjian
Nikolay Samokhvalov writes:
> Here is what ORMs do:
> select length('SELECT "column_name_1001", "column_name_1002",
> "column_name_1003", "column_name_1004", "column_name_1005",
> "column_name_1006", "column_name_1007", "column_name_1008",
> "column_name_1009", "column_name_1010", "column_name_101
I wrote:
> As far as point 2 goes, I think this is another outgrowth of the
> fundamental design error that we load a partitioned rel's partitioning
> info immediately when the relcache entry is created, rather than later
> on-demand. If we weren't doing that then it wouldn't be problematic
> to i
Here is what ORMs do:
select length('SELECT "column_name_1001", "column_name_1002",
"column_name_1003", "column_name_1004", "column_name_1005",
"column_name_1006", "column_name_1007", "column_name_1008",
"column_name_1009", "column_name_1010", "column_name_1011",
"column_name_1012", "column_name_1
Bruce Momjian writes:
> Do we need a C comment to document why no whitespace is allowed
> before it?
Probably, else we may not remember next time somebody wants to
change it.
regards, tom lane
On Tue, Dec 10, 2019 at 05:46:48PM -0500, Tom Lane wrote:
> "Bossart, Nathan" writes:
> > I noticed that pg_control_init() is failing an assertion on 13devel:
>
> Hmm, yeah. In a non-assert build I get
>
> regression=# select * from pg_control_init();
> ERROR: function return row and query-spe
Le sam. 21 déc. 2019 à 18:46, Bruce Momjian a écrit :
> On Thu, Dec 5, 2019 at 11:45:09PM +0100, Daniel Gustafsson wrote:
> > > On 5 Dec 2019, at 10:17, Julien Rouhaud wrote:
> >
> > > While reading pg_upgrade code to restore the objects on the new
> > > cluster, I noticed that 5b570d771b8 didn
On Sat, Dec 7, 2019 at 12:58:12PM -0500, Tom Lane wrote:
> "Shinoda, Noriyoshi (PN Japan A&PS Delivery)"
> writes:
> > I propose a small improvement to the psql command.
> > Currently, psql's help/quit/exit command needs to start from the first
> > position of the prompt.
> > The attached patch
I just had to retrieve my jaw from the floor after reading this
bit in RelationBuildPartitionDesc:
* The system cache may be out of date; if so, we may find no pg_class
* tuple or an old one where relpartbound is NULL. In that case, try
* the table directly. We can't j
On Thu, Dec 5, 2019 at 11:45:09PM +0100, Daniel Gustafsson wrote:
> > On 5 Dec 2019, at 10:17, Julien Rouhaud wrote:
>
> > While reading pg_upgrade code to restore the objects on the new
> > cluster, I noticed that 5b570d771b8 didn't adjust the database name in
> > the comments explaining the re
Amit Langote writes:
> On Wed, Dec 18, 2019 at 10:38 PM Tom Lane wrote:
>> My point is basically that CheckAttributeType already covers that
>> issue, as well as a lot of others. So why isn't the partitioning
>> code using it?
> My reason to not use it was that the error message that are produc
On Fri, Dec 20, 2019 at 05:57:55PM +, Simon Riggs wrote:
On Fri, 20 Dec 2019 at 17:46, Tom Lane wrote:
Simon Riggs writes:
> On Fri, 20 Dec 2019 at 13:07, Robert Haas wrote:
>> With regard to this point, I second Tomas's comments.
> I also agree with Tomas' comments. I am explaining *wh
> 21 дек. 2019 г., в 2:19, Tom Lane написал(а):
>
> Andrey Borodin writes:
>> I think proper solution here would be to add GUC to disallow cancellation of
>> synchronous replication.
>
> This sounds entirely insane to me. There is no possibility that you
> can prevent a failure from occurr
On Fri, Dec 20, 2019 at 11:07 AM Andrey Borodin wrote:
> I think changing synchronous_standby_names to some available standbys will
> resume all backends waiting for synchronous replication.
> Do we need to check necessity of synchronous replication in any other case?
The GUCs are not re-checked
On Sat, Dec 21, 2019 at 7:38 PM Peter Eisentraut
wrote:
> On 2019-10-29 03:33, Thomas Munro wrote:
> > Seems to work as described with -E UTF-8, but it fails with clusters
> > using -E SQL_ASCII. That causes the pg_upgrade check to fail on
> > machines where that is the default encoding chosen by
17 matches
Mail list logo
