Rebased the patch with latest master and also addressed the test case
failure reported by PostgreSQL Patch Tester.
Thanks
Richard
On Fri, Nov 29, 2019 at 11:35 AM Etsuro Fujita
wrote:
> On Fri, Nov 29, 2019 at 12:08 PM Richard Guo wrote:
> > On Fri, Nov 29, 2019 at 11:03 AM Michael Paquier
On Tue, Jan 14, 2020 at 07:35:22PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 26 Dec 2019 12:46:39 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Wed, 25 Dec 2019 16:15:21 -0800, Noah Misch wrote in
> > > === Defect 1: Forgets to skip WAL after SAVEPOINT; DROP TABLE; ROLLBACK TO
> > >
> > >
On Mon, Jan 13, 2020 at 01:56:30PM -0500, Stephen Frost wrote:
> > I think that having ALTER SYSTEM commands in pg_dumpall output
> > would be a problem. It would cause all kinds of problems whenever
> > parameters change. Thinking of the transition "checkpoint_segments"
> > -> "max_wal_size",
On Sat, Jan 18, 2020 at 11:46:24AM +0800, John Naylor wrote:
> On Wed, Jan 15, 2020 at 6:09 AM David Fetter wrote:
> > [v2 patch]
>
> Hi David,
>
> I have a stylistic comment on this snippet:
>
> - for (i = _hash_log2(metap->hashm_bsize); i > 0; --i)
> - {
> - if ((1 << i) <=
Hi,
On 2020-01-19 09:52:21 +1300, Thomas Munro wrote:
> On Sun, Jan 19, 2020 at 3:08 AM Justin Pryzby wrote:
> > As I understand, the first thing that happens syncing every file in the data
> > dir, like in initdb --sync. These instances were both 5+TB on zfs, with
> > compression, so that's
Hi,
On 2020-01-18 14:11:12 -0600, Justin Pryzby wrote:
> On Sat, Jan 18, 2020 at 10:48:22AM -0800, Andres Freund wrote:
> > On 2020-01-18 08:08:07 -0600, Justin Pryzby wrote:
> > > One of our PG12 instances was in crash recovery for an embarassingly long
> > > time
> > > after hitting ENOSPC.
> On 3 Jan 2020, at 23:07, Robert Haas wrote:
>
> On Mon, Dec 16, 2019 at 10:16 AM Daniel Gustafsson wrote:
>> If reviewers think this version is nearing completion, then a v16 should
>> address the comment below, but as this version switches its underlying
>> infrastructure it seemed usefel
I've pushed this patch with some further hacking.
Most notably, I shoved the conversion-names table over to charset.sgml,
as I'd mused about doing upthread. It no longer had any reason at all
to be in section 9.4. We could have moved it down to 9.5, but I felt
that it would still be wrongly
On Sun, Jan 19, 2020 at 3:08 AM Justin Pryzby wrote:
> As I understand, the first thing that happens syncing every file in the data
> dir, like in initdb --sync. These instances were both 5+TB on zfs, with
> compression, so that's slow, but tolerable, and at least understandable, and
> with
On Fri, Jan 17, 2020 at 1:18 AM Amit Kapila wrote:
> Thanks for doing this test again. In the attached patch, I have
> addressed all the comments and modified a few comments.
I am in favor of the general idea of parallel VACUUM that parallelizes
the processing of each index (I haven't looked at
On Sat, Jan 18, 2020 at 10:48:22AM -0800, Andres Freund wrote:
> Hi,
>
> On 2020-01-18 08:08:07 -0600, Justin Pryzby wrote:
> > One of our PG12 instances was in crash recovery for an embarassingly long
> > time
> > after hitting ENOSPC. (Note, I first started wroting this mail 10 months
> >
Hi,
On 2020-01-18 08:08:07 -0600, Justin Pryzby wrote:
> One of our PG12 instances was in crash recovery for an embarassingly long time
> after hitting ENOSPC. (Note, I first started wroting this mail 10 months ago
> while running PG11 after having same experience after OOM). Running linux.
>
On Thu, Dec 05, 2019 at 09:52:50AM -0500, Robert Haas wrote:
> On Tue, Dec 3, 2019 at 10:18 AM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > But nevertheless should we allow relocatable extension to use
> > > @extschema@. Any thoughts?
> >
> > No. The reasoning in the comment still
so 18. 1. 2020 v 18:46 odesílatel Nikita Glukhov
napsal:
> Attached 41th version of the patches.
>
> Changes since previous version:
> * Enabled DEFAULT clause for ON ERROR/ON EMPTY behaviors in JSON_QUERY()
> * Added RETURNING clause to JSON_EXISTS() ("side effect" of implementation
>
Hi Julien,
bot is still unhappy
https://travis-ci.org/postgresql-cfbot/postgresql/builds/638701399
portalcmds.c: In function ‘PerformCursorOpen’:
portalcmds.c:93:7: error: ‘queryString’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
plan = pg_plan_query(query,
Tom Lane-2 wrote
> legrand legrand
> legrand_legrand@
> writes:
>> after building devel snapshot from 2020-01-17 with msys,
>> initDB generates a lot of additional informations when launched:
>> [ debug output snipped ]
>> Is that the expected behavior, or just a temporary test ?
>
> It'd be
so 18. 1. 2020 v 17:07 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Sat, Jan 18, 2020 at 7:20 AM Pavel Stehule
> wrote:
> > Can be nice to have a polymorphic function
> >
> > multirange(anymultirange, anyrange) returns anymultirange. This
> functions should to do
On Sat, Jan 18, 2020 at 7:20 AM Pavel Stehule wrote:
> Can be nice to have a polymorphic function
>
> multirange(anymultirange, anyrange) returns anymultirange. This functions
> should to do multirange from $2 to type $1
>
> It can enhance to using polymorphic types and simplify casting.
Thanks
legrand legrand writes:
> after building devel snapshot from 2020-01-17 with msys,
> initDB generates a lot of additional informations when launched:
> [ debug output snipped ]
> Is that the expected behavior, or just a temporary test ?
It'd be the expected behavior if you'd given a -d switch to
Hi!
On Tue, Dec 3, 2019 at 12:41 PM Alexey Kondratov
wrote:
> On 01.12.2019 5:57, Michael Paquier wrote:
> > On Thu, Sep 26, 2019 at 03:08:22PM +0300, Alexey Kondratov wrote:
> >> As Alvaro correctly pointed in the nearby thread [1], we've got an
> >> interference regarding -R command line
pá 17. 1. 2020 v 21:08 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Fri, Jan 10, 2020 at 1:38 AM Pavel Stehule
> wrote:
> >> This still leaves the question of how best to format the docs for
> >> these operators. I like being able to combine all the <@ variations
>
On Tue, Jan 14, 2020 at 12:53:04PM -0500, Tom Lane wrote:
> Also worth noting is that we have a seriously bad track record about
> choosing external packages to depend on. The regex code has no upstream
> maintainer anymore (well, the Tcl guys seem to think that *we* are
> upstream for that now),
One of our PG12 instances was in crash recovery for an embarassingly long time
after hitting ENOSPC. (Note, I first started wroting this mail 10 months ago
while running PG11 after having same experience after OOM). Running linux.
As I understand, the first thing that happens syncing every file
On Sat, Jan 18, 2020 at 09:19:19AM +0200, Julien Rouhaud wrote:
> On Sat, 18 Jan 2020, 09:04 Amit Kapila > +1 for adding PGDLLIMPORT to these variables. In the past, we have
>> added it on the request of some extension authors, so I don't see any
>> problem doing this time as well.
>>
>
> +1 too
On Sat, Jan 18, 2020 at 02:32:49AM -0700, legrand legrand wrote:
> No specific use-case, just the need to test features (IVM, push agg to base
> relations and joins, ...)
> on a professional laptop in windows 10 for a nomad app that collects
> performance metrics on Oracle
> databases.
That
Hello,
after building devel snapshot from 2020-01-17 with msys,
initDB generates a lot of additional informations when launched:
VERSION=13devel
PGDATA=../data
share_path=C:/msys64/usr/local/pgsql/share
PGPATH=C:/msys64/usr/local/pgsql/bin
POSTGRES_SUPERUSERNAME=lemoyp
Michael Paquier-2 wrote
> On Fri, Jan 17, 2020 at 03:07:48PM -0700, legrand legrand wrote:
> [...]
>
> No objections from me to add both to what's imported. Do you have a
> specific use-case in mind for an extension on Windows? Just
> wondering..
> --
> Michael
>
> signature.asc (849 bytes)
>
Hi Laurenz,
Thank you for taking the time to review that patch.
Le lun. 25 nov. 2019 à 22:34, Laurenz Albe a
écrit :
> On Wed, 2019-11-13 at 16:48 +0100, Lætitia Avrot wrote:
> > So after some thoughts I did the minimal patch (for now).
> > I corrected documentation for the following tools so
28 matches
Mail list logo
