On Thu, Feb 13, 2020 at 07:09:18PM -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> It seems to me that FROM UNPACKAGED shouldn't support trusted.
>
> > Hmm, seems like a reasonable idea, but I'm not quite sure how to mechanize
> > it given that "unpackaged" isn't magic in any way
On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> On Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> > On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > > > The changes in hash AM and SIMPLEHASH do look like a net positive
> > > > improvement. My biggest cringe migh
Hi,
On Wed, Feb 26, 2020 at 04:41:12PM +0900, Michael Paquier wrote:
> The next commit fets is going to begin in a couple of days, and there
> is a total of 207 patches registered as of today. We don't have any
> manager yet, so is there any volunteer for taking the lead this time?
This is the l
On 2/26/20 2:47 AM, Andrew Dunstan wrote:
> On 2/25/20 8:24 PM, Andrew Dunstan wrote:
>> On 2/25/20 7:08 PM, Tom Lane wrote:
>>> Andrew Dunstan writes:
On 2/25/20 5:06 PM, Tom Lane wrote:
> No joy there --- now that I look closer, it seems the cfbot doesn't
> build any of the extern
Hi,
On 2020-02-26 09:11:21 +0100, Sandro Santilli wrote:
> PostGIS uses unpackaged-to-XXX pretty heavily, and has it under
> automated testing (which broke since "FROM unpackaged" support was
> removed, see 14514.1581638...@sss.pgh.pa.us)
>
> We'd be ok with requiring SUPERUSER for doing that, si
On Wed, Feb 26, 2020 at 12:17:37AM -0800, Andres Freund wrote:
> Hi,
>
> On 2020-02-26 09:11:21 +0100, Sandro Santilli wrote:
> > PostGIS uses unpackaged-to-XXX pretty heavily, and has it under
> > automated testing (which broke since "FROM unpackaged" support was
> > removed, see 14514.1581638...
> On 26 Feb 2020, at 02:48, Michael Paquier wrote:
>
> On Tue, Feb 25, 2020 at 11:55:06PM +, Dagfinn Ilmari Mannsåker wrote:
>> @@ -164,11 +164,11 @@ get_major_server_version(ClusterInfo *cluster)
>> snprintf(ver_filename, sizeof(ver_filename), "%s/PG_VERSION",
>> c
On Wed, Feb 26, 2020 at 9:56 AM Daniel Gustafsson wrote:
>
> > On 26 Feb 2020, at 02:48, Michael Paquier wrote:
> >
> > On Tue, Feb 25, 2020 at 11:55:06PM +, Dagfinn Ilmari Mannsåker wrote:
> >> @@ -164,11 +164,11 @@ get_major_server_version(ClusterInfo *cluster)
> >> snprintf(ver_filena
On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:
> +1, seems like that would be a regression in value.
Having more generic messages is less work for translators, we have
PG_VERSION in the file name, and that's more complicated to translate
in both French and Japanese. No idea abou
On 25.02.2020 19:40, Konstantin Knizhnik wrote:
I have ported vectorize_engine for zedstore (vertical table AM).
Results of TPCH-10G/Q1 are the following:
par.workers
PG9_6
vectorize=off
PG9_6
vectorize=on
master
vectorize=off
jit=on
master
vectorize=off
jit=of
Hi Konstantin,
On Tue, Feb 25, 2020 at 6:44 PM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 25.02.2020 11:06, Hubert Zhang wrote:
>
> Hi Konstantin,
>
> I checkout your branch pg13 in repo
> https://github.com/zhangh43/vectorize_engine
> After I fixed some compile error, I tes
On Wed, Feb 26, 2020 at 3:51 PM David Fetter wrote:
>
> I believe the following should error out, but doesn't.
>
> # SELECT date_trunc_interval('1 year 1 ms', TIMESTAMP '2001-02-16 20:38:40');
> date_trunc_interval
> ═
> 2001-01-01 00:00:00
> (1 row)
You're quite right. I fo
Hello.
Looks totally fine to me now.
So, I need to mark it as "ready to commiter", right?
On Tue, Feb 25, 2020 at 9:30 PM Tomas Vondra
wrote:
>
> On Sun, Feb 23, 2020 at 05:09:51PM -0800, Andres Freund wrote:
> >Hi,
> >
> >> The one piece of information I'm missing here is at least a very rough
> >> quantification of the individual steps of CSV processing - for example
> >> if parsing
On Wed, Feb 26, 2020 at 11:48 AM Michail Nikolaev <
michail.nikol...@gmail.com> wrote:
>
> Looks totally fine to me now.
>
> So, I need to mark it as "ready to commiter", right?
>
Yes, that's right. Thanks for reviewing it.
Regards
On 2/26/20 3:17 AM, Andrew Dunstan wrote:
> On 2/26/20 2:47 AM, Andrew Dunstan wrote:
>> On 2/25/20 8:24 PM, Andrew Dunstan wrote:
>>> On 2/25/20 7:08 PM, Tom Lane wrote:
Andrew Dunstan writes:
> On 2/25/20 5:06 PM, Tom Lane wrote:
>> No joy there --- now that I look closer, it seems
On 26.02.2020 13:11, Hubert Zhang wrote:
and with JIT:
13.88% postgres postgres [.]
tts_buffer_heap_getsomeattrs
7.15% postgres vectorize_engine.so [.] vfloat8_accum
6.03% postgres postgres [.]
HeapTupleSatisfiesVisibility
On 2020/02/18 12:39, Michael Paquier wrote:
On Mon, Feb 17, 2020 at 10:21:23PM +0900, Fujii Masao wrote:
On 2020/02/17 18:48, Michael Paquier wrote:
Actually, I have some questions:
1) Should a new wait event be added in recoveryPausesHere()? That
would be IMO useful.
Yes, it's useful, I t
On 2/26/20 3:15 AM, Michael Banck wrote:
On Wed, Feb 26, 2020 at 04:41:12PM +0900, Michael Paquier wrote:
The next commit fets is going to begin in a couple of days, and there
is a total of 207 patches registered as of today. We don't have any
manager yet, so is there any volunteer for taking
Greetings,
* Darafei "Komяpa" Praliaskouski (m...@komzpa.net) wrote:
> PostGIS 2.5 had raster and vector blended together in single extension.
> In PostGIS 3, they were split out into postgis and postgis_raster extensions.
For my 2c, at least, I still don't really get why that split was done.
>
On Wed, Feb 26, 2020 at 08:55:03AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Darafei "Komяpa" Praliaskouski (m...@komzpa.net) wrote:
> > PostGIS 2.5 had raster and vector blended together in single extension.
> > In PostGIS 3, they were split out into postgis and postgis_raster
> > extension
On 2020/02/18 21:31, Fujii Masao wrote:
On 2020/02/18 16:53, Amit Langote wrote:
On Tue, Feb 18, 2020 at 4:42 PM Fujii Masao wrote:
On 2020/02/18 16:02, Amit Langote wrote:
I noticed that there is missing tag in the documentation changes:
Could you tell me where I should add tag?
+
> On 26 Feb 2020, at 14:39, David Steele wrote:
>
> On 2/26/20 3:15 AM, Michael Banck wrote:
>> On Wed, Feb 26, 2020 at 04:41:12PM +0900, Michael Paquier wrote:
>>> The next commit fets is going to begin in a couple of days, and there
>>> is a total of 207 patches registered as of today. We don'
> On 26 Feb 2020, at 15:13, Sandro Santilli wrote:
> On pgsql-hackers we only want to find a future-proof way to "package
> existing objects into an extension".
What is the longterm goal of PostGIS, to use this as a stepping stone to reach
a point where no unpackaged extensions exist; or find a
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: tested, failed
Documentation:tested, failed
Hello Pavel
First thanks for working on this patch cause it migh
Andrew Dunstan writes:
> This seems to fix it.
OK, so we need that *and* the AddProject addition you mentioned?
regards, tom lane
On Wed, Feb 26, 2020 at 03:35:46PM +0100, Daniel Gustafsson wrote:
> > On 26 Feb 2020, at 15:13, Sandro Santilli wrote:
>
> > On pgsql-hackers we only want to find a future-proof way to "package
> > existing objects into an extension".
>
> What is the longterm goal of PostGIS, to use this as a s
On Wed, 26 Feb 2020 at 10:54, Amit Kapila wrote:
>
> On Tue, Feb 25, 2020 at 9:30 PM Tomas Vondra
> wrote:
> >
...
> >
> > Perhaps. I guess it'll depend on the CSV file (number of fields, ...),
> > so I still think we need to do some measurements first.
> >
>
> Agreed.
>
> > I'm willing to
> > do
On Tue, 25 Feb 2020 at 18:00, Tomas Vondra wrote:
> Perhaps. I guess it'll depend on the CSV file (number of fields, ...),
> so I still think we need to do some measurements first. I'm willing to
> do that, but (a) I doubt I'll have time for that until after 2020-03,
> and (b) it'd be good to agre
On Thu, Feb 20, 2020 at 12:01 PM Alex Malek wrote:
> On Thu, Feb 20, 2020, 6:16 AM Amit Kapila wrote:
>
>> On Thu, Feb 20, 2020 at 3:06 AM Alex Malek wrote:
>> >
>> >
>> > Hello Postgres Hackers -
>> >
>> > We are having a reoccurring issue on 2 of our replicas where
>> replication stops due to
On Wed, Feb 26, 2020 at 03:29:18PM +0100, Daniel Gustafsson wrote:
On 26 Feb 2020, at 14:39, David Steele wrote:
On 2/26/20 3:15 AM, Michael Banck wrote:
On Wed, Feb 26, 2020 at 04:41:12PM +0900, Michael Paquier wrote:
The next commit fets is going to begin in a couple of days, and
there is a
> On 26 Feb 2020, at 16:29, Tomas Vondra wrote:
> Did we actually decide who's going to be on RMT this year? I don't think
> anyone particular was mentioned / proposed at the FOSDEM dev meeting. It
> might be a good idea to decide that before the last CF too.
We didn't, we only discussed (based
John Naylor writes:
> [ v3-datetrunc_interval.patch ]
A few thoughts:
* In general, binning involves both an origin and a stride. When
working with plain numbers it's almost always OK to set the origin
to zero, but it's less clear to me whether that's all right for
timestamps. Do we need anoth
Greetings,
* Sandro Santilli (s...@kbt.io) wrote:
> On pgsql-hackers we only want to find a future-proof way to "package
> existing objects into an extension". If the syntax
> `CREATE EXTENSION FROM UNPACKAGED`
> has gone, would it be ok for just:
> `CREATE EXTENSION `
> to intercept unpackaged
David Steele writes:
> On 2/26/20 3:15 AM, Michael Banck wrote:
>> This is the last one for v13 I think? So probably somebody quite
>> experienced should handle this one. Or (if there is one already for
>> v13?) maybe even the Release Team themselves?
> I'm not sure it would be a good use of reso
On Wed, Feb 26, 2020 at 10:37:41AM -0500, Stephen Frost wrote:
> Greetings,
>
> * Sandro Santilli (s...@kbt.io) wrote:
> > On pgsql-hackers we only want to find a future-proof way to "package
> > existing objects into an extension". If the syntax
> > `CREATE EXTENSION FROM UNPACKAGED`
> > has g
OK, well, what PostGIS needs is the ability for 'ALTER EXTENSION …. UPDATE foo’
to end up with two extensions in the end, ‘foo’ and ‘foo_new’. That’s what’s
happening in the 2.x -> 3 upgrade process, as ‘postgis’ becomes ‘postgis’ and
‘postgis_raster’.
Presumably 15 years out from the 1.x -> 2
Michael Paquier writes:
> On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:
>> +1, seems like that would be a regression in value.
> Having more generic messages is less work for translators, we have
> PG_VERSION in the file name, and that's more complicated to translate
> in both
> 2020年2月25日 下午11:31，tushar 写道：
>
> Hi,
>
> I have created two global temporary tables like this -
>
> Case 1-
> postgres=# create global temp table foo(n int) with
> (on_commit_delete_rows='true');
> CREATE TABLE
>
> Case 2-
> postgres=# create global temp table bar1(n int) on commit
On 2/26/20 10:52 AM, Sandro Santilli wrote:
> This part is not clear to me. You're _assuming_ that the unpackaged--xxx
> will not make checks, so you _drop_ support for it ? Can't the normal
> extension script also be unsafe for some reason ? Or can't the
> unpackaged-xxx script be made safe by th
Am Dienstag, den 25.02.2020, 11:33 +0900 schrieb Michael Paquier:
> I really think that
> we should avoid duplicating the same logic around, and that we should
> remain consistent with non-directory entries in those paths,
> complaining with a proper failure if extra, unwanted files are
> present.
On Wed, Feb 26, 2020 at 06:38:57PM +0800, John Naylor wrote:
> On Wed, Feb 26, 2020 at 3:51 PM David Fetter wrote:
> >
> > I believe the following should error out, but doesn't.
> >
> > # SELECT date_trunc_interval('1 year 1 ms', TIMESTAMP '2001-02-16
> > 20:38:40');
> > date_trunc_interval
> >
Hi,
Attached is a patch for allowing auto_explain to log plans before
queries are executed.
Currently, auto_explain logs plans only after query executions,
so if a query gets stuck its plan could not be logged. If we can
know plans of stuck queries, we may get some hints to resolve the
stuck. Thi
On Thu, Feb 27, 2020 at 02:35:18AM +0900, Yugo NAGATA wrote:
> Hi,
>
> Attached is a patch for allowing auto_explain to log plans before
> queries are executed.
>
> Currently, auto_explain logs plans only after query executions,
> so if a query gets stuck its plan could not be logged. If we can
> k
Just one more data point: drivers do allow users to execute queries in a
free form.
Shat is the user might execute /*comment*/commit/*comment*/ as a free-form
SQL, and they would expect that the resulting
behaviour should be exactly the same as .commit() API call (==silent
rollback is converted to
Tom Lane writes:
> Michael Paquier writes:
>> On Wed, Feb 26, 2020 at 10:06:38AM +0100, Magnus Hagander wrote:
>>> +1, seems like that would be a regression in value.
>
>> Having more generic messages is less work for translators, we have
>> PG_VERSION in the file name, and that's more complicat
Am 24.02.2020 um 13:34 schrieb Robert Haas:
As I said upthread, I think one of the things that would be pretty
badly broken by this is psql -f something.sql, where something.sql
contains a series of blocks of the form "begin; something; something;
something; commit;". Right now whichever transact
On 25/02/2020 12:11, Laurenz Albe wrote:
> On Tue, 2020-02-25 at 13:25 +0530, Robert Haas wrote:
>> On Tue, Feb 25, 2020 at 12:47 PM Vladimir Sitnikov
>> wrote:
>>> Noone suggested that "commit leaves the session in a transaction state".
>>> Of course, every commit should terminate the transaction
On Tue, Feb 25, 2020 at 1:48 PM Alexander Korotkov
wrote:
>
> I think usage of chmod() deserves comment. As I get default
> permissions are sufficient for work, but we need to set them to
> satisfy 'check PGDATA permissions' test.
I've added this comment myself. I've also fixes some indentatio
On Wed, Feb 26, 2020 at 10:45:16AM -0500, Tom Lane wrote:
David Steele writes:
On 2/26/20 3:15 AM, Michael Banck wrote:
This is the last one for v13 I think? So probably somebody quite
experienced should handle this one. Or (if there is one already for
v13?) maybe even the Release Team themsel
On Thu, Feb 27, 2020 at 1:33 AM Tom Lane wrote:
>
> Andrew Dunstan writes:
> > This seems to fix it.
>
> OK, so we need that *and* the AddProject addition you mentioned?
>
>
Yes, the first one builds it, the second one fixes the tests to run correctly.
cheers
andrew
--
Andrew Dunstan
> Presumably 15 years out from the 1.x -> 2.x we can stop worrying about
> bundling unpackaged postgis into an extension, and just recommend a hard
> upgrade dump/restore to the hardy souls still running 1.x.
>
> P.
>
We don't need to worry about 1.x cause 1.x can only do a hard upgrade to 2 or
y with it. The problem is syntax. When I
try to reproduce syntax from PLpgSQL, then I need to introduce new reserved
keyword. So my initial idea was wrong.
We need to open discussion about implementable syntax. For this moment you
can use a workaround - any schema variable without WRITE right is constant.
Implementation is easy. Design of syntax is harder.
please see attached patch
Regards
Pavel
>
> Otherwise the documentation looks good to me.
>
> Regards
>
> Rémi
schema-variables-20200226.patch.gz
Description: application/gzip
On 2020-02-26 22:03, Alexander Korotkov wrote:
On Tue, Feb 25, 2020 at 1:48 PM Alexander Korotkov
wrote:
I think usage of chmod() deserves comment. As I get default
permissions are sufficient for work, but we need to set them to
satisfy 'check PGDATA permissions' test.
I've added this comm
On Wed, 26 Feb 2020 at 13:46, Vik Fearing wrote:
> On 25/02/2020 12:11, Laurenz Albe wrote:
> > On Tue, 2020-02-25 at 13:25 +0530, Robert Haas wrote:
> >> On Tue, Feb 25, 2020 at 12:47 PM Vladimir Sitnikov
> >> wrote:
> >>> Noone suggested that "commit leaves the session in a transaction
> state
Antonin Houska-2 wrote
> Alvaro Herrera <
> alvherre@
> > wrote:
>
>> This stuff seems very useful. How come it sits unreviewed for so long?
>
> I think the review is hard for people who are not interested in the
> planner
> very much. And as for further development, there are a few design
> d
Dave Cramer writes:
> OK, here is a patch that actually doesn't leave the transaction in a failed
> state but emits the error and rolls back the transaction.
> This is far from complete as it fails a number of tests and does not cover
> all of the possible paths.
> But I'd like to know if this i
On Wed, Feb 26, 2020 at 11:45 PM Alexey Kondratov
wrote:
> On 2020-02-26 22:03, Alexander Korotkov wrote:
> > On Tue, Feb 25, 2020 at 1:48 PM Alexander Korotkov
> > wrote:
> >>
> >> I think usage of chmod() deserves comment. As I get default
> >> permissions are sufficient for work, but we need
On 26/02/2020 22:22, Tom Lane wrote:
> Dave Cramer writes:
>> OK, here is a patch that actually doesn't leave the transaction in a failed
>> state but emits the error and rolls back the transaction.
>
>> This is far from complete as it fails a number of tests and does not cover
>> all of the pos
On Wed, 26 Feb 2020 at 16:57, Vik Fearing wrote:
> On 26/02/2020 22:22, Tom Lane wrote:
> > Dave Cramer writes:
> >> OK, here is a patch that actually doesn't leave the transaction in a
> failed
> >> state but emits the error and rolls back the transaction.
> >
> >> This is far from complete as
Hello Maksim,
reading about
https://www.postgresql-archive.org/Allow-auto-explain-to-log-plans-before-queries-are-executed-td6124646.html
makes me think (again) about your work and pg_query_state ...
Is there a chance to see you restarting working on this patch ?
Regards
PAscal
--
Sent from: h
On Mon, Feb 24, 2020 at 4:54 PM Peter Geoghegan wrote:
> Attached is v34, which has this change. My plan is to commit something
> very close to this on Wednesday morning (barring any objections).
Pushed.
I'm going to delay committing the pageinspect patch until tomorrow,
since I haven't thought
> On 14 Feb 2020, at 05:10, Michael Paquier wrote:
> createdb has a couple of issues with its quoting. For example take
> that, which can be confusing:
> $ createdb --lc-ctype="en_US.UTF-8';create table aa();select '1" popo
> createdb: error: database creation failed: ERROR: CREATE DATABASE
> c
On Sat, Feb 8, 2020 at 10:15 AM Thomas Munro wrote:
> > > Here are some patches to get rid of frequent system calls.
Here's a new version of this patch set. It gets rid of all temporary
WaitEventSets except a couple I mentioned in another thread[1].
WaitLatch() uses CommonWaitSet, and calls to W
On Mon, Feb 24, 2020 at 4:55 PM Thomas Munro wrote:
> On Mon, Feb 24, 2020 at 4:49 PM Thomas Munro wrote:
> > While working on a patch to reuse a common WaitEventSet for latch
> > waits, I noticed that be-secure-gssapi.c and be-secure-openssl.c don't
> > use FeBeWaitSet. They probably should, fo
On Wed, 26 Feb 2020 18:51:21 +0100
Julien Rouhaud wrote:
> On Thu, Feb 27, 2020 at 02:35:18AM +0900, Yugo NAGATA wrote:
> > Hi,
> >
> > Attached is a patch for allowing auto_explain to log plans before
> > queries are executed.
> >
> > Currently, auto_explain logs plans only after query execution
On Thu, Feb 27, 2020 at 12:43:55AM +0300, Alexander Korotkov wrote:
> Regarding text split change, it was made by pgindent. I didn't notice
> it belongs to unchanged part of code. Sure, we shouldn't include this
> into the patch.
I have read through v17 (not tested, sorry), and spotted a couple
On Thu, Feb 27, 2020 at 12:00:11AM +0100, Daniel Gustafsson wrote:
> Makes sense, it aligns it with other utils and passes all the tests. +1 on
> the
> fix.
Thanks for the review.
> I would've liked a negative test basically along the lines of your example
> above. If we left a hole the size o
On Wed, Feb 26, 2020 at 03:29:18PM +0100, Daniel Gustafsson wrote:
> On 26 Feb 2020, at 14:39, David Steele wrote:
>> I'm happy to be CFM for this commitfest.
>
> Thanks!
Thanks David!
--
Michael
signature.asc
Description: PGP signature
On Wed, Feb 26, 2020 at 08:34:26PM +0100, Tomas Vondra wrote:
> Nope, the RMT for PG12 was announced on 2019/03/30 [1], i.e. shortly
> before the end of the last CF (and before pgcon). I think there was some
> discussion about the members at/after the FOSDEM dev meeting. The
> overlap with CFM duti
On Wed, Feb 26, 2020 at 7:59 PM Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 26.02.2020 13:11, Hubert Zhang wrote:
>
>
>
>> and with JIT:
>>
>> 13.88% postgres postgres [.] tts_buffer_heap_getsomeattrs
>>7.15% postgres vectorize_engine.so [.] vfloat8_accum
On Thu, Feb 27, 2020 at 3:29 AM Julien Rouhaud wrote:
> [v10]
Thanks. I'll do some more testing and review soon. It'd be really
cool to get this into PG13.
FYI cfbot said:
+++
/home/travis/build/postgresql-cfbot/postgresql/src/test/regress/results/collate.icu.utf8.out
2020-02-26 14:45:52.114
On Mon, 2020-02-24 at 15:29 -0800, Andres Freund wrote:
> On 2020-02-22 11:02:16 -0800, Jeff Davis wrote:
> > On Sat, 2020-02-22 at 10:00 -0800, Andres Freund wrote:
> > > Both patches, or just 0013? Seems the earlier one might make the
> > > addition of the opcodes you add less verbose?
> >
> > J
On Mon, Feb 24, 2020 at 5:32 PM Robert Haas wrote:
> I've committed 0001 through 0003 as revised by Mark in accordance with
> the comments from Suraj. Here's the last patch again with a tweak to
> try not to break the Windows build, per some off-list advice I
> received on how not to break the Win
On Wed, Feb 26, 2020 at 11:53 PM Vladimir Sitnikov
wrote:
> Pushing full SQL parser to the driver is not the best idea taking into the
> account the extensibility the core has.
That wouldn't be necessary. You could just do strcmp() on the command tag.
--
Robert Haas
EnterpriseDB: http://www.en
But if the SQL is /*commit*/rollback, then the driver should not raise an
exception. The exception should be only for the case when the client asks
to commit and the database can't do that.
The resulting command tag alone is not enough.
Vladimir
> 2020年2月25日 下午9:36，Prabhat Sahu 写道：
>
> Hi All,
>
> Please check the below findings on GTT.
> -- Scenario 1:
> Under "information_schema", We are not allowed to create "temporary table",
> whereas we can CREATE/DROP "Global Temporary Table", is it expected ?
>
> postgres=# create temporary
Hello.
We found that targetted promotion can cause an assertion failure. The
attached TAP test causes that.
> TRAP: FailedAssertion("StandbyMode", File: "xlog.c", Line: 12078)
After recovery target is reached, StartupXLOG turns off standby mode
then refetches the last record. If the last record
Hello.
At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA wrote in
> On Wed, 26 Feb 2020 18:51:21 +0100
> Julien Rouhaud wrote:
>
> > On Thu, Feb 27, 2020 at 02:35:18AM +0900, Yugo NAGATA wrote:
> > > Hi,
> > >
> > > Attached is a patch for allowing auto_explain to log plans before
> > > queries
čt 27. 2. 2020 v 6:16 odesílatel Kyotaro Horiguchi
napsal:
> Hello.
>
> At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA
> wrote in
> > On Wed, 26 Feb 2020 18:51:21 +0100
> > Julien Rouhaud wrote:
> >
> > > On Thu, Feb 27, 2020 at 02:35:18AM +0900, Yugo NAGATA wrote:
> > > > Hi,
> > > >
> > > >
On 2020/02/27 12:48, Kyotaro Horiguchi wrote:
Hello.
We found that targetted promotion can cause an assertion failure. The
attached TAP test causes that.
TRAP: FailedAssertion("StandbyMode", File: "xlog.c", Line: 12078)
After recovery target is reached, StartupXLOG turns off standby mode
On Thu, 27 Feb 2020 14:14:41 +0900 (JST)
Kyotaro Horiguchi wrote:
> Hello.
>
> At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA wrote
> in
> > On Wed, 26 Feb 2020 18:51:21 +0100
> > Julien Rouhaud wrote:
> >
> > > On Thu, Feb 27, 2020 at 02:35:18AM +0900, Yugo NAGATA wrote:
> > > > Hi,
> > >
On Wed, Feb 26, 2020 at 09:12:24AM +0100, David Fetter wrote:
> On Fri, Jan 31, 2020 at 04:59:18PM +0100, David Fetter wrote:
> > On Wed, Jan 15, 2020 at 03:45:12PM -0800, Jesse Zhang wrote:
> > > On Tue, Jan 14, 2020 at 2:09 PM David Fetter wrote:
> > > > > The changes in hash AM and SIMPLEHASH d
At Thu, 27 Feb 2020 06:27:24 +0100, Pavel Stehule
wrote in
> odesílatel Kyotaro Horiguchi
> napsal:
> > > In the current patch, log_before_query (will be log_before_execution)
> > > has no effect if log_analyze is enabled in order to avoid to log the
> > > same plans twice. Instead, is it bett
On Thu, 27 Feb 2020 06:27:24 +0100
Pavel Stehule wrote:
> čt 27. 2. 2020 v 6:16 odesílatel Kyotaro Horiguchi
> napsal:
>
> > Hello.
> >
> > At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA
> > wrote in
> > > On Wed, 26 Feb 2020 18:51:21 +0100
> > > Julien Rouhaud wrote:
> > >
> > > > On Thu, F
On 2020/02/27 7:43, Peter Geoghegan wrote:
On Mon, Feb 24, 2020 at 4:54 PM Peter Geoghegan wrote:
Attached is v34, which has this change. My plan is to commit something
very close to this on Wednesday morning (barring any objections).
Pushed.
Thanks for committing this nice feature!
Her
Hi,
Attached is the latest patch (v14) to add support for Incremental Materialized
View Maintenance (IVM). It is possible to apply to current latest master branch.
Differences from the previous patch (v13) include:
* Support base tables using RLS
If a table has the Row Level Security (RLS) pol
čt 27. 2. 2020 v 6:58 odesílatel Kyotaro Horiguchi
napsal:
> At Thu, 27 Feb 2020 06:27:24 +0100, Pavel Stehule
> wrote in
> > odesílatel Kyotaro Horiguchi
> > napsal:
> > > > In the current patch, log_before_query (will be log_before_execution)
> > > > has no effect if log_analyze is enabled in
čt 27. 2. 2020 v 7:01 odesílatel Yugo NAGATA napsal:
> On Thu, 27 Feb 2020 06:27:24 +0100
> Pavel Stehule wrote:
>
> > čt 27. 2. 2020 v 6:16 odesílatel Kyotaro Horiguchi <
> horikyota@gmail.com>
> > napsal:
> >
> > > Hello.
> > >
> > > At Thu, 27 Feb 2020 10:18:16 +0900, Yugo NAGATA
> > > w
At Thu, 27 Feb 2020 14:40:55 +0900, Fujii Masao
wrote in
>
>
> On 2020/02/27 12:48, Kyotaro Horiguchi wrote:
> > Hello.
> > We found that targetted promotion can cause an assertion failure. The
> > attached TAP test causes that.
> >
> >> TRAP: FailedAssertion("StandbyMode", File: "xlog.c", L
On Thu, Feb 27, 2020 at 7:12 AM Pavel Stehule wrote:
>
> čt 27. 2. 2020 v 7:01 odesílatel Yugo NAGATA napsal:
>>
>> On Thu, 27 Feb 2020 06:27:24 +0100
>> Pavel Stehule wrote:
>>
>> > čt 27. 2. 2020 v 6:16 odesílatel Kyotaro Horiguchi
>> >
>> > napsal:
>> >
>> > > Hello.
>> > >
>> > > At Thu, 2
Hi,
On Fri, 17 Jan 2020 17:33:48 +0900
Yugo NAGATA wrote:
> On Sun, 29 Dec 2019 12:27:13 -0500
> Tom Lane wrote:
>
> > Tatsuo Ishii writes:
> > >> here is an unexpected error found while testing IVM v11 patches
> > >> ...
> > >> ERROR: out of shared memory
> >
> > > I think we could avoid s
On Thu, Feb 27, 2020 at 1:56 PM David Fetter wrote:
> [v6 set]
Hi David,
In 0002, the pg_bitutils functions have a test (input > 0), and the
new callers ceil_log2_* and next_power_of_2_* have asserts. That seems
backward to me. I imagine some callers of bitutils will already know
the value > 0,
On Wed, Feb 26, 2020 at 06:02:22PM +0100, Bernd Helmle wrote:
> My feeling is that in the case we cannot successfully resolve a
> tablespace location from pg_tblspc, we should error out, but i could
> imagine that people would like to have just a warning instead.
Thanks, this patch is much cleaner
At Tue, 25 Feb 2020 21:36:12 -0800, Noah Misch wrote in
> On Tue, Feb 25, 2020 at 10:01:51AM +0900, Kyotaro Horiguchi wrote:
> > At Sat, 22 Feb 2020 21:12:20 -0800, Noah Misch wrote in
> > > On Fri, Feb 21, 2020 at 04:49:59PM +0900, Kyotaro Horiguchi wrote:
> > I aggree that the new #ifdef can
On 2020/02/27 15:23, Kyotaro Horiguchi wrote:
At Thu, 27 Feb 2020 14:40:55 +0900, Fujii Masao
wrote in
On 2020/02/27 12:48, Kyotaro Horiguchi wrote:
Hello.
We found that targetted promotion can cause an assertion failure. The
attached TAP test causes that.
TRAP: FailedAssertion("Stand
On Sat, Feb 22, 2020 at 04:06:57PM +0100, Julien Rouhaud wrote:
> Sorry, I just realized that I forgot to commit the last changes before sending
> the patch, so here's the correct v2.
Thanks for the patch.
> + if (skipit)
> + {
> + ereport(NOTICE,
> + (err
97 matches
Mail list logo
