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
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
> "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
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
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
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,
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
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.
> 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)
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
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
Hello,
Commit 578b229718e8f remove oids option from pg_dump but its is
still in pg_dumpall .The attach patch remove it
regards
Surafel
diff --git a/doc/src/sgml/ref/pg_dumpall.sgml b/doc/src/sgml/ref/pg_dumpall.sgml
index 24c8c031d6..b35c702f99 100644
--- a/doc/src/sgml/ref/pg_dumpall.sgml
+++
>
>
>> 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
On Tue, May 21, 2019 at 7:36 AM Michael Paquier wrote:
> On Tue, May 21, 2019 at 02:37:10PM +1200, David Rowley wrote:
> > Maybe you could take a look at that and maybe sign up to review it?
>
> Yes, that would be great. New VS environments are a pain to set up so
> any input is welcome.
>
>
At
вт, 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
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,
ú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
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?
--
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
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
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
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
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
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
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
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
>
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:
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
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
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
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
> >
> >
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
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
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
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
>
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
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
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)
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
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
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
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
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
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
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:
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
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
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
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
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]?
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
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
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
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
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:
>
> >>
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
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
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)
[ 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
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
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 =
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
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 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
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
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 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
75 matches
Mail list logo
