Hi,
> If you are not sure whether PostgreSQL
> -is already available or whether you can use it for your
> -experimentation then you can install it yourself. Doing so is not
> +is already available for your experimentation,
> +you can install it yourself. Doing so is not
>
On Fri, Nov 2, 2018 at 2:02 AM Robert Haas wrote:
>
> On Mon, Oct 1, 2018 at 6:23 AM Masahiko Sawada wrote:
> > Attached patch adds a new option FREEZE_ONLY to VACUUM command. This
> > option is same as FREEZE option except for it disables reclaiming dead
> > tuples. That is, with this option
On 04/11/2018 16:54, Tom Lane wrote:
> I looked into SQL:2011 to see what it has to say about this. In
> 10.4 , syntax rule 9) g) iii) says
>
> For each SQL parameter Pi, 1 (one) ≤ i ≤ SRNP, that is an output SQL
> parameter or both an input SQL parameter and an output SQL parameter,
>
On Fri, Nov 2, 2018 at 1:32 AM Bossart, Nathan wrote:
>
> Hi,
>
> On 10/1/18, 5:23 AM, "Masahiko Sawada" wrote:
> > Attached patch adds a new option FREEZE_ONLY to VACUUM command. This
> > option is same as FREEZE option except for it disables reclaiming dead
> > tuples. That is, with this
Hi,
On Thu, Oct 25, 2018 at 10:38 PM, Amit Langote wrote:
> And here is the latest set of patches. Sorry it took me a while.
Thanks for revising the patch!
> I didn't get time today to repeat the performance tests, but I'm planning
> to next week. In the meantime, please feel free to test
On 11/2/18, Tom Lane wrote:
> On a FSM-less table, I'd be inclined to just check the
> last page and then grow the table if the tuple doesn't fit there.
> This would, in many cases, soon result in a FSM being created, but
> I think that's just fine. The point of the change is to optimize
> for
po 5. 11. 2018 v 7:20 odesílatel Amit Langote
napsal:
> On 2018/11/04 4:58, Pavel Stehule wrote:
> > here is a patch
>
> Thank you, Pavel.
>
> Here are some comments.
>
> I mentioned it during the last review, but maybe you missed it due to the
> other discussion.
>
> +the pattern are
Hello Thomas,
On Thu, Nov 1, 2018 at 8:53 AM Thomas Munro
wrote:
>
> It passes make check on Unix and Windows, though currently it's
> failing some of the TAP tests for reasons I'm looking into (possibly
> due to bugs in the lower level patches, not sure).
>
I looked into the regression failures
On Sun, Nov 4, 2018 at 12:03 AM Thomas Munro
wrote:
> On Sat, Nov 3, 2018 at 2:07 AM Jesper Pedersen
> wrote:
> > This still applies, and passes make check-world.
> >
> > I wonder what the commit policy is on this, if the Windows part isn't
> > included. I read Heikki's comment [1] as it would
On Mon, Nov 5, 2018 at 5:13 PM Kuntal Ghosh wrote:
>
> Hello Thomas,
>
> On Thu, Nov 1, 2018 at 8:53 AM Thomas Munro
> wrote:
> >
> > It passes make check on Unix and Windows, though currently it's
> > failing some of the TAP tests for reasons I'm looking into (possibly
> > due to bugs in the
Le dim. 4 nov. 2018 à 18:01, Jean-Christophe Arnu a
écrit :
> Le ven. 2 nov. 2018 à 08:37, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> a écrit :
>
>> On 26/10/2018 15:53, Jean-Christophe Arnu wrote:
>> > Exemple on CREATE DATABASE (without defining a template database) :
>> > rmgr:
On 11/5/18 4:00 AM, Amit Kapila wrote:
> On Sat, Nov 3, 2018 at 9:30 AM Amit Kapila wrote:
>> On Fri, Nov 2, 2018 at 6:41 PM Tomas Vondra
>> wrote:
>>> I'm sure
>>> it's not the only place where we do something like this, and the other
>>> places don't trigger the valgrind warning, so how do
Hi Thomas,
On 11/5/18 7:08 AM, Thomas Munro wrote:
On Sun, Nov 4, 2018 at 12:03 AM Thomas Munro
wrote:
On Sat, Nov 3, 2018 at 2:07 AM Jesper Pedersen
wrote:
This still applies, and passes make check-world.
I wonder what the commit policy is on this, if the Windows part isn't
included. I
> On Mon, 21 May 2018 at 15:46, Robert Haas wrote:
>
> On Sat, May 19, 2018 at 12:59 PM, Greg Stark wrote:
> > On 19 May 2018 at 01:13, Stephen Frost wrote:
> >> I'm not entirely sure about the varlena suggestion, seems like that
> >> would change a great deal more code and be slower, though
Please remove Tell from line 18 in fd.h. To Küssnacht with him!
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello Ryohei,
I'd like to suggest introducing two parameters to handle client-server
communication timeouts.
I'm generally fine with giving more access to low-level parameters to
users. However, I'm not sure I understand the use case you have that needs
these new extensions.
On Mon, Nov 5, 2018 at 3:12 AM Masahiko Sawada wrote:
> Adding a field-and-value style option might be worth. Or maybe we can
> add one option for example freeze_without_index_cleanup?
That seems non-orthogonal. We have an existing flag to force freezing
(FREEZE); we don't need a second option
On 11/5/18, 2:07 AM, "Masahiko Sawada" wrote:
> On Fri, Nov 2, 2018 at 1:32 AM Bossart, Nathan wrote:
>> 1. Create a separate FREEZE command instead of adding a new VACUUM
>>option
>>
>> The first line of the VACUUM documentation reads, "VACUUM reclaims
>> storage occupied by dead tuples,"
On 2018-Nov-05, Corey Huinker wrote:
> This is an important and much needed feature!
I agree :-)
> Based on my extremely naive reading of this code, I have two perhaps
> equally naive questions:
>
> 1. it seems that we will continue to to per-row RI checks for inserts and
> updates. However,
po 5. 11. 2018 v 10:22 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 04/11/2018 16:54, Tom Lane wrote:
> > I looked into SQL:2011 to see what it has to say about this. In
> > 10.4 , syntax rule 9) g) iii) says
> >
> > For each SQL parameter Pi, 1 (one) ≤ i ≤
Hi folks,
I failed to post a patch on the thread “Delta Materialized View Refreshes?”
(Message-ID 1541368916681-0.p...@n3.nabble.com), so I figured I’d try again and
post directly this time. Hopefully this time, it’ll make it through. Thanks for
your patience.
(Original message follows…)
Hi
Alvaro Herrera writes:
> On 2018-Nov-04, Thomas Munro wrote:
>> Here's a patch to add Windows support by supplying
>> src/backend/port/win32/pread.c. Thoughts?
> Hmm, so how easy is to detect that somebody runs read/write on fds where
> pread/pwrite have occurred? I guess for data files it's
On 2018-Nov-04, Thomas Munro wrote:
> Here's a patch to add Windows support by supplying
> src/backend/port/win32/pread.c. Thoughts?
Hmm, so how easy is to detect that somebody runs read/write on fds where
pread/pwrite have occurred? I guess for data files it's easy to detect
since you'd
On Monday, November 5, 2018, David Fetter wrote:
> On Mon, Nov 05, 2018 at 03:01:58PM -0500, Robert Haas wrote:
> > On Mon, Oct 1, 2018 at 4:21 PM Peter Eisentraut
> > wrote:
> > >
> > > Attached is a patch that implements this. For example:
> > >
> > > ssl_min_protocol_version = 'TLSv1'
>
>
>
> > 1. it seems that we will continue to to per-row RI checks for inserts and
> > updates. However, there already exists a bulk check in
> RI_Initial_Check().
> > Could we modify this bulk check to do RI checks on a per-statement basis
> > rather than a per-row basis?
>
> One of the goals when
Kai Kratz writes:
> first time writing to the hackers list, so I hope this is the right place to
> ask. I recently joined Swarm64 and we are building a postgres extension with
> the fdw interface.
> I am trying to evaluate sql statements with ExecutorBeing, -Run, -End,
> -Finish calls during
On 2018-11-05 15:08:33 +0100, Peter Eisentraut wrote:
> On 03/11/2018 22:55, Andres Freund wrote:
> > We have a few alterntive expected output files that are essentially full
> > of errors, because a certain feature isn't supported. Those are somewhat
> > painful to maintain. I wonder if it'd be
Hi,
The test I'm most commonly waiting for when doing a parallel make check
is pg_upgrade. And to a significant degree that's because it uses the
serial installcheck rather than installcheck-parallel.
Is there a reason to not use installcheck-parallel?
serial:
19.42user 7.77system
On 2018-11-05 16:10:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > ISTM we also should disable fsyncs for the postmaster instances. Wins
> > another ~5s on my laptop, and I suspect it makes a larger difference on
> > some of the buildfarm animals.
>
> Buildfarm did that long ago.
I don't
> On Thu, 17 May 2018 at 06:10, Higuchi, Daisuke
> wrote:
>
> Currently our customer uses PostgreSQL 9.6 and hits ECPG's bug during using
> numeric data type by SQLDA.
> I confirmed that this problem is occurred on master and 9.6 latest branch.
>
> FIX
> ---
On 2018-11-05 17:08:12 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-11-05 16:32:20 -0500, Tom Lane wrote:
> >> It's injected via the TEMP_CONFIG env variable.
>
> > Ah, thanks. Is there any good reason to not instead have it in the
> > script?
>
> Why that script in particular?
On Sat, Nov 3, 2018 at 2:20 PM Tom Lane wrote:
> > Is it realistic we could rename red-black tree methods from 'rb_*' to e.g.
> > 'rbt_*' to avoid this clash?
>
> That's not terribly appetizing, because it essentially means we're giving
> Ruby (and potentially every other library on the planet)
On Mon, Nov 05, 2018 at 03:01:58PM -0500, Robert Haas wrote:
> On Mon, Oct 1, 2018 at 4:21 PM Peter Eisentraut
> wrote:
> > There have been some requests to be able to select the TLS versions
> > PostgreSQL is using. We currently only hardcode that SSLv2 and SSLv3
> > are disabled, but there is
On 2018-Nov-02, Amit Langote wrote:
> Well, performDeletion *does* drop the child, because when the parent is
> dropped due to its ON COMMIT DROP action, it's done using:
>
> /*
> * Since this is an automatic drop, rather than one
> * directly
Andres Freund writes:
> ISTM we also should disable fsyncs for the postmaster instances. Wins
> another ~5s on my laptop, and I suspect it makes a larger difference on
> some of the buildfarm animals.
Buildfarm did that long ago.
regards, tom lane
On Mon, Oct 1, 2018 at 4:21 PM Peter Eisentraut
wrote:
> There have been some requests to be able to select the TLS versions
> PostgreSQL is using. We currently only hardcode that SSLv2 and SSLv3
> are disabled, but there is also some interest now in disabling TLSv1.0
> and TLSv1.1. Also, I've
On 11/2/18 8:14 PM, Tom Lane wrote:
> I've made a pass over the commit log up to now, and prepared draft
> release note entries for everything that seemed worth documenting;
> see
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=65a82a7649860f8010db581a0d1f12aa92f5969b
>
>
On Mon, Nov 5, 2018 at 2:28 AM Michael Paquier wrote:
> Hm. Don't we need to worry about anybody potentially using these APIs
> in a custom module on platforms where it was actually working? I
> imagine that their reaction is not going be nice if any code breaks
> suddenly after a minor
Andres Freund writes:
> On 2018-11-05 16:10:28 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> ISTM we also should disable fsyncs for the postmaster instances. Wins
>>> another ~5s on my laptop, and I suspect it makes a larger difference on
>>> some of the buildfarm animals.
>> Buildfarm
On 2018-Aug-07, Amit Langote wrote:
> > But in
> > case of partitioning there is only one parent and hence
> > coldef->constraints is NULL and hence just overwriting it works. I
> > think we need comments mentioning this special case.
>
> That's what I wrote in this comment:
>
>
On 2018-11-05 16:32:20 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-11-05 16:10:28 -0500, Tom Lane wrote:
> >> Andres Freund writes:
> >>> ISTM we also should disable fsyncs for the postmaster instances. Wins
> >>> another ~5s on my laptop, and I suspect it makes a larger
Andres Freund writes:
> On 2018-11-05 16:32:20 -0500, Tom Lane wrote:
>> It's injected via the TEMP_CONFIG env variable.
> Ah, thanks. Is there any good reason to not instead have it in the
> script?
Why that script in particular? If you don't want fsync, you likely
don't want it across the
On Tue, Nov 6, 2018 at 5:07 AM Alvaro Herrera wrote:
> Please remove Tell from line 18 in fd.h. To Küssnacht with him!
Thanks, done. But what is this arrow sticking through my Mac laptop's
screen...?
On Tue, Nov 6, 2018 at 6:23 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2018-Nov-04,
On 10/19/2018 10:15 PM, Andres Freund wrote:
Hi,
buildfarm member lorikeet had an interesting buildfarm failure in the
logical decoding test. The failure looks unrelated to logical decoding,
but might be more widely relevant:
On 4 November 2018 at 17:20, Edmund Horner wrote:
> I have managed to split my changes into 4 patches:
>
> v3-0001-Add-selectivity-and-nullness-estimates-for-the-ItemP.patch
> v3-0002-Support-range-quals-in-Tid-Scan.patch
> v3-0003-Support-backward-scans-over-restricted-ranges-in-hea.patch
>
Hi,
On 2018/11/06 12:49, Jonathan S. Katz wrote:
> On 11/5/18 9:58 PM, Amit Langote wrote:
>> On 2018/11/06 11:25, Noah Misch wrote:
>>> On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wrote:
Attached is a draft of the press release for review. Please let me know
if there are
On Tue, Nov 6, 2018 at 10:18 AM Robert Haas wrote:
> On Mon, Nov 5, 2018 at 2:28 AM Michael Paquier wrote:
> > Hm. Don't we need to worry about anybody potentially using these APIs
> > in a custom module on platforms where it was actually working? I
> > imagine that their reaction is not going
On Tue, Nov 06, 2018 at 05:29:36PM +1300, Thomas Munro wrote:
> Thanks. Pushed to master only.
Just a wild idea while this thread is hot: could we add in the
description of the broken APIs or in their headers more information
about how to not use them so as users are warned if trying to use them
On 05.11.18 09:22, LAM JUN RONG wrote:
New diff is attached.
This still has the "hard" in it. Everything else looks fine.
Once you changed that, please register the new patch in the Commitfest
application.
Regards,
--
Andreas 'ads' Scherbaum
German
At Fri, 02 Nov 2018 22:05:36 +0900, Etsuro Fujita
wrote in <5bdc4ba0.7050...@lab.ntt.co.jp>
> (2018/10/29 15:58), Kyotaro HORIGUCHI wrote:
> > At Tue, 23 Oct 2018 13:21:31 +0100, Tom Lane wrote
> > in<18397.1540297...@sss.pgh.pa.us>
> >> After a bit of thought, the problem here is blindingly
On 2018-Nov-06, David Rowley wrote:
> 14. we pass 'false' to what?
>
> + * save the tuple and the buffer returned to us by the access methods in
> + * our scan tuple slot and return the slot. Note: we pass 'false' because
> + * tuples returned by heap_getnext() are pointers onto disk pages and
On Sat, Nov 3, 2018 at 1:28 AM, Phil Florent wrote:
>2) it consumes system resources
While the system is running, you are always sampling system information, do not
you? Like Oracle ASH.
If so, does sampling have no significant impact on performance? Even if the
interval is 0.01 s or more.
On Thu, Jul 26, 2018 at 3:52 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Michael Paquier [mailto:mich...@paquier.xyz]
> > No, I really mean a library dependency failure. For example, imagine
> that
> > Postgres is compiled on Windows dynamically, and that it depends
I've realized that my patch to make nbtree keys unique by treating
heap TID as a tie-breaker attribute must use ASC ordering, for reasons
that I won't go into here. Now that I'm not using DESC ordering, there
are changes to a small number of DROP...CASCADE messages that leave
users with something
On 2018/11/06 11:25, Noah Misch wrote:
> On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wrote:
>> Attached is a draft of the press release for review. Please let me know
>> if there are any corrections/suggestions.
>> * Disallows the creation of a new partition from a trigger that is
On 11/5/18 9:58 PM, Amit Langote wrote:
> On 2018/11/06 11:25, Noah Misch wrote:
>> On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wrote:
>>> Attached is a draft of the press release for review. Please let me know
>>> if there are any corrections/suggestions.
>>> * Disallows the
On Mon, Nov 05, 2018 at 02:11:42PM -0800, Andres Freund wrote:
> Because just about everything else taking substantial time already
> disables it. pg_regress forks off a postmaster with -F, the tap tests do
> so for large portions via fsync=off in the config (c.f. PostgresNode.pm).
And in most
On 2018/11/06 4:37, Alvaro Herrera wrote:
> On 2018-Nov-02, Amit Langote wrote:
>
>> Well, performDeletion *does* drop the child, because when the parent is
>> dropped due to its ON COMMIT DROP action, it's done using:
>>
>> /*
>> * Since this is an automatic
On Mon, Nov 5, 2018 at 9:12 PM Greg Stark wrote:
> It sounds like it might be better to name this "VACUUM (FAST)” and document
> that it skips some of the normal (and necessary) work that vacuum does and is
> only suitable for avoiding wraparounds and not sufficient for avoiding bloat
We could
On Mon, Nov 05, 2018 at 02:37:05PM +0900, Amit Langote wrote:
> Michael pointed out a problem with specifying different ON COMMIT actions
> on a temporary inheritance parent and its children:
>
> https://www.postgresql.org/message-id/20181102051804.GV1727%40paquier.xyz
Thanks for starting a new
On Sat, Nov 03, 2018 at 08:02:36AM +0900, Michael Paquier wrote:
> So anybody has an objection with marking the function as parallel-safe?
> I'd like to do so if that's not the case and close the case.
And committed.
--
Michael
signature.asc
Description: PGP signature
On Mon, Nov 05, 2018 at 04:37:25PM -0300, Alvaro Herrera wrote:
> I think this code should collect all the OIDs to be dropped, then use a
> single performMultipleDeletions() at the end, after the heap_truncate
> call is done. That seems better to me than a relkind check.
Yes, using a relkind
In my opinion, your patch detected three problems:
1. Unsteady order of query results/system messages ('DROP...CASCADE'
detects it).
2. Hide info about a child object dropping ('drop cascades to 62
other objects' detects it).
3. Possible non-informative messages about dependencies ('drop
On Wed, Oct 4, 2017 at 12:07 AM Sokolov Yura wrote:
>
> On 2017-10-03 17:30, Sokolov Yura wrote:
> > Good day, hackers.
> >
> > During hard workload sometimes process reaches deadlock timeout
> > even if no real deadlock occurred. It is easily reproducible with
> > pg_xact_advisory_lock on same
On Mon 5 Nov 2018, 12:49 Robert Haas That seems non-orthogonal. We have an existing flag to force freezing
> (FREEZE); we don't need a second option that does the same thing.
> Skipping the index scans (and thus necessarily the second heap pass)
> is a separate behavior which we don't currently
On Mon, Nov 05, 2018 at 04:01:59PM -0500, Jonathan S. Katz wrote:
> Attached is a draft of the press release for review. Please let me know
> if there are any corrections/suggestions.
> This update is also the final release for PostgreSQL 9.3, which is now
> end-of-life and will no longer
Hi,
I must have forgotten to change the diff.
A revised diff is attached.
Jun Rong
From: Andreas 'ads' Scherbaum
Sent: Tuesday, November 6, 2018 8:41:15 AM
To: LAM JUN RONG; pgsql-hack...@postgresql.org
Subject: Re: [PATCH] Improvements to "Getting started"
On Mon, Nov 05, 2018 at 03:01:58PM -0500, Robert Haas wrote:
> +1. Maybe it would make sense to spell 'any' as the empty string.
> Intuitively, it makes more sense to me to think about there being no
> maximum than to think about the maximum being anything.
I have looked at the code a bit
On Sat, Nov 03, 2018 at 09:45:14AM +0100, Fabien COELHO wrote:
> Patch applies cleanly, compiles, make check ok, doc gen ok.
>
> Fine with me. I switched the patch to "Ready".
I have begun looking at this patch, and there are some noise diffs
because of the reordering of the items you are doing
On Tue, Nov 6, 2018 at 6:15 PM Michael Paquier wrote:
> On Tue, Nov 06, 2018 at 05:29:36PM +1300, Thomas Munro wrote:
> > Thanks. Pushed to master only.
>
> Just a wild idea while this thread is hot: could we add in the
> description of the broken APIs or in their headers more information
>
On Tue, Nov 06, 2018 at 06:45:02PM +1300, Thomas Munro wrote:
> Like this?
Ah, my mistake. I thought that the limitations with dsm_resize were not
documented but those actually return an error if trying to use
DSM_OP_RESIZE and I did not notice that, so we may be fine without a
comment or such
71 matches
Mail list logo
