út 30. 3. 2021 v 8:52 odesílatel Julien Rouhaud napsal:
> On Tue, Mar 30, 2021 at 08:03:09AM +0200, Pavel Stehule wrote:
> >
> > On second hand, it can be very nice to have some special strict mode in
> > Postgres - maybe slower, not compatible, that disallow some dangerous or
> > unsafe queries.
On Tue, Mar 30, 2021 at 01:58:50AM +0300, Arseny Sher wrote:
> Intimate reading of lazy_scan_heap says that the failure indeed might
> happen; if ConditionalLockBufferForCleanup couldn't lock the buffer and
> either the buffer doesn't need freezing or vacuum is not aggressive, we
> don't insist on
On 2021/3/27, 10:23 PM, "Alvaro Herrera" wrote:
>Hmm, can you post a rebased set, where the points under discussion
> are marked in XXX comments explaining what the issue is? This thread is
>long and old ago that it's pretty hard to navigate the whole thing in
>order to find out ex
On Tue, Mar 30, 2021 at 09:02:39AM +0200, Pavel Stehule wrote:
> út 30. 3. 2021 v 8:52 odesílatel Julien Rouhaud napsal:
>
> > On Tue, Mar 30, 2021 at 08:03:09AM +0200, Pavel Stehule wrote:
> > >
> > > On second hand, it can be very nice to have some special strict mode in
> > > Postgres - maybe
út 30. 3. 2021 v 9:28 odesílatel Julien Rouhaud napsal:
> On Tue, Mar 30, 2021 at 09:02:39AM +0200, Pavel Stehule wrote:
> > út 30. 3. 2021 v 8:52 odesílatel Julien Rouhaud
> napsal:
> >
> > > On Tue, Mar 30, 2021 at 08:03:09AM +0200, Pavel Stehule wrote:
> > > >
> > > > On second hand, it can b
On Tue, Mar 30, 2021 at 5:30 PM Markus Wanner <
markus.wan...@enterprisedb.com> wrote:
> Hello Ajin,
>
> On 30.03.21 06:48, Ajin Cherian wrote:
> > For now, I've created a patch that addresses the problem reported using
> > the existing callbacks.
>
> Thanks.
>
> > Do have a look if this fixes the
On Tue, Mar 30, 2021, at 08:03, Pavel Stehule wrote:
> Maybe there were no technical problems. Just this technology was coming at a
> bad time. The people who needed (wanted) OOP access to data got the
> Hibernate, and there was no necessity to do this work on SQL level. In this
> time, there
On 30.03.21 09:39, Ajin Cherian wrote:
Where do you suggest this be documented? From an externally visible
point of view, I dont see much of a surprise.
If you start to think about the option of committing a prepared
transaction from a different node, the danger becomes immediately
apparent:
>
> I agree, it's not very comfortable. Maybe we can think of ways to improve
> the comfort?
>
> Here are two such ideas:
>
> Idea #1
> ===
>
> Initial semi-automated script-assisted renaming of existing foreign keys.
>
> In my experiences, multiple foreign keys per primary table is quite commo
At Tue, 30 Mar 2021 09:41:24 +0900, Masahiro Ikeda
wrote in
> I update the patch since there were my misunderstanding points.
>
> On 2021/03/26 16:20, Masahiro Ikeda wrote:
> > Thanks for many your suggestions!
> > I made the patch to handle the issues.
> >
> >> 1) What is the motivation to ha
On Tue, Mar 30, 2021 at 5:10 PM Tom Lane wrote:
>
> Peter Smith writes:
> > There are a couple of error messages within the logical replication
> > code where the errdetail text includes a prefix of "The error was:"
>
> Hmm, isn't project style more usually to include the error reason
> in the pr
On Mon, Mar 29, 2021 at 4:46 PM Markus Wanner
wrote:
>
> On 29.03.21 13:04, vignesh C wrote:
> > The above content looks sufficient to me.
>
> Good, thanks. Based on that, I'm adding v7 of the patch.
>
Pushed. In the last version, you have named the patch incorrectly.
--
With Regards,
Amit Kap
Hi All,
I recently used pg_sequence_last_value() when working on a feature in an
extension, and it would have been easier for me if there were some
documentation for this function.
I'd like to help document this function if there are no objections.
Best,
Hanefi
-Original Message-
From
On Tue, Mar 30, 2021, at 10:24, Pavel Stehule wrote:
>
>>
>> I think this is a good example of where this improves the situation the most,
>> when you have multiple joins of the same table, forcing you to come up with
>> multiple aliases
>> for the same table, keeping them all in memory while wr
Hi,
The logical replication tablesync worker creates tablesync slots.
Previously some PG docs pages were referring to these as "tablesync
slots", but other pages called them as "table synchronization slots".
PSA a trivial patch which (for consistency) now calls them all the
same - "tablesync sl
út 30. 3. 2021 v 10:49 odesílatel Joel Jacobson napsal:
> On Tue, Mar 30, 2021, at 10:24, Pavel Stehule wrote:
>
>
>
> I think this is a good example of where this improves the situation the
> most,
> when you have multiple joins of the same table, forcing you to come up
> with multiple aliases
>
On Tue, Mar 30, 2021 at 12:00 PM Markus Wanner
wrote:
>
> Hello Ajin,
>
> On 30.03.21 06:48, Ajin Cherian wrote:
> > For now, I've created a patch that addresses the problem reported using
> > the existing callbacks.
>
> Thanks.
>
> > Do have a look if this fixes the problem reported.
>
> Yes, thi
On Tue, Mar 30, 2021 at 7:10 PM Markus Wanner <
markus.wan...@enterprisedb.com> wrote:
> On 30.03.21 09:39, Ajin Cherian wrote:
> > Where do you suggest this be documented? From an externally visible
> > point of view, I dont see much of a surprise.
>
>
>
> So I suggest to document this as a cavea
On Tue, Mar 30, 2021 at 2:21 PM Peter Smith wrote:
>
> Hi,
>
> The logical replication tablesync worker creates tablesync slots.
>
> Previously some PG docs pages were referring to these as "tablesync
> slots", but other pages called them as "table synchronization slots".
>
> PSA a trivial patch w
On 24.03.21 11:52, houzj.f...@fujitsu.com wrote:
+ if (!has_nonconst_input)
+ return ece_evaluate_expr(expr);
That's not okay without a further check to see if the comparison function used
by the node is immutable. Compare Scal
On Tue, Mar 30, 2021, at 10:24, Pavel Stehule wrote:
> For our example data model, this would produce:
>>
>> ALTER TABLE public.orders RENAME CONSTRAINT orders_customer_id_fkey TO
>> customers;
>> ALTER TABLE public.order_details RENAME CONSTRAINT
>> order_details_order_id_fkey TO orders;
>> ALT
On Tue, Mar 30, 2021, at 11:21, Joel Jacobson wrote:
> On Tue, Mar 30, 2021, at 10:24, Pavel Stehule wrote:
>> For our example data model, this would produce:
>>>
>>> ALTER TABLE public.orders RENAME CONSTRAINT orders_customer_id_fkey TO
>>> customers;
>>> ALTER TABLE public.order_details RENAME
On Tue, Mar 30, 2021 at 2:44 PM Amit Kapila wrote:
>
> On Tue, Mar 30, 2021 at 2:21 PM Peter Smith wrote:
> >
> > Hi,
> >
> > The logical replication tablesync worker creates tablesync slots.
> >
> > Previously some PG docs pages were referring to these as "tablesync
> > slots", but other pages c
> This patch has not gotten any review in the last two CFs and is unlikely
> to be committed for PG14 so I have moved it to the 2021-07 CF. A rebase
> is also required so marked Waiting for Author.
>
> I can see this is a work in progress, but you may want to consider the
> several suggestions th
On 30.03.21 10:33, Amit Kapila wrote:
Pushed. In the last version, you have named the patch incorrectly.
Thanks a lot, Amit!
Regards
Markus
Hi,
Noticed that an extra semicolon in a couple of test cases related to
postgres_fdw. Removed that in the attached patch. It can be backported till
v11 where we added those test cases.
--
--
Thanks & Regards,
Suraj kharage,
edbpostgres.com
remove_extra_semicolon_postgres_fdw.patch
Descrip
On Tue, Mar 30, 2021 at 03:50:28PM +0900, Michael Paquier wrote:
> The test_*() ones are just wrappers for psql able to use a customized
> connection string. It seems to me that it would make sense to move
> those two into PostgresNode::psql itself and extend it to be able to
> handle custom conne
On 30.03.21 11:02, Amit Kapila wrote:
On Tue, Mar 30, 2021 at 12:00 PM Markus Wanner
Yes, this replaces the PREPARE I would do from the concurrent_abort
callback in a direct call to rb->prepare.
Because concurrent_abort()
internally trying to prepare transaction seems a bit ugly and not only
t
On Mon, 22 Mar 2021 at 13:43, Dean Rasheed wrote:
>
> On Sun, 14 Mar 2021 at 16:08, Fabien COELHO wrote:
> >
> > > My main question on this now is, do you have a scholar reference for
> > > this algorithm?
> >
> > Nope, otherwise I would have put a reference. I'm a scholar though, if
> > it helps
Hi,
While running some sanity checks on the regression tests, I found one test that
returns different results depending on whether an index or a sequential scan is
used.
Minimal reproducer:
=# CREATE TABLE point_tbl AS select '(nan,nan)'::point f1;
=# CREATE INDEX ON point_tbl USING gist(f1);
=
On Tue, Mar 30, 2021 at 3:21 PM Suraj Kharage
wrote:
>
> Hi,
>
> Noticed that an extra semicolon in a couple of test cases related to
> postgres_fdw. Removed that in the attached patch. It can be backported till
> v11 where we added those test cases.
+1 for the change. It looks like a typo and
On Mon, Mar 29, 2021 at 6:47 PM Euler Taveira wrote:
>
Few comments:
==
1. How can we specify row filters for multiple tables for a
publication? Consider a case as below:
postgres=# CREATE TABLE tab_rowfilter_1 (a int primary key, b text);
CREATE TABLE
postgres=# CREATE TABLE tab_rowfi
On 30.03.21 11:12, Ajin Cherian wrote:
I found some documentation that already was talking about concurrent
aborts and updated that.
Thanks.
I just noticed as of PG13, concurrent_abort is part of ReorderBufferTXN,
so it seems the prepare_cb (or stream_prepare_cb) can actually figure a
concur
On Tue, Mar 30, 2021 at 4:50 PM Bharath Rupireddy
wrote:
>
> On Tue, Mar 30, 2021 at 3:21 PM Suraj Kharage
> wrote:
> >
> > Hi,
> >
> > Noticed that an extra semicolon in a couple of test cases related to
> > postgres_fdw. Removed that in the attached patch. It can be backported till
> > v11 wh
On 30.03.21 11:54, Markus Wanner wrote:
I would recommend this more explicit API and communication over hiding
the concurrent abort in a prepare callback.
I figured we already have the ReorderBufferTXN's concurrent_abort flag,
thus I agree the prepare_cb is sufficient and revoke this recommend
On 2021/03/30 17:28, Kyotaro Horiguchi wrote:
> At Tue, 30 Mar 2021 09:41:24 +0900, Masahiro Ikeda
> wrote in
>> I update the patch since there were my misunderstanding points.
>>
>> On 2021/03/26 16:20, Masahiro Ikeda wrote:
>>> Thanks for many your suggestions!
>>> I made the patch to handle
Hi,
I just noticed that the comment for CreateStmt.inhRelations says that it's a
List of inhRelation, which hasn't been the case for a very long time.
Trivial patch attached.
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index 12e0e026dc..334262b1dd 100644
--- a/src
On Tue, 2021-03-30 at 17:57 +0800, Julien Rouhaud wrote:
> While running some sanity checks on the regression tests, I found one test
> that
> returns different results depending on whether an index or a sequential scan
> is
> used.
>
> Minimal reproducer:
>
> =# CREATE TABLE point_tbl AS selec
On Tue, Mar 30, 2021 at 02:47:05PM +0200, Laurenz Albe wrote:
> On Tue, 2021-03-30 at 17:57 +0800, Julien Rouhaud wrote:
> >
> > Getting a consistent behavior shouldn't be hard, but I'm unsure which
> > behavior
> > is actually correct.
>
> I'd say that this is certainly wrong:
>
> SELECT point
On 2021-03-30 02:28, Fujii Masao wrote:
Thanks for reviewing and kind suggestions!
It adds pg_log_backend_memory_contexts(pid) which logs memory contexts
of the specified backend process.
The number of child contexts to be logged per parent is limited to 100
as with MemoryContextStats().
As w
On 3/30/21 10:12 AM, Michael Paquier wrote:
> Yep, this is the same problem as the one discussed for c2dc1a7, where
> a concurrent checkpoint may cause a page to be skipped, breaking the
> test.
Indeed, Alexander Lakhin pointed me to that commit after I wrote the
message.
> Why not just using
On 3/30/21 5:53 AM, Michael Paquier wrote:
> On Tue, Mar 30, 2021 at 03:50:28PM +0900, Michael Paquier wrote:
>> The test_*() ones are just wrappers for psql able to use a customized
>> connection string. It seems to me that it would make sense to move
>> those two into PostgresNode::psql itself
Hi Alvaro san, Tsunakawa san
Thank you for creating the v30 patch.
> From: Tsunakawa, Takayuki/綱川 貴之
> Sent: Monday, March 29, 2021 9:45 AM
...
> Iwata-san,
> Please review Alvaro-san's code, and I think you can integrate all patches
> into
> one except for 0002 and 0007. Those two patches may
Robert Haas writes:
> On Wed, Mar 24, 2021 at 2:15 PM Tom Lane wrote:
>> But let's ignore the case of pg_upgrade and just consider a dump/restore.
>> I'd still say that unless you give --no-toast-compression then I would
>> expect the dump/restore to preserve the tables' old compression behavior.
Hi,
While reading the documentation for DROP INDEX[1], I noticed the lock was
described colloquially as an "exclusive" lock, which made me pause for a
second because it's the same name as the EXCLUSIVE table lock.
The attached patch explicitly states that an ACCESS EXCLUSIVE lock is
acquired.
[1
On Sat, 27 Mar 2021 at 16:28, Joel Jacobson wrote:
> Hi,
>
> The database Neo4j has a language called "Cypher" where one of the key
> selling points is they "don’t need join tables".
>
> Here is an example from
> https://neo4j.com/developer/cypher/guide-sql-to-cypher/
>
> SQL:
>
> SELECT DISTINCT
Julien Rouhaud writes:
> On Tue, Mar 30, 2021 at 02:47:05PM +0200, Laurenz Albe wrote:
>> I'd say that this is certainly wrong:
>> SELECT point('NaN','NaN') <@ polygon('(0,0),(1,0),(1,1),(0,0)');
>>
>> ?column?
>> --
>> t
>> (1 row)
> Yeah that's what I think too, but I wanted to have
On 2021-Mar-30, Michael Paquier wrote:
> On Tue, Mar 30, 2021 at 03:50:28PM +0900, Michael Paquier wrote:
> > The test_*() ones are just wrappers for psql able to use a customized
> > connection string. It seems to me that it would make sense to move
> > those two into PostgresNode::psql itself a
On Tue, Mar 30, 2021 at 11:02:32AM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Tue, Mar 30, 2021 at 02:47:05PM +0200, Laurenz Albe wrote:
> >> I'd say that this is certainly wrong:
> >> SELECT point('NaN','NaN') <@ polygon('(0,0),(1,0),(1,1),(0,0)');
> >>
> >> ?column?
> >> --
On 3/30/21 4:09 AM, Tomas Vondra wrote:
> Hi,
>
> ...
>
> We may need to "sync" the counts for individual relations in a couple
> places (e.g. after the worker is done with the leaf, it should propagate
> the remaining delta before resetting the values to 0). Maybe multi-level
> partitioning n
Hi,
Am Montag, den 29.03.2021, 17:59 + schrieb Cary Huang:
> I have tried the patch and the new option is able to control the
> contents of pg_dump outputs to include only create db related
> commands.
Thanks for testing!
> I also agree that the option name is a little misleading to the use
Currently, when the origin is after the input, the result is the timestamp
at the end of the bin, rather than the beginning as expected. The attached
puts the result consistently at the beginning of the bin.
--
John Naylor
EDB: http://www.enterprisedb.com
rationalize-future-origin.patch
Descript
Hi,
In paraminfo_get_equal_hashops(),
+ /* Reject if there are any volatile functions */
+ if (contain_volatile_functions(expr))
+ {
You can move the above code to just ahead of:
+ if (IsA(expr, Var))
+ var_relids = bms_make_singleton(((Var *) expr)->varno);
Th
On Sat, Mar 27, 2021 at 1:06 PM Justin Pryzby wrote:
>
> The current docs seem to be missing a "synopsis", like
>
> +
> +date_trunc(stride,
timestamp, origin)
> +
The attached
- adds a synopsis
- adds a bit more description to the parameters similar to those in
date_trunc
- documents that negativ
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Michael Paquier (mich...@paquier.xyz) wrote:
> > > On Mon, Mar 22, 2021 at 04:07:12PM -0400, Robert Haas wrote:
> > > > On Mon, Mar 22, 2021 at 1:48 PM Stephen Frost
> > > > wrote:
> > > >>
> On 2021.03.27. 02:12 Nikita Glukhov wrote:
>
> Attached 47th version of the patches.
>
[..]
>
> I have added forgotten files and fixed the first patch.
>
> [0001-SQL-JSON-functions-v47.patch]
> [0002-JSON_TABLE-v47.patch]
> [0003-JSON_TABLE-PLAN-DEFAULT-clause-v47.patch]
> [0004-JSON_TABLE-P
On Tue, 2021-03-30 at 09:55 +0900, Michael Paquier wrote:
> On Mon, Mar 29, 2021 at 11:53:03PM +, Jacob Champion wrote:
> > It's not a matter of the tests being stable, but of the tests needing
> > to change and evolve as the implementation changes. A big part of that
> > is visibility into wha
On 2021/03/26 22:14, David Steele wrote:
On 3/25/21 9:23 PM, Fujii Masao wrote:
On 2021/03/25 23:21, David Steele wrote:
On 1/25/21 3:55 AM, Laurenz Albe wrote:
On Mon, 2021-01-25 at 08:19 +, osumi.takami...@fujitsu.com wrote:
I think you should pst another patch where the second, now
Andrew,
While developing some cross version tests, I noticed that PostgresNode::init
fails for postgres versions older than 9.3, like so:
# Checking port 52814
# Found port 52814
Name: 9.2.24
Data directory:
/Users/mark.dilger/hydra/postgresnode.review/src/test/modules/test_cross_version/tmp_ch
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
All the tests passed successfully.
The new status of this patch is:
On Tue, Mar 30, 2021, at 16:25, Rod Taylor wrote:
> On Sat, 27 Mar 2021 at 16:28, Joel Jacobson wrote:
>> __Imagine if we could simply write the SQL query like this:
>>
>> SELECT DISTINCT od.order_id.customer_id.company_name
>> FROM order_details AS od
>> WHERE od.product_id.product_name = 'Choco
Surafel Temesgen wrote:
> > About intervals, if there were locale-aware functions like
> > add_interval(timestamptz, interval [, locale]) returns timestamptz
> > or
> > sub_timestamp(timestamptz, timestamptz [,locale]) returns interval
> > that would use ICU to compute the results accord
Hello Dean,
Thanks a lot for this work. This version looks much better than the
previous one you sent, and has significant advantages over the one I sent,
in particular avoiding the prime number stuff and large modular multiply.
So this looks good!
I'm happy that halves-xoring is back becau
On Mon, Mar 29, 2021, at 16:17, Vik Fearing wrote:
> SELECT DISTINCT order_details."order"->customer->company_name
> FROM order_details
> WHERE order_details.product->product_name = 'Chocolade';
I like the idea of using -> instead of . (dot),
since name resolution is already complicated,
so overlo
I wrote:
> I've not made any attempt to do performance testing on this,
> but I think that's about the only thing standing between us
> and committing this thing.
I think the main gating condition for committing this is "does it
make things worse for simple non-partitioned updates?". The need
for
I wrote:
> ... I also tried variants
> of that involving updating two columns of a 6-column table and of a
> 10-column table, figuring that those cases might be a bit more
> representative of typical usage (see attached scripts).
Argh, I managed to attach the wrong file for the 10-column test
case
отбой: Маша сказала: уже оплатили :)
вт 30.03.21 20:44, Maxim Orlov пишет:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:no
On Tue, 30 Mar 2021 at 14:30, Joel Jacobson wrote:
If the expression ends with a column_name,
> you get the value for the column.
>
> If the expression ends with a constraint_name,
> you get the referenced table as a record.
>
Can’t you just leave off the “ends with a column_name” part? If you w
Hi Tang,
Thanks a lot for the patch.
I did a quick test based on the latest patch V3 on latest master branch
"commit 4753ef37e0eda4ba0af614022d18fcbc5a946cc9".
Case 1: before patch
1 postgres=# set a
2 all allow_system_table_mods
application_name array_nulls
On 12/15/20 5:13 PM, Bruce Momjian wrote:
On Wed, Dec 9, 2020 at 09:48:54PM +0100, Peter Eisentraut wrote:
On 2020-12-03 20:26, Peter Eisentraut wrote:
> On 2020-12-03 16:34, Tom Lane wrote:
> > As I recall, a whole lot of the pain we have with INTO has to do
> > with the semantics we've chosen
Hi,
Some catalog oid values originate from other catalogs,
such as pg_aggregate.aggfnoid -> pg_proc.oid
or pg_attribute.attrelid -> pg_class.oid.
For such oid values, the foreign catalog is the regclass
which should be passed as the first argument to
all the functions taking (classid oid, objid o
On Tue, 30 Mar 2021 at 19:26, Fabien COELHO wrote:
>
> First, I have a thing against erand48.
Yeah, that's probably a fair point. However, all the existing pgbench
random functions are using it, so I think it's fair enough for
permute() to do the same (and actually 2^48 is pretty huge). Switching
On Tue, Mar 30, 2021, at 21:02, Isaac Morland wrote:
> On Tue, 30 Mar 2021 at 14:30, Joel Jacobson wrote:
>
>> __
>> If the expression ends with a column_name,
>> you get the value for the column.
>>
>> If the expression ends with a constraint_name,
>> you get the referenced table as a record.
>
On 2021/03/30 22:06, torikoshia wrote:
Modified the patch according to the suggestions.
Thanks for updating the patch!
I applied the cosmetic changes to the patch and added the example of
the function call into the document. Attached is the updated version
of the patch. Could you check this
On 3/21/21 12:27 PM, Tom Lane wrote:
I think we may have to adjust the acl.c APIs, or maybe better provide new
entry points, so that we can have variants of pg_xxx_aclcheck that won't
throw a hard error upon not finding the row. We cheesily tried to avoid
adjusting those APIs to support the sema
On Tue, 30 Mar 2021 at 20:31, Dean Rasheed wrote:
>
> Yeah, that's probably a fair point. However, all the existing pgbench
> random functions are using it, so I think it's fair enough for
> permute() to do the same (and actually 2^48 is pretty huge). Switching
> to a 64-bit PRNG might not be a ba
On Mon, Mar 29, 2021 at 7:16 PM Mark Dilger
wrote:
> Sure, here are four patches which do the same as the single v12 patch did.
Thanks. Here are some comments on 0003 and 0004:
When you posted v11, you said that "Rather than print out all four
toast pointer fields for each toast failure, va_raws
On Tue, 30 Mar 2021 at 15:33, Joel Jacobson wrote:
> Also, should the join be a left join, which would therefore return a NULL
> when there is no matching record? Or could we have a variation such as ->?
> to give a left join (NULL when no matching record) with -> using an inner
> join (record is
Joe Conway writes:
> On 3/21/21 12:27 PM, Tom Lane wrote:
>> I think we may have to adjust the acl.c APIs, or maybe better provide new
>> entry points, so that we can have variants of pg_xxx_aclcheck that won't
>> throw a hard error upon not finding the row. We cheesily tried to avoid
>> adjustin
On 3/30/21 3:37 PM, Joe Conway wrote:
On 3/21/21 12:27 PM, Tom Lane wrote:
I think we may have to adjust the acl.c APIs, or maybe better provide new
entry points, so that we can have variants of pg_xxx_aclcheck that won't
throw a hard error upon not finding the row. We cheesily tried to avoid
a
On 30.03.2021 19:56, Erik Rijkers wrote:
On 2021.03.27. 02:12 Nikita Glukhov wrote:
Attached 47th version of the patches.
Hi,
Apply, build all fine. It also works quite well, and according to
specification, as far as I can tell.
But today I ran into:
ERROR: function ExecEvalJson not in
On Thu, Mar 4, 2021 at 3:29 PM Kyotaro Horiguchi
wrote:
> A recent commot about LSN_FORMAT_ARGS conflicted this.
> Just rebased.
FYI I've been looking at this, and I think it's a very nice
improvement. I'll post some review comments and a rebase shortly.
Hello all,
We just upgraded from postgres 11 to 12.6 and our server is running
out of memory and rebooting about 1-2 times a day.Application
architecture is a single threaded stored procedure, executed with CALL
that loops and never terminates. With postgres 11 we had no memory
issues. Ultima
> On Mar 30, 2021, at 10:39 AM, Mark Dilger
> wrote:
>
> Andrew,
>
> While developing some cross version tests, I noticed that PostgresNode::init
> fails for postgres versions older than 9.3, like so:
>
> # Checking port 52814
> # Found port 52814
> Name: 9.2.24
> Data directory:
> /Users/
I've built Postgres inside a Ubuntu Vagrant VM. When I try to "make check",
I get a complaint about the permissions on the data directory:
[]
pg_regress: initdb failed
Examine /vagrant/src/test/regress/log/initdb.log for the reason.
Command was: "initdb" -D "/vagrant/src/test/regress/./tmp_che
> On 2021.03.30. 22:25 Nikita Glukhov wrote:
>
>
> On 30.03.2021 19:56, Erik Rijkers wrote:
>
> >> On 2021.03.27. 02:12 Nikita Glukhov wrote:
> >>
> >> Attached 47th version of the patches.
> > Hi,
> >
> > Apply, build all fine. It also works quite well, and according to
> > specification
> On 30 Mar 2021, at 11:53, Michael Paquier wrote:
>
> On Tue, Mar 30, 2021 at 03:50:28PM +0900, Michael Paquier wrote:
>> The test_*() ones are just wrappers for psql able to use a customized
>> connection string. It seems to me that it would make sense to move
>> those two into PostgresNode::p
On 2021-Mar-30, Mark Dilger wrote:
> The problem is clear enough; -N/--nosync was added in 9.3, and
> PostgresNode::init is passing -N to initdb unconditionally. I wonder
> if during PostgresNode::new a call should be made to pg_config and the
> version information grep'd out so that version speci
I wrote:
> However, I then tried a partitioned equivalent of the 6-column case
> (script also attached), and it looks like
> 6 columns 16551 19097 15637 18201
> which is really noticeably worse, 16% or so.
... and on the third hand, that might just be some weird compiler-
and platform-sp
On 2021-Mar-30, Daniel Gustafsson wrote:
> +$node->connect_ok($common_connstr . " " . "user=ssltestuser",
>
> This double concatenation could be a single concat, or just use scalar value
> interpolation in the string to make it even more readable. As it isn't using
> the same line broken pattern
> On Mar 30, 2021, at 3:12 PM, Alvaro Herrera wrote:
>
> On 2021-Mar-30, Mark Dilger wrote:
>
>> The problem is clear enough; -N/--nosync was added in 9.3, and
>> PostgresNode::init is passing -N to initdb unconditionally. I wonder
>> if during PostgresNode::new a call should be made to pg_co
On 2021-Mar-30, Mark Dilger wrote:
> Once you have a node running, you can query the version using
> safe_psql, but that clearly doesn't work soon enough, since we need
> the information prior to running initdb.
I was thinking something like examining some file in the install dir --
say, include/
Joe Conway writes:
> Heh, I missed the forest for the trees it seems.
> That version undid the changes fixing what Ian was originally complaining
> about.
Duh, right. It would be a good idea for there to be a code comment
explaining this, because it's *far* from obvious. Say like
* Ch
Isaac Morland writes:
> I've built Postgres inside a Ubuntu Vagrant VM. When I try to "make check",
> I get a complaint about the permissions on the data directory:
> vagrant@ubuntu-focal:/vagrant$ tail /vagrant/src/test/regress/log/initdb.log
> creating subdirectories ... ok
> selecting dynamic
On Tue, Mar 30, 2021, at 22:01, Isaac Morland wrote:
> On Tue, 30 Mar 2021 at 15:33, Joel Jacobson wrote:
>>> Also, should the join be a left join, which would therefore return a NULL
>>> when there is no matching record? Or could we have a variation such as ->?
>>> to give a left join (NULL whe
On Tue, 2021-03-30 at 17:06 +, Jacob Champion wrote:
> Would it be acceptable to adjust the tests for live rotation using the
> logging collector, rather than a full restart? It would unfortunately
> mean that we have to somehow wait for the rotation to complete, since
> that's asynchronous.
I
Hackers,
Over on [1] I've been working on adding a new type of executor node
which caches tuples in a hash table belonging to a given cache key.
The current sole use of this node type is to go between a
parameterized nested loop and the inner node in order to cache
previously seen sets of paramet
Hi,
I was reading this part of the description:
the Result Cache's
hash table is much smaller than the hash join's due to result cache only
caching useful values rather than all tuples from the inner side of the
join.
I think the word 'Result' should be part of the cache name considering the
abov
On Tue, Mar 30, 2021 at 04:17:03PM -0500, Merlin Moncure wrote:
> Hello all,
>
> We just upgraded from postgres 11 to 12.6 and our server is running
> out of memory and rebooting about 1-2 times a day.Application
> architecture is a single threaded stored procedure, executed with CALL
> that l
Okay, pushed this patch and the new testing for it based on
libpq_pipeline. We'll see how the buildfarm likes it.
I made some further changes to the last version; user-visibly, I split
the trace flags in two, keeping the timestamp suppression separate from
the redacting feature for regression tes
1 - 100 of 168 matches
Mail list logo
