On September 27, 2018 10:23:31 PM PDT, Michael Paquier
wrote:
>On Thu, Sep 27, 2018 at 08:40:26PM -0700, Andres Freund wrote:
>> On 2018-09-28 12:28:27 +0900, Michael Paquier wrote:
>>> While reviewing the archiving code, I have bumped into the fact that
>>> XLogArchiveCleanup() thinks that
On Thu, Sep 27, 2018 at 08:40:26PM -0700, Andres Freund wrote:
> On 2018-09-28 12:28:27 +0900, Michael Paquier wrote:
>> While reviewing the archiving code, I have bumped into the fact that
>> XLogArchiveCleanup() thinks that it is safe to do only a plain unlink()
>> for .ready and .done files
On Thu, Sep 27, 2018 at 11:10:08PM +0200, Peter Eisentraut wrote:
> On 26/09/2018 08:44, Michael Paquier wrote:
>> Could you rebase once again? I am going through the patch and wanted to
>> test pg_upgrade on Linux with XFS, but it does not apply anymore.
>
> attached
Thanks for the rebase. At
Hi,
On 2018-09-26 22:38:41 +0200, Fabien COELHO wrote:
> > > +"9223372036854775808" {
> > > + /* yuk: special handling for minint */
> > > + return MAXINT_PLUS_ONE_CONST;
> > > + }
> >
> > Yikes, do we really
On Wed, 19 Sep 2018 at 18:56, David Rowley wrote:
>
> On 19 September 2018 at 18:04, Edmund Horner wrote:
> > I have been generally following this approach (handling more kinds of
> > TID comparisons), and have found myself doing things like pairing up >
> > with <, estimating how much of a
On Tue, Sep 25, 2018 at 6:11 AM Alvaro Herrera wrote:
>
> On 2018-Sep-24, Sergei Kornilov wrote:
>
> > Hi
> >
> > > An autovacuum can't be just aggressive; it's either anti-wraparound or
> > > normal.
> > But autovacuum _can_ be aggressive and not anti-wraparound.
> > I build current master and
On 2018/09/28 12:12, Michael Paquier wrote:
> On Fri, Sep 28, 2018 at 02:46:30PM +1200, David Rowley wrote:
>> I don't agree that we can skip explaining why one of the optimisations
>> can't be applied just because we've explained why a similar
>> optimisation cannot be applied somewhere close by.
On 2018/09/28 11:46, David Rowley wrote:
> On 28 September 2018 at 14:25, Amit Langote
> wrote:
>> Looking at the patch itself, does it seem like both the newly added
>> comments repeat the same point (that we'll need per-partition hi_options
>> to enable these optimizations) and are pretty close
Hi,
On 2018-09-28 12:28:27 +0900, Michael Paquier wrote:
> While reviewing the archiving code, I have bumped into the fact that
> XLogArchiveCleanup() thinks that it is safe to do only a plain unlink()
> for .ready and .done files when removing a past segment. I don't think
> that it is a smart
Hi all,
While reviewing the archiving code, I have bumped into the fact that
XLogArchiveCleanup() thinks that it is safe to do only a plain unlink()
for .ready and .done files when removing a past segment. I don't think
that it is a smart move, as on a subsequent crash we may still see
those,
On Thu, Sep 27, 2018 at 11:02:06PM +0200, Dmitry Dolgov wrote:
> Yes, you're right. Although probably it's not great that the sequence of
> EventTriggerAlterTableStart, EventTriggerAlterTableRelid and
> EventTriggerAlterTableEnd is distributed between different functions (which
> most likely is
On Fri, Sep 28, 2018 at 02:46:30PM +1200, David Rowley wrote:
> I don't agree that we can skip explaining why one of the optimisations
> can't be applied just because we've explained why a similar
> optimisation cannot be applied somewhere close by. I think that the
> WAL/FSM optimisation can
On Friday, September 28, 2018 6:03 AM, David Rowley <
david.row...@2ndquadrant.com> wrote:
> I think instead of attempting to highlight other bottlenecks, it might
> be better to focus on lending a hand reviewing and testing the existing
> set of patches.
Thanks for your reply. Ok, I focus on
On 2018-09-28 12:21:08 +1000, Haribabu Kommi wrote:
> Here I attached further cleanup patches.
> 1. Re-arrange the GUC variable
> 2. Added a check function hook for default_table_access_method GUC
Cool.
> 3. Added a new hook validate_index. I tried to change the function
>
On 28 September 2018 at 14:25, Amit Langote
wrote:
> Looking at the patch itself, does it seem like both the newly added
> comments repeat the same point (that we'll need per-partition hi_options
> to enable these optimizations) and are pretty close to each other?
Thanks for looking at this.
I
Hi,
On 2018/09/28 10:23, David Rowley wrote:
> On Thu, 20 Sep 2018 at 11:31, Andres Freund wrote:
>>
>> On 2018-09-19 12:06:47 +0900, Michael Paquier wrote:
>>> On Wed, Sep 19, 2018 at 01:14:10PM +1200, David Rowley wrote:
Wouldn't it be better to modify copy.c to just perform the heap_sync
On Fri, Sep 21, 2018 at 5:40 PM Haribabu Kommi
wrote:
>
> On Fri, Sep 21, 2018 at 5:05 PM Andres Freund wrote:
>
>> Hi,
>>
>> On 2018-09-21 16:57:43 +1000, Haribabu Kommi wrote:
>>
>> > For example, in the sequential scan, the heap returns the slot with
>> > the tuple or with value array of all
On Tue, Sep 25, 2018 at 3:09 PM Michael Paquier wrote:
> On Tue, Sep 25, 2018 at 01:49:09PM +1000, Haribabu Kommi wrote:
> > Thanks for the review.
> > Fixed in the attached patch as per your suggestion.
>
Thanks for the review.
Hmm. I see a problem with the tests and the stability of what
>
On Thu, 20 Sep 2018 at 11:31, Andres Freund wrote:
>
> On 2018-09-19 12:06:47 +0900, Michael Paquier wrote:
> > On Wed, Sep 19, 2018 at 01:14:10PM +1200, David Rowley wrote:
> > > Wouldn't it be better to modify copy.c to just perform the heap_sync
> > > on just the partitions it touches?
> >
> >
On 2018/09/27 23:24, Alvaro Herrera wrote:
> On 2018-Sep-27, Amit Langote wrote:
>
>> Sorry I couldn't reply sooner, but the following of your proposed text
>> needs to be updated a bit:
>>
>> +
>> +
>> + Having a "default" partition for storing data that does not match a
Hi,
On 2018-09-27 17:34:54 -0700, Andres Freund wrote:
> On 2018-09-27 20:18:12 -0400, Tom Lane wrote:
> > > /* Handle +/- */
> > > if (dosign && adjust_sign((value < 0), forcesign, );
> > > uvalue = -(uint64) value;
> > > else
> > > uvalue = (uint64) value;
> >
> > Hm,
Hi,
On 2018-09-27 20:18:12 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I just noticed, while reviewing a patch that corrects overflow handing
> > in snprintf, that we don't correctly handle INT64_MIN in snprintf.c:
>
> Well, you still get the right answer, even if the "-value" is
>
Wrong list, reminder: always double-check thunderbird completion.
Sorry for the noise.
--
Gilles Darold
http://www.darold.net/
Greetings, all,
* Stephen Frost (sfr...@snowman.net) wrote:
> I still don't see that as a reason for tools to be suseptible to serious
> issues if a funky user gets created and I'd be surprised if there
> weren't other ways to get funky characters into the log file, but that's
> all ultimately an
Keiichi Hirobe writes:
> I am not sure whether to fix another bug, but I fixed and I attached a new
> patch,
> please check it.
I think this duplicates what I already committed at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=87d9bbca13f9c6b8f6ee986f0e399cb83bd731d4
Andres Freund writes:
> I just noticed, while reviewing a patch that corrects overflow handing
> in snprintf, that we don't correctly handle INT64_MIN in snprintf.c:
Well, you still get the right answer, even if the "-value" is
nominally undefined.
> I suspect the best way to fix this, would be
Hi,
I just noticed, while reviewing a patch that corrects overflow handing
in snprintf, that we don't correctly handle INT64_MIN in snprintf.c:
static void
fmtint(int64 value, char type, int forcesign, int leftjust,
int minlen, int zpad, int precision, int pointflag,
Hi,
On 2018-09-28 10:55:13 +1200, Thomas Munro wrote:
> On Tue, May 22, 2018 at 12:07 PM Thomas Munro
> wrote:
> > On Mon, May 21, 2018 at 7:27 PM, Mateusz Guzik wrote:
> > > I have benchmarked the change on a FreeBSD box and found an big
> > > performance win once the number of clients goes
On Tue, May 22, 2018 at 12:07 PM Thomas Munro
wrote:
> On Mon, May 21, 2018 at 7:27 PM, Mateusz Guzik wrote:
> > I have benchmarked the change on a FreeBSD box and found an big
> > performance win once the number of clients goes beyond the number of
> > hardware threads on the target machine.
On Thu, Sep 27, 2018 at 07:38:31PM +0530, Amit Kapila wrote:
> Okay, I am planning to commit the attached patch tomorrow unless you
> or anybody else has any objections to it.
None from here. Thanks for taking care of it.
--
Michael
signature.asc
Description: PGP signature
Michael,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Sep 06, 2018 at 09:20:15AM -0700, Michael Paquier wrote:
> > Attached is a patch with more comments about the intents of the test
> > suite, and the separate issue pointed out by Tom fixed. It seems to me
> > that actually
On Thu, Sep 06, 2018 at 09:20:15AM -0700, Michael Paquier wrote:
> Attached is a patch with more comments about the intents of the test
> suite, and the separate issue pointed out by Tom fixed. It seems to me
> that actually checking the contents of pg_init_privs would improve the
> reason why
Jimmy Yih writes:
> A colleague and I were playing around with dumping views and found an
> inconsistency for a view definition involving subqueries and undecorated
> constants in a UNION. When we took that view definition and restored it,
> dumping the view gave different syntax again.
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On September 27, 2018 2:55:56 PM PDT, Stephen Frost
> wrote:
> >* Andres Freund (and...@anarazel.de) wrote:
> >> On 2018-09-27 17:41:56 -0400, Stephen Frost wrote:
> >> > Of course, if I'm missing something as to why the ascii-cleaning
>
On September 27, 2018 2:55:56 PM PDT, Stephen Frost wrote:
>Greetings,
>
>* Andres Freund (and...@anarazel.de) wrote:
>> On 2018-09-27 17:41:56 -0400, Stephen Frost wrote:
>> > Of course, if I'm missing something as to why the ascii-cleaning
>makes
>> > sense or is necessary, I'm all ears, but
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-09-27 17:41:56 -0400, Stephen Frost wrote:
> > Of course, if I'm missing something as to why the ascii-cleaning makes
> > sense or is necessary, I'm all ears, but I'm just not seeing it.
>
> There's many reasons. For example you
On Fri, Sep 28, 2018 at 9:19 AM Peter Eisentraut
wrote:
> On 16/09/2018 10:19, Thomas Munro wrote:
> > 4. After creating a new database, update that row as appropriate in
> > the new database (!). Or find some other way to write a new table out
> > and switch it around, or something like that.
Hello,
A colleague and I were playing around with dumping views and found an
inconsistency for a view definition involving subqueries and undecorated
constants in a UNION. When we took that view definition and restored it,
dumping the view gave different syntax again. Although the slightly
Hi,
On 2018-09-27 17:41:56 -0400, Stephen Frost wrote:
> Of course, if I'm missing something as to why the ascii-cleaning makes
> sense or is necessary, I'm all ears, but I'm just not seeing it.
There's many reasons. For example you can send terminal control
characters to the server. When
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 24/09/2018 23:10, Stephen Frost wrote:
> > Since we're putting it into common/string.c (which seems pretty
> > reasonable to me, at least), I went ahead and changed it to be
> > 'pg_clean_ascii'. I didn't see any other
On 16/09/2018 20:12, Douglas Doole wrote:
> All this collation stuff is great, and I know users want it, but it
> feels like were pushing them out of an airplane with a ripped parachute
> every time the collation libraries change. Maybe they'll land safely or
> maybe things will get very messy.
I've noticed that the comments above the PartitionedRelPruneInfo
struct incorrectly document how subplan_map and subpart_map are
indexed. This seems to have snuck in on 4e232364033.
Also, while reading the executor README file, I noticed that we
mentioned that executor nodes are created one for
On 16/09/2018 10:19, Thomas Munro wrote:
> 4. After creating a new database, update that row as appropriate in
> the new database (!). Or find some other way to write a new table out
> and switch it around, or something like that. That is, if you say
> CREATE DATABASE foo LC_COLLATE = 'xx_XX',
On 24/09/2018 23:10, Stephen Frost wrote:
> Since we're putting it into common/string.c (which seems pretty
> reasonable to me, at least), I went ahead and changed it to be
> 'pg_clean_ascii'. I didn't see any other obvious cases where we could
> use this function (though typecmds.c does have an
On 26/09/2018 08:44, Michael Paquier wrote:
> On Sat, Sep 01, 2018 at 07:28:37AM +0200, Peter Eisentraut wrote:
>> rebased patch, no functionality changes
>
> Could you rebase once again? I am going through the patch and wanted to
> test pg_upgrade on Linux with XFS, but it does not apply
On Thu, 27 Sep 2018 at 14:16, Kato, Sho wrote:
> I am planning to investigate using a system TAP etc. for other bottlenecks.
> If you have any other convenient method, please let me know.
> Also, if there is something already known as a bottleneck, please let me know.
Thanks for doing this
> On Wed, 26 Sep 2018 at 05:33, Michael Paquier wrote:
>
> On Tue, Sep 25, 2018 at 01:39:59PM +0200, Dmitry Dolgov wrote:
> > Shouldn't it be fixed by adding EventTriggerAlterTableStart? Judging from
> > the
> > following call of ATController, we can just pass NULL as parsetree.
>
> Hmm. I
On 2018-Sep-27, Tomas Vondra wrote:
> I may be missing what you're saying, but point_mul_point is not just a
> simple multiplication of coordinates, i.e.
>
> (x1,y1) * (x2,y2) != (x1*x2, y1*y2)
>
> It essentially does this:
>
> ((x1 * x2 - y1 * y2), (x1 * y2 + x2 * y1))
>
> so I
Justin Pryzby writes:
> pg_get_partition_constraintdef() doesn't like being passed a relkind='I',
It'll also fall over if the passed OID isn't a relation at all, which
is also very much not-nice for SQL-exposed inquiry functions.
I'm inclined to fix this by
(1) inventing an lsyscache function
On 09/27/2018 07:05 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 09/27/2018 12:48 AM, Tom Lane wrote:
>>> Actually, it seems simpler than that: gaur produces plus zero already
>>> from the multiplication:
>>> regression=# select '-3'::float8 * '0'::float8;
>>> ?column?
>>> --
>>> 0
On 09/27/2018 07:21 PM, Alvaro Herrera wrote:
> If you look at the differing results carefully, there's this one:
>
> *** 3249,3255
> ! [(0,0),(3,0),(4,5),(1,6)] | (-5,-12) |
> [(0,-0),(-15,-36),(40,-73),(67,-42)]
> --- 3249,3255
> ! [(0,0),(3,0),(4,5),(1,6)] | (-5,-12)
On Thu, Sep 27, 2018 at 8:28 PM Mark Dilger wrote:
> > On Sep 18, 2018, at 3:58 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
> >
> > On Mon, Sep 17, 2018 at 12:42 PM Andrey Borodin
> wrote:
> >>> 17 сент. 2018 г., в 2:03, Alexander Korotkov <
> a.korot...@postgrespro.ru>
> On Thu, 27 Sep 2018 at 15:59, Jesper Pedersen
> wrote:
>
> I think we need a comment on this in the patch, as 10 *
> node->ioss_PlanRows looks a bit random.
Yeah, you're right, it's a bit arbitrary number - we just need to make sure
that this estimation is not too small (to avoid false
For indices inherited from relkind=p:
pryzbyj=# CREATE TABLE tt(i int)PARTITION BY RANGE(i);
pryzbyj=# CREATE TABLE tt1 PARTITION OF tt DEFAULT;
pryzbyj=# CREATE INDEX ON tt((0+i));
pryzbyj=# ALTER INDEX tt1_expr_idx ALTER COLUMN 1 SET STATISTICS 123;
pryzbyj=# \d+ tt1_expr_idx
ERROR: 42809:
I wrote:
> Here's a partial patch for that: it adds the third build variant
> to src/port/ and teaches libpq to use it. We'd want to likewise
> modify src/common/ and fix up other callers such as ecpg, but this
> seems to be enough to test whether the idea works or not.
> ...
> What I think would
On 2018-09-26 12:35:25 -0700, Andres Freund wrote:
> Hi,
>
> On 2018-09-26 12:41:38 +0900, Michael Paquier wrote:
> > On Tue, Sep 25, 2018 at 06:42:51PM -0700, Andres Freund wrote:
> > > My point is that FuncCallContext->slot isn't actually all that related
> > > to TupleDescGetSlot() and could
Dear Sir/Ma'am,
This is in reference to applying to become a mentor in Google code in.
I want to have a mentor-ship role in your organization and hence I'm
writing this email to you. I am a Final year student pursuing a major in
B.Tech Computer Science Engineering of Bharati Vidyapeeth’s College
> On Sep 18, 2018, at 3:58 PM, Alexander Korotkov
> wrote:
>
> On Mon, Sep 17, 2018 at 12:42 PM Andrey Borodin wrote:
>>> 17 сент. 2018 г., в 2:03, Alexander Korotkov
>>> написал(а):
>>>
>>> Also, it appears to me that it's OK to be a single patch
>>
>> +1, ISTM that these 6 patches
If you look at the differing results carefully, there's this one:
*** 3249,3255
! [(0,0),(3,0),(4,5),(1,6)] | (-5,-12) |
[(0,-0),(-15,-36),(40,-73),(67,-42)]
--- 3249,3255
! [(0,0),(3,0),(4,5),(1,6)] | (-5,-12) |
[(0,0),(-15,-36),(40,-73),(67,-42)]
(Third column
Tomas Vondra writes:
> On 09/27/2018 12:48 AM, Tom Lane wrote:
>> Actually, it seems simpler than that: gaur produces plus zero already
>> from the multiplication:
>> regression=# select '-3'::float8 * '0'::float8;
>> ?column?
>> --
>> 0
>> (1 row)
> Hmmm, interesting. But I still don't
Hi Andrew,
I have a question about how buildfarm works with git, could you please
help? We use buildfarm locally at PGPro to test our branches, and it
breaks when I rebase and force push to the repository. To get the remote
changes, buildfarm does 'git checkout .' followed by 'git pull', and
Working on the new lazy transform for jsonb I found another memory leak in
PLyObject_ToJsonbValue(): palloc() for output boolean JsonbValue is unnecessary,
'out' variable is already initialized.
Fix is attached.
On 15.06.2018 14:42, Alexander Korotkov wrote:
Hi!
On Fri, Jun 15, 2018 at 2:11
Hi,
On 9/27/18 5:15 AM, David Rowley wrote:
I've just completed a review of the v5 patch set. I ended up just
making the changes myself since Amit mentioned he was on leave for a
few weeks.
Summary of changes:
1. Changed the way we verify the lock already exists with debug
builds. I reverted
On 2018-Sep-27, Amit Langote wrote:
> Sorry I couldn't reply sooner, but the following of your proposed text
> needs to be updated a bit:
>
> +
> +
> + Having a "default" partition for storing data that does not match a
> + partition key
> +
> +
>
>
Michael Paquier writes:
>> On September 26, 2018 9:03:05 PM PDT, Tom Lane wrote:
>>> # libpgport is needed by some contrib
>>> +# currently we don't install libpgport_shlib.a, maybe we should?
> Likely you should as this could be used directly by out-of-core things.
Maybe, but what things
On Thu, Sep 27, 2018 at 6:22 PM Michael Paquier wrote:
>
> On Thu, Sep 27, 2018 at 04:19:02PM +0530, Amit Kapila wrote:
> > I think this is mostly fine, but it seems "if the instance just got
> > out of recovery" doesn't fit well because it can happen anytime after
> > recovery, this code gets
Hi Thomas,
On 9/18/18 9:48 PM, Thomas Munro wrote:
It certainly wouldn't hurt... but more pressing to get this committed
would be Windows support IMHO. I think the thing to do is to open
files with the FILE_FLAG_OVERLAPPED flag, and then use ReadFile() and
WriteFile() with an LPOVERLAPPED
Hi Dmitry,
On 9/15/18 3:52 PM, Dmitry Dolgov wrote:
On Thu, 13 Sep 2018 at 21:36, Alexander Kuzmenkov
wrote:
El 13/09/18 a las 18:39, Jesper Pedersen escribió:
I think we can improve this,
and the skip scan can be strictly faster than index scan regardless of
the data. As a first
Hey, folks!
I've got a question about events on roles creation.
I need to execute some custom logic on role creation.
All information about roles located in `pg_authid` table.
The first thing that comes to mind is to create trigger on `pg_authid` table,
but this is not possible, because this is
On 27 September 2018 at 06:12, Madeleine Thompson wrote:
> This is my first PostgreSQL review. Hopefully I'm getting it right. I
> independently ran into the bug in question and found that the author had
> already written a patch. I'm happy the author wrote this.
>
Thanks for the review. And
On Thu, Sep 27, 2018 at 04:19:02PM +0530, Amit Kapila wrote:
> I think this is mostly fine, but it seems "if the instance just got
> out of recovery" doesn't fit well because it can happen anytime after
> recovery, this code gets called from checkpointer. I think we can
> slightly tweak it as
On 09/27/2018 12:48 AM, Tom Lane wrote:
Tomas Vondra writes:
On 09/26/2018 06:45 PM, Tom Lane wrote:
gaur's not happy, but rather surprisingly, it looks like we're
mostly OK elsewhere. Do you need me to trace down exactly what's
going wrong on gaur?
Or you could just try doing
On Thu, Sep 27, 2018 at 1:32 PM Michael Paquier wrote:
>
> On Thu, Sep 27, 2018 at 11:18:02AM +0530, Amit Kapila wrote:
> > Your proposed solution makes sense to me. IIUC, this is quite similar
> > to what Dilip has also proposed [1].
>
> Indeed. I would just add with the patch a comment like
On Wed, Sep 19, 2018 at 1:48 PM Thomas Munro
wrote:
> On Fri, Sep 7, 2018 at 2:17 AM Jesper Pedersen
> wrote:
> > > This needs a rebase again.
And again, due to the conflict with ppoll in AC_CHECK_FUNCS.
--
Thomas Munro
http://www.enterprisedb.com
On 2018/09/27 18:15, David Rowley wrote:
> I've just completed a review of the v5 patch set. I ended up just
> making the changes myself since Amit mentioned he was on leave for a
> few weeks.
Thanks David. I'm back today and will look at the updated patches tomorrow.
Regards,
Amit
On Wed, Sep 26, 2018 at 10:34 AM Michael Paquier wrote:
>
> On Tue, Sep 25, 2018 at 11:54:53PM +0900, Masahiko Sawada wrote:
> > Can we use "XLOG_PARAMETER_CHANGE record" instead of "record
> > XLOG_PARAMETER_CHANGE" at the second hunk because the comment of the
> > first hunk uses it. The other
On Thu, Sep 27, 2018 at 01:30:13PM +0530, Amit Kapila wrote:
> I can take care of committing something along the lines of Dilip's
> patch if you are okay.
Sure, feel free to if you have some room. I am fine to take care of it
as well, so that's up to you to decide. Adding a comment like what I
On Thu, Sep 27, 2018 at 11:18:02AM +0530, Amit Kapila wrote:
> Your proposed solution makes sense to me. IIUC, this is quite similar
> to what Dilip has also proposed [1].
Indeed. I would just add with the patch a comment like that:
"Perform this call outside the critical section so as if the
On Wed, Sep 05, 2018 at 03:24:21PM +, Bossart, Nathan wrote:
> And here it is. Here is a summary of the notable changes:
>
> 1) Patches v8-0003 and v8-0008 have been discarded. These patches
> added SKIP_LOCKED behavior when opening a relation's indexes.
> Instead, I've documented
Hi,
On 2018/09/17 1:07, Jonathan S. Katz wrote:
> On 9/16/18 11:36 AM, Bruce Momjian wrote:
>> On Sat, Sep 15, 2018 at 11:06:04AM -0400, Jonathan Katz wrote:
>>> @@ -2414,12 +2408,8 @@ same commits as above
>>> The option --create-slot creates
>>> the named replication slot
Noumea, New Caledonia - September 27th, 2018
**Ora2Pg 19.1 released**
Version 19.1 of Ora2Pg, a free and reliable tool used to migrate an
Oracle database to PostgreSQL, has been officially released and is
publicly available for download.
This release fix several issues reported during the last
81 matches
Mail list logo
