On Sun, Dec 30, 2018 at 01:45:42AM -0500, Tom Lane wrote:
> Hah, I was just about to work on that myself --- glad I didn't get
> to it quite yet. A couple of thoughts:
>
> 1. Surely there's documentation about --disable-strong-random
> to clean up too?
Oops, I forgot to grep on this one.
Michael Paquier writes:
> Attached is a patch to clean up the code, which removes all the code
> specific to random generation for backends (no more shmem code paths
> and such), as well as the pg_frontend_random() and
> pg_backend_random(). Thoughts or opinions?
Hah, I was just about to work
Hi all
As mentioned here, there has been a discussion about $subject and the
fact that it may be rather useless:
https://www.postgresql.org/message-id/21150.1546010...@sss.pgh.pa.us
--disable-strong-random is also untested in the buildfarm.
Attached is a patch to clean up the code, which
On Sat, Dec 29, 2018 at 10:36:02AM -0500, Tom Lane wrote:
> Project practice is to use plain-vanilla autoconf 2.69. Vendor
> packages tend to contain various "improvements" that will cause you
> to get different results than other committers do. Fortunately
> autoconf is pretty trivial to
On Sat, Dec 29, 2018 at 10:46:31PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > Looking more closely, we already have the TEMP_CONFIG variable and apply it
> > to
> > everything except TAP suites. Closing that gap, as attached, is enough.
> > The
> > buildfarm client uses TEMP_CONFIG to
On Sun, Dec 30, 2018 at 02:40:57PM +0900, Michael Paquier wrote:
> Attached is the set of tests I used which has some regression tests.
> The results won't fail with HEAD at 4203842a, and will generate some
> diffs after e0ef136d as Pavel's patch has changed the generated
> output.
And of course
On Sat, Dec 29, 2018 at 04:29:28PM +0100, Peter Eisentraut wrote:
> On 22/12/2018 00:42, Michael Paquier wrote:
>> What about the following then? This is your second proposal except
>> that the sentence refers to the backup current running using "this",
>> which shows better the context in my
On Sat, Dec 29, 2018 at 04:31:11PM +0100, Peter Eisentraut wrote:
> On 21/12/2018 05:05, Michael Paquier wrote:
>> -(errmsg("pg_stop_backup cleanup done, waiting for required WAL segments
>> to be archived")));
>> +(errmsg("waiting for required WAL segments to be archived")));
>
> I
On Fri, Dec 28, 2018 at 04:50:11PM +0900, Michael Paquier wrote:
> Okay, that makes sense, now I got your point. Perhaps somebody else
> has an opinion to offer or has an objection with the proposed change?
And committed this one, after playing more with the instrumentation
callbacks and
On 12/31/15 16:49, Chapman Flack wrote:
> Ok, how numerous would be the problems with this:
>
> - The classid and refclassid columns (in both pg_shdepend and pg_depend)
> are currently Oid columns referencing pg_class.oid. The catalog
> definition would not preclude putting the oid of a
Noah Misch writes:
> Looking more closely, we already have the TEMP_CONFIG variable and apply it to
> everything except TAP suites. Closing that gap, as attached, is enough. The
> buildfarm client uses TEMP_CONFIG to implement its extra_config setting, so
> this will cause extra_config to start
2018年12月30日(日) 4:12 Tom Lane :
>
> Kohei KaiGai writes:
> > 2018年12月29日(土) 1:44 Tom Lane :
> >> However, first I'd like to know why this situation is arising in the first
> >> place. To have the situation you're describing, we'd have to have
> >> attempted to make some Gather paths before we
On Sun, 30 Dec 2018 at 13:00, James Coleman wrote:
> Note that the index scan (or bitmap scan) nodes return all 1500 rows
> matching `bar_fk IN (1,2,3)`. After all rows are returned, that total
> set is ordered, and finally the LIMIT is applied. While only 50 rows
> were requested, 30x that were
On 11/12/18 04:58, Pavel Stehule wrote:
> It is assigned to January commitfest.
When I build this patch against master (4203842), it builds, but breaks
make check. The diffs seem only incidental (loss of some error context
output), but there are no make check errors building 4203842 unmodified,
On Fri, Dec 28, 2018 at 06:19:50PM -0800, Noah Misch wrote:
> "env EXTRA_REGRESS_OPTS=--temp-config=SOMEFILE make check" appends the
> contents of SOMEFILE to the test cluster's postgresql.conf. I want a similar
> feature for TAP suites and other non-pg_regress suites. (My immediate use
> case
On Wed, 26 Dec 2018 at 09:50, Tomas Vondra wrote:
> Yeah, good questions. I think the simplest thing we could do is building
> them on the first access - that would at least ensure we don't build the
> index without accessing it at least once.
I think we first need to focus on what is
tl;dr: I'd like to teach btrees to support returning ordered results
where the ordering is only a suffix of the index keys and the query
includes a scalar array op qual on the prefix key of the index.
Suppose we have the following schema:
CREATE TABLE foos(bar_fk integer, created_at timestamp);
I wrote:
> Further to this ... I was just doing some measurements to see how much
> it'd add to backend startup time if we start using pg_strong_random()
> to set the initial random seed. The answer, at least on my slightly
> long-in-the-tooth RHEL6 box, is "about 25 usec using /dev/urandom,
> or
Vik Fearing writes:
> I was working on a little thing where I needed to simulate BETWEEN
> SYMMETRIC so naturally I used least() and greatest(). I was a little
> surprised to see that my expressions were not folded into straight
> constants and the estimates were way off as a consequence.
> I
Starting from
https://www.postgresql.org/message-id/CAEepm%3D2vORBhWQZ1DJmKXmCVi%2B15Tgrv%2B9brHLanWU7XE_FWxQ%40mail.gmail.com
Here is a patch trying to implement what was proposed by Tom Lane:
"What we could/should do instead, I think, is have pgss_planner_hook
make its own pgss_store() call to
Vik Fearing writes:
> On 06/12/2018 15:41, Tom Lane wrote:
>> So what I'm thinking we should do is document that the behavior of a
>> domain CHECK constraint is expected to be immutable, and it's on the
>> user's head to preserve consistency if it isn't. We could recommend
>> that any attempt to
On 06/12/2018 15:41, Tom Lane wrote:
> So what I'm thinking we should do is document that the behavior of a
> domain CHECK constraint is expected to be immutable, and it's on the
> user's head to preserve consistency if it isn't. We could recommend
> that any attempt to change a constraint's
I think 0001 with complete keyword lookup replacement is in decent
enough shape to post. Make check-world passes. A few notes and
caveats:
-I added an --extern option to the script for the core keyword
headers. This also capitalizes variables.
-ECPG keyword lookup is a bit different in that the
I was working on a little thing where I needed to simulate BETWEEN
SYMMETRIC so naturally I used least() and greatest(). I was a little
surprised to see that my expressions were not folded into straight
constants and the estimates were way off as a consequence.
I came up with the attached patch
I wrote:
> Thomas Munro writes:
>> I was going to suggest that we might be able to use a single
>> not-visible-to-users number that is mixed into the existing recipe, so
>> that we only ever read urandom once for the cluster.
> Yeah, I was thinking along similar lines, but there's a problem:
>
Further to this ... I was just doing some measurements to see how much
it'd add to backend startup time if we start using pg_strong_random()
to set the initial random seed. The answer, at least on my slightly
long-in-the-tooth RHEL6 box, is "about 25 usec using /dev/urandom,
or about 80 usec
Michael Paquier writes:
> I was just modifying configure.in for another patch, then tried to
> generate the new configure with autoconf on Debian. However I am
> bumping into some noise in the process.
Project practice is to use plain-vanilla autoconf 2.69. Vendor
packages tend to contain
On 21/12/2018 05:05, Michael Paquier wrote:
> - (errmsg("pg_stop_backup cleanup
> done, waiting for required WAL segments to be archived")));
> + (errmsg("waiting for required
> WAL segments to be
On 22/12/2018 00:42, Michael Paquier wrote:
> What about the following then? This is your second proposal except
> that the sentence refers to the backup current running using "this",
> which shows better the context in my opinion:
> "This backup can be canceled safely, but it will not be usable
initdb and pg_basebackup can use atexit() to register cleanup actions
instead of requiring the use of custom exit_nicely() etc. Patches attached.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From
On 21/12/2018 11:12, Jesper Pedersen wrote:
> Here is a patch that passes the -j option from pg_upgrade down to
> vacuumdb if supported.
It's not clear to me that that is what is usually wanted.
The point of the post-upgrade analyze script is specifically to do the
analyze in a gentle fashion.
Hi all,
I was just modifying configure.in for another patch, then tried to
generate the new configure with autoconf on Debian. However I am
bumping into some noise in the process. First the state associated to
runstatedir support gets generated, which makes little sense for
Postgres as that's a
On Sat, Dec 8, 2018 at 6:35 PM Amit Kapila wrote:
>
> On Fri, Dec 7, 2018 at 7:25 PM John Naylor wrote:
> >
> > On 12/6/18, Amit Kapila wrote:
> > > On Thu, Dec 6, 2018 at 10:53 PM John Naylor
wrote:
> > >>
> > >> I've added an additional regression test for finding the right block
I did run
Hi,
Am Freitag, den 28.12.2018, 10:12 +0100 schrieb Magnus Hagander:
> On Fri, Dec 28, 2018 at 1:14 AM Tomas Vondra
> wrote:
> > On 12/28/18 12:25 AM, Michael Paquier wrote:
> > > On Thu, Dec 27, 2018 at 03:46:48PM +0100, Tomas Vondra wrote:
> > >> On 12/27/18 11:43 AM, Magnus Hagander wrote:
>
34 matches
Mail list logo
