On Sat, Jan 19, 2019 at 8:50 AM Tom Lane wrote:
>
> Failed miserably. It turns out cmake has a hard dependency on libuv
> which (a) has a hard dependency on atomic ops and (b) according to its
> own docs, doesn't really care about any platforms other than
> Linux/macOS/Windows and maybe FreeBSD.>
ne 20. 1. 2019 v 6:06 odesílatel Chapman Flack
napsal:
> On 01/19/19 23:49, Pavel Stehule wrote:
>
> > If I remember, described functionality was implemented in early patches,
> > but was removed to simplify code. To now, there was not a request to do
> it.
> >
> > Unfortunately, the documentatio
On 01/19/19 23:49, Pavel Stehule wrote:
> If I remember, described functionality was implemented in early patches,
> but was removed to simplify code. To now, there was not a request to do it.
>
> Unfortunately, the documentation was not fixed.
I'll do that, as I'm working in there anyway. :)
>
ne 20. 1. 2019 v 5:37 odesílatel Chapman Flack
napsal:
> Working slowly through the documentation, I came upon:
>
> For XMLTABLE:
>
> - The xmltable function produces a table based on the given XML value,
> an XPath filter to extract rows, and an optional set of column
> definitions.
On Sat, Jan 19, 2019 at 10:59 AM Tomas Vondra
wrote:
>
> On 1/19/19 12:05 AM, John Naylor wrote:
> > I used a similar test, but with unlogged tables, and "-c 2", and got:
> >
> > normal table: 32000tps
> > 10k partitions / master: 82tps
> > 10k partitions / patch: 7000tps
> >
> > So far I haven't
Working slowly through the documentation, I came upon:
For XMLTABLE:
- The xmltable function produces a table based on the given XML value,
an XPath filter to extract rows, and an optional set of column
definitions.
...
The mandatory COLUMNS
> "Tom" == Tom Lane writes:
Tom> +1 for not ignoring rowMarks, but this patch seems like a hack to
Tom> me. Why didn't you just add RowMarkClause as one of the known
Tom> alternative expression node types?
>> Because it's not an expression and nothing anywhere else in the
>> backend tre
On Sat, Dec 1, 2018 at 2:30 AM Chengchao Yu wrote:
>
>
> Recently, we hit a few occurrences of deadlock when IO failure (including
> disk full, random remote disk IO failures) happens in single user mode. We
> found the issue exists on both Linux and Windows in multiple postgres
> versions.
>
>
On Sat, Jan 19, 2019 at 5:12 PM Tom Lane wrote:
>
> Paul Martinez writes:
> > I have a proposal for a feature to add to Postgres. I believe it is a
> > natural
> > extension to the current standard SQL ON DELETE SET NULL behavior when using
> > composite foreign keys. The basic idea is that you
Paul Ramsey writes:
> On Jan 19, 2019, at 5:53 PM, Tom Lane wrote:
>> [ maybe what we need is special index operators for extensions ]
> While I’m not 100% sure what this new thing would “look like” there are at
> least a few quirky variations on the pattern you’ve correctly identified. So,
>
> On Jan 19, 2019, at 5:53 PM, Tom Lane wrote:
>
> I wrote:
>> Paul Ramsey writes:
>>> Is there a rule of thumb we can use in costing our wrappers to ensure that
>>> they always inline?
>
>> Not really, which is a weak spot of this whole approach.
>
> BTW, it suddenly strikes me that at l
> "Donald" == Donald Dong writes:
Donald> I wonder if it's necessary to update the doc accordingly?
Yes, I specifically mentioned that doc updates were needed, and that
they were not included because they depend on final decisions on the
various questions that I have asked.
--
Andrew (irc
Andrew Gierth writes:
> Would it help if we had non-locale-aware functions for both
> floating-point output _and_ input? i.e. import a known-working strtod()
> (allowing us to remove all the hacks that have grown up around it, for
> special-case input and wonky error handling) with locale function
I wrote:
> Paul Ramsey writes:
>> Is there a rule of thumb we can use in costing our wrappers to ensure that
>> they always inline?
> Not really, which is a weak spot of this whole approach.
BTW, it suddenly strikes me that at least for the specific cases you've
shown in this thread, worrying
> "Michael" == Michael Meskes writes:
>> Therefore, it's plain crazy for ecpg to be calling setlocale()
>> inside threaded code. It looks to me like what ecpg is doing is
>> trying to defend itself against non-C LC_NUMERIC settings, which is
>> laudable, but this implementation of that is
> On Jan 19, 2019, at 5:12 PM, Andrew Gierth
> wrote:
>
>> "Donald" == Donald Dong writes:
>
> Donald> I think the previous additional digits behavior still exist
> Donald> in the latest patch. For example:
>
> Donald> =# set extra_float_digits = 0;
> Donald> SET
> Donald> =# select flo
> "Donald" == Donald Dong writes:
Donald> I think the previous additional digits behavior still exist
Donald> in the latest patch. For example:
Donald> =# set extra_float_digits = 0;
Donald> SET
Donald> =# select float4in('1.123456789');
Donald> float4in
Donald> --
Donald>
Paul Martinez writes:
> I have a proposal for a feature to add to Postgres. I believe it is a natural
> extension to the current standard SQL ON DELETE SET NULL behavior when using
> composite foreign keys. The basic idea is that you can specify which columns
> to
> set to NULL in the DELETE trig
On 19/01/2019 18:02, Tom Lane wrote:
> Vik Fearing writes:
>> Does the extension need a version bump for this?
>
> We don't bump its version when we make any other change that affects
> its hash calculation. I don't think this could be back-patched,
> but Andrew wasn't proposing to do so (IIUC).
> "Tom" == Tom Lane writes:
Tom> The other thing we need to consider is whether we need any
Tom> documentation adjustments. I believe that right now, the rules for
Tom> inlining SQL functions are not documented anywhere but the code,
That is correct, though we got so tired of explaining i
Hello!
I have a proposal for a feature to add to Postgres. I believe it is a natural
extension to the current standard SQL ON DELETE SET NULL behavior when using
composite foreign keys. The basic idea is that you can specify which columns to
set to NULL in the DELETE trigger created by a foreign k
Michael Meskes writes:
>> While (b) has more theoretical purity, I'm inclined to think it
>> doesn't really improve anybody's life compared to (a), because
>> --disable-thread-safety doesn't actually stop anyone from using
>> libpq or ecpglib in threaded environments. It just makes it
>> more lik
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> +1 for not ignoring rowMarks, but this patch seems like a hack to
> Tom> me. Why didn't you just add RowMarkClause as one of the known
> Tom> alternative expression node types?
> Because it's not an expression and nothing anywhere else
> While (b) has more theoretical purity, I'm inclined to think it
> doesn't really improve anybody's life compared to (a), because
> --disable-thread-safety doesn't actually stop anyone from using
> libpq or ecpglib in threaded environments. It just makes it
> more likely to fail when they do.
Th
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> I propose that it should not ignore rowMarks, per the attached patch or
>> something similar.
Tom> +1 for not ignoring rowMarks, but this patch seems like a hack to
Tom> me. Why didn't you just add RowMarkClause as one of the known
Michael Meskes writes:
>> IOW, not only is setlocale() not necessarily thread-safe itself,
>> but using it to change locales in a multithread program is seriously
>> unsafe because of concurrent effects on other threads.
> Agreed.
> How about attached patch? According to my manpages it should on
> On Jan 18, 2019, at 2:05 AM, Andrew Gierth
> wrote:
>
> BTW, doing that in a thread about a commitfest patch confuses the
> commitfest app and cfbot (both of which think it's a new version of the
> patch under discussion), so best avoided.
Oops. Thank you. Noted.
I think the previous addit
On Sat, Jan 19, 2019 at 8:06 AM Amit Kapila wrote:
>
> On Thu, Jan 17, 2019 at 11:13 PM John Naylor
> Few more comments:
> 1.
> I think we should not allow to create FSM for toast tables as well
> till there size reaches HEAP_FSM_CREATION_THRESHOLD. If you try below
> test, you can see that FSM w
On Sat, Jan 19, 2019 at 2:54 AM Alexander Korotkov
wrote:
> 1) It seems that @* and @# are not going to be supported by any
> indexes. I think we should remove these operators and let users use
> functions instead.
> 2) I propose to rename @~ operator to @@. We already use @@ as
> "satisfies" in
On 1/14/19 10:25 PM, Tomas Vondra wrote:
> On 12/13/18 8:09 AM, Surafel Temesgen wrote:
>>
>>
>> On Wed, Dec 12, 2018 at 9:28 PM Tomas Vondra
>> mailto:tomas.von...@2ndquadrant.com>> wrote:
>>
>>
>> Can you also update the docs to mention that the functions called from
>> the WHERE claus
> So my conclusion is that this version of setlocale() has some
> thread-safety issues. I was all set to go file a bug report
> when I noticed this in the POSIX spec for setlocale:
>
> The setlocale() function need not be thread-safe.
>
> as well as this:
>
> The global locale estab
Magnus Hagander writes:
> On Sat, Jan 19, 2019 at 7:19 PM Stephen Frost wrote:
>> Does this also implicitly mean we've just agreed to push back the
>> retirement of the @postgresql.org aliases for the lists until v11 is
>> EOL..?
> Specifically for pgsql-bugs, yes :) We can special-case that one
Paul Ramsey writes:
> Is there a rule of thumb we can use in costing our wrappers to ensure that
> they always inline?
Not really, which is a weak spot of this whole approach.
In particular, if you just make procost really big, you risk screwing
things up rather badly in cases where inlining f
> On Jan 19, 2019, at 12:25 PM, Tom Lane wrote:
>
> Adam Brightwell writes:
>> I've been working with Paul to create and test a patch (attached) that
>> addresses Solution #2. This patch essentially modifies the inlining
>> logic to compare the cost of the function with the total cost of the
Adam Brightwell writes:
> I've been working with Paul to create and test a patch (attached) that
> addresses Solution #2. This patch essentially modifies the inlining
> logic to compare the cost of the function with the total cost of the
> parameters. The goal as stated above, is that for these ki
Hi,
On 01/19/19 08:35, Alvaro Herrera wrote:
>> Is there, somewhere, a written-up "house style" for what DocBook 4.2
>> elements to use for which types of content in the manual?
>> ...
> I don't think we do. I'd suggest to come up with something and then see
> if it makes sense to patch the docs
On Sat, Jan 19, 2019 at 7:19 PM Stephen Frost wrote:
> Greetings,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Fri, Jan 18, 2019 at 4:02 PM Tom Lane wrote:
> > > Magnus Hagander writes:
> > > > On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier >
> > > wrote:
> > > >> Wouldn't it be
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Jan 18, 2019 at 4:02 PM Tom Lane wrote:
> > Magnus Hagander writes:
> > > On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier
> > wrote:
> > >> Wouldn't it be better to also switch the references to pgsql-bugs in
> > >> all the C c
On Fri, Jan 18, 2019 at 4:02 PM Tom Lane wrote:
> Magnus Hagander writes:
> > On Fri, Jan 18, 2019 at 1:26 AM Michael Paquier
> wrote:
> >> Wouldn't it be better to also switch the references to pgsql-bugs in
> >> all the C code for the different --help outputs?
>
> > You are right, we definite
Vik Fearing writes:
> Does the extension need a version bump for this?
We don't bump its version when we make any other change that affects
its hash calculation. I don't think this could be back-patched,
but Andrew wasn't proposing to do so (IIUC).
regards, tom lane
Andrew Gierth writes:
> I propose that it should not ignore rowMarks, per the attached patch or
> something similar.
+1 for not ignoring rowMarks, but this patch seems like a hack to me.
Why didn't you just add RowMarkClause as one of the known alternative
expression node types? There's no advan
I tried to build cmake on OpenBSD running on my old HPPA hardware,
not because I cared about cmake per se but because it's a dependency
of something I did care about. Failed miserably. It turns out cmake has
a hard dependency on libuv which (a) has a hard dependency on atomic ops
and (b) accordin
On January 19, 2019 7:32:55 AM PST, Stephen Frost wrote:
>Greetings,
>
>* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
>> My vote is to have homogeneous syntax for all of this, and so put it
>in
>> parentheses, but we should also allow CREATE INDEX and DROP INDEX to
>use
>> parentheses for
On 1/19/19 12:05 AM, John Naylor wrote:
> On 11/22/18, David Rowley wrote:
>> If required, such operations could LOCK TABLE the top partitioned
>> table to block the DML operation. There's already a risk of similar
>> deadlocks from such operations done on multiple separate tables when
>> the orde
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Jan 18, 2019 at 09:50:40AM -0500, Stephen Frost wrote:
> > It'd probably be good to give folks an opportunity to voice their
> > opinion regarding their use-case for the file existing as it does and
> > being documented as it is.
Greetings,
* Vik Fearing (vik.fear...@2ndquadrant.com) wrote:
> On 16/01/2019 18:59, Alvaro Herrera wrote:
> > On 2019-Jan-16, Michael Paquier wrote:
> >
> >> Regarding the grammar, we tend for the last couple of years to avoid
> >> complicating the main grammar and move on to parenthesized gramm
On 19/01/2019 15:43, Andrew Gierth wrote:
> pg_stat_statements considers a plain select and a select for update to
> be equivalent, which seems quite wrong to me as they will have very
> different performance characteristics due to locking.
>
> The only comment about it in the code is:
>
> /*
Fabien COELHO wrote:
> > I've also changed handleCopyOut() to return success if it
> > could pump the data without writing it out locally for lack of
> > an output stream. It seems to make more sense like that.
>
> I'm hesitating on this one.
>
> On the one hand the SQL query is executed
pg_stat_statements considers a plain select and a select for update to
be equivalent, which seems quite wrong to me as they will have very
different performance characteristics due to locking.
The only comment about it in the code is:
/* we ignore rowMarks */
I propose that it should not ign
Hi
On 2019-Jan-18, Chapman Flack wrote:
> Is there, somewhere, a written-up "house style" for what DocBook 4.2
> elements to use for which types of content in the manual?
>
> In func.sgml I'm seeing what looks like a variety of examples, and
> I'm not sure which ones to try to follow.
I don't t
On Thu, Jan 17, 2019 at 11:13 PM John Naylor
wrote:
>
> On Wed, Jan 16, 2019 at 10:35 PM Amit Kapila wrote:
> > Yes, I think it would be good if you can explain the concept of
> > local-map with the help of this example.
>
> > Then let's not add a reference to the version number in this case. I
On Fri, Jan 18, 2019 at 9:58 PM Etsuro Fujita
wrote:
> I updated the patch as such and rebased it to the latest HEAD. I also
> added the commit message. Attached is an updated patch. Does that make
> sense? If there are no objections, I'll push that patch early next week.
Thank you. Looks go
On Sat, Jan 19, 2019 at 7:16 AM Alvaro Herrera wrote:
> Thanks, this is better. There were a few other things I didn't like, so
> I updated it. Mostly, two things:
>
> 1. I didn't like a seqscan on pg_trigger, so I turned that into an
> indexed scan on the constraint OID, and then the other two
Hello
> I don't want a situation like this:
> CREATE INDEX CONCURRENTLY ...
> DROP INDEX CONCURRENTLY ...
> REINDEX INDEX (CONCURRENTLY) ...
>
> All three should be the same, and my suggestion is to add the
> parenthesized version to CREATE and DROP and not add the unparenthesized
> ve
Bonjour Daniel,
I took a quick look at this patch.
PFA an updated patch addressing your comments and Fabien's.
About this v2.
Applies cleanly, compiles cleanly, "make check" ok.
No tests, but Tom suggests this does not belong here: the committer is
right:-)
I tested the feature manual
55 matches
Mail list logo
