At Tue, 21 May 2019 14:31:32 +0900, Michael Paquier wrote
in <20190521053132.gg1...@paquier.xyz>
> On Mon, May 20, 2019 at 09:55:59AM -0400, Robert Haas wrote:
> > Well, it's confusing that we're not consistent about which spellings
> > are accepted. The GUC system accepts true/false, on/off, an
>
>
>> Is there anything preventing us from having the planner resolve object
>> names from strings?
>>
>
> The basic problem is fact so when you use PREPARE, EXECUTE protocol, you
> has not parameters in planning time.
>
I agree that it defeats PREPARE as it is currently implemented with
PQprepar
On Tue, May 21, 2019 at 8:17 AM Andres Freund wrote:
>
>
>Add command to create
>new table types (Haribabu Kommi, Andres Freund, Álvaro Herrera,
>Dimitri Dolgov)
>
>
> A few points:
>
> 1) Is this really source code, given that CREATE ACCESS METHOD TYPE
>
út 21. 5. 2019 v 9:04 odesílatel Corey Huinker
napsal:
>
>>> Is there anything preventing us from having the planner resolve object
>>> names from strings?
>>>
>>
>> The basic problem is fact so when you use PREPARE, EXECUTE protocol, you
>> has not parameters in planning time.
>>
>
> I agree tha
вт, 21 мая 2019 г. в 08:43, Michael Paquier :
>
> On Mon, May 20, 2019 at 02:32:39PM +0300, Matwey V. Kornilov wrote:
> > This patch series is to add support for spgist quadtree @<(point,circle)
> > operator. The first two patches are to refactor existing code before
> > implemention the new featur
On Mon, May 20, 2019 at 09:16:32AM -0400, Robert Haas wrote:
> Based on the discussion so far, I think there are a number of related
> problems here:
Thanks for the summary.
> 1. A base backup might copy the main fork but not the init fork. I
> think that's a problem that nobody's thought about b
On Tue, May 21, 2019 at 09:31:48AM +0300, Surafel Temesgen wrote:
> Commit 578b229718e8f remove oids option from pg_dump but its is
> still in pg_dumpall .The attach patch remove it
Good catch. Your cleanup looks correct to me. Andres, perhaps you
would prefer doing the cleanup yourself?
--
Mich
Robert Haas wrote:
> It seems to me that it's better to unwind the stack i.e. have the
> function return the error information to the caller and let the caller
> do as it likes.
Thanks for a hint. The next version tries to do that.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
Thi
Perhaps it's just a matter of taste, but I think the TupleTableSlotOps
structure, once initialized, should be used wherever possible. At least for me
personally, when I read the code, the particular callback function name is a
bit disturbing wherever it's not necessary.
--
Antonin Houska
Web: htt
Hello.
At Mon, 20 May 2019 15:54:30 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190520.155430.215084510.horiguchi.kyot...@lab.ntt.co.jp>
> > I suspect the design in the https://postgr.es/m/559fa0ba.3080...@iki.fi last
> > paragraph will be simpler, not more complex. In the imple
On Tue, May 21, 2019 at 4:17 AM Michael Paquier wrote:
> > 2. Suppose the system reaches the end of
> > heapam_relation_set_new_filenode and then the system crashes. Because
> > of the smgrimmedsync(), and only because of the smgrimmedsync(), the
> > init fork would exist at the start of recovery
On Tue, May 21, 2019 at 8:02 AM Antonin Houska wrote:
> Perhaps it's just a matter of taste, but I think the TupleTableSlotOps
> structure, once initialized, should be used wherever possible. At least for me
> personally, when I read the code, the particular callback function name is a
> bit distu
Michael Paquier writes:
> On Mon, May 20, 2019 at 09:55:59AM -0400, Robert Haas wrote:
>> Well, it's confusing that we're not consistent about which spellings
>> are accepted. The GUC system accepts true/false, on/off, and 0/1, so
>> it seems reasonable to me to standardize on that treatment acro
On 2019-05-21 00:17, Andres Freund wrote:
>
>
>
>
> Reduce locking requirements for index renaming (Peter Eisentraut)
>
>
>
> Should we specify the newly required lock level? Because it's quire
> relevant for users what exactly they're now able to do concurr
David Rowley writes:
> I did add the following query just before the failing one and included
> the expected output from below. The tests pass for me in make check
> and the post-upgrade test passes in make check-world too. I guess we
> could commit that and see if it fails along with the other
Robert Haas wrote:
> On Tue, May 21, 2019 at 8:02 AM Antonin Houska wrote:
> > Perhaps it's just a matter of taste, but I think the TupleTableSlotOps
> > structure, once initialized, should be used wherever possible. At least for
> > me
> > personally, when I read the code, the particular callb
Hi,
On 2019-05-21 16:00:25 +0900, Kyotaro HORIGUCHI wrote:
> At Tue, 21 May 2019 14:31:32 +0900, Michael Paquier
> wrote in <20190521053132.gg1...@paquier.xyz>
> > On Mon, May 20, 2019 at 09:55:59AM -0400, Robert Haas wrote:
> > > Well, it's confusing that we're not consistent about which spelli
Hi,
On 2019-05-20 10:29:29 -0400, Robert Haas wrote:
> From 4e361bfe51810d7c637bf57968da2dfea4197701 Mon Sep 17 00:00:00 2001
> From: Robert Haas
> Date: Fri, 17 May 2019 16:01:47 -0400
> Subject: [PATCH v2] tableam: Move heap-specific logic from needs_toast_table
> below tableam.
Assuming you
On Tue, May 21, 2019 at 11:53 AM Andres Freund wrote:
> Assuming you didn't sneakily change the content of
> heapam_relation_needs_toast_table from its previous behaviour, this
> looks good to me ;)
git diff --color-moved=zebra says I didn't.
Committed; thanks for the review.
--
Robert Haas
En
On Tue, May 21, 2019 at 10:48 AM Antonin Houska wrote:
> Do you refer to the fact that for example the address of
>
> tts_virtual_clear(dstslot);
>
> is immediately available in the text section while in this case
>
> dstslot->tts_ops->clear(dstslot);
>
> the CPU first needs to fet
Hi,
Sorry for the late response.
On 2019-04-16 12:27:46 +0530, Amit Khandekar wrote:
> On Sat, 13 Apr 2019 at 00:57, Andres Freund wrote:
> > > Not sure why this is happening. On slave, wal_level is logical, so
> > > logical records should have tuple data. Not sure what does that have
> > > to d
On Wed, May 15, 2019 at 1:53 PM Tom Lane wrote:
> >> That seems too confusing.
>
> > Ok. Are you voting for using EXEC as a keyword to replace ANALYZE?
>
> FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name",
> we should probably just drop the whole idea. It seemed like a great
Hi,
On 2019-05-21 12:16:22 -0400, Robert Haas wrote:
> On Tue, May 21, 2019 at 10:48 AM Antonin Houska wrote:
> > Do you refer to the fact that for example the address of
> >
> > tts_virtual_clear(dstslot);
> >
> > is immediately available in the text section while in this case
> >
> >
Hi,
On 2019-05-21 16:47:50 +0200, Antonin Houska wrote:
> I admit I didn't think about this problem. Nevertheless I imagine that due to
> constness of the variables like TTSOpsVirtual (and due to several other const
> declarations) the compiler might be able to compute the address of the
> tts_ops
Hi,
On 2019-05-05 10:28:21 +0530, Amit Kapila wrote:
> From 5d9e179bd481b5ed574b6e7117bf3eb62b5dc003 Mon Sep 17 00:00:00 2001
> From: Amit Kapila
> Date: Sat, 4 May 2019 16:52:01 +0530
> Subject: [PATCH] Allow undo actions to be applied on rollbacks and discard
> unwanted undo.
I think this nee
On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
> On Wed, May 15, 2019 at 1:53 PM Tom Lane wrote:
> > >> That seems too confusing.
> >
> > > Ok. Are you voting for using EXEC as a keyword to replace ANALYZE?
> >
> > FWIW, given the conflict against "EXPLAIN EXECUTE prepared_stmt_name
David Fetter writes:
> On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
>> Defaulting BUFFERS to ON is probably a reasonable change, thuogh.
> Would this be worth back-patching? I ask because adding it will cause
> fairly large (if mechanical) churn in the regression tests.
It really
On Tue, May 21, 2019 at 1:38 PM David Fetter wrote:
> Would this be worth back-patching? I ask because adding it will cause
> fairly large (if mechanical) churn in the regression tests.
No. I can't believe you're even asking that question.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.c
Hi,
On 2019-05-21 19:38:57 +0200, David Fetter wrote:
> On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
> > Defaulting BUFFERS to ON is probably a reasonable change, thuogh.
>
> Would this be worth back-patching? I ask because adding it will cause
> fairly large (if mechanical) churn
On Sat, May 18, 2019 at 1:17 AM Sergei Kornilov wrote:
> Hello
>
> No, this is not bug. This is expected beharior of search_path setting:
> https://www.postgresql.org/docs/current/runtime-config-client.html
>
> > Likewise, the current session's temporary-table schema, pg_temp_nnn, is
> always sea
Andres Freund writes:
> On 2019-05-21 19:38:57 +0200, David Fetter wrote:
>> On Tue, May 21, 2019 at 12:32:21PM -0400, Robert Haas wrote:
>>> Defaulting BUFFERS to ON is probably a reasonable change, thuogh.
>> Would this be worth back-patching? I ask because adding it will cause
>> fairly large
On 5/20/19 9:58 PM, Andres Freund wrote:
> Hi Andrew,
>
> On 2019-03-30 16:42:16 -0400, Andrew Dunstan wrote:
>> On some machines (*cough* Mingw *cough*) installs are very slow. We've
>> ameliorated this by allowing temp installs to be reused, but the
>> pg_upgrade Makefile never got the message.
Hi Tom!
> Le 20 mai 2019 à 15:54, Tom Lane a écrit :
>
> Akim Demaille writes:
>> It is for the same reasons that I would recommend not using associativity
>> directives (%left, %right, %nonassoc) where associativity plays no role:
>> %precedence is made for this. But it was introduced in Bi
Akim Demaille writes:
>> Le 20 mai 2019 à 15:54, Tom Lane a écrit :
>> 2013? Certainly not. We have a lot of buildfarm critters running
>> older platforms than that.
> This I fully understand. However, Bison is a source generator,
> and it's quite customary to use modern tools on the maintain
Andrew Dunstan writes:
> On 5/20/19 9:58 PM, Andres Freund wrote:
>> I'm confused as to why this was done as a purely optional path, rather
>> than just ripping out the pg_upgrade specific install?
> By specifying NO_TEMP_INSTALL you are in effect certifying that there is
> already a suitable tem
On Tue, May 21, 2019 at 09:09:10AM -0700, Shawn Debnath wrote:
> On Sat, May 11, 2019 at 04:33:24PM -0400, Bruce Momjian wrote:
> > I have posted a draft copy of the PG 12 release notes here:
> >
> > http://momjian.us/pgsql_docs/release-12.html
> >
> > They are committed to git. It includes
Hi,
On 2019-05-21 14:48:27 -0400, Andrew Dunstan wrote:
> On 5/20/19 9:58 PM, Andres Freund wrote:
> > Hi Andrew,
> >
> > On 2019-03-30 16:42:16 -0400, Andrew Dunstan wrote:
> >> On some machines (*cough* Mingw *cough*) installs are very slow. We've
> >> ameliorated this by allowing temp installs
On Tue, May 21, 2019 at 11:47 AM Masahiko Sawada wrote:
>
> On Tue, May 21, 2019 at 2:10 AM Fujii Masao wrote:
> >
> > On Fri, May 17, 2019 at 10:21 AM Kyotaro HORIGUCHI
> > wrote:
> > >
> > > We now have several syntax elements seemingly the same but behave
> > > different way.
> > >
> > > At T
Hi,
On 2019-05-21 12:19:18 -0700, Andres Freund wrote:
> Roughly like in the attached?
> -check: test.sh all
> - MAKE=$(MAKE) bindir="$(tbindir)" libdir="$(tlibdir)"
> EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< $(DOINST)
> +check: test.sh all temp-install
> + MAKE=$(MAKE) $(w
[ redirecting to pgsql-hackers as the more relevant list ]
I wrote:
> PegoraroF10 writes:
>> I tried sometime ago ... but with no responses, I ask you again.
>> pg_publication_tables is a view that is used to refresh publication, but as
>> we have 15.000 tables, it takes hours and doesn't complet
On Tue, May 21, 2019 at 4:42 PM Tom Lane wrote:
>
> [ redirecting to pgsql-hackers as the more relevant list ]
>
> I wrote:
> > PegoraroF10 writes:
> >> I tried sometime ago ... but with no responses, I ask you again.
> >> pg_publication_tables is a view that is used to refresh publication,
but a
qOn Mon, May 20, 2019 at 03:17:19PM -0700, Andres Freund wrote:
> Hi,
>
> Note that I've added a few questions to individuals involved with
> specific points. If you're in the To: list, please search for your name.
>
>
> On 2019-05-11 16:33:24 -0400, Bruce Momjian wrote:
> > I have posted a draf
Consider:
CREATE TABLE testwid
(
txtnotnull text,
txtnull text,
int8notnull int8,
int8null int8
);
INSERT INTO testwid
SELECT 'a' || g.i,
NULL,
g.i,
NULL
FROM generate_series(1,1) AS g(i);
ANALYZE testwid;
SELECT attname, avg_width FROM pg_stats WHERE tablename = '
Joe Conway writes:
> else if (null_cnt > 0)
> {
> /* We found only nulls; assume the column is entirely null */
> stats->stats_valid = true;
> stats->stanullfrac = 1.0;
> if (is_varwidth)
> stats->stawidth = 0;/* "unknown" */
> else
> stats->stawidth = stats
Hi,
On 2019-05-21 15:47:34 -0400, Bruce Momjian wrote:
> On Mon, May 20, 2019 at 03:17:19PM -0700, Andres Freund wrote:
> > Hi,
> >
> > Note that I've added a few questions to individuals involved with
> > specific points. If you're in the To: list, please search for your name.
> >
> >
> > On 2
On 5/21/19 3:55 PM, Tom Lane wrote:
> Joe Conway writes:
>> else if (null_cnt > 0)
>> {
>> /* We found only nulls; assume the column is entirely null */
>> stats->stats_valid = true;
>> stats->stanullfrac = 1.0;
>> if (is_varwidth)
>> stats->stawidth = 0;/* "unknown" */
On Tue, May 21, 2019 at 1:18 PM Andres Freund wrote:
> I think this needs to be split into some constituent parts, to be
> reviewable. Discussing 270kb of patch at once is just too much.
+1.
> > + {
> > + {"rollback_overflow_size", PGC_USERSET, RESOURCES_MEM,
> > +
On Tue, May 21, 2019 at 12:08:25AM +0100, Andrew Gierth wrote:
> > "Andres" == Andres Freund writes:
>
> Andres> Any chance for you to propose a text?
>
> This is what I posted before; I'm not 100% happy with it but it's still
> better than any of the other versions:
>
> * Output REAL and
On Tue, May 21, 2019 at 12:04:50PM +1200, David Rowley wrote:
> On Tue, 21 May 2019 at 10:17, Andres Freund wrote:
> > commit 4da597edf1bae0cf0453b5ed6fc4347b6334dfe1
> > Author: Andres Freund
> > Date: 2018-11-16 16:35:11 -0800
> >
> > Make TupleTableSlots extensible, finish split of exist
On Mon, May 20, 2019 at 06:56:50PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > Note that I've added a few questions to individuals involved with
> > specific points. If you're in the To: list, please search for your name.
>
> I'm not sure which of my commits you want me to opine on, other
On Mon, May 20, 2019 at 08:48:15PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-20 18:56:50 -0400, Tom Lane wrote:
> >> I'm not sure which of my commits you want me to opine on, other than
>
> > That was one of the main ones. I'm also specifically wondering about:
>
> >> Author:
> On Wed, Mar 27, 2019 at 11:42 AM Haribabu Kommi
> wrote:
>
> Visual Studio 2019 is officially released. There is no major change in the
> patch, except some small comments update.
>
> Also attached patches for the back branches also.
>
I have gone through path
'0001-Support-building-with-visual
On Mon, May 20, 2019 at 05:48:50PM -0700, Peter Geoghegan wrote:
> On Mon, May 20, 2019 at 3:17 PM Andres Freund wrote:
> >
> >
> >
> > Improve speed of btree index insertions (Peter Geoghegan,
> > Alexander Korotkov)
> >
>
> My concern here (which I believe Alexa
Joe Conway writes:
> On 5/21/19 3:55 PM, Tom Lane wrote:
>> Are you suggesting that we should set stawidth to zero even for a
>> fixed-width datatype? That seems pretty silly. We know exactly what
>> the value should be, and would be if we'd chanced to find even one
>> non-null entry.
> Well yo
Bruce Momjian writes:
> On Mon, May 20, 2019 at 08:48:15PM -0400, Tom Lane wrote:
>> Yes, this should be in "source code". I think it should be merged
>> with a391ff3c and 74dfe58a into something like
>>
>> Allow extensions to create planner support functions that
>> can provide function-specifi
Given the number of different people that have sent in patches
for building with VS2019, it doesn't seem to me that we ought
to let that wait for v13. We could treat it as something that
we only intend to go into v12, or we could think that we ought
to back-patch it, but either way it should be on
Hi Matsumura-san,
> (1)
> I attach a new patch. Please review it.
> ...
This looks good to me. It passes all my tests, too.
There were two minor issues, the regression test did not run and gcc
complained about the indentation in ECPGprepare(). Both I easily fixed.
Unless somebody objects I will
On Tue, May 21, 2019 at 1:51 PM Bruce Momjian wrote:
> > My concern here (which I believe Alexander shares) is that it doesn't
> > make sense to group these two items together. They're two totally
> > unrelated pieces of work. Alexander's work does more or less help with
> > lock contention with w
I have gone through path '0001-Support-building-with-visual-studio-2019.patch'
only, but I am sure some comments will also apply to back branches.
1. The VisualStudioVersion value looks odd:
+ $self->{VisualStudioVersion}= '16.0.32.32432';
Are you using a pre-release version [1]?
Andres Freund writes:
> On 2019-05-17 10:29:46 -0400, Tom Lane wrote:
>> We should do a pgindent run fairly soon, so that people with patches
>> awaiting the next CF will have plenty of time to rebase them as
>> necessary.
>> I don't want to do it right this minute, to avoid making trouble for the
Michael Meskes writes:
> Unless somebody objects I will commit it as soon as I have time at
> hand. Given that this patch also and mostly fixes some completely
> broken old logic I'm tempted to do so despite us being pretty far in
> the release cycle. Any objections?
None here. You might want to
El mar., 21 may. 2019 23:06, Tom Lane escribió:
> Given the number of different people that have sent in patches
> for building with VS2019, it doesn't seem to me that we ought
> to let that wait for v13.
I am not so sure if there are actually that many people or it's just me
making too much no
On Mon, May 20, 2019 at 3:10 AM Jason Harvey wrote:
> This week I upgraded one of my large(2.8TB), high-volume databases from 9 to
> 11. The upgrade itself went fine. About two days later, we unexpectedly hit
> transaction ID wraparound. What was perplexing about this was that the age of
> our
On 5/12/19 5:33 AM, Bruce Momjian wrote:
I have posted a draft copy of the PG 12 release notes here:
http://momjian.us/pgsql_docs/release-12.html
They are committed to git. It includes links to the main docs, where
appropriate. Our official developer docs will rebuild in a few hours.
On Wed, May 8, 2019 at 8:08 AM Tomas Vondra
wrote:
> On Tue, May 07, 2019 at 05:30:27PM -0700, Melanie Plageman wrote:
> > One thing I was a little confused by was the nbatch_inmemory member
> > of the hashtable. The comment in ExecChooseHashTableSize says that
> > it is determining the nu
Attached is a patch for a write after allocated memory which we found in
testing. Its an obscure case but can happen if the same column is used in
different grouping keys, as in the example below, which uses tables from
the regress test suite (build with --enable-cassert in order to turn on
memory
> None here. You might want to get it in in the next 12 hours or so
> so you don't have to rebase over a pgindent run.
Thanks for the heads-up Tom, pushed.
And thanks to Matsumura-san for the patch.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
On Tue, May 21, 2019 at 3:49 AM Peter Geoghegan wrote:
> On Mon, May 20, 2019 at 3:17 PM Andres Freund wrote:
> >
> >
> >
> > Improve speed of btree index insertions (Peter Geoghegan,
> > Alexander Korotkov)
> >
>
> My concern here (which I believe Alexander share
Hi,
Attached is a draft of the PG12 Beta 1 press release that is going out
this Thursday. The primary goals of this release announcement are to
introduce new features, enhancements, and changes that are available in
PG12, as well as encourage our users to test and provide feedback to
help ensure t
Hi!
On Wed, May 22, 2019 at 6:40 AM Jonathan S. Katz wrote:
> Attached is a draft of the PG12 Beta 1 press release that is going out
> this Thursday. The primary goals of this release announcement are to
> introduce new features, enhancements, and changes that are available in
> PG12, as well as
On Wed, May 22, 2019 at 2:39 AM Tom Lane wrote:
> David Rowley writes:
> > I did add the following query just before the failing one and included
> > the expected output from below. The tests pass for me in make check
> > and the post-upgrade test passes in make check-world too. I guess we
> >
Thomas Munro writes:
> Huh, idiacanthus failed showing vacuum_count 0, in select_parallel.
> So ... the VACUUM command somehow skipped those tables?
No, because the reltuples counts are correct. I think what we're
looking at there is the stats collector dropping a packet that
told it about vacuu
> "Robert" == Robert Haas writes:
Robert> But the number of people using out-of-core postfix operators
Robert> has got to be really tiny -- unless, maybe, there's some really
Robert> popular extension like PostGIS that uses them.
If there's any extension that uses them I've so far failed
For CTEs, is forcing inlining the example we want to give, rather than the
example of forcing materialization given?
According to the docs, virtual generated columns aren't yet supported. I'm
pretty sure the docs are right. Do we still want to mention it?
Otherwise it looks good to me.
On Tue, M
On 2019-05-22 05:39, Jonathan S. Katz wrote:
Speaking of feedback, please provide me with your feedback on the
technical correctness of this announcement so I can incorporate changes
prior to the release.
Here are a few changes.
Main change: generated columns exist only in the STORED variety.
Find some corrections inline.
On Tue, May 21, 2019 at 11:39:38PM -0400, Jonathan S. Katz wrote:
> PostgreSQL 12 Beta 1 Released
> =
>
> The PostgreSQL Global Development Group announces that the first beta release
> of
> PostgreSQL 12 is now available for download. Th
On Wed, May 22, 2019 at 05:10:14AM +0200, Michael Meskes wrote:
> Thanks for the heads-up Tom, pushed.
>
> And thanks to Matsumura-san for the patch.
This patch seems to have little incidence on the stability, but FWIW I
am not cool with the concept of asking for objections and commit a
patch onl
On Wed, 22 May 2019 at 15:39, Jonathan S. Katz wrote:
> Speaking of feedback, please provide me with your feedback on the
> technical correctness of this announcement so I can incorporate changes
> prior to the release.
Seems like a pretty good summary. Thanks for writing that up.
Couple notes f
On 2019/05/22 15:47, David Rowley wrote:
> On Wed, 22 May 2019 at 15:39, Jonathan S. Katz wrote:
>> PostgreSQL 12 also provides improvements to the performance of both
>> using `COPY` with a partitioned table as well as the `ATTACH PARTITION`
>> operation. Additionally, the ability to use foreign
79 matches
Mail list logo
