Hello,
The attached patch adds TRUNCATE support on foreign table.
This patch adds an optional callback ExecForeignTruncate(Relation rel)
to FdwRoutine.
It is invoked during ExecuteTruncateGuts, then FDW driver hands over
the jobs related
to complete "truncate on the foreign table".
Of course, it
Hi,
I found one crash in pg_restore, this occurs when there is a failure before
all the child workers are created. Back trace for the same is given below:
#0 0x7f9c6d31e337 in raise () from /lib64/libc.so.6
#1 0x7f9c6d31fa28 in abort () from /lib64/libc.so.6
#2 0x7f9c6d317156 in __a
Hello,
We right now don't support TRUNCATE on foreign tables.
It may be a strange missing piece and restriction of operations.
For example, if a partitioned table contains some foreign tables in its leaf,
user cannot use TRUNCATE command to clean up the partitioned table.
Probably, API design is
On 12/31/19 10:43 AM, David Fetter wrote:
On Tue, Dec 31, 2019 at 01:30:01PM +0100, Tels wrote:
Moin,
sorry for the very late reply. There was a discussion about the specific
format of the backup manifests, and maybe that was already discussed and I
just overlooked it:
1) Why invent your own f
Andrew Dunstan writes:
> On Wed, Jan 1, 2020 at 3:05 AM Bruce Momjian wrote:
>> Does the next decade start on 2020-01-01 or 2021-01-01? Postgres says
>> it start on the former date:
>> ...
>> That seems inconsistent to me. /pgtop/src/backend/utils/adt/timestamp.c
>> has this C comment:
>>
>> *
On Wed, Jan 1, 2020 at 3:05 AM Bruce Momjian wrote:
>
> Does the next decade start on 2020-01-01 or 2021-01-01? Postgres says
> it start on the former date:
>
> SELECT EXTRACT(DECADE FROM '2019-01-01'::date);
> date_part
> ---
>201
>
> SELE
Funnily enough I was having a conversation with my wife on exactly this as I
opened your email.
If the Wikipedia article is to be trusted, the following seems fitting:
SELECT EXTRACT(ORDINAL DECADE FROM '2020-01-01'::date);
date_part
---
201
And the default:
SELECT
On Tue, Dec 31, 2019 at 01:30:01PM +0100, Tels wrote:
> Moin,
>
> sorry for the very late reply. There was a discussion about the specific
> format of the backup manifests, and maybe that was already discussed and I
> just overlooked it:
>
> 1) Why invent your own format, and not just use a machi
On 31/12/19 14:35, Tom Lane wrote:
Peter Eisentraut writes:
With the attached patch, I propose to enable the colored output by
default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it
Does the next decade start on 2020-01-01 or 2021-01-01? Postgres says
it start on the former date:
SELECT EXTRACT(DECADE FROM '2019-01-01'::date);
date_part
---
201
SELECT EXTRACT(DECADE FROM '2020-01-01'::date);
date_part
On Tue, 31 Dec 2019 at 10:18, Alvaro Herrera
wrote:
Per https://no-colors.org (thanks for the link) it seems pretty clear
>
https://no-color.org
On 2019-Dec-31, Andreas Joseph Krogh wrote:
> It's easier to spot errors/warnings when they are colored/emphasized imo.
> Much
> like colored output from grep/diff; We humans have colored vision for a
> reason.
I do use color output (and find it useful), for that reason.
I'm not sure that th
På tirsdag 31. desember 2019 kl. 14:35:39, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>:
Peter Eisentraut writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many peo
> On 31 Dec 2019, at 14:35, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> With the attached patch, I propose to enable the colored output by
>> default in PG13.
>
> FWIW, I shall be setting NO_COLOR permanently if this gets committed.
Me too.
> I may well be in the minority, but I think so
On Tue, Dec 31, 2019 at 7:35 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > With the attached patch, I propose to enable the colored output by
> > default in PG13.
>
> FWIW, I shall be setting NO_COLOR permanently if this gets committed.
> I wonder how many people there are who actually *like
Peter Eisentraut writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable t
On December 31, 2019 8:10:13 PM GMT+09:00, Peter Eisentraut
wrote:
> seems counterproductive. Let's just use the normal function names.
+1.
--
Michael
Moin,
sorry for the very late reply. There was a discussion about the specific
format of the backup manifests, and maybe that was already discussed and
I just overlooked it:
1) Why invent your own format, and not just use a machine-readable
format that already exists? It doesn't have to be f
On Tue, Dec 31, 2019 at 11:40 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
>
> I'm aware of the pending patch to improve color support on Windows.
> I'll check that one out as well, but it appears to be orthogonal to this
> one.
>
>
Actually I think it would be better to rebase t
On 2019-12-24 11:17, Fabien COELHO wrote:
As suggested in "cce64a51", this patch make pgbench use postgres logging
capabilities.
I tried to use fatal/error/warning/info/debug where appropriate.
Some printing to stderr remain for some pgbench specific output.
The patch seems pretty straightfor
On 2019-12-04 11:32, Guram Duka wrote:
Master branch got error in configure stage and then compiling like 12.1
branch.
checking how to link an embedded Python application... configure:
error: could not find shared library for Python
You might have to rebuild your Python installation
With the attached patch, I propose to enable the colored output by
default in PG13.
For those who don't like color output, I also add support for the
environment variable NO_COLOR, which is an emerging standard for turning
off color across different software packages (https://no-color.org/).
Hi!
Here is the case.
Assume we have a master to slave replication with shared_buffers set up
to 2 GB at the master and 4 GB at the slave. All of the data is written
to the master, while reading occurs from slave.
Now we decided to drop many tables, let's say 1000 or 1 not in a
single t
On 2019-12-09 11:37, Peter Eisentraut wrote:
Per discussion in [0], here is a patch set to remove support for Python
versions older than 2.6.
[0]:
https://www.postgresql.org/message-id/6d3b7b69-0970-4d40-671a-268c46e93...@2ndquadrant.com
It appears that the removal of old OpenSSL support is s
On Tue, Dec 31, 2019 at 1:05 PM Masahiko Sawada
wrote:
> On Sun, Dec 1, 2019 at 12:03 PM Michael Paquier
> wrote:
> >
> > On Fri, Nov 01, 2019 at 09:38:37AM +0900, Moon, Insung wrote:
> > > Of course, I may not have written the excellent quality code
> > > correctly, so I will make an interim re
On Sun, Dec 1, 2019 at 12:03 PM Michael Paquier wrote:
>
> On Fri, Nov 01, 2019 at 09:38:37AM +0900, Moon, Insung wrote:
> > Of course, I may not have written the excellent quality code
> > correctly, so I will make an interim report if possible.
>
> The last patch has rotten, and does not apply a
26 matches
Mail list logo
