On Mon, Aug 14, 2023 at 8:38 PM shveta malik wrote:
>
> On Mon, Aug 14, 2023 at 3:22 PM shveta malik wrote:
> >
> > On Tue, Aug 8, 2023 at 11:11 AM Drouvot, Bertrand
> > wrote:
> > >
> > > Hi,
> > >
> > > On 8/8/23 7:01 AM, shveta malik wrote:
> > > > On Mon, Aug 7, 2023 at 3:17 PM Drouvot,
On Fri, Aug 4, 2023 at 2:11 PM Ashutosh Bapat
wrote:
>
> Attached patchset fixing those.
> 0001 - patch to report planning memory, with to explain.out regression output
> fix. We may consider committing this as well.
> 0002 - with your comment addressed above.
0003 - Added this patch for
Hi,
On 8/14/23 6:37 AM, Michael Paquier wrote:
On Thu, Aug 10, 2023 at 08:09:34PM +0200, Drouvot, Bertrand wrote:
Agree that's worth it given the fact that iterating one more time is not that
costly here.
I have reviewed v4, and finished by putting my hands on it to see what
I could do.
On Tue, Aug 15, 2023 at 5:58 PM jian he wrote:
> Hi.
> in v11, json_query:
> +The returned data_type has the
> same semantics
> +as for constructor functions like
> json_objectagg;
> +the default returned type is text.
> +The ON EMPTY clause specifies the behavior
Hi,
On 2023-08-16 12:37:21 +0900, Michael Paquier wrote:
> I won't fight much if there are objections to backpatching, but that's
> not really wise (no idea how much EDB's close flavor of BDR relies on
> that).
To be clear: I don't just object to backpatching, I also object to making
existing
Hi,
On 2023-08-16 03:20:53 +0200, Tomas Vondra wrote:
> On 8/16/23 02:33, Andres Freund wrote:
> > Hi,
> >
> > On 2023-08-16 06:58:56 +0900, Michael Paquier wrote:
> >> On Tue, Aug 15, 2023 at 11:37:32AM +0200, Tomas Vondra wrote:
> >>> Shouldn't the flush be done only for non-transactional
On Fri, Aug 11, 2023 at 11:45 PM Melih Mutlu wrote:
>
> Again, I couldn't reproduce the cases where you saw significantly degraded
> performance. I wonder if I'm missing something. Did you do anything not
> included in the test scripts you shared? Do you think v26-0001 will perform
> 84% worse
On Wed, Aug 16, 2023 at 03:20:53AM +0200, Tomas Vondra wrote:
> So are you objecting to adding the flush in general, or just to the
> backpatching part?
>
> IMHO we either guarantee durability of non-transactional messages, in
> which case this would be a clear bug - and I'd say a fairly serious
On Wed, Aug 16, 2023 at 12:17 AM Nathan Bossart
wrote:
>
> On Tue, Aug 15, 2023 at 01:53:25PM +0700, John Naylor wrote:
> > - *ptr = '\0';
> > + Assert(base == 2 || base == 8 || base == 16);
> >
> > + *ptr = '\0';
> >
> > Spurious whitespace change?
>
> I think this might just be a weird
Dear Hou,
Thanks for posting the patch! I want to open a question to gather opinions from
others.
> > It was primarily for upgrade purposes only. So, as we can't see a good
> > reason to
> > go via pg_dump let's do it in upgrade unless someone thinks otherwise.
>
> Removed the new option in
On 8/16/23 02:33, Andres Freund wrote:
> Hi,
>
> On 2023-08-16 06:58:56 +0900, Michael Paquier wrote:
>> On Tue, Aug 15, 2023 at 11:37:32AM +0200, Tomas Vondra wrote:
>>> Shouldn't the flush be done only for non-transactional messages? The
>>> transactional case will be flushed by regular commit
On Tue, Aug 15, 2023 at 7:50 PM Etsuro Fujita
wrote:
> So we should have modified the second one as well? Attached is a
> small patch for that.
Agreed, nice catch! +1 to the patch.
Thanks
Richard
Hi,
On 2023-08-16 06:58:56 +0900, Michael Paquier wrote:
> On Tue, Aug 15, 2023 at 11:37:32AM +0200, Tomas Vondra wrote:
> > Shouldn't the flush be done only for non-transactional messages? The
> > transactional case will be flushed by regular commit flush.
>
> Indeed, that would be better. I
Here is another review comment about patch v26-0001.
The tablesync worker processes include the 'relid' as part of their
name. See launcher.c:
snprintf(bgw.bgw_name, BGW_MAXLEN,
"logical replication tablesync worker for subscription %u sync %u",
subid,
relid);
~~
And if that worker
On Tue, Aug 08, 2023 at 01:06:06PM -0700, Nathan Bossart wrote:
> I ran a couple of tests for pg_upgrade with 100k tables (created using the
> script here [0]) in order to demonstrate the potential benefits of this
> patch.
That shows some nice numbers with many files, indeed. How does the
size
>
>
> Please look at the bug #18014:
>
> https://www.postgresql.org/message-id/flat/18014-28c81cb79d44295d%40postgresql.org
> There were other aspects of the xmlmap test failure discussed in that
> thread as well.
>
Thank you Alexander for the information, I will go through there for
On Tue, Aug 15, 2023 at 03:39:10PM -0700, Jacob Champion wrote:
> I'm not super comfortable with saying "connection authenticated" when
> it explicitly hasn't been (nor with switching the meaning of a
> non-NULL SYSTEM_USER from "definitely authenticated somehow" to "who
> knows; parse it apart to
On 2023-Aug-16, Michael Paquier wrote:
> > Personally I think backpatching 28b5726 has a really low risk of
> > breaking anything.
>
> I agree about the low-risk argument, though. This is just new code.
Here's a way to think about it. If 16.1 was already out, would we add
libpq support for
On Tue, Aug 15, 2023 at 3:24 PM Michael Paquier wrote:
> The first message from Jacob outlines the idea behind the handling of
> trust. We could perhaps add one extra set_authn_id() for the uaTrust
> case (not uaCert!) if that's more helpful.
I'm not super comfortable with saying "connection
On Wed, Aug 16, 2023 at 12:14:21AM +0200, Jelte Fennema wrote:
> 28b5726 allows sending Close messages from libpq, as opposed to
> sending DEALLOCATE queries to deallocate prepared statements. Without
> support for Close messages, libpq based clients won't be able to
> deallocate prepared
On Tue, Aug 15, 2023 at 04:49:47PM -0500, Shaun Thomas wrote:
> The switch statement that decodes port->hba->auth_method ends by
> simply setting status = STATUS_OK; with no supplementary output since
> it never calls set_authn_id. So in theory, a malicious user could add
> a trust line to
Hi,
I know that this will probably get a staunch "No" as an answer, but...
I'm still going to ask: Would it be possible to backport 28b5726 to
the PG16 branch? Even though it's clearly a new feature?
I'm working on named prepared statement support in PgBouncer:
On Tue, Aug 15, 2023 at 11:37:32AM +0200, Tomas Vondra wrote:
> Shouldn't the flush be done only for non-transactional messages? The
> transactional case will be flushed by regular commit flush.
Indeed, that would be better. I am sending an updated patch.
I'd like to backpatch that, would there
Hi everyone,
This started as a conversation on Discord. Someone asked if Postgres
logs which line in pg_hba.conf matched against a certain login
attempt, and I said no. That's not quite right, as enabling
log_connections includes a line like this:
2023-08-15 13:26:03.159 PDT [692166]
> On Wed, Aug 16, 2023 at 06:25:09AM +0900, Tatsuo Ishii wrote:
>> Currently pqcomm.h needs c.h which is not problem for Pgpool-II. But
>> what about other middleware?
>
> Why do you need to include directly c.h? There are definitions in
> there that are not intended to be exposed.
pqcomm.h has
On 2023-Aug-16, Michael Paquier wrote:
> On Wed, Aug 16, 2023 at 06:25:09AM +0900, Tatsuo Ishii wrote:
> > Currently pqcomm.h needs c.h which is not problem for Pgpool-II. But
> > what about other middleware?
>
> Why do you need to include directly c.h? There are definitions in
> there that are
On Wed, Aug 16, 2023 at 06:25:09AM +0900, Tatsuo Ishii wrote:
> Currently pqcomm.h needs c.h which is not problem for Pgpool-II. But
> what about other middleware?
Why do you need to include directly c.h? There are definitions in
there that are not intended to be exposed.
--
Michael
> On Tue, Aug 15, 2023 at 02:46:24PM +0900, Tatsuo Ishii wrote:
>> Is it possible to put the new define staff into protocol.h then let
>> pqcomm.h include protocol.h? This makes Pgpool-II and other middle
>> ware/drivers written in C easier to use the defines so that they only
>> include
On Fri, Aug 11, 2023 at 01:59:40PM -0700, Peter Geoghegan wrote:
> I'm starting to have doubts about this policy. There have now been
> quite a few follow-up "fixes" to indentation issues that koel
> complained about. None of these fixups have been included in
> .git-blame-ignore-revs. If things
On Tue, Aug 15, 2023 at 01:53:25PM +0700, John Naylor wrote:
> If we're not going to have a general SQL conversion function, here are some
> comments on the current patch.
I appreciate the review.
> +static char *convert_to_base(uint64 value, int base);
>
> Not needed if the definition is above
On Wed, Aug 9, 2023 at 8:57 AM Amit Langote wrote:
> I checked enough to be sure that IsParallelWorker() is reliable at the
> time of ExecutorStart() / ExecInitNode() in ParallelQueryMain() in a
> worker. However, ParallelWorkerContext is not available at that
> point. Here's the relevant part
On Mon, Aug 7, 2023 at 7:24 PM Jeff Davis wrote:
> I might just avoid guc.c entirely and directly set
> namespace_search_path and baseSearchPathValid=false. The main thing we
> lose there is the GUC stack (AtEOXact_GUC()), but there's already a
> PG_TRY/PG_FINALLY block in fmgr_security_definer,
On 14/08/2023 05:41, Thomas Munro wrote:
The new idea is to overload smgrrelease(it) so that it also clears the
owner, which means that AtEOXact_SMgr() will eventually smgrclose(it),
unless it is re-owned by a relation before then. That choice stems
from the complete lack of information
On Tue, Aug 15, 2023 at 02:46:24PM +0900, Tatsuo Ishii wrote:
> Is it possible to put the new define staff into protocol.h then let
> pqcomm.h include protocol.h? This makes Pgpool-II and other middle
> ware/drivers written in C easier to use the defines so that they only
> include protocol.h to
On Tue, Aug 15, 2023 at 07:58:17AM +0200, Vik Fearing wrote:
> On 8/15/23 06:11, Nathan Bossart wrote:
>> If there are no objections, I'd like to commit this patch soon.
>
> I just took a look at this (and the rest of the thread). I am a little bit
> disappointed that we don't have a generic
On Tue, Aug 15, 2023 at 09:46:59AM +0200, Fabien COELHO wrote:
> I'm unclear about what variety of scripts that could be provided given the
> tables made available with pgbench. ISTM that other scenari would involve
> both an initialization and associated scripts, and any proposal would be
> bared
On Tue, Aug 15, 2023 at 12:29:24PM +0200, Michail Nikolaev wrote:
>> What sort of benefits do you see from this patch? It might be worthwhile
>> in itself to remove spinlocks when possible, but IME it's much easier to
>> justify such changes when there is a tangible benefit we can point to.
>
>
Hi there
I am trying to convert a SQL Anywhere database to postgres. Within SQL anywhere
a field can have a default value of 'last user'. This means that when you
perform an update on a table, if the field is not explicitly set then the
current user is used. So for instance if I have a field
Hi Andy,
15.08.2023 14:09, Andy Fan wrote:
Hi:
In the test case of xmlmap.sql, we have the query below under schema_to_xml.
Please look at the bug #18014:
https://www.postgresql.org/message-id/flat/18014-28c81cb79d44295d%40postgresql.org
There were other aspects of the xmlmap test failure
On 01/08/2023 16:48, Joe Conway wrote:
Any further comments on the posted patch[1]? I would like to apply/push
this prior to the beta and minor releases next week.
I'm not sure about the placement of the uselocale() calls. In
plperl_spi_exec(), for example, I think we should switch to the
Hi Etsuro, all
The commit[1] seems to break some queries in Citus[2], which is an
extension which relies on set_join_pathlist_hook.
Although the comment says */*Finally, give extensions a chance to
manipulate the path list.*/ *we use it to extract lots of information
about the joins and do the
On Tue, Aug 15, 2023 at 9:34 AM Masahiko Sawada
wrote:
> BTW cfbot reported that some regression tests failed due to OOM. I've
> attached the patch to fix it.
Seems worth doing now rather than later, so added this and squashed most of
the rest together. I wonder if that test uses too much
Hi,
While working on the join pushdown issue, I noticed this bit in commit
e4106b252:
--- parameterized remote path
+-- parameterized remote path for foreign table
EXPLAIN (VERBOSE, COSTS false)
- SELECT * FROM ft2 a, ft2 b WHERE a.c1 = 47 AND b.c1 = a.c2;
+ SELECT * FROM "S 1"."T 1" a, ft2 b
I overlooked the fact even in the bitmap index scan loose mode, the recheck
is still executed before the qual, so bitmap index scan is OK in this case.
Sort
Output: oid, relname
Sort Key: pg_class.relname
-> Bitmap Heap Scan on pg_catalog.pg_class
Output: oid, relname
Hi:
In the test case of xmlmap.sql, we have the query below
under schema_to_xml.
explain (costs off, verbose)
SELECT oid FROM pg_catalog.pg_class
WHERE relnamespace = 28601
AND relkind IN ('r','m','v')
AND pg_catalog.has_table_privilege (oid, 'SELECT')
ORDER BY relname;
If the query is using
Hello, Nathan.
> What sort of benefits do you see from this patch? It might be worthwhile
> in itself to remove spinlocks when possible, but IME it's much easier to
> justify such changes when there is a tangible benefit we can point to.
Oh, it is not an easy question :)
The answer, probably,
On 2023-Aug-15, Dean Rasheed wrote:
> I think perhaps for ALTER TABLE INHERIT, it should check that the
> child has a NOT NULL constraint, and error out if not. That's the
> current behaviour, and also matches other constraints types (e.g.,
> CHECK constraints).
Yeah, I reached the same
On Fri, 11 Aug 2023 at 14:54, Alvaro Herrera wrote:
>
> Right, in the end I got around to that point of view. I abandoned the
> idea of adding these dependency links, and I'm back at relying on the
> coninhcount/conislocal markers. But there were a couple of bugs in the
> accounting for that,
About pgbench exit on abort v4:
Patch applies cleanly, compiles, local make check ok, doc looks ok.
This looks ok to me.
--
Fabien.
On 8/15/23 08:38, Michael Paquier wrote:
> Hi all,
>
> While playing with pg_logical_emit_message() and WAL replay, I have
> noticed that LogLogicalMessage() inserts a record but forgets to make
> sure that the record has been flushed. So, for example, if the system
> crashes the message
[...] Further changes are already needed for their "main" branch (LLVM
17-to-be), so this won't quite be enough to shut seawasp up.
For information, the physical server which was hosting my 2 bf animals
(seawasp and moonjelly) has given up rebooting after a power cut a few
weeks/months
Hi,
Has anyone tried generating a dynamic memory trace of a backend Postgres
process while it's running a query?
I want to characterize the memory access pattern of the Postgres database
engine when it's running any given query. The usual way to do this would be
to attach a dynamic
Hi.
in v11, json_query:
+The returned data_type has the
same semantics
+as for constructor functions like json_objectagg;
+the default returned type is text.
+The ON EMPTY clause specifies the behavior if the
+path_expression yields no value at all; the
+
On Fri, Jul 14, 2023 at 8:46 PM Andres Freund wrote:
>
> Hi,
>
> As I think I mentioned before, I like this idea. However, I don't like the
> implementation too much.
Thanks for looking into it.
> This might work right now, but doesn't really seem maintainable. Nor do I like
> adding branches
On Tue, Aug 8, 2023 at 6:30 PM Richard Guo wrote:
> On Tue, Aug 8, 2023 at 4:40 PM Etsuro Fujita wrote:
>> I modified the code a bit further to use an if-test to avoid a useless
>> function call, and added/tweaked comments and docs further. Attached
>> is a new version of the patch. I am
Hello Nathan,
1. so I don't have to create the script and function manually each
time I want to test mainly the database (instead of the
client-database system)
2. so that new users of PostgreSQL can easily see how much better OLTP
workloads perform when packaged up as a server-side function
út 15. 8. 2023 v 9:05 odesílatel Andy Fan napsal:
>
>
>> a) effectiveness. The ending performance should be similar like your
>> current patch, but without necessity to use planner support API.
>>
>
> So the cost is we need to create a new & different framework.
>
yes, it can be less work, code
>
> a) effectiveness. The ending performance should be similar like your
> current patch, but without necessity to use planner support API.
>
So the cost is we need to create a new & different framework.
>
>
b) because you can write only var := j->'f', and plpgsql forces cast
> function
On Tue, Jul 25, 2023 at 05:16:56PM -0700, Nathan Bossart wrote:
> [v4]
If we're not going to have a general SQL conversion function, here are some
comments on the current patch.
+static char *convert_to_base(uint64 value, int base);
Not needed if the definition is above the callers.
+ *
út 15. 8. 2023 v 8:04 odesílatel Andy Fan napsal:
>
>> My idea of an ideal solution is the introduction of the possibility to
>> use "any" pseudotype as return type with possibility to set default return
>> type. Now, "any" is allowed only for arguments. The planner can set the
>> expected type
On Tue, Apr 18, 2023 at 01:34:00PM +0900, Michael Paquier wrote:
> Note that the development of PostgreSQL 16 has just finished, so now
> may not be the best moment to add these extra AOT calls, but these
> could be added in 17~ for sure at the beginning of July once the next
> development cycle
Hi all,
While playing with pg_logical_emit_message() and WAL replay, I have
noticed that LogLogicalMessage() inserts a record but forgets to make
sure that the record has been flushed. So, for example, if the system
crashes the message inserted can get lost.
I was writing some TAP tests for it
út 15. 8. 2023 v 8:04 odesílatel Vik Fearing
napsal:
> On 8/15/23 07:53, Pavel Stehule wrote:
> > út 15. 8. 2023 v 7:48 odesílatel Vik Fearing
> > napsal:
> >
> >> On 8/14/23 15:37, Pavel Stehule wrote:
> >>> po 14. 8. 2023 v 15:09 odesílatel Erik Rijkers napsal:
> >>>
> >>> I think so this
On 8/15/23 07:53, Pavel Stehule wrote:
út 15. 8. 2023 v 7:48 odesílatel Vik Fearing
napsal:
On 8/14/23 15:37, Pavel Stehule wrote:
po 14. 8. 2023 v 15:09 odesílatel Erik Rijkers napsal:
I think so this can be +/- 40 lines of C code
It seems to me like a good candidate for an extension.
>
>
> My idea of an ideal solution is the introduction of the possibility to use
> "any" pseudotype as return type with possibility to set default return
> type. Now, "any" is allowed only for arguments. The planner can set the
> expected type when it knows it, or can use the default type.
>
> so
Hi,
sorry for the double reply, but it seems my mail client's default is
now to send to the list only when hitting group reply. Not good, sigh.
> I have a modified version of ECPG, to which I gave the ability to
> do semantic analysis of SQL statements. Where i can share it or with
> whom can I
út 15. 8. 2023 v 5:12 odesílatel jian he
napsal:
> \df jsonb_populate_record
> List of functions
>Schema | Name | Result data type | Argument data
> types | Type
>
>
67 matches
Mail list logo
