> "Michael" == Michael Paquier writes:
> On Fri, Oct 18, 2019 at 02:21:30PM +0100, Colin Watson wrote:
>> However, an alternative would be to backport the new syntax to some
>> earlier versions. "WITH ... AS MATERIALIZED" can easily just be
>> synonymous with "WITH ... AS" in versions
On Fri, Oct 18, 2019 at 01:26:27PM -0500, Justin Pryzby wrote:
> Checking if anybody is working on either of these
> https://www.postgresql.org/message-id/20191013025145.GC4475%40telsasoft.com
> https://www.postgresql.org/message-id/20191015164047.GA22729%40telsasoft.com
FWIW, I have spent an
On Fri, Oct 18, 2019 at 02:21:30PM +0100, Colin Watson wrote:
> However, an alternative would be to backport the new syntax to some
> earlier versions. "WITH ... AS MATERIALIZED" can easily just be
> synonymous with "WITH ... AS" in versions prior to 12; there's no need
> to support "NOT
On Thu, Oct 17, 2019 at 02:35:13PM +0900, Michael Paquier wrote:
> ArchiveRecoveryRequested will be set to true if recovery.signal or
> standby.signal are found, so it seems to me that you can make all
> those checks more simple by removing from the equation
> StandbyModeRequested, no?
On Fri, Oct 18, 2019 at 10:03:11AM +0900, Michael Paquier wrote:
> Not sure that's worth the trouble. If there are no objections, I will
> remove the compatibility macros.
Okay, cleanup done with the compatibility macros removed.
--
Michael
signature.asc
Description: PGP signature
On Fri, Oct 18, 2019 at 07:30:37AM -0300, Alvaro Herrera wrote:
> Sure thing, thanks, done :-)
Thanks, Alvaro.
--
Michael
signature.asc
Description: PGP signature
I am not sure if this causes any potential problems or not, but for
consistency of code seems we are missing below. All other places in code
where sigsetjmp() exists for top level handling has error_context_stack set
to NULL.
diff --git a/src/backend/postmaster/autovacuum.c
I've been struggling with how we're going to upgrade launchpad.net to
PostgreSQL 12 or newer (we're currently on 10). We're one of those
applications that deliberately uses CTEs as optimization fences in a few
difficult places. The provision of the MATERIALIZED keyword in 12 is
great, but the
On Fri, Oct 18, 2019, at 12:37, Ariadne Conill wrote:
> Hello,
>
> I am one of the primary maintainers of Pleroma, a federated social
> networking application written in Elixir, which uses PostgreSQL in
> ways that may be considered outside the typical usage scenarios for
> PostgreSQL.
>
>
Checking if anybody is working on either of these
https://www.postgresql.org/message-id/20191013025145.GC4475%40telsasoft.com
https://www.postgresql.org/message-id/20191015164047.GA22729%40telsasoft.com
On Sat, Oct 12, 2019 at 09:51:45PM -0500, Justin Pryzby wrote:
> I ran into this while trying
Smarter version of join selectivity patch handling cases like this:
explain select * from outer_tab join inner_tab using(x,y) where x=1;
QUERY PLAN
Nested
Hi Hackers,
By optimising our application I stumbled over the join quals used very often in
our application.
In general this concerns datasets, which are subdivided into chunks, like
years, seasons (here half a year), multiple tenants in OLTP system etc.
In these cases many tables are joined
Hi,
I can trivially reproduce this - it's enough to create a master-standby
setup, and then do this on the master
CREATE TABLE t (a int, b int);
INSERT INTO t SELECT i, i FROM generate_series(1,1) s(i);
and run pgbench with this script
DROP INDEX CONCURRENTLY IF EXISTS t_a_idx;
CREATE
Kyotaro Horiguchi writes:
> The immediately problematic command generated by autoconf is:
> ...
> /usr/bin/ld: /tmp/ccGxodNv.o: relocation R_X86_64_32 against symbol
> `PL_memory_wrap' can not be used when making a PIE object; recompile with
> -fPIC
> /usr/bin/ld: final link failed:
On Fri, Oct 18, 2019 at 07:54:18AM -0400, Corey Huinker wrote:
Attached is a patch to implement change badges in our documentation.
What's a change badge? It's my term for a visual cue in the documentation
used to indicate that the nearby section of documentation is new in this
version or
Jeremy Finzel writes:
> test=# CREATE TEMP TABLE foo (id int primary key);
> CREATE TABLE
> test=# CREATE VIEW bar AS SELECT * FROM foo;
> NOTICE: view "bar" will be a temporary view
> CREATE VIEW
> ...
> test=# INSERT INTO bar (id)
> VALUES (1)
> ON CONFLICT ON CONSTRAINT foo_pkey
> DO NOTHING;
Greetings,
* Chapman Flack (c...@anastigmatix.net) wrote:
> On 10/18/19 08:18, Stephen Frost wrote:
> > I realize that I need to don some fireproof gear for suggesting this,
> > but I really wonder how much fallout we'd have from just allowing {} to
> > be used.. It's about a billion[1] times
Alvaro Herrera writes:
> On 2019-Oct-17, Michael Paquier wrote:
>> On Tue, Oct 15, 2019 at 09:00:23AM +0200, Peter Eisentraut wrote:
>>> I think we can clean this up and just have the regular ddl.def built
>>> normally at build time if required.
>>> Does anyone know more about this?
> Well, yes,
On 10/18/19 08:18, Stephen Frost wrote:
> I realize that I need to don some fireproof gear for suggesting this,
> but I really wonder how much fallout we'd have from just allowing {} to
> be used.. It's about a billion[1] times cleaner and more sensible than
> using {0} and doesn't create a
On Fri, Oct 18, 2019 at 3:42 AM Tom Lane wrote:
> Jeremy Finzel writes:
> > I'm not sure if this can be considered a bug or not, but it is perhaps
> > unexpected. I found that when using a view that is simply select * from
> > table, then doing INSERT ... ON CONFLICT ON CONSTRAINT
>>ShmZoneContext for SharedPlan and SharedRelCache is not implemented but
>>I'm going to do it following your points.
>
>After looking into existing code, I'm thinking Generation Memory Context seems
>to
>have the similar purpose. So I'll implement ShmZoneContext by reference it.
>Generation
On Fri, 18 Oct 2019 07:47:13 +0200
Julien Rouhaud wrote:
> On Fri, Oct 18, 2019 at 7:32 AM Michael Paquier wrote:
> >
> > On Thu, Oct 17, 2019 at 08:00:15PM +0200, Julien Rouhaud wrote:
> > > Jehan-Guillaume (in Cc) reported me today a problem with logical
> > > replication, where in case of
On Thu, 17 Oct 2019 at 03:12, Sergei Fedorov
wrote:
> Hello everybody,
>
> Our company was in desperate need of portals in async interface of libpq,
> so we patched it.
>
> We would be happy to upstream the changes.
>
> The description of changes:
>
> Two functions in libpq-fe.h:
>
Greetings,
* Thomas Munro (thomas.mu...@gmail.com) wrote:
> On Tue, Oct 8, 2019 at 11:09 PM Amit Kapila wrote:
> > I am personally still in the camp of people advocating the use of
> > macro for this purpose. It is quite possible after reading your
> > points, some people might change their
On 2019-Oct-17, Michael Paquier wrote:
> On Tue, Oct 15, 2019 at 09:00:23AM +0200, Peter Eisentraut wrote:
> > I think we can clean this up and just have the regular ddl.def built
> > normally at build time if required.
> >
> > Does anyone know more about this?
>
> This comes from here, but I
Am 18.10.19 um 05:06 schrieb Michael Paquier:
> So attached is a patch to skip trailing whitespaces as well,
> which also fixes the issue with ECPG. I have refactored the parsing
> logic a bit while on it. The comment at the top of parse_int_param()
> needs to be reworked a bit more.
I tested
Am 18.10.19 um 05:06 schrieb Michael Paquier:
> So attached is a patch to skip trailing whitespaces as well,
> which also fixes the issue with ECPG. I have refactored the parsing
> logic a bit while on it. The comment at the top of parse_int_param()
> needs to be reworked a bit more.
I tested
On Mon, Oct 14, 2019 at 3:09 PM Dilip Kumar wrote:
>
> On Thu, Oct 3, 2019 at 4:03 AM Tomas Vondra
> wrote:
> >
> >
> > Sure, I wasn't really proposing to adding all stats from that patch,
> > including those related to streaming. We need to extract just those
> > related to spilling. And yes,
Am 18.10.19 um 05:06 schrieb Michael Paquier:
> So attached is a patch to skip trailing whitespaces as well,
> which also fixes the issue with ECPG. I have refactored the parsing
> logic a bit while on it. The comment at the top of parse_int_param()
> needs to be reworked a bit more.
I tested
Attached is a patch to implement change badges in our documentation.
What's a change badge? It's my term for a visual cue in the documentation
used to indicate that the nearby section of documentation is new in this
version or otherwise changed from the previous version.
One example of change
On Fri, Oct 18, 2019 at 10:55 AM Amit Kapila wrote:
>
> On Fri, Oct 18, 2019 at 9:41 AM Dilip Kumar wrote:
> >
> > On Wed, Oct 16, 2019 at 7:22 PM Heikki Linnakangas wrote:
> > >
> > > On 16 October 2019 12:57:03 CEST, Amit Kapila
> > > wrote:
> > > >On Tue, Oct 15, 2019 at 7:13 PM Heikki
On Thu, Oct 17, 2019 at 10:51 AM Asif Rehman wrote:
>
> Attached are the updated patches.
>
I had a quick look over these changes and they look good overall.
However, here are my few review comments I caught while glancing the patches
0002 and 0003.
--- 0002 patch
1.
Can lsn option be
On 2019-Oct-18, Michael Paquier wrote:
> What you are proposing here sounds fine to me. Perhaps you would
> prefer to adjust the code yourself?
Sure thing, thanks, done :-)
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training
Hi,
On 2019-10-17 12:47:47 -0300, Alvaro Herrera wrote:
> On 2019-Oct-10, Ildar Musin wrote:
>
> > 1. Unlike FDW API, in pluggable storage API there are no routines like
> > "begin modify table" and "end modify table" and there is no shared
> > state between insert/update/delete calls.
>
> Hmm.
On Thu, 17 Oct 2019 at 21:19, Alvaro Herrera
wrote:
> On 2019-Sep-26, Alvaro Herrera wrote:
>
> > On 2019-Sep-26, Jeff Janes wrote:
>
> > > Hi Alvaro, does this count as a review?
> >
> > Well, I'm already a second pair of eyes for Craig's code, so I think it
> > does :-) I would have liked
On 2019-Oct-18, Etsuro Fujita wrote:
> While reviewing the partitionwise-join patch, I noticed $Subject，ie,
> this in create_list_bounds():
>
> /*
> * Never put a null into the values array, flag instead for
> * the code further down below where
At the risk of forking this thread... I think there's actually a
planner estimation bug here too.
Consider this test case of a simple partitioned table and a simple
join. The cardinality estimates for each partition and the Append node
are all perfectly accurate. But the estimate for the join is
Hi,
Am Samstag, den 04.05.2019, 21:50 +0900 schrieb Michael Paquier:
> On Tue, Apr 30, 2019 at 03:07:43PM +0200, Michael Banck wrote:
> > This is still an open item for the back branches I guess, i.e. zero page
> > header for pg_verify_checksums and additionally random page header for
> >
Jeremy Finzel writes:
> I'm not sure if this can be considered a bug or not, but it is perhaps
> unexpected. I found that when using a view that is simply select * from
> table, then doing INSERT ... ON CONFLICT ON CONSTRAINT constraint_name on
> that view, it does not find the constraint and
On Fri, Oct 11, 2019 at 3:14 AM Tom Lane wrote:
> I do not like attaching this data to the DECLARE_UNIQUE_INDEX macros.
> It's really no business of the indexes' whether they are associated
> with a syscache. It's *certainly* no business of theirs how many
> buckets such a cache should start off
While reviewing the partitionwise-join patch, I noticed $Subject，ie,
this in create_list_bounds():
/*
* Never put a null into the values array, flag instead for
* the code further down below where we construct the actual
*
On Fri, Oct 18, 2019 at 11:25 AM Amit Kapila wrote:
>
> On Fri, Oct 18, 2019 at 8:45 AM Dilip Kumar wrote:
> >
> > On Thu, Oct 17, 2019 at 4:00 PM Amit Kapila wrote:
> > >
> > > On Thu, Oct 17, 2019 at 3:25 PM Dilip Kumar wrote:
> > > >
> > > > On Thu, Oct 17, 2019 at 2:12 PM Masahiko Sawada
42 matches
Mail list logo
