On Mon, Oct 9, 2023 at 12:13 PM David Rowley wrote:
> I've now pushed the patch that trims off the Pathkeys for the ORDER BY
> / DISTINCT aggregates.
Thanks for pushing!
> Those results are a bit noisy. Perhaps a few more runs might yield
> more consistency, but it seems that there's not
On Mon, Oct 9, 2023 at 10:51 AM Drouvot, Bertrand
wrote:
>
> I like the idea and I think that's the one that seems the more reasonable
> to me. I'd vote for this idea with:
>
> - standby_slot_names on the primary (could also be set on standbys in case of
> cascading context)
> - enable_failover
Hi,
On 10/6/23 6:48 PM, Amit Kapila wrote:
On Wed, Oct 4, 2023 at 5:34 PM Drouvot, Bertrand
wrote:
On 10/4/23 1:50 PM, shveta malik wrote:
On Wed, Oct 4, 2023 at 5:00 PM Amit Kapila wrote:
On Wed, Oct 4, 2023 at 11:55 AM Drouvot, Bertrand
wrote:
On 10/4/23 6:26 AM, shveta malik wrote:
On Sun, Oct 8, 2023 at 9:10 PM Noah Misch wrote:
>
> I didn't think of any phrasing that clearly explained things without the
> reader consulting the code. I considered these:
>
> "socket file descriptor out of range: %d" [what range?]
>
>
Quick drive-by...but it seems that < 0 is a
David Rowley writes:
> On Thu, 5 Oct 2023 at 21:24, David Rowley wrote:
>> I looked at the patch again and I just couldn't bring myself to change
>> it to that. If it were a macro going into stringinfo.h then I'd agree
>> with having a macro or inline function as it would allow the reader to
>>
On Fri, Oct 6, 2023 at 12:15 PM Peter Smith wrote:
>
> Here is a patch to add the 2 missing references:
>
> ref/alter_subscription.sgml ==> added more ids
> ref/alter_publication.sgml ==> added link to
> "sql-altersubscription-refresh-publication"
> ref/drop_subscription.sgml ==> added link to
On Thu, 5 Oct 2023 at 21:24, David Rowley wrote:
>
> On Thu, 5 Oct 2023 at 18:23, Michael Paquier wrote:
> > Ahem, well. Based on this argument my own argument does not hold
> > much. Perhaps I'd still use a macro at the top of array_userfuncs.c
> > and numeric.c, to avoid repeating the same
On Mon, 9 Oct 2023 at 12:42, David Rowley wrote:
> Maybe it's worth checking the total planning time spent in a run of
> the regression tests with and without the patch to see how much
> overhead it adds to the "average case".
I've now pushed the patch that trims off the Pathkeys for the ORDER
On Mon, Oct 09, 2023 at 04:22:52PM +1300, Thomas Munro wrote:
> On Mon, Oct 9, 2023 at 3:25 PM Noah Misch wrote:
> > The "fd >= FD_SETSIZE" check is irrelevant on Windows. See comments in the
> > attached patch; in brief, Windows assigns FDs and uses FD_SETSIZE
> > differently.
> > The first
On Mon, Oct 9, 2023 at 3:25 PM Noah Misch wrote:
> The "fd >= FD_SETSIZE" check is irrelevant on Windows. See comments in the
> attached patch; in brief, Windows assigns FDs and uses FD_SETSIZE differently.
> The first associated failure was commit dea12a1 (2023-08-03); as a doc commit,
> it's
On Sun, Oct 8, 2023 at 6:55 PM Erik Wienhold wrote:
> On 2023-10-08 06:14 +0200, Laurenz Albe write:
> > On Sat, 2023-10-07 at 20:41 +0200, Erik Wienhold wrote:
> > > > If you are happy enough with my patch, shall we mark it as ready for
> > > > committer?
> > >
> > > I amended your patch to
On Mon, 9 Oct 2023 at 10:28, Tom Lane wrote:
>
> David Rowley writes:
> > It looks like nobody is objecting to this. I understand that not
> > everyone who might object will have read this email thread, so what I
> > propose to do here is move along and just commit the patch to swap out
> >
It looks like an issue with JIT. If I disable the JIT then the above query
runs successfully.
postgres=# set jit to off;
SET
postgres=# SELECT * FROM rm32044_t1 LEFT JOIN rm32044_t2 ON rm32044_t1.pkey
= rm32044_t2.pkey, rm32044_t3 LEFT JOIN rm32044_t4 ON rm32044_t3.pkey =
rm32044_t4.pkey order
On Mon, Sep 04, 2023 at 03:18:40PM +1200, Thomas Munro wrote:
> Somehow these tests have recently become unstable and have failed a few times:
>
> https://github.com/postgres/postgres/commits/REL_15_STABLE
>
> The failures are like:
>
> [22:32:26.722] # Failed test 'pgbench simple update stdout
On Mon, Oct 9, 2023 at 7:42 AM David Rowley wrote:
> On Sun, 8 Oct 2023 at 23:52, Richard Guo wrote:
> > If the pathkeys that were added by adjust_group_pathkeys_for_groupagg()
> > are computable from the targetlist, it seems that we do not need to trim
> > them off, because
On 2023-10-08 06:14 +0200, Laurenz Albe write:
> On Sat, 2023-10-07 at 20:41 +0200, Erik Wienhold wrote:
> > > If you are happy enough with my patch, shall we mark it as ready for
> > > committer?
> >
> > I amended your patch to also document the effect of \pset null in this
> > case. See the
On Mon, Oct 9, 2023 at 8:52 AM David Rowley wrote:
> On Sun, 8 Oct 2023 at 18:32, Michał Kłeczek wrote:
> > On 8 Oct 2023, at 03:33, Andy Fan wrote:
> >> For the patches for performance improvement, it is better to provide
> >> an example to show how much benefits we can get. As for this
Hi, this is my first email to the pgsql hackers.
I came across this email thread while looking at
https://github.com/rails/rails/pull/49388 for Ruby on Rails one of the
popular web application framework by replacing every query `in` clause
with `any` to reduce similar entries in
On Sun, 8 Oct 2023 at 18:32, Michał Kłeczek wrote:
> On 8 Oct 2023, at 03:33, Andy Fan wrote:
>> For the patches for performance improvement, it is better to provide
>> an example to show how much benefits we can get. As for this case,
>> I'm doubtful it can work as an improvement.
> Could
On Sun, 8 Oct 2023 at 23:52, Richard Guo wrote:
> On Thu, Oct 5, 2023 at 2:26 PM David Rowley wrote:
>>
>> So in short, I propose the attached fix without any regression tests
>> because I feel that any regression test would just mark that there was
>> a big in create_agg_path() and not really
On Sat, 7 Oct 2023 at 03:11, Sergei Glukhov wrote:
> I noticed that combination of prepared statement with generic plan and
> 'IS NULL' clause could lead partition pruning to crash.
> Test case:
> --
> set plan_cache_mode to force_generic_plan;
> prepare stmt AS select * from hp where a is
On Mon, Oct 9, 2023 at 2:20 AM Andrew Dunstan wrote:
> I've had to disable COW on my BTRFS-resident buildfarm animals (see
> previous discussion re Direct I/O).
Right, because it is still buggy[1]. I don't see any sign that a fix
has been committed yet, assuming that is the right thing (and it
On Sep 12, 2023, at 21:00, Erik Wienhold wrote:
>> I posted this question on Stack Overflow
>> (https://stackoverflow.com/q/77046554/79202),
>> and from the suggestion I got there, it seems that @@ expects a boolean to be
>> returned by the path query, while @? wraps it in an implicit exists().
On Fri, Oct 6, 2023 at 7:37 PM Alvaro Herrera wrote:
>
> On 2023-Sep-27, Peter Smith wrote:
>
> > 3. get_local_synced_slot_names
> >
> > + for (int i = 0; i < max_replication_slots; i++)
> > + {
> > + ReplicationSlot *s = >replication_slots[i];
> > +
> > + /* Check if it is logical synchronized
Michael Paquier writes:
> On Fri, Oct 06, 2023 at 03:29:28PM +0900, Michael Paquier wrote:
>> Andres, are there logs for this TAP test on serinus? Or perhaps there
>> is a core file that could be looked at? The other animals are not
>> showing anything for the moment.
> Well, it looks OK.
David Rowley writes:
> It looks like nobody is objecting to this. I understand that not
> everyone who might object will have read this email thread, so what I
> propose to do here is move along and just commit the patch to swap out
> debug_print_rel and use pprint instead. If that's done now
On Tue, 3 Oct 2023 at 12:29, David Rowley wrote:
>
> On Fri, 29 Sept 2023 at 10:59, Tom Lane wrote:
> > We could also discuss keeping the "tracing" aspect of it, but
> > replacing debug_print_rel with pprint(rel), which'd still allow
> > removal of all the "DEBUG SUPPORT" stuff at the bottom of
On Fri, Oct 6, 2023 at 1:29 PM Jeff Davis wrote:
>
> On Thu, 2023-10-05 at 14:28 -0700, Gurjeet Singh wrote:
>
> > This way there's a notion of a 'new' and 'old' passwords.
>
> IIUC, you are proposing that there are exactly two slots, NEW and OLD.
> When adding a password, OLD must be unset and
On Sun, Oct 8, 2023 at 10:50:15AM -0700, Gurjeet Singh wrote:
> On Sun, Oct 8, 2023 at 10:29 AM Bruce Momjian wrote:
> >
> > I was speaking of autoremoving in cases where we are creating a new one,
> > and taking the previous new one and making it the old one, if that was
> > not clear.
>
>
On Mon, Oct 02, 2023 at 09:49:53AM -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > CREATE FUNCTION silly() RETURNS trigger LANGUAGE plpgsql AS 'BEGIN RETURN
> > NULL; END;';
> > CREATE TRIGGER silly BEFORE DELETE ON child FOR EACH ROW EXECUTE FUNCTION
> > silly();
>
> > The trigger function
On Sun, Oct 8, 2023 at 10:29 AM Bruce Momjian wrote:
>
> I was speaking of autoremoving in cases where we are creating a new one,
> and taking the previous new one and making it the old one, if that was
> not clear.
Yes, I think I understood it differently. I understood it to mean that
this
On Sun, Oct 8, 2023 at 10:24:42AM -0700, Gurjeet Singh wrote:
> On Fri, Oct 6, 2023 at 1:46 PM Bruce Momjian wrote:
> >
> > On Fri, Oct 6, 2023 at 01:20:03PM -0700, Jeff Davis wrote:
> > > The basic problem, as I see it, is: how do we keep users from
> > > accidentally dropping the wrong
On Fri, Oct 6, 2023 at 1:46 PM Bruce Momjian wrote:
>
> On Fri, Oct 6, 2023 at 01:20:03PM -0700, Jeff Davis wrote:
> > The basic problem, as I see it, is: how do we keep users from
> > accidentally dropping the wrong password? Generated unique names or
>
> I thought we could auto-remove old
## Fabrice Chapuis (fabrice636...@gmail.com):
> From a conceptual point of view I think that specific wals per subscription
> should be used and stored in the pg_replslot folder in order to avoid
> working directly on the wals of the instance.
> What do you think about this proposal?
I think
On 2023-10-07 Sa 01:51, Thomas Munro wrote:
Hello hackers,
Here is an experimental POC of fast/cheap database cloning. For
clones from little template databases, no one cares much, but it might
be useful to be able to create a snapshot or fork of very large
database for
On Thu, Oct 5, 2023 at 2:26 PM David Rowley wrote:
> So in short, I propose the attached fix without any regression tests
> because I feel that any regression test would just mark that there was
> a big in create_agg_path() and not really help with ensuring we don't
> end up with some similar
36 matches
Mail list logo
