On Wed, Jan 13, 2021 at 10:28:26AM -0500, Tom Lane wrote:
> So a non-rewriting conversion would only be possible if local time is
> identical to UTC; which is true for few enough people that nobody has
> bothered with attempting the optimization.
PostgreSQL 12 and later do have that optimization.
On Sat, Jan 16, 2021 at 12:21 PM Bharath Rupireddy
wrote:
> > In the test, can we have multiple publications for the subscription
> > because that is how we discovered that the originally proposed patch
> > was not correct? Also, is it possible to extend some of the existing
> > tests in 001_rep_c
On 12/29/20 10:18 AM, Peter Eisentraut wrote:
> On 2020-12-28 21:54, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> I was surprised to find that this doesn't error:
>>> => select 100a;
>>> a
>>> -
>>> 100
>>
>>> I suspect this and similar cases used to error before aliases without AS
>
On 12/30/20 12:59 PM, Noah Misch wrote:
> On Tue, Dec 29, 2020 at 05:49:24AM -0800, Noah Misch wrote:
>> https://postgr.es/m/20201031163518.gb4039...@rfd.leadboat.com gave $SUBJECT
>> as
>> one of the constituent projects for changing the public schema default ACL.
>> This ended up being simple.
On 1/3/21 1:12 PM, Joel Jacobson wrote:
> Hi hackers,
>
> I just learned about a feature called "LET clause".
>
> It's not part of the SQL standard, but it's supported by Oracle [1],
> Couchbase [2] and AsterixDB [3].
>
> I searched the pgsql-hackers archives and couldn't find any matches on "L
On 1/14/21 10:22 PM, Simon Riggs wrote:
> On Thu, Jan 14, 2021 at 5:46 PM Surafel Temesgen
> wrote:
>
>> On Fri, Jan 8, 2021 at 7:50 PM Ryan Lambert wrote:
>>>
>>> I prefer to have them hidden by default. This was mentioned up-thread with
>>> no decision, it seems the standard is ambiguous.
On 1/14/21 6:42 PM, Surafel Temesgen wrote:
> Hi Simon,
> Thank you for all the work you does
>
> On Mon, Jan 11, 2021 at 5:02 PM Simon Riggs
> wrote:
>
>>
>>
>> * Anomalies around use of CURRENT_TIMESTAMP are not discussed or resolved.
>> Probably need to add a test that end_timestamp > start_t
On 12.01.2021 22:30, Tomas Vondra wrote:
Thanks. These patches seem to resolve the TOAST table issue, freezing
it as expected. I think the code duplication is not an issue, but I
wonder why heap_insert uses this condition:
/*
* ...
*
* No need to update the visibilitymap if
On 1/16/21 2:02 PM, Vik Fearing wrote:
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
because identifiers cannot start with an underscore, but I don't want to
take it that far).
It would also allow us to h
Hi hackers!
Does anyone maintain opensource pg_surgery analogs for released versions of PG?
It seems to me I'll have to use something like this and I just though that I
should consider pg_surgery in favour of our pg_dirty_hands.
Thanks!
Best regards, Andrey Borodin.
On 1/16/21 4:32 PM, Andreas Karlsson wrote:
> On 1/16/21 2:02 PM, Vik Fearing wrote:
>> I am in favor of such a change so that we can also accept 1_000_000
>> which currently parses as "1 AS _000_000" (which also isn't compliant
>> because identifiers cannot start with an underscore, but I don't wa
Noah Misch writes:
> On Wed, Jan 13, 2021 at 10:28:26AM -0500, Tom Lane wrote:
>> So a non-rewriting conversion would only be possible if local time is
>> identical to UTC; which is true for few enough people that nobody has
>> bothered with attempting the optimization.
> PostgreSQL 12 and later
Vik Fearing writes:
> On 1/16/21 4:32 PM, Andreas Karlsson wrote:
>> On 1/16/21 2:02 PM, Vik Fearing wrote:
>>> I am in favor of such a change so that we can also accept 1_000_000
>>> which currently parses as "1 AS _000_000" (which also isn't compliant
>>> because identifiers cannot start with an
On 1/16/21 6:10 PM, Tom Lane wrote:
> Vik Fearing writes:
>> On 1/16/21 4:32 PM, Andreas Karlsson wrote:
>>> On 1/16/21 2:02 PM, Vik Fearing wrote:
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
>>
On Sat, Jan 16, 2021 at 1:40 AM Andres Freund wrote:
>
> On 2021-01-15 09:53:05 +0100, Peter Eisentraut wrote:
> > On 2020-12-08 10:38, vignesh C wrote:
> > > I have implemented printing of backtrace based on handling it in
> > > CHECK_FOR_INTERRUPTS. This patch also includes the change to allow
>
Hi,
On Sat, Jan 16, 2021, at 09:34, vignesh C wrote:
> On Sat, Jan 16, 2021 at 1:40 AM Andres Freund wrote:
> >
> > On 2021-01-15 09:53:05 +0100, Peter Eisentraut wrote:
> > > On 2020-12-08 10:38, vignesh C wrote:
> > > > I have implemented printing of backtrace based on handling it in
> > > > CH
On Fri, Jan 15, 2021 at 8:02 PM Simon Riggs
wrote:
>
> There are no existing applications, so for PostgreSQL, it wouldn't be an
> issue.
>
>
Yes we don't have but the main function of ALTER TABLE foo ADD SYSTEM
VERSIONING
is to add system versioning functionality to existing application
regards
On 1/16/21 7:39 PM, Surafel Temesgen wrote:
> On Fri, Jan 15, 2021 at 8:02 PM Simon Riggs
> wrote:
>
>>
>> There are no existing applications, so for PostgreSQL, it wouldn't be an
>> issue.
>>
>>
> Yes we don't have but the main function of ALTER TABLE foo ADD SYSTEM
> VERSIONING
> is to add syst
On Sat, Jan 16, 2021, at 17:21, Vik Fearing wrote:
> I agree on the conciseness, but I'm wondering what performance problem
> you think there is with the CROSS JOIN LATERAL VALUES technique. Have
> you tried running an EXPLAIN (ANALYZE, VERBOSE) on that?
Yes, I've tried, it results in the same pr
Vik Fearing writes:
> With respect, you are looking at a 10-year-old document and I am not.
> 5.3 has since been modified.
Is a newer version of the spec available online?
regards, tom lane
vignesh C writes:
> On Sat, Jan 16, 2021 at 1:40 AM Andres Freund wrote:
>> Why is a full signal needed? Seems the procsignal infrastructure should
>> suffice?
> Most of the processes have access to ProcSignal, for these processes
> printing of callstack signal was handled by using ProcSignal. P
On Fri, 2021-01-15 at 13:55 -0800, Andres Freund wrote:
> Has anybody dug out the thread leading to the commit?
https://www.postgresql.org/message-id/CAMsr%2BYEN04ztb%2BSDb_UfD72Kg5M3F%2BCpad31QBKT2rRjysmxRg%40mail.gmail.com
Regards,
Jeff Davis
On 1/16/21 4:11 PM, Anastasia Lubennikova wrote:
> ...
As Pavan correctly figured it out before the problem is that
RelationGetBufferForTuple() moves to the next page, losing free space in
the block:
> ... I see that a relcache invalidation arrives
> after 1st and then after every 32672
On Sat, Jan 16, 2021 at 12:28 PM Masahiko Sawada wrote:
>
> ---
> + /* test for recovery pause if user has requested the pause */
> + if (((volatile XLogCtlData *) XLogCtl)->recoveryPause)
> + recoveryPausesHere(false);
> +
> + now = GetCurrentTimestamp();
> +
>
> Hmm,
> If we agree on removing heap_multi_insert_v2 API and embed that logic
> inside heap_insert_v2, then we can do this - pass the required
> information and the functions ExecInsertIndexTuples and
> ExecARInsertTriggers as callbacks so that, whether or not
> heap_insert_v2 choses single or multi in
On Sat, Jan 16, 2021 at 05:48:43PM +0100, Tomas Vondra wrote:
> +
> + expr text
> +
> +
> + Expression the extended statistics is defined on
> +
Expression the extended statistics ARE defined on
Or maybe say "on which the extended statistics are defined"
> +
On 1/15/21 5:19 PM, Tomas Vondra wrote:
On 1/15/21 9:47 AM, Julien Rouhaud wrote:
On Wed, Jan 13, 2021 at 10:22:05AM +0900, Tatsuro Yamada wrote:
Hi Tomas,
On 2021/01/13 7:48, Tatsuro Yamada wrote:
On 2021/01/12 20:08, Tomas Vondra wrote:
On 1/12/21 2:57 AM, Tatsuro Yamada wrote:
On 20
> > > I think that's not at all acceptable. I don't mind hashing out details
> > > on calls / off-list, but the design needs to be public, documented, and
> > > reviewable. And if it's something the community can't understand, then
> > > it can't get in. We're going to have to maintain this going
On Sat, Jan 16, 2021 at 12:03:19PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Jan 13, 2021 at 10:28:26AM -0500, Tom Lane wrote:
> >> So a non-rewriting conversion would only be possible if local time is
> >> identical to UTC; which is true for few enough people that nobody has
> >> bo
Hi, hackers.
I tested this committed feature.
It doesn't seem to be available to non-superusers due to the inability to
access pg_statistics_ext_data.
Is this the expected behavior?
--- operation ---
postgres=> CREATE STATISTICS stat1_data1 ON c1, c2 FROM data1;
CREATE STATISTICS
postgres=> AN
For the record, this got committed as 6bc27698324 in December, along
with the other incremental sort fixes and improvements. I forgot to mark
it as committed in the app, so I've done that now.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 1/17/21 2:41 AM, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Hi, hackers.
I tested this committed feature.
It doesn't seem to be available to non-superusers due to the inability to
access pg_statistics_ext_data.
Is this the expected behavior?
Hmmm, that's a good point. Bummer we haven't not
I've been looking into the planner failure reported at [1].
The given test case is comparable to this query in the
regression database:
regression=# select i8.*, ss.v, t.unique2
from int8_tbl i8
left join int4_tbl i4 on i4.f1 = 1
left join lateral (select i4.f1 + 1 as v) as ss on true
Hi,
+* Check that only the base rel is mentioned. (This should be dead code
+* now that add_missing_from is history.)
+*/
+ if (list_length(pstate->p_rtable) != 1)
If it is dead code, it can be removed, right ?
For statext_mcv_clauselist_selectivity:
+ // bms_fre
From: Osumi, Takamichi/大墨 昂道
> I updated my patch to take in those feedbacks !
> Have a look at the latest patch.
Looks good to me (the status remains ready for committer.)
Regards
Takayuki Tsunakawa
From: iwata@fujitsu.com
> This patch includes these items:
Is there anything else in this revision that is not handled?
Below are my comments.
Also, why don't you try running the regression tests with a temporary
modification to PQtrace() to output the trace to a file? The sole purpose is
On Sun, Jan 17, 2021 at 01:23:39AM +0100, Tomas Vondra wrote:
> diff --git a/doc/src/sgml/ref/create_statistics.sgml
> b/doc/src/sgml/ref/create_statistics.sgml
> index 4363be50c3..5b8eb8d248 100644
> --- a/doc/src/sgml/ref/create_statistics.sgml
> +++ b/doc/src/sgml/ref/create_statistics.sgml
> @
On Sun, Jan 17, 2021 at 3:52 AM Masahiko Sawada wrote:
>
> On Sat, Jan 16, 2021 at 12:28 PM Masahiko Sawada
> wrote:
> >
> > ---
> > + /* test for recovery pause if user has requested the pause */
> > + if (((volatile XLogCtlData *) XLogCtl)->recoveryPause)
> > + recoveryPa
On Wed, Jan 13, 2021 at 11:16 PM Peter Geoghegan wrote:
>
> On Mon, Jan 11, 2021 at 9:26 PM Peter Geoghegan wrote:
> > I'm going to proceed with committing the original version of the patch
> > -- I feel that this settles it.
>
> Pushed both patches from the patch series just now.
>
Nice work! I
On Thu, Jan 14, 2021 at 6:49 PM Yugo NAGATA wrote:
>
> On Wed, 13 Jan 2021 17:49:43 +0530
> Dilip Kumar wrote:
>
> > On Wed, Jan 13, 2021 at 3:35 PM Dilip Kumar wrote:
> > >
> > > On Wed, Jan 13, 2021 at 3:27 PM Yugo NAGATA wrote:
> > > >
> > > > On Thu, 10 Dec 2020 11:25:23 +0530
> > > > Dilip
On Sun, Jan 17, 2021 at 5:38 AM Tom Kincaid wrote:
>
> > > > I think that's not at all acceptable. I don't mind hashing out details
> > > > on calls / off-list, but the design needs to be public, documented, and
> > > > reviewable. And if it's something the community can't understand, then
> > >
Hi,
On 2021-01-17 11:54:57 +0530, Amit Kapila wrote:
> On Sun, Jan 17, 2021 at 5:38 AM Tom Kincaid wrote:
> > Admittedly I am a novice on this topic, and the majority of the
> > PostgreSQL source code, however I am hopeful enough (those of you who
> > know me understand that I suffer from eternal
Hello Tom,
04.01.2021 08:47, Tom Lane wrote:
> Hm. There isn't anything about test_regex()'s API that I would want
> to expose to end users ;-) ... it's just designed to replicate the
> test API that Henry Spencer designed a couple decades ago, which IMO
> was not too clean even by the standards o
On Sat, Jan 16, 2021 at 10:36 AM Bharath Rupireddy
wrote:
> > > Please consider the v9 patch set for further review.
> >
> > Thanks for updating the patch! I reviewed only 0001 patch.
I addressed the review comments and attached v10 patch set. Please
consider it for further review.
With Regards
44 matches
Mail list logo
