Hi,
On Tue, May 28, 2019 at 12:54 PM Amit Langote
wrote:
> On 2019/05/27 22:02, Tom Lane wrote:
> > Amit Langote writes:
> >> On 2019/05/27 10:52, Shohei Mochizuki wrote:
> >>> I noticed returning a modified record in a row-level BEFORE UPDATE trigger
> >>> on postgres_fdw foreign tables do not
On Sun, May 26, 2019 at 6:43 PM Michael Paquier wrote:
> As you mention for reindex_relation() no indexes <=> nothing to do,
> still let's not rely on that. Instead of making the error message
> specific to concurrent operations, I would suggest to change it to
> "table foo has no indexes to rei
28.05.2019 2:05, Amit Kapila wrote:
> On Mon, May 27, 2019 at 3:59 AM Tom Lane wrote:
>> Amit Kapila writes:
>>> On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin
>>> wrote:
5. ExecContextForcesOids - not changed, but may be should be removed
(orphaned after 578b2297)
>>> Yes, we shoul
On 2019/05/27 21:56, Tom Lane wrote:
> Amit Langote writes:
>> On 2019/05/24 23:28, Tom Lane wrote:
>>> So my thought, if we want to do something about this, is not "find
>>> some things we can pfree at the end of planning" but "find a way
>>> to use a separate context for each statement in the qu
Dear moderator,
Are there teams behind the names or does everybody write with their
personal name?
Sascha kuhl
(personal name)
Hello,
When investigating behavior of "DISCARD ALL", I found that order of
steps of equivalent sequence in documentation is not updated with
changes in code.
Please find attached patch to fix documentation.
Best Regards,
Jan Chochol
From 6c3d4e626e993ae0ab2c05e773beea926c687177 Mon Sep 17 00:00:
Mochizuki-san,
On 2019/05/28 13:10, Shohei Mochizuki wrote:
> On 2019/05/28 12:54, Amit Langote wrote:
>> On 2019/05/27 22:02, Tom Lane wrote:
>>> Perhaps, if the table has relevant BEFORE triggers, we should just abandon
>>> our attempts to optimize away fetching/storing all columns? It seems li
On 2019/05/28 12:54, Amit Langote wrote:
On 2019/05/27 22:02, Tom Lane wrote:
Amit Langote writes:
On 2019/05/27 10:52, Shohei Mochizuki wrote:
I noticed returning a modified record in a row-level BEFORE UPDATE trigger
on postgres_fdw foreign tables do not work. Attached patch fixes this issu
On 2019/05/27 22:02, Tom Lane wrote:
> Amit Langote writes:
>> On 2019/05/27 10:52, Shohei Mochizuki wrote:
>>> I noticed returning a modified record in a row-level BEFORE UPDATE trigger
>>> on postgres_fdw foreign tables do not work. Attached patch fixes this issue.
>>> This is because current fd
On Mon, May 27, 2019 at 10:17:43AM +0200, Michael Banck wrote:
> Before we switch to -f out of consistency with oid2name, we should
> consider Magnus' argument from
> cabuevezoexaxbcymmzsnf1aqdcwovys7-chqcugry5+nsqz...@mail.gmail.com IMO:
>
> |I have no problem with changing it to -r. -f seems a b
Please see attached the patch that corrects the file-level SQL comment that
indicates which submodule of pgcrypto is being tested.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
pgcrypto-test-comments.patch
Description: Binary data
Hey Tom,
> Le 22 mai 2019 à 23:25, Tom Lane a écrit :
>
> Akim Demaille writes:
>> Honestly, I seriously doubt that you have contributors that don't
>> have MacPorts or Brew installed, and both are pretty up to date on
>> Bison.
>
> Hm, well, I'm a counterexample ;-).
Wow :) I have even more
hi Tom!
> Le 23 mai 2019 à 00:29, Tom Lane a écrit :
>
> Andrew Dunstan writes:
>> On 5/21/19 11:49 AM, Akim Demaille wrote:
>>> Usually users of Bison build tarballs with the generated parsers
>>> in them, and ship/test from that.
>
>> The buildfarm client does not build from tarballs, it bui
Tom,
> Le 23 mai 2019 à 06:00, Tom Lane a écrit :
>
> Robert Haas writes:
>> Another thing is that it would be nice to have a better way of
>> resolving conflicts than attaching precedence declarations. Some
>> problems can't be solved that way at all, and others can only be
>> solved that way
> Le 22 mai 2019 à 23:44, Daniel Gustafsson a écrit :
>
>> On 22 May 2019, at 23:25, Tom Lane wrote:
>>
>> Akim Demaille writes:
>>> Honestly, I seriously doubt that you have contributors that don't
>>> have MacPorts or Brew installed, and both are pretty up to date on
>>> Bison.
>>
>> Hm,
On Mon, May 27, 2019 at 3:59 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sun, May 26, 2019 at 2:20 AM Alexander Lakhin
> > wrote:
> >> 5. ExecContextForcesOids - not changed, but may be should be removed
> >> (orphaned after 578b2297)
>
> > Yes, we should remove the use of ExecContextForc
On Mon, May 27, 2019 at 02:08:26PM +0900, Kyotaro HORIGUCHI wrote:
> At Fri, 24 May 2019 19:33:32 -0700, Noah Misch wrote in
> <20190525023332.ge1624...@rfd.leadboat.com>
> > On Mon, May 20, 2019 at 03:54:30PM +0900, Kyotaro HORIGUCHI wrote:
> > > Following this direction, the attached PoC works
On Mon, Nov 19, 2018 at 12:53:15PM -0300, Alvaro Herrera wrote:
> commit 6e5f8d4
> Commit: Alvaro Herrera
> CommitDate: Mon Nov 19 14:34:12 2018 -0300
>
> psql: Show IP address in \conninfo
> Discussion: https://postgr.es/m/alpine.DEB.2.21.1810261532380.27686@lancre
> https://p
On Mon, May 27, 2019 at 4:51 PM Alvaro Herrera
wrote:
>
> On 2019-May-27, Peter Eisentraut wrote:
>
> > I propose to add a column "command" to pg_stat_progress_create_index.
> > The sibling view pg_stat_progress_cluster already contains such a
> > column. This can help distinguish which command i
On 2019-May-27, Peter Eisentraut wrote:
> I propose to add a column "command" to pg_stat_progress_create_index.
> The sibling view pg_stat_progress_cluster already contains such a
> column. This can help distinguish which command is running and thus
> which phases to expect. It seems reasonable
Hi,
On 2019-05-27 14:18:12 -0400, Peter Eisentraut wrote:
> I propose to add a column "command" to pg_stat_progress_create_index.
> The sibling view pg_stat_progress_cluster already contains such a
> column. This can help distinguish which command is running and thus
> which phases to expect. It
I propose to add a column "command" to pg_stat_progress_create_index.
The sibling view pg_stat_progress_cluster already contains such a
column. This can help distinguish which command is running and thus
which phases to expect. It seems reasonable to keep these views
consistent, too. (They are b
On Fri, May 24, 2019 at 05:07:15PM +0200, Sascha Kuhl wrote:
> Hi,
>
> Is it possible to obtain money for a contribution I give hear. Or is
> everything expected to be free?
As there is no sole or primary PostgreSQL company, there is no purse
from which to disburse such payments.
If you're quali
On 27.05.2019 12:26, Konstantin Knizhnik wrote:
Hi, hackers.
There is the following problem with Postgres at Windows: files of
dropped relation can be blocked for arbitrary long amount of time.
Such behavior is caused by two factors:
1. Windows doesn't allow deletion of opened file.
2. Post
Bonjour Michael,
+
+ -f filenode
+
--filenode=filenode
+
+
+Only validate checksums in the relation with specified relation file
node.
+
Two nits. I would just have been careful about the number of
characters in the line within the markup. And we
Antonin Houska wrote:
> One problem I see is that SubLink can be in the JOIN/ON clause and thus it's
> not necessarily at the top of the join tree. Consider this example:
>
> CREATE TABLE a(i int);
> CREATE TABLE b(j int);
> CREATE TABLE c(k int NOT NULL);
> CREATE TABLE d(l int);
>
> SELECT
Hi,
On 2019-05-25 00:42:39 +0200, Tomas Vondra wrote:
> On Fri, May 24, 2019 at 09:24:28AM -0700, Andres Freund wrote:
> > On 2019-05-24 12:08:57 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > The basic problem with backtrace() is that it
> > > only knows about global functions, and so
Hi,
I am getting this below error - after performing pg_rewind when i try to
start new slave ( which earlier was my master) against PGv12 Beta1.
"
cp: cannot stat ‘pg_wal/RECOVERYHISTORY’: No such file or directory
2019-05-27 18:55:47.387 IST [25500] LOG: entering standby mode
cp: cannot stat
On 2019-05-27 17:04:44 +0530, Amit Khandekar wrote:
> On Fri, 24 May 2019 at 21:00, Amit Khandekar wrote:
> >
> > On Fri, 24 May 2019 at 19:26, Amit Khandekar wrote:
> > > Working on the patch now
> >
> > Attached is an incremental WIP patch
> > handle_wal_level_changes_WIP.patch to be appli
On Tue, May 14, 2019 at 11:06 AM Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello.
>
> At Mon, 13 May 2019 17:37:50 +0800, Paul Guo wrote in <
> caeet0zf9yn4daxyuflzocayyxuff1ms_oqwea+rwv3gha5q...@mail.gmail.com>
> > Thanks for the reply.
> >
> > On Tue, May 7, 2019 at 2:47 PM
Amit Langote writes:
> On 2019/05/27 10:52, Shohei Mochizuki wrote:
>> I noticed returning a modified record in a row-level BEFORE UPDATE trigger
>> on postgres_fdw foreign tables do not work. Attached patch fixes this issue.
>> This is because current fdw code adds only columns to RemoteSQL that
Amit Langote writes:
> On 2019/05/24 23:28, Tom Lane wrote:
>> So my thought, if we want to do something about this, is not "find
>> some things we can pfree at the end of planning" but "find a way
>> to use a separate context for each statement in the query string".
> Maybe like the attached? I
On Fri, 24 May 2019 at 21:00, Amit Khandekar wrote:
>
> On Fri, 24 May 2019 at 19:26, Amit Khandekar wrote:
> > Working on the patch now
>
> Attached is an incremental WIP patch
> handle_wal_level_changes_WIP.patch to be applied over the earlier main
> patch logical-decoding-on-standby_v4_re
"Kato, Sho" writes:
> Friday, May 24, 2019 5:10 PM, David Rowley wrote:
>> The planner can only push quals down into a subquery, it cannot pull quals
>> from a subquery into the outer query.
> However, following query looks like the subquery qual is pushed down into the
> outer query.
> postgres
On Thu, May 23, 2019 at 3:44 AM Haribabu Kommi
wrote:
>
> Updated patches are attached for all branches.
>
>
I have gone through all patches and there are a couple of typos:
1. s/prodcutname/productname/
1.1 In file: 0001-support-building-with-visual-studio-2019_v9.4.patch
@@ -97,8 +97,
Hi, hackers.
There is the following problem with Postgres at Windows: files of
dropped relation can be blocked for arbitrary long amount of time.
Such behavior is caused by two factors:
1. Windows doesn't allow deletion of opened file.
2. Postgres backend caches opened descriptors and this cach
David Rowley wrote:
> On Wed, 6 Mar 2019 at 12:54, David Rowley
> wrote:
> > The latest patch is attached.
>
> Rebased version after pgindent run.
I've spent some time looking into this.
One problem I see is that SubLink can be in the JOIN/ON clause and thus it's
not necessarily at the top o
On Mon, May 27, 2019 at 08:32:21AM +0200, Fabien COELHO wrote:
> I've used both -f & --filenode in the test to check that the renaming was
> ok. I have reordered the options in the documentation so that they appear in
> alphabetical order, as for some reason --progress was out of it.
No objection
Hi,
On Mon, May 27, 2019 at 09:22:42AM +0200, Daniel Gustafsson wrote:
> > On 27 May 2019, at 03:52, Michael Paquier wrote:
> > pg_verify_checksums has been using -r for whatever reason, but as we
> > do a renaming of the binary for v12 we could just fix that
> > inconsistency as well.
>
> The o
On Mon, May 27, 2019 at 09:22:42AM +0200, Daniel Gustafsson wrote:
> The original patch used -o in pg_verify_checksums, the discussion of which
> started in the below mail:
>
> https://postgr.es/m/20180228194242.qbjasdtwm2yj5rqg%40alvherre.pgsql
>
> Since -f was already used for “force check”, -r
Mochizuki-san,
On 2019/05/27 10:52, Shohei Mochizuki wrote:
> Hi,
>
> I noticed returning a modified record in a row-level BEFORE UPDATE trigger
> on postgres_fdw foreign tables do not work. Attached patch fixes this issue.
>
> Without attached patch:
>
> postgres=# UPDATE rem1 set f1 = 10;
> po
On Mon, May 27, 2019 at 12:20:58AM -0400, Alvaro Herrera wrote:
> I wonder if we really want to abolish all distinction between "cannot do
> X" and "Y is not supported". I take the former to mean that the
> operation is impossible to do for some reason, while the latter means we
> just haven't imp
> On 27 May 2019, at 03:52, Michael Paquier wrote:
> pg_verify_checksums has been using -r for whatever reason, but as we
> do a renaming of the binary for v12 we could just fix that
> inconsistency as well.
The original patch used -o in pg_verify_checksums, the discussion of which
started in th
43 matches
Mail list logo
