Peter Eisentraut writes:
> Refactor dlopen() support
Buildfarm member locust doesn't like this much. I've been able to
reproduce the problem on an old Mac laptop running the same macOS release,
viz 10.5.8. (Note that we're not seeing it on earlier or later releases,
which is odd in itself.) Ac
On Thu, Sep 6, 2018 at 12:01 PM Peter Eisentraut
wrote:
> On 05/09/2018 23:18, Thomas Munro wrote:
> > On Wed, Sep 5, 2018 at 12:10 PM Christoph Berg wrote:
> >>> So, it's not ideal but perhaps worth considering on the grounds that
> >>> it's better than nothing?
> >>
> >> Ack.
> >
> > Ok, here's
On Tue, Aug 28, 2018 at 07:34:36PM +0900, Kyotaro HORIGUCHI wrote:
> Thanks for prompting. The difference is in a comment and I'm fine
> with the change.
/*
* Properly accept or ignore signals the postmaster might send us.
*/
- pqsignal(SIGHUP, StartupProcSigHupHandler); /* reload config f
Andres Freund writes:
> Could you attach the current version of the patch, or were there no
> meaningful changes?
No changes.
>> So I took that as license to proceed, but while doing a final round of
>> testing I found out that a CLOBBER_CACHE_RECURSIVELY build fails,
>> because now that's an in
On Thu, Sep 06, 2018 at 11:25:01PM +0200, Dmitry Dolgov wrote:
> I always wondered what would be the reaction on a first-time CFM?
There is a first time for all.
--
Michael
signature.asc
Description: PGP signature
On 2018-09-06 17:38:38 -0400, Tom Lane wrote:
> I wrote:
> > So where are we on this? Should I proceed with my patch, or are we
> > going to do further investigation? Does anyone want to do an actual
> > patch review?
>
> [ crickets... ]
Sorry, bit busy with postgres open, and a few people bein
I wrote:
> So where are we on this? Should I proceed with my patch, or are we
> going to do further investigation? Does anyone want to do an actual
> patch review?
[ crickets... ]
So I took that as license to proceed, but while doing a final round of
testing I found out that a CLOBBER_CACHE_REC
> On Thu, 6 Sep 2018 at 22:50, Michael Paquier wrote:
>
> If somebody wishes to act as such and is familiar with the community process,
> feel free to reply to this thread to manifest yourself.
I always wondered what would be the reaction on a first-time CFM? If it's ok I
would love to try out, b
Hi all,
We are already in September, hence it is time to move on with the 2nd
commit fest for v12. As usual, there are many patches waiting for
review and integration:
https://commitfest.postgresql.org/19/
With a couple of days of delay, I have switched the CF app as
in-progress on Tuesday AOE.
> "Tom" == Tom Lane writes:
Tom> Also, in further service of providing insulation between SPI
Tom> nesting levels, I thought it'd be a good idea for SPI_connect() to
Tom> reset the globals to zero/NULL after saving them. This ensures
Tom> that a nesting level can't accidentally be affecte
Peter Eisentraut writes:
> On 06/09/2018 18:25, Tom Lane wrote:
>> Also, in further service of providing insulation between SPI nesting
>> levels, I thought it'd be a good idea for SPI_connect() to reset the
>> globals to zero/NULL after saving them. This ensures that a nesting
>> level can't acc
On 09/06/2018 08:04 PM, James Coleman wrote:
> I disagree because it's not ideal to basically have to append pk to
> every index in the system just to get the ability to tie-break when
> there's actually very low likelihood of ties anyway.
>
> A similar use case is trying to batch through a result
This documentation
+
+Specify the maximum size of WAL files
+that replication
+slots are allowed to retain in the
pg_wal
+directory at checkpoint time.
+If max_slot_wal_keep_size is zero (the default),
+replication slots retain unlimited size
On 06/09/2018 18:25, Tom Lane wrote:
> Here's a proposed patch along that line. I included SPI_result (SPI's
> equivalent of errno) in the set of saved-and-restored variables,
> so that all the exposed SPI globals behave the same.
>
> Also, in further service of providing insulation between SPI n
On Thu, Sep 6, 2018 at 4:22 PM Michael Paquier wrote:
>
> On Wed, Sep 05, 2018 at 09:23:37AM -0700, Andres Freund wrote:
> > Well, we kinda do, during some of their own DDL. CF
> > AcquireDeletionLock(), RangeVarGetAndCheckCreationNamespace(), and other
> > LockDatabaseObject() callers. The
> > R
On Wed, Sep 05, 2018 at 09:23:37AM -0700, Andres Freund wrote:
> Well, we kinda do, during some of their own DDL. CF
> AcquireDeletionLock(), RangeVarGetAndCheckCreationNamespace(), and other
> LockDatabaseObject() callers. The
> RangeVarGetAndCheckCreationNamespace() even locks the schema an obje
Hi,
The code currently says:
* We can't use parallelism in serializable mode because the predicate
* locking code is not parallel-aware. It's not catastrophic if someone
* tries to run a parallel plan in serializable mode; it just won't get
* any workers and w
On 05/09/2018 23:18, Thomas Munro wrote:
> On Wed, Sep 5, 2018 at 12:10 PM Christoph Berg wrote:
>>> So, it's not ideal but perhaps worth considering on the grounds that
>>> it's better than nothing?
>>
>> Ack.
>
> Ok, here's a little patch like that.
>
> postgres=# select collname, collcollate,
On Wed, Sep 05, 2018 at 12:14:41AM -0700, Jimmy Yih wrote:
> Attached the isolation spec file. I originally was only going to fix the
> simple CREATE TYPE scenario but decided to look up other objects that can
> reside in namespaces and ended up finding a handful of others. I tested
> each one ma
I disagree because it's not ideal to basically have to append pk to every
index in the system just to get the ability to tie-break when there's
actually very low likelihood of ties anyway.
A similar use case is trying to batch through a result set, in which case
you need a stable sort as well.
Th
James Coleman writes:
> A fairly common planning problem for us is what we call "most recent first"
> queries; i.e., "the 50 most recent rows for a ".
> Here's a basic setup:
> -- created_at has very high cardinality
> create table foo(pk serial primary key, owner_fk integer, created_at
> tim
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
A fairly common planning problem for us is what we call "most recent
I wrote:
> Chapman Flack writes:
>> Another alternative might be to have SPI_connect save them and
>> SPI_finish put them back, which leaves you just responsible for
>> reasoning about your own code. You'd still be expected to save them
>> across your own uses of other SPI calls, but no longer exp
Hi Stephen,
On Tue, Sep 04, 2018 at 04:14:15PM -0700, Michael Paquier wrote:
> On Tue, Sep 04, 2018 at 06:02:51PM -0400, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> I'm confused. Isn't the point of that script exactly to create a modified
>>> extension for testing pg_dump w
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> Consulting old manuals suggests it may have version 3.80 (c. 2002),
>> which lacks the 'else if..' syntax introduced in 3.81 (c. 2006).
Tom> Right; I haven't updated it because that's specifically called out to
Tom> be the minimum
>
> Just skimming the thread but I'd have to say being able to leverage
> pg_dump's dependency resolution is a major reason for adding features to it
> instead sticking to writing psql scripts. This feature in a multi-tenant
> situation is something with, I suspect, reasonably wide appeal.
>
That
On Thu, Sep 6, 2018 at 8:40 AM, Jeremy Finzel wrote:
> Why not simply use \copy (select * from largetable where created_at >=
>> '2018-05-01') to stdout? That is what I’ve always done when I need
>> something like this and have not found it particularly bothersome but
>> rather quite powerful. An
On Mon, May 21, 2018 at 6:34 AM Carter Thaxton
wrote:
> Many times I've wanted to export a subset of a database, using some sort
> of row filter condition on some of the large tables. E.g. copying a
> production database to a staging environment, but with some time series
> data only from the pa
On Thu, Sep 6, 2018 at 1:16 AM Peter Eisentraut
wrote:
> I'm going to use this thread for a moment to work out some details with
> the cfbot.
>
> The v2 patch I sent previously was created using git format-patch with
> default settings. This detected a rename:
>
> rename src/{backend/port/dynloa
Peter Eisentraut writes:
> On 06/09/2018 10:16, Peter Eisentraut wrote:
>> The v3 patch attached here was made with git format-patch --no-renames.
>> Let's see how that works out.
> That worked, and the patch has been committed.
Sure enough, gaur's not happy. I'll take a look in a bit.
Hi,
On 09/05/2018 02:42 PM, Jesper Pedersen wrote:
On 07/26/2018 10:04 PM, Thomas Munro wrote:
Done. Rebased.
This needs a rebase again.
Would it be of benefit to update these call sites
* slru.c
- SlruPhysicalReadPage
- SlruPhysicalWritePage
* xlogutils.c
- XLogRead
* pg_receivew
Andrew Gierth writes:
> Consulting old manuals suggests it may have version 3.80 (c. 2002),
> which lacks the 'else if..' syntax introduced in 3.81 (c. 2006).
Right; I haven't updated it because that's specifically called out to
be the minimum supported version in our docs (cf installation.sgml).
Andrew Gierth writes:
> "Michael" == Michael Paquier writes:
> Michael> prairiedog is unhappy with this commit:
> What version of GNU Make is on there, do you know? Tom? I don't see it
> mentioned in the output anywhere.
$ make -v
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc
As a status note, the above patch has not been run through pg_indent and
while I have run make check-world on linux (passed) and a non-Linux system
(which failed both with and without my patch) I will be making one more
small revision before final submission unless anyone thinks I need to
change ap
On Tue, Jul 3, 2018 at 1:11 AM, Carter Thaxton
wrote:
> The whole reason for the colon in the --where option is to indicate which
> table the WHERE clause should refer to, so that one can dump less than all
> of the rows.
> The --table option is totally different. It specifies which tables to
>
On Thu, Sep 6, 2018 at 2:40 PM Alexander Korotkov
wrote:
>
> On Wed, Sep 5, 2018 at 7:28 PM amul sul wrote:
> > On Wed, Sep 5, 2018, 6:35 PM Alexander Korotkov
> > wrote:
> >> On Wed, Sep 5, 2018 at 3:10 PM amul sul wrote:
> >> > On Wed, Sep 5, 2018 at 3:05 PM Alexander Korotkov
> >> > wrote:
Why can not those shared catalog tables take lock via fast path if
eligible？ User tables and local catalog tables can take lock via fast path .
On 06/09/2018 10:16, Peter Eisentraut wrote:
> The v3 patch attached here was made with git format-patch --no-renames.
> Let's see how that works out.
That worked, and the patch has been committed.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On Tue, 10 Jul 2018 17:34:20 -0400
Tom Lane wrote:
>Heikki Linnakangas writes:
>> But stepping back a bit, it's a bit weird that we're handling this
>> differently from VALUES and other subqueries. The planner knows how
>> to do this trick for simple subqueries:
>
>> postgres=# explain select
On Thu, Sep 6, 2018 at 1:31 PM Chris Travers
wrote:
>
>
> On Thu, Sep 6, 2018 at 11:08 AM Chris Travers
> wrote:
>
>> Ok, so here's my current patch (work in progress). I have not run tests
>> yet, and finding a way to add a test case is virtually impossible though I
>> expect we will find ways
On Wed, Sep 5, 2018 at 7:28 PM amul sul wrote:
> On Wed, Sep 5, 2018, 6:35 PM Alexander Korotkov
> wrote:
>> On Wed, Sep 5, 2018 at 3:10 PM amul sul wrote:
>> > On Wed, Sep 5, 2018 at 3:05 PM Alexander Korotkov
>> > wrote:
>> > > On Wed, Sep 5, 2018 at 1:22 AM David G. Johnston
>> > > wrote:
On Thu, Sep 6, 2018 at 11:08 AM Chris Travers
wrote:
> Ok, so here's my current patch (work in progress). I have not run tests
> yet, and finding a way to add a test case is virtually impossible though I
> expect we will find ways of using gdb to confirm local fix later.
>
> After careful code r
Ugrrr! PLEASE ignore this! It's not wrong at all.
2018年9月6日(木) 18:58 Kyotaro HORIGUCHI :
> - The following assertion looks contradicting to the comment.
> |/* Postmaster-managed callers must handle postmaster death somehow. */
> |Assert(!IsUnderPostmaster ||
> | (wakeEvents & (W
On Thu, Sep 6, 2018 at 4:10 PM, Kyotaro HORIGUCHI
wrote:
> Thank you for the comment.
>
> At Wed, 5 Sep 2018 14:31:10 +0900, Masahiko Sawada
> wrote in
>> On Tue, Sep 4, 2018 at 7:52 PM, Kyotaro HORIGUCHI
>> Thank you for updating! Here is the review comment for v8 patch.
>>
>> +/*
And background worker patch in attachment.
05.09.2018 15:25, Andrey Lepikhov пишет:
Hi,
I prepared next version of Background worker (cleaner) based on a retail
indextuple deletion patch.
This version shows stable behavior on regression tests and pgbench
workloads.
In this version:
1. Only
At Sun, 2 Sep 2018 07:04:19 +1200, Thomas Munro
wrote in
> > > # Is it intentional that the patch doesn't touch pgstat.c?
> >
> > Yes. pgstat.c still uses WL_POSTMASTER_DEATH because it does
> > something special: it calls pgstat_write_statsfiles() before it exits.
Mmm. Exactly..
> Rebased.
On Thu, Sep 6, 2018 at 12:53 AM R, Siva wrote:
> On Tue, Sep 5, 2018 at 08:55 PM, Alexander Korotkov
> wrote:
> > Finally I managed to reproduce the bug. The scenario is following.
> > Underlying idea is that when insertion of multiple tuples goes to the
> > beginning of the page and this inser
Ok, so here's my current patch (work in progress). I have not run tests
yet, and finding a way to add a test case is virtually impossible though I
expect we will find ways of using gdb to confirm local fix later.
After careful code review, I settled on the following approach which seemed
to be th
On 01/09/2018 06:51, Peter Eisentraut wrote:
>> How about this: We only have two nonstandard dlopen() implementations
>> left: Windows and (old) HP-UX. We move those into src/port/dlopen.c and
>> treat it like a regular libpgport member. That gets rid of all those
>> duplicative empty per-platfor
At Sat, 1 Sep 2018 19:52:16 +0300, Alexander Korotkov
wrote in
> On Thu, Aug 30, 2018 at 2:44 PM Kyotaro HORIGUCHI
> wrote:
> > At Thu, 30 Aug 2018 13:42:42 +0300, Alexander Korotkov
> > wrote in
> >
> > > It seems that http://commitfest.cputube.org/ runs only "make check" on
> > > Windows
Hello.
> Just my 2 cents: that was a hacky use case for development reasons.
I know. So I intended to preserve the parameter with default of 100% if
no one strongly objects to preserve. Then I abandoned that since I had:p
> I think that removing fillfactor is good idea and your latest patch
Thank you for the comment.
At Wed, 5 Sep 2018 14:31:10 +0900, Masahiko Sawada
wrote in
> On Tue, Sep 4, 2018 at 7:52 PM, Kyotaro HORIGUCHI
> Thank you for updating! Here is the review comment for v8 patch.
>
> +/*
> + * This slot still has all required segments. Calcula
52 matches
Mail list logo
