On Fri, 2020-07-17 at 05:21 +, tsunakawa.ta...@fujitsu.com wrote:
> From: Masahiko Sawada
> I have briefly checked the only oracle_fdw but in general I think that
> > if an existing FDW supports transaction begin, commit, and rollback,
> > these can be ported to new FDW transaction APIs
>
> Leader process then identifies that there are some messages that need
> to be processed, it copies the messages and sets the latch so that the
> worker process can copy the remaining message from the below function:
> shm_mq_inc_bytes_read -> SetLatch(>procLatch);, Worker is not
> able to
On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Noah Misch writes:
> > On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
> >> Along the same line, I read at [1]
> >>
> >> Because it has been such a long time, and because some of the changes
> >>
On 2020/07/16 11:50, torikoshia wrote:
On 2020-07-15 11:44, Fujii Masao wrote:
On 2020/07/14 21:24, torikoshia wrote:
On 2020-07-10 10:49, torikoshia wrote:
On 2020-07-08 16:41, Fujii Masao wrote:
On 2020/07/08 10:14, torikoshia wrote:
On 2020-07-06 22:16, Fujii Masao wrote:
On
On Fri, 17 Jul 2020 at 11:06, Masahiro Ikeda wrote:
>
> On 2020-07-16 13:16, Masahiko Sawada wrote:
> > On Tue, 14 Jul 2020 at 17:24, Masahiro Ikeda
> > wrote:
> >>
> >> > I've attached the latest version patches. I've incorporated the review
> >> > comments I got so far and improved locking
From: Laurenz Albe
> On Fri, 2020-07-17 at 05:21 +, tsunakawa.ta...@fujitsu.com wrote:
> > And most importantly, do other major DBMSs, including Oracle, provide the
> API for
> > preparing a transaction? In other words, will the FDWs other than
> postgres_fdw
> > really be able to take
On 2020-07-16 18:17, Tom Lane wrote:
Andres Freund writes:
I think it'd be a good plan to adopt the beta on master.
We already have parts of it backpacked, there have been things we couldn't
easily do because of bugs in 2.69. There aren't that many changes to configure
it total, and
On 2020/07/14 20:30, David Steele wrote:
On 7/14/20 12:00 AM, Fujii Masao wrote:
The patch was no longer applied cleanly because of recent commit.
So I updated the patch. Attached.
Barring any objection, I will commit this patch.
This doesn't look right:
+ the most recent megabytes
+
The attached patch allows the vacuum to continue by emitting WARNING
for the corrupted tuple instead of immediately error out as discussed
at [1].
Basically, it provides a new GUC called vacuum_tolerate_damage, to
control whether to continue the vacuum or to stop on the occurrence of
a corrupted
On Wednesday, July 15, 2020 12:52 PM (GMT+9), David Rowley wrote:
>On Wed, 15 Jul 2020 at 14:51, Amit Kapila wrote:
>>
>> On Wed, Jul 15, 2020 at 5:55 AM David Rowley wrote:
>>> If we've not seen any performance regressions within 1 week, then I
>>> propose that we (pending final review) push
>
> On Tue, Jul 14, 2020 at 6:13 PM Ashutosh Bapat
> wrote:
> >
> > Has this been added to CF, possibly next CF?
> >
>
> I have not added yet. Request to get it done in this CF, as the final
> patch for review(v3 patch) is ready and shared. We can target it to
> the next CF if there are major
On Fri, 17 Jul 2020 at 14:22, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> I have briefly checked the only oracle_fdw but in general I think that
> > if an existing FDW supports transaction begin, commit, and rollback,
> > these can be ported to new FDW transaction APIs easily.
> >
> > I will change the status to "ready for committer" in commitfest
> > tomorrow. Hope that's fine.
>
> I agree, a committer can have a look at this.
>
I changed the status in the commit fest to "Ready for Committer".
https://commitfest.postgresql.org/28/2632/
With Regards,
Bharath
On Fri, Jul 17, 2020 at 11:35 AM k.jami...@fujitsu.com
wrote:
>
> On Wednesday, July 15, 2020 12:52 PM (GMT+9), David Rowley wrote:
>
> >On Wed, 15 Jul 2020 at 14:51, Amit Kapila wrote:
> >>
> >> On Wed, Jul 15, 2020 at 5:55 AM David Rowley wrote:
> >>> If we've not seen any performance
Noah Misch writes:
> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
>
>> Instead of doing this on the master branch, would it be worth defining a
>> namespace for branches that the buildfarm tests in addition to master
>> and REL_*_STABLE?
>>
>> In the Perl world we
On Fri, Jul 17, 2020 at 9:53 AM osumi.takami...@fujitsu.com
wrote:
>
> Lastly, I have to admit that
> the status of target table where data is loaded by COPY UNLOGGED would be
> marked
> as invalid and notified to standbys under replication environment
> from the point in time when the operation
On 7/17/20 5:11 AM, Fujii Masao wrote:
On 2020/07/14 20:30, David Steele wrote:
On 7/14/20 12:00 AM, Fujii Masao wrote:
The patch was no longer applied cleanly because of recent commit.
So I updated the patch. Attached.
Barring any objection, I will commit this patch.
This doesn't look
On Fri, Jul 17, 2020 at 11:15 AM Michael Paquier wrote:
>
> On Fri, Jul 10, 2020 at 09:58:28AM +0530, vignesh C wrote:
> > Thanks for reviewing the patch.
> > This changes is already present in the document, no need to make any
> > changes as shown below:
> >
> > COPY table_name [ ( column_name
On Fri, Jul 17, 2020 at 4:12 PM Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> > Noah Misch writes:
> >> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker
> wrote:
> >>> Instead of doing this on the master branch, would it be worth
On Fri, Jul 17, 2020 at 1:56 AM Alexey Kondratov
wrote:
> However, there is an issue with aggregates as well. For a query like:
>
> SELECT
> count(*)
> FROM
> documents
> WHERE
> company_id = 5;
>
> It would be great to teach planner to understand, that it's a
> partition-wise
On Fri, Jul 17, 2020 at 8:10 AM Dave Cramer wrote:
> This started out with just fixing
>
> "One option do deal" to " One option to deal"
>
> But after reading the rest I'd propose the following patch.
>
Suggest replacing "though" with "however" instead of trying to figure out
what amount of
On Sat, Jul 18, 2020 at 12:44 AM Ashutosh Bapat
wrote:
> On Fri, Jul 17, 2020 at 8:24 PM Etsuro Fujita wrote:
> > On Fri, Jul 17, 2020 at 1:56 AM Alexey Kondratov
> > wrote:
> > > However, there is an issue with aggregates as well. For a query like:
> > >
> > > SELECT
> > > count(*)
> > >
Some review comments (mostly) from the leader side code changes:
1) Do we need a DSM key for the FORCE_QUOTE option? I think FORCE_QUOTE
option is only used with COPY TO and not COPY FROM so not sure why you have
added it.
PARALLEL_COPY_KEY_FORCE_QUOTE_LIST
2) Should we be allocating the
Michael Paquier writes:
> On Thu, Jul 16, 2020 at 09:46:03PM +0200, Christoph Berg wrote:
>> Or that, yes. (The correct German transliteration is
>> "Mitteleuropaeische" with 'ae'.)
> tznames/Europe.txt is iso-latin-1-unix for buffer-file-coding-system
> since its introduction in d8b5c95, and
> On Fri, Jul 17, 2020 at 7:01 AM Michael Paquier wrote:
>
> > Hmm. Knowing if a leader is actually running parallel query or not
> > requires a lookup at lockGroupMembers, that itself requires a LWLock.
> > I think that it would be better to not require that. So what if
> > instead we logged
On Fri, Jul 17, 2020 at 8:24 PM Etsuro Fujita wrote:
>
> On Fri, Jul 17, 2020 at 1:56 AM Alexey Kondratov
> wrote:
> > However, there is an issue with aggregates as well. For a query like:
> >
> > SELECT
> > count(*)
> > FROM
> > documents
> > WHERE
> > company_id = 5;
> >
> > It
On Fri, Jul 17, 2020 at 8:58 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Hey,
>
> I installed PostgreSQL source for the first time a few weeks ago. I am
> now just getting to my first pull-and-reinstall. I run make again at the
> top of the repo and I get:
> [...]
>
> I then ran
Magnus Hagander writes:
> That one does more or less what Dagfinn suggests except in a separate repo.
> We could also just have a separate repo for it where people could push if
> we wanted to. Which could be committers, or others. But in comparison with
> what Perl does, I would assume actually
On Fri, 17 Jul 2020 at 11:17, David G. Johnston
wrote:
> On Fri, Jul 17, 2020 at 8:10 AM Dave Cramer wrote:
>
>> This started out with just fixing
>>
>> "One option do deal" to " One option to deal"
>>
>> But after reading the rest I'd propose the following patch.
>>
>
> Suggest replacing
On Fri, Jul 17, 2020 at 5:11 PM Rémi Lapeyre
wrote:
>
>
> > It's hard to find an explanation what this patch actually does. I don't
> > want to have to go through threads dating back 4 months to determine
> > what was discussed and what was actually implemented. Since you're
> > already using
On 2020/07/16 14:47, Masahiko Sawada wrote:
On Tue, 14 Jul 2020 at 11:19, Fujii Masao wrote:
On 2020/07/14 9:08, Masahiro Ikeda wrote:
I've attached the latest version patches. I've incorporated the review
comments I got so far and improved locking strategy.
Thanks for updating the
I wrote:
> Given the current state of affairs, I'm inclined to commit the
> attached with no new test coverage, and then come back and look
> at better testing after the other bugs are dealt with.
Pushed back to v12.
regards, tom lane
On Fri, Jul 17, 2020 at 5:40 AM Noah Misch wrote:
> On Wed, Jul 15, 2020 at 02:54:37PM +0200, Magnus Hagander wrote:
> > Our Fine Manual (TM) specifies:
> > "As an exception, when changing the type of an existing column, if the
> > USING clause does not change the column contents and the old
Magnus Hagander writes:
> As Amit mentions it is also triggered by some store parameter changes. But
> not all. So looking at it the other way, the part that the end user really
> cares about it "which ALTER TABLE operations will rewrite the table and
> which will not". Maybe what we need is a
Hey,
I installed PostgreSQL source for the first time a few weeks ago. I am now
just getting to my first pull-and-reinstall. I run make again at the top
of the repo and I get:
git @ 7fe3083f4
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Noah Misch writes:
>> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
>>> Instead of doing this on the master branch, would it be worth defining a
>>> namespace for branches that the buildfarm tests
CSV format supports the HEADER option to output a header in the output,
it is convenient when other programs need to consume the output. This
patch adds the same option to the default text format.
Discussion:
> It's hard to find an explanation what this patch actually does. I don't
> want to have to go through threads dating back 4 months to determine
> what was discussed and what was actually implemented. Since you're
> already using git format-patch, just add something to the commit message.
>
>
This started out with just fixing
"One option do deal" to " One option to deal"
But after reading the rest I'd propose the following patch.
Dave Cramer
reorderdoc.patch
Description: Binary data
On 2020/07/17 20:04, Masahiko Sawada wrote:
On Fri, 17 Jul 2020 at 14:22, tsunakawa.ta...@fujitsu.com
wrote:
From: Masahiko Sawada
I have briefly checked the only oracle_fdw but in general I think that
if an existing FDW supports transaction begin, commit, and rollback,
these can be
COPY FROM supports the HEADER option to silently discard the header from
a CSV or text file. It is possible to load by mistake a file that
matches the expected format, for example if two text columns have been
swapped, resulting in garbage in the database.
This option adds the possibility to
>
> I don't know how to do that with git-send-email, but you can certainly do it
> easy with git-format-patch and just attach them using your regular MUA.
>
> (and while the cfbot and the archives have no problems dealing with the
> change in subject, it does break threading in some other
On Fri, Jul 17, 2020 at 11:35:40AM -0400, Alvaro Herrera wrote:
> > On Fri, Jul 17, 2020 at 7:01 AM Michael Paquier wrote:
> >
> > > Hmm. Knowing if a leader is actually running parallel query or not
> > > requires a lookup at lockGroupMembers, that itself requires a LWLock.
> > > I think that
On 2020-07-17 15:55, Masahiko Sawada wrote:
On Fri, 17 Jul 2020 at 11:06, Masahiro Ikeda
wrote:
On 2020-07-16 13:16, Masahiko Sawada wrote:
> On Tue, 14 Jul 2020 at 17:24, Masahiro Ikeda
> wrote:
>>
>> > I've attached the latest version patches. I've incorporated the review
>> > comments I
On 2020-Jul-17, Justin Pryzby wrote:
> Ok, but should we then consider changing pg_stat_activity for consistency ?
> Probably in v13 to avoid changing it a year later.
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b025f32e0b5d7668daec9bfa957edf3599f4baa8
>
> I think the
On Sat, Jul 18, 2020 at 2:12 AM Tom Lane wrote:
> Another issue is that we're not going to open up the main repo for
> access by non-committers, so this approach doesn't help for most
> developers. We've had some success, I think, with Munro's cfbot
> solution --- I'd rather see that approach
On Thu, Jul 16, 2020 at 10:24 AM Anastasia Lubennikova
wrote:
> It's impressive that this check helped to find several bugs.
While it's definitely true that it *could* have detected the bug fixed
by commit b0229f26, it's kind of debatable whether or not the bugs I
fixed in commit fa7ff642 and
On Fri, Jul 17, 2020 at 05:27:21PM -0400, Alvaro Herrera wrote:
> On 2020-Jul-17, Justin Pryzby wrote:
> > Ok, but should we then consider changing pg_stat_activity for consistency ?
> > Probably in v13 to avoid changing it a year later.
> >
Hi,
So, I am not a Windows native, and here I am mentoring a GSoC student
setting up CI on multiple environments, including Windows.
In my own development and testing, by habit I do everything from
unprivileged accounts, just spinning up an instance in a temp location,
running some tests, and
On Tue, 2020-07-14 at 21:12 -0700, Peter Geoghegan wrote:
> Attached is a WIP patch implementing hash_mem_multiplier, with 1.0 as
> the GUC's default value (i.e. the patch introduces no behavioral
> changes by default). The first patch in the series renames some local
> variables whose name is
On Fri, Jul 17, 2020 at 5:13 PM Jeff Davis wrote:
> The idea is growing on me a bit. It doesn't give exactly v12 behavior,
> but it does offer another lever that might tackle a lot of the
> practical cases.
Cool.
> If I were making the decision alone, I'd still choose
> the escape hatch based
On Fri, Jul 17, 2020 at 07:24:28PM +0200, Christoph Berg wrote:
> Re: Tom Lane
>> Done that way. I also checked for other discrepancies between
>> tznames/Default and the other files, and found a few more trivialities.
>
> Thanks!
+1.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2020-07-17 10:46:30 +0200, Peter Eisentraut wrote:
> Okay, let's take a look. Attached is a patch series.
Cool.
> One thing that's annoying is that the release notes claim that configure
> should now be faster, and some of the changes they have made should support
> that, but my
headerscheck and cpluspluscheck are both unhappy about this:
./src/include/replication/worker_internal.h:49:2: error: unknown type name
'slock_t'
slock_t relmutex;
^~~
Now, worker_internal.h itself hasn't changed in some time.
I conclude that somebody rearranged one of the header files
Working through this ... what is the rationale for having changed
the API of logicalrep_read_update? It seems kind of random,
especially since no comparable change was made to
logicalrep_read_insert. If there's actually a good reason,
it seems like it'd apply to both. If there's not, I'd be
On 2020-Jul-17, David G. Johnston wrote:
> On Fri, Jul 17, 2020 at 8:58 AM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> Sorry for the noise - though maybe some insight is still warranted - but
> running make clean first seems to have cleared up my problem.
Do you run "configure
Re: Tom Lane
> Done that way. I also checked for other discrepancies between
> tznames/Default and the other files, and found a few more trivialities.
Thanks!
Christoph
"David G. Johnston" writes:
> Sorry for the noise - though maybe some insight is still warranted - but
> running make clean first seems to have cleared up my problem.
Yeah. Just doing "git pull" and "make" will often fail, because by
default there's nothing guaranteeing that all dependent files
On Thu, 16 Jul 2020 at 20:29, Tom Lane wrote:
>
> Dean Rasheed questioned this longstanding behavior:
>
> regression=# SELECT 'nan'::float8 / '0'::float8;
> ERROR: division by zero
>
> After a bit of research I think he's right: per IEEE 754 this should
> yield NaN, not an error. Accordingly I
Hi,
On 2020-07-17 16:09:14 -0400, Tom Lane wrote:
> headerscheck and cpluspluscheck are both unhappy about this:
>
> ./src/include/replication/worker_internal.h:49:2: error: unknown type name
> 'slock_t'
> slock_t relmutex;
> ^~~
>
> Now, worker_internal.h itself hasn't changed in
On Sat, Jul 11, 2020 at 11:53 PM Tom Lane wrote:
>
> vignesh C writes:
> > On Tue, Jun 30, 2020 at 2:41 PM Bharath Rupireddy
> > wrote:
> >> I've added this patch to commitfest -
> >> https://commitfest.postgresql.org/28/.
>
> > I felt this patch is ready for committer, changing the status to
Bharath Rupireddy writes:
> On Sat, Jul 11, 2020 at 11:53 PM Tom Lane wrote:
>> Pushed with some fiddling. Mainly, if we're going to the trouble of
>> checking for binary mode here, we might as well skip allocating the
>> line_buf too.
> Isn't it good if we backpatch this to versions 13, 12,
On Fri, Jul 17, 2020 at 05:28:51PM +0530, vignesh C wrote:
> On Fri, Jul 17, 2020 at 11:15 AM Michael Paquier wrote:
>> Not completely actually. The page of psql for \copy does not mention
>> the optional where clause, and I think that it would be better to add
>> that for consistency (perhaps
On Fri, Jul 17, 2020 at 04:08:36PM +0200, Magnus Hagander wrote:
> On Fri, Jul 17, 2020 at 5:40 AM Noah Misch wrote:
> > On Wed, Jul 15, 2020 at 02:54:37PM +0200, Magnus Hagander wrote:
> > > Our Fine Manual (TM) specifies:
> > > "As an exception, when changing the type of an existing column, if
64 matches
Mail list logo
