Hello.
At Fri, 18 Jan 2019 17:09:41 -0800, "and...@anarazel.de"
wrote in <20190119010941.6ruftewah7t3k...@alap3.anarazel.de>
> Hi,
>
> On 2019-01-18 19:57:03 -0500, Robert Haas wrote:
> > On Fri, Jan 18, 2019 at 4:23 PM and...@anarazel.de
> > wrote:
> > > My proposal for this was to attach a
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> 0003: Remote GUC setting
>
> It is independent from the above two, and heavily arguable.
>
> pg_set_backend_config(pid, name, value) changes the GUC on the
> backend with to .
>
Not having looked at the code yet, why did you
From: Haribabu Kommi [mailto:kommi.harib...@gmail.com]
> Thanks for finding out the problem, how about the following way of checking
> for prefer-read/prefer-standby.
>
> 1. (default_transaction_read_only = true and recovery = true)
>
> 2. If none of the host satisfies the above scenario, then
ne 20. 1. 2019 23:13 odesílatel Chapman Flack
napsal:
> On 01/20/19 12:48, Pavel Stehule wrote:
> >>
> >> Accordingly, I think the paragraph beginning "Unlike regular PostgreSQL
> >> functions," is more likely to perplex readers than to enlighten them.
> >> What it says about column_expression
From: Laurenz Albe [mailto:laurenz.a...@cybertec.at]
> Tsunakawa, Takayuki wrote:
> > I'm sorry to repeat myself, but anyway, I think we need a method to connect
> to a standby
> > as the original desire, because the primary instance may be read only
> by default while
> > only limited users
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Hm. Well, I suppose we can figure that the buildfarm should tell us if
> there's anything too old that we still care about.
>
> So like this ...
How quick! Thank you. I've reviewed the code for both Unix and Windows, and
it looks OK. I haven't
On Tue, 15 Jan 2019 at 13:17, Tom Lane wrote:
>
> David Rowley writes:
> > I also did a quick benchmark of v6 and found the slowdown to be
> > smaller after the change made in build_simple_rel()
>
> Thanks for confirming. I was not very sure that was worth the extra
> few bytes of code space,
Imai-san,
On 2019/01/21 9:45, Imai, Yoshikazu wrote:
> I'll check if this fact is really correct by majoring the time of the
> first 5 queries before generic plan is created and the other queries
> after generic plan is created.
That would really help. If you are able to recreate that behavior
On 1/21/19 3:12 AM, Andres Freund wrote:
> On 2019-01-20 18:08:05 -0800, Andres Freund wrote:
>> On 2019-01-20 21:00:21 -0500, Tomas Vondra wrote:
>>>
>>>
>>> On 1/20/19 8:24 PM, Andres Freund wrote:
Hi,
On 2019-01-20 00:24:05 +0100, Tomas Vondra wrote:
> On 1/14/19 10:25 PM,
On 1/21/19 3:12 AM, Andres Freund wrote:
> On 2019-01-20 18:08:05 -0800, Andres Freund wrote:
>> On 2019-01-20 21:00:21 -0500, Tomas Vondra wrote:
>>>
>>>
>>> On 1/20/19 8:24 PM, Andres Freund wrote:
Hi,
On 2019-01-20 00:24:05 +0100, Tomas Vondra wrote:
> On 1/14/19 10:25 PM,
"Tsunakawa, Takayuki" writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> How far back does that exist?
> I couldn't find the relevant doc, but I've just confirmed I can use it with
> Visual Studio 2008 on Win7, which is my oldest combination at hand. VS 2008
> is already past its EOL,
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> "Tsunakawa, Takayuki" writes:
> > On Windows, _configthreadlocale() enables us to restrict the effect of
> setlocale() only to the calling thread. We can call it in
> ecpg_do_prolog/epilog().
>
> How far back does that exist?
I couldn't find the
On 1/18/19 8:32 PM, Mitar wrote:
On Fri, Jan 18, 2019 at 7:18 AM Andreas Karlsson wrote:
These rules are usually pretty easy to add. Just take a look in
src/bin/psql/tab-complete.c to see how it is usually done.
Thanks. I have added the auto-complete and attached a new patch.
Hm, I do not
On 01/20/19 20:07, Chapman Flack wrote:
> So it appears that this example does not depend on any special treatment
> of the default_expression.
>
> Is there an example that can be constructed that would depend on the
> special treatment (in which case, the PL/Java implementation would be
>
On 1/17/19 8:31 PM, Tom Lane wrote:
Creating the view object inside the rStartup callback is itself pretty
much of a kluge; you'd expect that to happen earlier. I think the
reason it was done that way was it was easier to find out the view's
column set there, but I'm sure we can find another
"Tsunakawa, Takayuki" writes:
> On Windows, _configthreadlocale() enables us to restrict the effect of
> setlocale() only to the calling thread. We can call it in
> ecpg_do_prolog/epilog().
How far back does that exist?
regards, tom lane
On Windows, _configthreadlocale() enables us to restrict the effect of
setlocale() only to the calling thread. We can call it in
ecpg_do_prolog/epilog().
https://docs.microsoft.com/en-us/cpp/parallel/multithreading-and-locales?view=vs-2017
Regards
Takayuki Tsunakawa
On 2019-01-20 18:08:05 -0800, Andres Freund wrote:
> On 2019-01-20 21:00:21 -0500, Tomas Vondra wrote:
> >
> >
> > On 1/20/19 8:24 PM, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2019-01-20 00:24:05 +0100, Tomas Vondra wrote:
> > > > On 1/14/19 10:25 PM, Tomas Vondra wrote:
> > > > > On
On Mon, Jan 21, 2019 at 12:25:16AM +, Andrew Gierth wrote:
> > "Tom" == Tom Lane writes:
>
> Tom> A larger issue is whether "hand out some OIDs on-demand" is a
> Tom> sustainable strategy.
>
> No.
>
> Not for any concerns over availability of oids, but simply from the fact
> that we
On 2019-01-20 21:00:21 -0500, Tomas Vondra wrote:
>
>
> On 1/20/19 8:24 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2019-01-20 00:24:05 +0100, Tomas Vondra wrote:
> > > On 1/14/19 10:25 PM, Tomas Vondra wrote:
> > > > On 12/13/18 8:09 AM, Surafel Temesgen wrote:
> > > > >
> > > > >
> > > > >
On 1/20/19 8:24 PM, Andres Freund wrote:
Hi,
On 2019-01-20 00:24:05 +0100, Tomas Vondra wrote:
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
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= writes:
>> Pushed with that correction.
> Thanks a lot!
Hm, so bowerbird (a Windows machine) has been failing the pgbench tests
since this went in, cf
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2019-01-20%2004%3A57%3A01
I'm
On Mon, 21 Jan 2019 at 13:45, Imai, Yoshikazu
wrote:
> On Wed, Jan 17, 2019 at 10:25 AM, Amit Langote wrote:
> > Are you saying that, when using auto mode, all executions of the query
> > starting from 7th are slower than the first 5 executions? That is, the
> > latency of creating and using a
Chapman Flack writes:
> On 01/20/19 19:43, Tom Lane wrote:
>>> If the extension script could somehow be informed at CREATE EXTENSION time
>>> of what its OID is, that would clear the way for ALTER EXTENSION RENAME, no?
>> And it remembers that where?
> Top level answer: up to the extension
Hi,
On 2019-01-20 00:24:05 +0100, Tomas Vondra wrote:
> 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
On 01/20/19 17:13, Chapman Flack wrote:
> On 01/20/19 12:48, Pavel Stehule wrote:
>> regular Postgres' functions has evaluated all arguments before own
>> execution. I think so this note is related much more to expressions used as
>> defaults.
>
> Sure, but again, is there an example, or can one
Andrew Gierth writes:
> In fact I suggest that "there shall be no registries of third parties"
> be made a formal project policy.
You're a decade or two too late for that; see pg_statistic.h.
In any case, it's not like this issue applies to every extension anybody
might want to make. Only
On 01/20/19 19:43, Tom Lane wrote:
>> If the extension script could somehow be informed at CREATE EXTENSION time
>> of what its OID is, that would clear the way for ALTER EXTENSION RENAME, no?
>
> And it remembers that where?
Top level answer: up to the extension author.
Next level answer:
Tsunakawa-san
On Thu, Jan 18, 2019 at 5:29 AM, Amit Langote wrote:
> On 2019/01/18 14:12, Tsunakawa, Takayuki wrote:
...
> > Isn't CheckCachedPlan() (and AcquireExecutorLocks() therein) called
> in every EXECUTE after 6th one due to some unknow issue?
>
> CheckCachedPlan is only called if
> "Tom" == Tom Lane writes:
Tom> I'm not exactly following this concern. I wasn't imagining that
Tom> we'd assign each individual OID ourselves, but rather give out
Tom> blocks of OIDs. Admittedly, the blocks can't be huge, but it
Tom> doesn't seem to me that this'd create an impossible
Hi Amit-san,
On Wed, Jan 17, 2019 at 10:25 AM, Amit Langote wrote:
> Thank you Imai-san for testing. Sorry it totally slipped my mind to reply to
> this email.
Thanks for replying and sorry for my late reply. I've been undertaking
on-the-job training last week.
> Are you saying that, when
Chapman Flack writes:
> On 01/20/19 18:50, Tom Lane wrote:
>> we make a catalog entry showing that object number three has OID
>> thus-and-so, and then that catalog entry can be consulted to get
>> the right OID (by C code that has hard-wired knowledge that object
>> number three is the function
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> A larger issue is whether "hand out some OIDs on-demand" is a
> Tom> sustainable strategy.
> No.
> Not for any concerns over availability of oids, but simply from the fact
> that we have no business whatsoever inserting ourselves into
On 01/20/19 18:50, Tom Lane wrote:
> we make a catalog entry showing that object number three has OID
> thus-and-so, and then that catalog entry can be consulted to get
> the right OID (by C code that has hard-wired knowledge that object
> number three is the function it cares about). This is
> "Tom" == Tom Lane writes:
Tom> A larger issue is whether "hand out some OIDs on-demand" is a
Tom> sustainable strategy.
No.
Not for any concerns over availability of oids, but simply from the fact
that we have no business whatsoever inserting ourselves into the
extension development
on Fri, 18 2019 at 19:41, David Rowley wrote:
>Perhaps you're running with plan_cache_mode = force_custom_plan.
>You'll likely need it set to auto for these to pass.
Thank you.
I was running with plan_cache_mode = force_custom_plan.
When it set to auto, all tests are passed.
regards,
sho kato
I wrote:
> I'll try to sketch up a more concrete plan soon.
I've posted some preliminary design ideas at
https://www.postgresql.org/message-id/15193.1548028...@sss.pgh.pa.us
and
https://www.postgresql.org/message-id/15289.1548028...@sss.pgh.pa.us
While there's a nontrivial amount of work needed
In [1] I propose that we should allow extensions to get their hands
on the ability to transform function calls as per "protransform" and
to generate lossy index quals based on items in WHERE clauses. The
APIs to give an extension control at the right points seem pretty
straightforward, but
Over in the thread at [1], we realized that PostGIS has been thrashing
around trying to fake its way to having "special index operators", ie
a way to automatically convert WHERE clauses into lossy index quals.
That's existed in a non-extensible way inside indxpath.c for twenty
years come July.
On 1/20/19 11:21 PM, Andres Freund wrote:
> On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote:
>> On 1/17/19 3:15 PM, Arthur Zakirov wrote:
>>> I attached files of new version of the patch, I applied your tweaks.
>>>
XXX All dictionaries, but only when there's invalid dictionary?
>>>
>>> I've
On Tue, Jan 15, 2019 at 6:05 PM Andres Freund wrote:
> Hi,
>
> On 2019-01-15 18:02:38 +1100, Haribabu Kommi wrote:
> > On Tue, Dec 11, 2018 at 1:13 PM Andres Freund
> wrote:
> >
> > > Hi,
> > >
> > > On 2018-11-26 17:55:57 -0800, Andres Freund wrote:
> > > Further tasks I'm not yet planning to
On Fri, Jan 18, 2019 at 5:33 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
> > As for prefer-standby/prefer-read, if host parameter specifies
> host1,host2
> > in this order, and host1 is the primary with
> >
On Sun, Jan 20, 2019 at 6:30 AM Alexander Korotkov
wrote:
> I'll continue revising this patchset. Nikita, could you please write
> tests for 3-argument versions of functions? Also, please answer the
> question regarding "id" property.
I've some more notes regarding function set provided in
On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote:
> On 1/17/19 3:15 PM, Arthur Zakirov wrote:
> > I attached files of new version of the patch, I applied your tweaks.
> >
> >> XXX All dictionaries, but only when there's invalid dictionary?
> >
> > I've made a little optimization. I introduced
On 1/17/19 3:15 PM, Arthur Zakirov wrote:
> I attached files of new version of the patch, I applied your tweaks.
>
>> XXX All dictionaries, but only when there's invalid dictionary?
>
> I've made a little optimization. I introduced hashvalue into
> TSDictionaryCacheEntry. Now released only DSM
On 01/20/19 12:48, Pavel Stehule wrote:
>>
>> Accordingly, I think the paragraph beginning "Unlike regular PostgreSQL
>> functions," is more likely to perplex readers than to enlighten them.
>> What it says about column_expression does not seem to lead to any useful
>> difference from the behavior
On Mon, 21 Jan 2019 at 09:51, Kim Rose Carlsen wrote:
> remove_useless_join does not prove uniqueness if the unique index is partial,
> and therefore wont remove the join if no columns are referenced (see example
> in bottom).
>
> I have been trying to look around the source code and from what
Hello Tom,
Here is a POC which defines an internal interface for a PRNG, and use it
within pgbench, with several possible implementations which default to
rand48.
I seriously dislike this patch. pgbench's random support is quite
overengineered already IMO, and this proposes to add a whole
On Sat, 19 Jan 2019 at 12:05, 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
Hi
remove_useless_join does not prove uniqueness if the unique index is partial,
and therefore wont remove the join if no columns are referenced (see example in
bottom).
I have been trying to look around the source code and from what I have
identified the problem seems to be that
Fabien COELHO writes:
>>> I'd suggest that maybe we should get rid of the use of both random()
>>> and srandom() in pgbench, and go over to letting set_random_seed()
>>> fill the pg_erand48 state directly.
> Here is a POC which defines an internal interface for a PRNG, and use it
> within
I wrote:
> On the third hand, the lack of previous reports suggests that maybe
> this whole thing is seldom a problem in practice. Maybe we should
> just use uselocale() where available and otherwise hope it's OK
> to keep on doing what we were doing.
If we go with that approach, I think we need
Hi,
Currently RelationFindReplTupleByIndex(), RelationFindReplTupleSeq()
lock the found tuple. I don't quite get what that achieves - why isn't
dealing with concurrency in the table_update/delete calls at the
callsites sufficient? As far as I can tell there's no meaningful
concurrency handling in
Hi,
On 2019-01-20 14:37:43 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-20 10:15:53 -0500, Tom Lane wrote:
> >> Indeed, the main reason why I'm interested in keeping this old dinosaur
> >> going at all is that it is so different from other platforms in terms
> >> of what we can
Andres Freund writes:
> On 2019-01-20 10:15:53 -0500, Tom Lane wrote:
>> Indeed, the main reason why I'm interested in keeping this old dinosaur
>> going at all is that it is so different from other platforms in terms
>> of what we can assume about spinlocks and atomic ops. Keeps us honest.
>
Hi John,
On 1/16/19 10:08 PM, John Naylor wrote:
>> [v5]
>
> Hi Tomas,
> Peter suggested upthread to use 'settings' rather than 'gucs' for the
> explain option (and output?), and you seemed to agree. Are you going
> to include that in a future version? Speaking of the output, v5's
> default text
Hi,
On 2019-01-20 10:15:53 -0500, Tom Lane wrote:
> Andres Freund writes:
> > HPPA doesn't hardware instructions for atomic ops other than
> > test-and-set IIRC.
>
> Indeed, the main reason why I'm interested in keeping this old dinosaur
> going at all is that it is so different from other
>
> Accordingly, I think the paragraph beginning "Unlike regular PostgreSQL
> functions," is more likely to perplex readers than to enlighten them.
> What it says about column_expression does not seem to lead to any useful
> difference from the behavior if it were "just like regular PostgreSQL
>
On 01/20/19 11:55, Pavel Stehule wrote:
> input row mean a row of processed relation. The xml value from this row can
> be transformed to 0..M output rows.
>
> The column filter expressions are evaluated once per input rows, default
> expressions are evaluated when it is necessary - possibly once
Michael Meskes writes:
>> No, we shouldn't use setlocale(), because it clearly is hazardous
>> even on platforms where it doesn't fail outright. I don't see
>> anything so wrong with just documenting the hazard. The situation
> Actually I meant using setlocale() and documenting that it must
> On Fri, Jan 18, 2019 at 11:22 AM Amit Khandekar
> wrote:
>
> --- a/src/test/regress/expected/copy2.out
> +++ b/src/test/regress/expected/copy2.out
> @@ -1,3 +1,4 @@
> +\set HIDE_TABLEAM on
>
> I thought we wanted to avoid having to add this setting in individual
> regression tests. Can't we do
Hi,
The patch needs rebasing, as it got broken by 285d8e1205, and there's
some other minor bitrot.
On 11/27/18 4:40 PM, Tomas Vondra wrote:
> On 11/27/18 9:59 AM, Kyotaro HORIGUCHI wrote:
>>>
>>> ...>>
>>> For the main workload there's pretty much no difference, but for
>>> selects from the
> > The question is, what do we do on those platforms? Use setlocale()
> > or
> > fallback to (a) and document that ecpg has to run in a C locale?
>
> No, we shouldn't use setlocale(), because it clearly is hazardous
> even on platforms where it doesn't fail outright. I don't see
> anything so
ne 20. 1. 2019 v 17:06 odesílatel Chapman Flack
napsal:
> Hi,
>
> On 01/20/19 00:26, Pavel Stehule wrote:
> >>> column expressions are evaluated once per row, but XPath expression is
> >>> compiled per row too, if I remember well.
> >>
> >> I looked for evidence of that in the code, but did not
Dave Cramer
On Tue, 15 Jan 2019 at 07:53, Dave Cramer wrote:
>
> Dave Cramer
>
>
> On Sun, 13 Jan 2019 at 23:19, Craig Ringer wrote:
>
>> On Mon, 3 Dec 2018 at 19:38, Dave Cramer wrote:
>>
>>> Dmitry,
>>>
>>> Please see attached rebased patches
>>>
>>
>> I'm fine with patch 0001, though I
On 1/20/19 5:07 PM, chenhj wrote:
> In our PG 10.2(CentOS 7.3) database, the following error is reported when
> querying a table. We have already restored the production data through
> backup, but i want to confirm what may be the reason and how to avoid it in
> the future.
>
> lma=#
In our PG 10.2(CentOS 7.3) database, the following error is reported when
querying a table. We have already restored the production data through backup,
but i want to confirm what may be the reason and how to avoid it in the future.
lma=# select count(*) from
Hi,
On 01/20/19 00:26, Pavel Stehule wrote:
>>> column expressions are evaluated once per row, but XPath expression is
>>> compiled per row too, if I remember well.
>>
>> I looked for evidence of that in the code, but did not find it; the
>> compilation appears to happen in
Andres Freund writes:
> On 2019-01-19 23:39:37 -0800, Jesse Zhang wrote:
>> Atomic ops (compare-and-exchange) might be a harder dependency to shed
>> for libuv. Does the fallback onto compiler intrinsics
>> (__sync_val_compare_and_swap, or on GCC 4.7+,
>> __atomic_compare_exchange_n) not work
I understand from the code that the COPY is really executed, so the ERROR
and so ROW_COUNT about the SQL should reflect that. Basically the change
makes the client believe that there is an SQL error whereas the error is
on the client.
Right, but wether COPY fails because psql can't write the
On Sat, Jan 19, 2019 at 4:02 AM Nishant, Fnu wrote:
>
> Hello,
>
> While locking heap pages (function RelationGetBufferForTuple() in file hio.c)
> we acquire locks in increasing block number order to avoid deadlock. In
> certain cases, we do have to drop and reacquire lock on heap pages (when
On 1/20/19 5:45 AM, John Naylor wrote:
> 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
Bonjour Daniel,
:ROW_COUNT is incorrect after COPY TO STDOUT but this is a PG11-only
bug, :ROW_COUNT being a recent addition, so maybe we should deal with
this separately, since the current patch is supposed to address all versions?
ISTM that the patch is considered a bug fix, so it shoud
В письме от четверг, 17 января 2019 г. 20:33:06 MSK пользователь Alvaro
Herrera написал:
> You introduced new macros IsHeapRelation and IsViewRelation, but I don't
> want to introduce such API. Such things have been heavily contested and
> I don't to have one more thing to worry about for this
Hello Tom,
Maybe on OpenBSD pg should switch srandom to srandom_deterministic?
Dunno. I'm fairly annoyed by their idea that they're smarter than POSIX.
Hmmm. I'm afraid that is not that hard.
However, for most of our uses of srandom, this behavior isn't awful;
it's only pgbench that has
On Sun, Jan 20, 2019 at 2:24 AM Tomas Vondra
wrote:
>
> Pushed, thanks for the patch.
>
> cheers
>
>
>
Thank you
regards
Surafel
Hi,
On 2019-01-19 23:39:37 -0800, Jesse Zhang wrote:
> 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
77 matches
Mail list logo
