nge. But if there is interest
in improving these commands I will be pleased to do that, with the
syntax suggested.
Best regards,
--
Gilles Darold
diff --git a/doc/src/sgml/ref/vacuumdb.sgml b/doc/src/sgml/ref/vacuumdb.sgml
index 956c0f01cb..e4f6d32ba9 100644
--- a/doc/src/sgml/ref/vacuumdb.sgm
Le 04/03/2022 à 11:56, Justin Pryzby a écrit :
On Fri, Mar 04, 2022 at 10:11:28AM +0100, Gilles Darold wrote:
The attached patch implements that. Option -n | --schema can be used
multiple time and can not be used together with options -a or -t.
Yes, thanks.
I suggest there should also be an
Le 04/03/2022 à 11:56, Justin Pryzby a écrit :
> On Fri, Mar 04, 2022 at 10:11:28AM +0100, Gilles Darold wrote:
>> The attached patch implements that. Option -n | --schema can be used
>> multiple time and can not be used together with options -a or -t.
> Yes, thanks.
>
>
Le 06/03/2022 à 16:04, Justin Pryzby a écrit :
> On Sun, Mar 06, 2022 at 09:39:37AM +0100, Gilles Darold wrote:
>> Attached a new patch version that adds the -N | --exclude-schema option
>> to the vacuumdb command as suggested. Documentation updated too.
>>
>> +
Hi,
New version v4 of the patch to fix a typo in a comment.
--
Gilles Darold
diff --git a/doc/src/sgml/ref/vacuumdb.sgml b/doc/src/sgml/ref/vacuumdb.sgml
index 956c0f01cb..378328afb3 100644
--- a/doc/src/sgml/ref/vacuumdb.sgml
+++ b/doc/src/sgml/ref/vacuumdb.sgml
@@ -39,6 +39,40 @@ PostgreSQL
Le 09/03/2022 à 22:10, Justin Pryzby a écrit :
> On Mon, Mar 07, 2022 at 08:38:04AM +0100, Gilles Darold wrote:
>>> Maybe it's clearer to write this with =ANY() / != ALL() ?
>>> See 002.
>> I have applied your changes and produced a new version v3 of the patch,
>
to Commitfest 2021-01.
Best regards
[1]
https://www.postgresql-archive.org/Issue-with-server-side-statement-level-rollback-td6162387.html
[2]
https://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1F6A9286%40G01JPEXMBYT05
[3] https://github.com/darold/pg_statement_rollbackv2
h some foreign
keys. There is no explicit FOR SHARE on the queries, only some FOR
UPDATE clauses. I guess that the multixact contention is the result of
the for share locks produced for FK.
So in our case being able to tune the multixact buffers could help a lot
to improve the performances.
--
Gilles Darold
test triggers ... FAILED
test inherit ...
^C
This is also where I left my last try to back port for PG11, I will try
to fix it again but it could take time to have it working.
Best regards,
--
Gilles Darold
Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
H
Le 09/12/2020 à 11:51, Gilles Darold a écrit :
Also PG regression tests are failing too on several part.
Forget this, I have not run the regression tests in the right repository:
...
===
All 189 tests passed.
===
I'm looking why the applicati
Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
Hi Gilles!
Many thanks for your message!
8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable reproduction exists.
I've rebased patche
Le 10/12/2020 à 15:45, Gilles Darold a écrit :
Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
Hi Gilles!
Many thanks for your message!
8 дек. 2020 г., в 21:05, Gilles Darold написал(а):
I know that this report is not really helpful
Quite contrary - this benchmarks prove that controllable
Le 11/12/2020 à 18:50, Gilles Darold a écrit :
> Le 10/12/2020 à 15:45, Gilles Darold a écrit :
>> Le 08/12/2020 à 18:52, Andrey Borodin a écrit :
>>> Hi Gilles!
>>>
>>> Many thanks for your message!
>>>
>>>> 8 дек. 2020 г., в 21:05, Gilles
dy for
committers review as it fixes the bug reported.
--
Gilles Darold
LzLabs GmbH
https://www.lzlabs.com/
diff --git a/src/backend/catalog/pg_proc.c b/src/backend/catalog/pg_proc.c
index 1dd9ecc063..9b305896a3 100644
--- a/src/backend/catalog/pg_proc.c
+++ b/src/backend/catalog/pg_proc.c
@
Le 18/12/2020 à 00:26, Tom Lane a écrit :
Gilles Darold writes:
The same problem applies if the returned type or the procedural language
is dropped. I have tried to fix that in ProcedureCreate() by using an
AccessSharedLock for the data types and languages involved in the
function declaration
Le 13/12/2020 à 18:24, Andrey Borodin a écrit :
13 дек. 2020 г., в 14:17, Gilles Darold написал(а):
I've done more review on these patches.
Thanks, Gilles! I'll incorporate all your fixes to patchset.
Can you also benchmark conditional variable sleep? The patch "Add condition
t1 WHERE regexp_like(col1, '^d$', 'm');
to obtain a PostgreSQL equivalent:
SELECT * FROM t1 WHERE regexp_match (col1, '^d$', 'm' ) IS
NOT NULL;
There is also a possible extension to regexp_replace() that I have not
implemented yet bec
My apologies for the links in the head, the email formatting and the
missing patch, I accidently send the email too early.
--
Gilles
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index bf99f82149..88e08b40d2 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -3097
to return all start/end positions of an occurrence chained
in an integer array {start1,end1,start2,end2,..}.
Regards,
--
Gilles Darold
Le 15/02/2021 à 18:17, Andrey Borodin a écrit :
23 дек. 2020 г., в 21:31, Gilles Darold написал(а):
Sorry for the response delay, we have run several others tests trying to figure
out the performances gain per patch but unfortunately we have very heratic
results. With the same parameters
Le 12/03/2021 à 13:44, Andrey Borodin a écrit :
>
>> 11 марта 2021 г., в 20:50, Gilles Darold написал(а):
>>
>>
>> The patch doesn't apply anymore in master cause of error: patch failed:
>> src/backend/utils/init/globals.c:150
>>
>>
>>
ble to make the assert happy but I don't think so.
Cheers
--
Gilles Darold
Hi,
Le 19/11/2020 à 21:43, Andres Freund a écrit :
Hi,
On 2020-11-12 11:40:22 +0100, Gilles Darold wrote:
The problem we are encountering is when PostgreSQL is compiled in debug
mode with --enable-cassert. At line 1327 of src/backend/tcop/pquery.c
the following assert fail
Le 20/11/2020 à 16:18, Gilles Darold a écrit :
> I will work later on a POC to demonstrate the use case I want to
> implement.
Hi Andres,
I have created a new version of the pg_statement_rollback extension [1]
to demonstrate the use of the hooks on start_xact_command(),
finish_xact_c
Le 15/12/2021 à 13:41, Peter Eisentraut a écrit :
On 03.08.21 19:10, Tom Lane wrote:
Gilles Darold writes:
Sorry I have missed that, but I'm fine with this implemenation so let's
keep the v6 version of the patch and drop this one.
Pushed, then. There's still lots of ti
Le 12/03/2021 à 06:55, Julien Rouhaud a écrit :
> Hi,
>
> On Tue, Dec 08, 2020 at 11:15:12AM +0100, Gilles Darold wrote:
>> Based on a PoC reported in a previous thread [1] I'd like to propose new
>> hooks around transaction commands. The objective of this patch is to
>
#FUNCTIONS-POSIX-REGEXP
[2]
https://www.postgresql.org/message-id/flat/bfd5-909d-408b-8531-95b32f18d4ab%40www.fastmail.com#3ec8ba658eeabcae2ac6ccca33bd1aed
--
Gilles Darold
LzLabs GmbH
http://www.lzlabs.com/
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index fee0561961
Le 20/03/2021 à 19:48, Gilles Darold a écrit :
>
> Hi,
>
>
> This is a new version of the patch that now implements all the XQUERY
> regexp functions as described in the standard, minus the differences
> of PostgerSQL regular expression explain in [1].
>
>
> The s
Le 21/03/2021 à 12:07, e...@xs4all.nl a écrit :
>> On 2021.03.20. 19:48 Gilles Darold wrote:
>>
>> This is a new version of the patch that now implements all the XQUERY
>> regexp functions as described in the standard, minus the differences of
>> PostgerSQL re
eSQL behavior with regexp, the one
used by regex_replace() and regex_matches(). All regexp modifiers can be
used.
[1] https://github.com/orafce/orafce/blob/master/orafce--3.14--3.15.sql
--
Gilles Darold
http://www.darold.net/
Le 21/03/2021 à 15:53, Tom Lane a écrit :
> Chapman Flack writes:
>> If this turns out to be a case of "attached the wrong patch, here's
>> the one that does implement foo_regex functions!" then I reserve an
>> objection to that. :)
>>
And the patch renamed.
diff --git a/doc/src/sgml/func.sgml b
ss that
the modification should be applied to pg_foreign_data_wrapper_aclmask()
and pg_foreign_server_aclmask() too.
Best regards,
--
Gilles Darold
Le 28/08/2020 à 16:52, Stephen Frost a écrit :
Greetings,
* Gilles Darold (gil...@darold.net) wrote:
Le 28/08/2020 à 15:26, Stephen Frost a écrit :
* Magnus Hagander (mag...@hagander.net) wrote:
On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net
o it can
be used in some PostgreSQL forks if one is interested by this feature.
--
Gilles Darold
hrough an extension was
possible I would not write a patch to core but an extension, this is my
common behavior.
Best regards,
--
Gilles Darold
http://www.darold.net/
umn list. We can add such filter in psql but
how about other clients? They all have to implement their own filtering
method. I think the HIDDEN attribute provide a common and basic way to
implement that in all client application.
--
Gilles Darold
http://www.darold.net/
Le 14/10/2021 à 17:38, Jaime Casanova a écrit :
On Thu, Oct 14, 2021 at 01:16:45PM +0200, Gilles Darold wrote:
Hi,
Here is a proposal to implement HIDDEN columns feature in PostgreSQL.
Great! Actually I found this very useful, especially for those people
using big fields (geometry, files
ea; but our policy is that the only point of having the
information_schema views at all is if they're standard-compliant.
Ok, I will remove it.
--
Gilles Darold
(2 rows)
gilles=# SELECT row_to_json(t) FROM htest0 t;
row_to_json
--
{"a":1,"b":"htest0 one"}
{"a":2,"b":"htest0 two"}
(2 rows)
You should have a look at the patch, I don't think that the way it is
done there could have gotchas.
--
Gilles Darold
tly set.
This feature is known like this and I'm not in favor to tear off a leg.
--
Gilles Darold
Le 14/10/2021 à 20:55, Gilles Darold a écrit :
gilles=# SELECT row_to_json(t.*) FROM htest0 t;
row_to_json
--
{"a":1,"b":"htest0 one"}
{"a":2,"b":"htest0 two"}
(2 rows)
gill
Le 14/10/2021 à 22:01, Gavin Flower a écrit :
> On 15/10/21 07:01, Josef Šimánek wrote:
>> čt 14. 10. 2021 v 13:17 odesílatel Gilles Darold
>> napsal:
>>> Hi,
>>>
>>>
>>> Here is a proposal to implement HIDDEN columns feature in PostgreSQL.
>
using the wildcard. Also as Vik or
Dave mention being able to hide all tsvector columns from query without
having to specify it as exception in each query used can save some time.
IMHO this is definitively not the same feature.
--
Gilles Darold
ething I will never said, even if this is a bad practice so I have
to find a solution to avoid showing technical columns. If we really want
SELECT * to be reserved to DBA then why not removing the star from PG
unless you have the admin privilege?
--
Gilles Darold
we must
handle the case.
--
Gilles Darold
Le 15/10/2021 à 21:52, Andrew Dunstan a écrit :
On 10/15/21 2:51 PM, Bruce Momjian wrote:
On Fri, Oct 15, 2021 at 11:32:53AM +0200, Laurenz Albe wrote:
On Thu, 2021-10-14 at 13:16 +0200, Gilles Darold wrote:
Here is a proposal to implement HIDDEN columns feature in PostgreSQL.
The user
Le 15/10/2021 à 18:42, Aleksander Alekseev a écrit :
> Hi Gilles,
>
>> Yes, I don't wanted to offend you or to troll. This was just to point
>> that the position of "SELECT * is bad practice" is not a good argument
>> in my point of view, just because it is allowed for every one. I mean
>> that in
fication involving other tables in the query you have
to define rules. Handling a technical column through a view over the
real table require lot of work, this feature will help a lot to save
this time.
--
Gilles Darold
Le 17/10/2021 à 23:04, Vik Fearing a écrit :
> On 10/17/21 11:01 PM, Gilles Darold wrote:
>> - Add a check into SET UNEXPANDED code to verify that there is at
>> least one column expanded.
> What is the point of this? Postgres allows column-less tables.
>
> Both of th
Le 17/10/2021 à 23:48, Isaac Morland a écrit :
> On Sun, 17 Oct 2021 at 17:42, Gilles Darold <mailto:gil...@migops.com>> wrote:
>
> Perhaps I misunderstand what you are saying, but a no-columns table
> definitely can return rows:
>
> psql (12.2)
> Type "help&quo
Le 18/10/2021 à 17:24, Vik Fearing a écrit :
> On 10/18/21 8:44 AM, Gilles Darold wrote:
>> Le 17/10/2021 à 23:48, Isaac Morland a écrit :
>>> On Sun, 17 Oct 2021 at 17:42, Gilles Darold >> <mailto:gil...@migops.com>> wrote:
>>>
>>> Note that p
Le 28/10/2021 à 16:31, Bruce Momjian a écrit :
> On Thu, Oct 28, 2021 at 11:30:27AM +0200, Gilles Darold wrote:
>> Fixed with new patch version v7 attached. It also fixes unwanted change
>> of some regression tests output reported by the cfbot because I forgot
>> to change
"9.7.3.8 Differences from XQuery" And try to modify chapter "9.16.2.3.
SQL/JSON Regular Expressions" to mention the REGEXP_LIKE operator. For
the second fix there should be better wording.
Best regards,
--
Gilles Darold
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.s
Le 02/11/2021 à 16:50, Tom Lane a écrit :
Gilles Darold writes:
Since we have the regexp_like operator I have found that there is two
references in the documentation about PostgreSQL lacking of LIKE_REGEX
implementation. Here is a patch to fix the documentation. I simply
remove the reference
is own beforehand
expiration notice but with psql we don't have it for the moment. If
there is interest for this psql feature I can post the patch.
--
Gilles Darold
Le 19/11/2021 à 16:55, Tom Lane a écrit :
Gilles Darold writes:
Now that the security policy is getting stronger, it is not uncommon to
create users with a password expiration date (VALID UNTIL).
TBH, I thought people were starting to realize that forced password
rotations are a net security
s.
>>
> +1 for a server side solution. The people most likely to benefit from
> this are the people least likely to be using psql IMNSHO.
Ok, I can try to implement something at server side using a NOTICE message.
--
Gilles Darold
res_fdw as per the
SELECT statement above the message should be more comprehensible with:
ERROR: cannot PREPARE a transaction that has operated on remote tables
like for temporary objects:
ERROR: cannot PREPARE a transaction that has operated on temporary
objects
Best regards,
--
Gille
Le 02/11/2019 à 08:31, Michael Paquier a écrit :
> On Fri, Nov 01, 2019 at 05:29:23PM +0100, Gilles Darold wrote:
>> I have attached a patch to the documentation that adds remote tables to
>> the list of objects where any operation prevent using a prepared
>> transaction,
Hi Esturo,
Le 05/11/2019 à 10:35, Etsuro Fujita a écrit :
> Hi Gilles,
>
> On Sat, Nov 2, 2019 at 1:29 AM Gilles Darold wrote:
>> As per the following code, t1 is a remote table through postgres_fdw:
>> test=# BEGIN;
>> BEGIN
>> test=# SELECT * FROM t1;
>&g
age is rather
> wrong.
This is not what I've experienced, see the first message of the thread.
A SELECT on foreign table prevent to use PREPARE TRANSACTION like with
temporary table. Perhaps postgres_fdw should not throw an error with
readonly queries on foreign tables but I guess that it is pretty hard to
know especially on a later PREPARE event. But maybe I'm wrong, it is not
easy every day :-) Can you share the SQL code you have executed to allow
PREPARE transaction after a SELECT on a postgres_fdw foreign table?
--
Gilles Darold
well,
> as you proposed.
>
> Thanks again for reviewing!
>
> Best regards,
> Etsuro Fujita
Looks good for me,
--
Gilles Darold
ort or not of 2PC is on foreign data wrapper
side. In postgres_fdw contrib the error for use with 2PC is not part of
the test but it will be thrown anyway. I guess that a test will be
valuable only if there is support for readonly query.
--
Gilles Darold
Le 09/11/2019 à 02:22, Michael Paquier a écrit :
> On Fri, Nov 08, 2019 at 10:19:01AM +0100, Gilles Darold wrote:
>> I don't think so. The support or not of 2PC is on foreign data wrapper
>> side. In postgres_fdw contrib the error for use with 2PC is not part of
>> the
l versions since 9.4.
[1] https://www.postgresql.org/docs/current/infoschema-views.html
--
Gilles Darold
http://www.darold.net/
diff --git a/doc/src/sgml/information_schema.sgml b/doc/src/sgml/information_schema.sgml
index 234a3bb6d1..d8c7902ff8 100644
--- a/doc/src/sgml/information_schema.sgml
+++
the
documentation that this option also works with inheritance.
Attached is a new patch v2 using the --with-partitions and the
documentation fix.
--
Gilles Darold
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 49d218905f..15ada5c8ee 100644
--- a/doc/src/s
Le 04/03/2023 à 19:18, Tom Lane a écrit :
Gilles Darold writes:
But I disagree the use of --table-with-childs and
--exclude-table-with-childs because we already have the --table and
--exclude-table, and it will add lot of code where we just need a switch
to include children tables.
I quite
xclude-table-and-children
--exclude-table-data-and-children.
Documentation have been updated too.
Thanks
--
Gilles Darold
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 334e4b7fd1..e97b73194e 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/r
Le 11/03/2023 à 19:51, Gilles Darold a écrit :
Le 04/03/2023 à 20:18, Tom Lane a écrit :
As noted, "childs" is bad English and "partitions" is flat out wrong
(unless you change it to recurse only to partitions, which doesn't
seem like a better definition). We could
mp_connstr.pl . ok
All tests successful.
Files=4, Tests=9531, 11 wallclock secs ( 0.33 usr 0.04 sys + 3.05
cusr 1.22 csys = 4.64 CPU)
Result: PASS
Anyway this test must be fixed and this is done in version v5 of the
patch attached here.
Thanks for the review.
--
Gilles Darold
pane, I've changed commit fest status to "Ready for committers".
--
Gilles Darold
ption.
As it seems to have a consensus to apply this patch I will change the
commitfest status to ready for committers.
Regards,
--
Gilles Darold
nd and current patch
adds a sentence about the silent behavior in the documentation. This is
good but I just want to ask if we could want to fix this behavior too or
just keep things like that with the lack of noise.
Best regards,
--
Gilles Darold
Le 04/01/2023 à 19:18, Nathan Bossart a écrit :
On Wed, Jan 04, 2023 at 02:25:13PM +0100, Gilles Darold wrote:
This is the current behavior of the CLUSTER command and current patch adds a
sentence about the silent behavior in the documentation. This is good but I
just want to ask if we could
Le 05/01/2023 à 06:12, Nathan Bossart a écrit :
On Wed, Jan 04, 2023 at 11:27:05PM +0100, Gilles Darold wrote:
Got it, this is patch add_cluster_skip_messages.patch . IMHO this patch
should be part of this commitfest as it is directly based on this one. You
could create a second patch here that
kip warning messages
except partially in src/test/regress/sql/cluster.sql to validate the
presence of the warning.
I'm moving this commitfest entry to Ready for Committers.
Regards,
--
Gilles Darold
t; --with-childs > out.sql
Here in attachment the patch that adds this feature to pg_dump.
Is there is any interest for this feature?
Best regards,
--
Gilles Darold
https://www.migops.com/
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 2c938cd7e1..f9635442f9 100
Le 11/01/2023 à 18:54, Nathan Bossart a écrit :
On Wed, Jan 11, 2023 at 02:22:26PM +0100, Gilles Darold wrote:
I'm moving this commitfest entry to Ready for Committers.
Thank you for reviewing.
I have changed the status to "Returned with feedback" as per commit
ff9618e8 this
t; + * If no tables were listed, filter for the relevant relation types.
> If
> + * tables were given via --table, don't bother filtering by relation
> type.
> + * Instead, let the server decide whether a given relation can be
> + * proce
Le 08/04/2022 à 02:46, Justin Pryzby a écrit :
On Wed, Apr 06, 2022 at 07:43:42PM +0200, Gilles Darold wrote:
Thanks for the review, all these changes are available in new version v6
of the patch and attached here.
This is failing in CI (except on macos, which is strangely passing).
http
Le 08/04/2022 à 02:46, Justin Pryzby a écrit :
On Wed, Apr 06, 2022 at 07:43:42PM +0200, Gilles Darold wrote:
Thanks for the review, all these changes are available in new version v6
of the patch and attached here.
This is failing in CI (except on macos, which is strangely passing).
http
Le 11/04/2022 à 20:37, Nathan Bossart a écrit :
> On Fri, Apr 08, 2022 at 05:16:06PM +0200, Gilles Darold wrote:
>> Attached v7 of the patch that should pass cfbot.
> Thanks for the new patch! Unfortunately, it looks like some recent changes
> have broken it again.
>
Le 18/04/2022 à 23:56, Nathan Bossart a écrit :
On Thu, Apr 14, 2022 at 10:27:46PM +0200, Gilles Darold wrote:
Attached v8 of the patch that tries to address the remarks above, fixes
patch apply failure to master and replace calls to pg_log_error+exit
with pg_fatal.
Thanks for the new patch
Le 20/04/2022 à 19:38, Nathan Bossart a écrit :
Thanks for the new patch! I think this is on the right track.
On Wed, Apr 20, 2022 at 05:15:02PM +0200, Gilles Darold wrote:
Le 18/04/2022 à 23:56, Nathan Bossart a écrit :
- if (!tables_listed)
+ if (!objects_listed || objfilter
goo
Le 25/04/2022 à 03:27, Nathan Bossart a écrit :
> On Fri, Apr 22, 2022 at 10:57:46PM -0700, Nathan Bossart wrote:
>> On Fri, Apr 22, 2022 at 11:57:05AM +0200, Gilles Darold wrote:
>>> Patch v10 attached.
>> Thanks! I've attached a v11 with some minor editorializ
OF PARTITION OF
gilles=# CREATE TABLE test AS
SELECT WITH
Adding the patch to current commitfest.
Best regards,
--
Gilles Darold
http://www.darold.net/
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 93742fc6ac..d793a94d6a 100644
--- a/src/bin/psql/tab
Le 15/11/2023 à 03:58, Michael Paquier a écrit :
On Thu, Nov 02, 2023 at 07:27:02PM +0300, Gilles Darold wrote:
Look like the tab completion for CREATE TABLE ... AS is not
proposed.
+ /* Complete CREATE TABLE AS with list of keywords */
+ else if (TailMatches("CREATE&quo
Le 25/03/2020 à 03:49, Dave Sharpe a écrit :
>
> Hi pghackers,
>
> This is my first time posting here ... Gilles Darold and I are
> developing a new FDW which is based on the contrib/postgres_fdw. The
> postgres_fdw logic uses a RegisterXactCallback function to send local
>
of a kind of backport of commit
e3fcbbd623b9ccc16cdbda374654d91a4727d173 ?
Best regards,
--
Gilles Darold
Le 17/11/2022 à 17:59, Tom Lane a écrit :
Gilles Darold writes:
I have an incorrect behavior with pg_dump prior PG version 15. With
PostgreSQL 15, thanks to commit e3fcbbd623b9ccc16cdbda374654d91a4727d173
the problem is gone but for older versions it persists with locks on
partitioned tables
Le 17/11/2022 à 17:59, Tom Lane a écrit :
Gilles Darold writes:
I have an incorrect behavior with pg_dump prior PG version 15. With
PostgreSQL 15, thanks to commit e3fcbbd623b9ccc16cdbda374654d91a4727d173
the problem is gone but for older versions it persists with locks on
partitioned tables
7;t have a functionit would be ideal for DBAs.I agree this is unusual
but when it does happen to you being able to call get_query_def () helps
a lot.
--
Gilles Darold
http://www.darold.net/
Le 28/06/2021 à 18:41, Julien Rouhaud a écrit :
> Thanks for the feedback Gilles!
>
> On Mon, Jun 28, 2021 at 04:06:54PM +0200, Gilles Darold wrote:
>> If we could at least call get_query_def()through an extension if we didn't
>> have a functionit would be ideal for DB
s case I can update the patch. For this feature we
need a hook that is executed before any command even if the transaction
is in abort state to be able to inject the rollback to savepoint, maybe
I'm not looking at the right place to do that.
Thanks
--
Gilles Darold
http://www.darold.net/
dif
was. Thanks Julien.
I'm joining a new patch v4 that removes the need of any hook and adds a
new events XACT_EVENT_COMMAND_START and SUBXACT_EVENT_COMMAND_START that
can be cautch in the xact callbacks when a new command is to be executed.
--
Gilles Darold
http://www.darold.net/
diff --
Planning Time: 0.745 ms
Execution Time: 3.860 ms
(5 rows)
I don't see a good reason to never push the CASE WHEN clause but perhaps
I'm missing something, any though?
Best regards,
--
Gilles Darold
MigOps Inc (http://migops.com)
diff --git a/contrib/postgres_fdw/deparse.c b
Le 07/07/2021 à 06:59, David Rowley a écrit :
> On Wed, 7 Jul 2021 at 10:18, Gilles Darold wrote:
>> I have noticed that postgres_fdw do not push down the CASE WHEN clauses. In
>> the following case this normal:
> This looks very similar to [1] which is in the current commi
m(CASE WHEN mod(c1, 4) = 0 THEN 1 ELSE 2 END) FROM ft1;
-- Same but without the ELSE clause
EXPLAIN (VERBOSE, COSTS OFF)
SELECT sum(CASE WHEN mod(c1, 4) = 0 THEN 1 END) FROM ft1;
For convenience I'm attaching a new patch v5 that change the code
following my comments above, fix t
Le 07/07/2021 à 17:39, Alexander Pyhalov a écrit :
Hi.
Gilles Darold писал 2021-07-07 15:02:
Le 22/06/2021 à 15:39, Alexander Pyhalov a écrit :
Seino Yuki писал 2021-06-22 16:03:
On 2021-06-16 01:29, Alexander Pyhalov wrote:
Hi.
Ashutosh Bapat писал 2021-06-15 16:24:
Looks quite useful to
Le 07/07/2021 à 18:50, Gilles Darold a écrit :
Great, I changing the state in the commitfest to "Ready for committers".
I'm attaching the v5 patch again as it doesn't appears in the Latest
attachment list in the commitfest.
--
Gilles Darold
MigOps Inc
diff --git a/
1 - 100 of 143 matches
Mail list logo
