On Fri, Jan 04, 2019 at 02:45:55PM +0100, Daniel Gustafsson wrote:
> (Michael: sorry for not having responded to your comments on the patch, $life
> has had little time over for hacking lately)
No worries, I understand.
> There is that. We might not be excited about writing tests for this
>
On Fri, Jan 04, 2019 at 11:49:46PM +, Bossart, Nathan wrote:
> 0004 introduces a slight change to existing behavior. Currently, if
> you specify a missing table, vacuumdb will process each table until
> it reaches the nonexistent one, at which point it will fail. After
> 0004 is applied,
On Fri, Jan 04, 2019 at 10:05:25AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Jan 4, 2019 at 12:26 PM Peter Eisentraut <
>> peter.eisentr...@2ndquadrant.com> wrote:
>>> Why does the commit fest app not automatically fill in the author for a
>>> new patch?
>
>> I'm not sure it's
On Fri, Jan 04, 2019 at 06:54:51PM -0500, Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> Do we want to do the whole version string, or just "PostgreSQL 12devel"?
>
> The whole thing.
I would prefer the whole string as well, as that's useful to look
after
On 1/5/19 3:31 AM, Michael Paquier wrote:
On Mon, Dec 31, 2018 at 01:07:34PM +0200, David Steele wrote:
In short, the *initial* name of the WAL file is set to what it should be if
it doesn't complete so we don't need to run around and try to rename files
on failure. Only on success do we need
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 21/11/2018 15:46, Christoph Berg wrote:
> > 2018-11-21 15:19:47.394 CET [24453] LOG: starting PostgreSQL 12devel on
> > x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-9) 8.2.0, 64-bit
>
> Do we want to do the
Allison Kaptur writes:
> I encountered a surprising error when writing a migration that both added a
> primary key to a table and added a new NOT NULL column. It threw the error "
> column "col_d" contains null values", even though I supplied a default. The
> migration looks like this:
> CREATE
On Fri, Jan 04, 2019 at 02:36:15PM -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-04 16:43:39 -0500, Tom Lane wrote:
> > Joerg Sonnenberger writes:
> > >> * What's the generator written in? (if the answer's not "Perl", wedging
> > >> it into our build processes might be painful)
> >
> > >
On Tue, Dec 4, 2018 at 2:23 AM Nikita Glukhov wrote:
> 2) We define both DCH_FF# and DCH_ff#, but we never ever use the
> lower-case version. Heck, it's not mentioned even in DCH_keywords, which
> does this:
>
> ...
> {"FF1", 3, DCH_FF1, false, FROM_CHAR_DATE_NONE}, /* F */
> ...
>
On Fri, Jan 04, 2019 at 04:35:51PM -0300, Alvaro Herrera wrote:
> On 2018-Dec-29, Peter Eisentraut wrote:
>> @@ -3438,5 +3437,8 @@ main(int argc, char *argv[])
>>
>> destroyPQExpBuffer(start_db_cmd);
>>
>> +/* prevent cleanup */
>> +made_new_pgdata = found_existing_pgdata =
On Mon, Dec 31, 2018 at 01:07:34PM +0200, David Steele wrote:
> In short, the *initial* name of the WAL file is set to what it should be if
> it doesn't complete so we don't need to run around and try to rename files
> on failure. Only on success do we need to rename.
>
> Sound plausible?
It
On Thu, Jan 03, 2019 at 11:27:34AM -0500, Andrew Alsup wrote:
> Thanks for the help on "make distclean". That did the trick. I will be
> more careful when pulling master. Somehow, I hadn't been hit with this
> before, which was just dumb luck. Thanks for helping me out.
A more violent method is
Hi,
On 2019-01-04 16:43:39 -0500, Tom Lane wrote:
> Joerg Sonnenberger writes:
> >> * What's the generator written in? (if the answer's not "Perl", wedging
> >> it into our build processes might be painful)
>
> > Plain C, nothing really fancy in it.
>
> That's actually a bigger problem than you
Hi Tomas,
> Thanks for the updated patch - I've started working on a review, with
> the hope of getting it committed sometime in 2019-01. But the patch
> bit-rotted again a bit (probably due to d3c09b9b), which broke the last
> part. Can you post a fixed version?
>
PFA, updated patch set.
Why does the commit fest app not automatically fill in the author for a
new patch?
And relatedly, every commit fest, there are a few patches registered
without authors, probably because of the above behavior.
Could this be improved?
--
Peter Eisentraut http://www.2ndQuadrant.com/
On 12/12/2018 22:32, Adrien Nayrat wrote:
> Per idea of Nikolay Samokhvalov[1] I propose this patch to add the possibility
> to log all statements from a fraction of transactions.
>
> I have several questions:
> * Do we want this feature?
It's not clear to me what the use is. The
> About syntax: i vote for current syntax "reindex table CONCURRENTLY
> tablename". This looks consistent with existed CREATE INDEX CONCURRENTLY
> and REFRESH MATERIALIZED VIEW CONCURRENTLY.
>
+1
Pavel
> regards, Sergei
>
> [1]:
>
On Fri, Jan 04, 2019 at 09:19:25AM -0300, Alvaro Herrera wrote:
> I'll do it.
Thanks for taking care of it. Please note that commands/copy.c also
makes use of RELKIND_CAN_HAVE_STORAGE() as of bf491a9. Could you
split the renaming with a commit independent on what is being
discussed on this
3 янв. 2019 г., в 23:47, Andrey Borodin написал(а):
>
>> * Bitmapset stores 32 bit signed integers, but BlockNumber is unsigned. So
>> this will fail with an index larger than 2^31 blocks. That's perhaps
>> academical, I don't think anyone will try to create a 16 TB GiST index any
>> time
(2018/12/28 17:28), Etsuro Fujita wrote:
> I noticed that I forgot to modify the cost for evaluating the PathTarget
> for each output row accordingly to this change :(. Attached is a patch
> for that.
On reflection, I noticed these on estimate_path_cost_size, other than that:
1) In the case of
On Mon, 31 Dec 2018 at 18:58, Surafel Temesgen wrote:
> On Fri, Dec 28, 2018 at 6:46 PM Fabien COELHO wrote:
>> > At first i also try to do it like that but it seems the function will
>> > became long and more complex to me
>>
>> Probably. But calling it with size 100 should result in the same
On 26/12/2018 06:42, Michael Paquier wrote:
> On Tue, Oct 30, 2018 at 11:44:42AM +0100, Daniel Gustafsson wrote:
>> Circling back to this, I updated the patch with providing another
>> option as I couldn’t think of another way to do it cleanly. I’ll
>> add the patch to the next CF but as it’s
On 19/11/2018 14:40, Tomas Vondra wrote:
> On 11/19/18 2:57 AM, Michael Paquier wrote:
>> On Sun, Nov 18, 2018 at 12:18:33PM +0100, Dmitry Dolgov wrote:
>>> Since it's hard to come up with a concise name that will mention sampling
>>> rate
>>> in the context of min_duration_statement, I think
On 25/12/2018 00:56, Corey Huinker wrote:
> The regression diff (attached) seems to imply that the triggers simply
> are not firing, though.
The reason for this was explained by Dean. If you take out the check
that he mentioned, then your trigger fires but crashes. In your changed
On 13/11/2018 14:35, Pavel Stehule wrote:
> I am try to enhance plpgsql_check about profiler functionality and I
> have to solve how to identify every plpgsql statement across different
> sessions. There is lineno, but surely it should not be unique. I propose
> introduce stmtid to every statement
On 06/12/2018 18:27, Pavel Stehule wrote:
> For my purpose I can imagine PRAGMA on function level with same syntax
> like PL/SQL - I need to push somewhere some information that I can use
> for plpgsql_check to protect users against false alarms. The locality in
> this moment is not too important
On Fri, Jan 04, 2019 at 11:41:15AM +0100, Peter Eisentraut wrote:
> Note that pgxs supports PG_CPPFLAGS for adding custom pieces to CPPFLAGS
> in a safe way. Maybe we should add an equivalent for CFLAGS? It's just
> that it hasn't been needed so far.
+1. Wouldn't it make sense to also have
On 18/12/2018 08:18, Amit Langote wrote:
> Sorry to be saying it late, but I have to agree with Horiguchi-san here
> that RELKIND_HAS_STORAGE sounds better and is clear.
I think I agree. Does someone want to send a patch?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL
On Thu, 20 Dec 2018 at 23:59, Jose Luis Tallon
wrote:
> IMVHO: Please do not disregard potential optimization by the compiler
> around those calls.. o_0 That might explain the reduced performance
> improvement observed.
It was a speedup that I measured. Did you see something else?
> > What I'm
On 06/12/2018 21:37, Alvaro Herrera wrote:
> When scanning the list of virtual transactions looking for one
> particular vxid, we cancel the transaction *and* break out of the loop
> only if both backendId and localTransactionId matches us. The canceling
> part is okay, but limiting the break to
FWIW you can insert multiple zero-column rows with "insert into ..
select union all select union all select".
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pá 4. 1. 2019 v 14:07 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 06/12/2018 18:27, Pavel Stehule wrote:
> > For my purpose I can imagine PRAGMA on function level with same syntax
> > like PL/SQL - I need to push somewhere some information that I can use
> > for
Policy on contrib has shifted over time. But generally we want to encourage
a lively ecosystem of extensions maintained outside of the Postgres source
tree so we avoid adding things to contrib when there's no particular
advantage.
The most common reason things are added to contrib is when the
On 21/11/2018 14:28, Christoph Berg wrote:
> The context here is that we want to use the *FLAGS from pg_config for
> compiling PG extension packages, but add additional *FLAGS from the
> extension build environment. Merging the pg_config CFLAGS with the
> environment CFLAGS seemed
On 28/12/2018 08:43, Mitar wrote:
> A summary of the patch: This patch enables adding AFTER triggers (both
> ROW and STATEMENT) on materialized views. They are fired when doing
> REFRESH MATERIALIZED VIEW CONCURRENTLY for rows which have changed.
What bothers me about this patch is that it subtly
On Fri, Jan 4, 2019 at 12:26 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> Why does the commit fest app not automatically fill in the author for a
> new patch?
>
> And relatedly, every commit fest, there are a few patches registered
> without authors, probably because of the
Hello
Thank you! I review new patch version. It applied, builds and pass tests. Code
looks good, but i notice new behavior notes:
> postgres=# reindex (verbose) table CONCURRENTLY measurement ;
> WARNING: REINDEX of partitioned tables is not yet implemented, skipping
> "measurement"
> NOTICE:
On 2019-Jan-04, Peter Eisentraut wrote:
> On 18/12/2018 08:18, Amit Langote wrote:
> > Sorry to be saying it late, but I have to agree with Horiguchi-san here
> > that RELKIND_HAS_STORAGE sounds better and is clear.
>
> I think I agree. Does someone want to send a patch?
I'll do it.
--
Thanks for looking at this.
On Thu, 20 Dec 2018 at 23:56, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I've checked for Clang 6, it turns out that indeed it generates popcnt without
> any macro, but only in one place for bloom_prop_bits_set. After looking at
> this
> function it seems that it
On Fri, Jan 04, 2019 at 01:06:24PM +0100, Peter Eisentraut wrote:
> Do we really want to add user-facing options just to be able to run
> tests? Should we write the tests differently instead?
The take is that the output of the plans generated includes data which
is run-dependent because the
(Michael: sorry for not having responded to your comments on the patch, $life
has had little time over for hacking lately)
> On 4 Jan 2019, at 13:49, Michael Paquier wrote:
>
> On Fri, Jan 04, 2019 at 01:06:24PM +0100, Peter Eisentraut wrote:
>> Do we really want to add user-facing options just
On Thu, Jan 03, 2019 at 03:36:36PM +0100, Peter Eisentraut wrote:
> done
Thanks, Peter.
--
Michael
signature.asc
Description: PGP signature
Hi Arseny,
> I hadn't checked whether my concerns where addressed in the latest
> version though.
>
I'd like to believe that the latest patch set tries to address some
(if not all) of your concerns. Can you please take a look and let me
know?
Regards,
Nikhil
--
Nikhil Sontakke
2ndQuadrant -
On Thu, Jan 3, 2019 at 1:38 AM David Rowley
wrote:
> On Thu, 3 Jan 2019 at 01:50, Surafel Temesgen
> wrote:
> > On Mon, Dec 31, 2018 at 12:38 PM David Rowley <
> david.row...@2ndquadrant.com> wrote:
> >> Just looking at the v5 patch, it seems not to handle 0 column tables
> correctly.
>
> > The
On 1/4/19 1:53 AM, David Rowley wrote:
> On Fri, 4 Jan 2019 at 13:01, Tomas Vondra
> wrote:
>> On 1/3/19 11:57 PM, David Rowley wrote:
>>> You'll know you're getting a generic plan when you see "Filter (a =
>>> $1)" and see "Subplans Removed: " below the Append.
>>>
>>
>> Indeed, with
Hi Thomas,
I'm back from vacations.
Thanks for the 2 patches!
I've seen also the discussion around this subject. Very interesting. Should I
wait for a decision been taken? or should I study and experiment your patches
before?
I'm now in the process of studying with gprof what Postgres does
pá 4. 1. 2019 v 13:58 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 13/11/2018 14:35, Pavel Stehule wrote:
> > I am try to enhance plpgsql_check about profiler functionality and I
> > have to solve how to identify every plpgsql statement across different
> >
On 20/12/2018 14:02, Surafel Temesgen wrote:
> Currently we can skip header line on COPY FROM but having the ability to
> skip and stop copying at any line can use to divide long copy operation
> and enable to copy a subset of the file and skipping footer.
It seems a bit fragile to me if I want
Magnus Hagander writes:
> On Fri, Jan 4, 2019 at 12:26 PM Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>> Why does the commit fest app not automatically fill in the author for a
>> new patch?
> I'm not sure it's a good idea to *enforce* it -- because you can't register
> an
On 27/12/2018 00:53, Thomas Munro wrote:
> mmap and sysv were the same, but there
> did seem to be a measurable speed-up available at high client counts
> with kern.ipc.shm_use_phys=1 and thus for sysv only, for people
> prepared to set 3 sysctls and this proposed new GUC. Maybe the effect
>
Hi!
I'm starting to look at this patchset. Not ready to post detail
review, but have a couple of questions.
On Wed, Sep 19, 2018 at 9:24 PM Peter Geoghegan wrote:
> I still haven't managed to add pg_upgrade support, but that's my next
> step. I am more or less happy with the substance of the
Le 4 janvier 2019 13:16:48 GMT+01:00, Peter Eisentraut
a écrit :
>On 19/11/2018 14:40, Tomas Vondra wrote:
>> On 11/19/18 2:57 AM, Michael Paquier wrote:
>>> On Sun, Nov 18, 2018 at 12:18:33PM +0100, Dmitry Dolgov wrote:
Since it's hard to come up with a concise name that will mention
Kristjan Tammekivi writes:
> I've noticed a change in the behaviour in triggers / hstores in Postgres
> 11.1 when compared to Postgres 10.5.
> [ reference to OLD in an insert trigger doesn't throw error anymore ]
Hmm. This seems to be a side effect of the changes we (I) made in v11
to
pá 4. 1. 2019 v 17:44 odesílatel Tom Lane napsal:
> Kristjan Tammekivi writes:
> > I've noticed a change in the behaviour in triggers / hstores in Postgres
> > 11.1 when compared to Postgres 10.5.
> > [ reference to OLD in an insert trigger doesn't throw error anymore ]
>
> Hmm. This seems to
On 12/12/2018 08:32, Richard Guo wrote:
> This small revise is not expected to bring performance improvements, but
> can improve the readability of the code that for empty relids, the qual
> is always considered as being not-outerjoin_delayed.
I think code readability and maintainability would be
On 1/4/19 7:40 AM, Surafel Temesgen wrote:
>
>
> On Thu, Jan 3, 2019 at 4:51 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
>
> On 1/3/19 1:00 PM, Surafel Temesgen wrote:
> > Hi
> >
> > On Tue, Jan 1, 2019 at 10:08 PM Tomas Vondra
> >
On 1/4/19 8:08 AM, Surafel Temesgen wrote:
>
>
>
> On Tue, Jan 1, 2019 at 10:08 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
> The execution part of the patch seems to be working correctly, but I
> think there's an improvement - we don't need to execute the outer
Le 4 janvier 2019 13:20:09 GMT+01:00, Peter Eisentraut
a écrit :
>On 12/12/2018 22:32, Adrien Nayrat wrote:
>> Per idea of Nikolay Samokhvalov[1] I propose this patch to add the
>possibility
>> to log all statements from a fraction of transactions.
>>
>> I have several questions:
>> * Do we
Peter Eisentraut wrote:
> Here is an updated patch.
When using GROUP BY and ORDER BY on a field with a non-deterministic
collation, this pops out:
CREATE COLLATION myfr (locale='fr-u-ks-level1',
provider='icu', deterministic=false);
=# select n from (values ('été' collate "myfr"),
I wrote:
> Andres Freund writes:
>> On 2018-12-29 16:59:52 -0500, John Naylor wrote:
>>> 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 tried to take this for a spin, an for me the build
Hi Alexander,
On Fri, Jan 4, 2019 at 7:40 AM Alexander Korotkov
wrote:
> I'm starting to look at this patchset. Not ready to post detail
> review, but have a couple of questions.
Thanks for taking a look!
> Yes, it shouldn't be too hard, but it seems like we have to keep two
> branches of
David Rowley writes:
> I've just looked over the v4 patch. I agree that having an RTE for a
> from-less SELECT seems like a good idea.
Thanks for looking!
> While reading the patch, I noted the following:
> 1. It's more efficient to use bms_next_member as it does not need to
> re-skip 0 words
On 12/30/18, Andres Freund wrote:
> I tried to take this for a spin, an for me the build fails because various
> frontend programs don't have KeywordOffsets/Strings defined, but reference
> it
> through various functions exposed to the frontend (like fmtId()). That I
> see
> that error but you
On 2019-Jan-02, James Robinson wrote:
> So -- do others find this inconsistent, or is it just me and I should
> work on having psycopg2 be able to learn the type mapping itself if I
> don't want to do SQL-side casts? I'll argue that if scalar projections
> erase the domain's oid, then array
On 2018-Dec-29, Peter Eisentraut wrote:
> @@ -387,6 +388,7 @@ StreamLog(void)
> if (!conn)
> /* Error message already written in GetConnection() */
> return;
> + atexit(disconnect_atexit);
>
> if (!CheckServerVersionForStreaming(conn))
> {
On 1/3/19, Joerg Sonnenberger wrote:
> Hello John,
> I was pointed at your patch on IRC and decided to look into adding my
> own pieces. What I can provide you is a fast perfect hash function
> generator. I've attached a sample hash function based on the current
> main keyword list. hash()
John Naylor writes:
> On 1/3/19, Joerg Sonnenberger wrote:
>> I was pointed at your patch on IRC and decided to look into adding my
>> own pieces. What I can provide you is a fast perfect hash function
>> generator. I've attached a sample hash function based on the current
>> main keyword list.
Hi,
On 2019-01-03 13:40:42 -0500, Tom Lane wrote:
> I noticed that this patch has broken restores of existing dump files:
>
> psql:testbed.public.backup:82: ERROR: unrecognized configuration parameter
> "default_with_oids"
>
> Quite aside from the fact that this won't work if the user tries
On 12/27/18, Tom Lane wrote:
> If you really are hot about saving that other 440 bytes, the way to
> do it would be to drop the struct entirely and use two parallel
> arrays, an int16[] for value and a char[] (or better uint8[]) for
> category. Those would be filled by reading kwlist.h twice
Alvaro Herrera writes:
> On 2019-Jan-02, James Robinson wrote:
>> So -- do others find this inconsistent, or is it just me and I should
>> work on having psycopg2 be able to learn the type mapping itself if I
>> don't want to do SQL-side casts? I'll argue that if scalar projections
>> erase the
On 2019-01-04 12:26:18 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> On 2018-12-29 16:59:52 -0500, John Naylor wrote:
> >>> I think 0001 with complete keyword lookup replacement is in decent
> >>> enough shape to post. Make check-world passes. A few notes and
> >>> caveats:
>
Andres Freund writes:
> On 2019-01-04 12:26:18 -0500, Tom Lane wrote:
>> I'm wondering where we want to go with this. Is anyone excited
>> about pursuing the perfect-hash-function idea? (Joerg's example
>> function looked pretty neat to me.) If we are going to do that,
>> does it make sense to
On Fri, Jan 04, 2019 at 03:31:11PM -0500, Tom Lane wrote:
> John Naylor writes:
> > On 1/3/19, Joerg Sonnenberger wrote:
> >> I was pointed at your patch on IRC and decided to look into adding my
> >> own pieces. What I can provide you is a fast perfect hash function
> >> generator. I've
Joerg Sonnenberger writes:
> On Fri, Jan 04, 2019 at 03:31:11PM -0500, Tom Lane wrote:
>> The sample hash function certainly looks great. I'm not terribly on board
>> with using |0x20 as a substitute for lower-casing, but that's a minor
>> detail.
> Yeah, I've included that part more because I
Hi!
I am new to contributing to PostgreSQL and this is my first time
having patches in commit fest, so I am not sure about details of the
process here, but I assume that replying and discuss the patch during
this period is one of the actives, so I am replying to the comment. If
I should wait or
I wrote:
> If you reverse out just that change you'll see why I added it: without it,
> the plan for the earlier "test a corner case in which we shouldn't apply
> the star-schema optimization" isn't optimized as much as I thought it
> should be.
Hmm ... looking at this closer, it seems like this
Hi,
every now and then I have to investigate an execution plan that is
strange in some way and I can't reproduce the same behavior. Usually
it's simply due to data distribution changing since the problem was
observed (say, after a nightly batch load/update).
In many cases it however may be due
On Sat, 5 Jan 2019 at 03:12, Tomas Vondra wrote:
> >>
> >> partitions0 100 10001
> >>
> >> master 19 1590 2090 128
> >> patched 18 1780 6820 1130
> >>
> >> So, that's nice. I
78 matches
Mail list logo
