artín
--
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see
From eda9f0c811ba115edf47b4f81200073a41d10cc3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?=
Date: Sat, 6 Apr 2024 19:30:23 +0200
Subject: [PATCH 1/2] Remove unneeded wordi
> postgresql.auto.conf, maintained by an external program, to control the
> instance's behaviour.
I believe that's the idea, although we have `include` and
`include_dir` which can be used the same way as `postgresql.auto.conf`
is automatically included.
Kind regards, Martín
--
And this is a product and we shouldn't be
advertising hacks to overcome limitations.
I find the opposition to this lacking good reasons, while I find the
implementation to be useful in some cases.
Kind regards, Martín
--
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see
> > get some fire from users for this, although I concede the theoretical
> > sanity of the change.
>
> Great, thanks for that.
>
> This has now been committed- thanks again to everyone for their help!
>
> Stephen
--
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see
#x27;m not sure, but can amend, is if we need tests for
this change (that would be something like switching ROLE to
pg_read_all_stats and query the pg_replication_origin_status, checking
we get the right result.
Kind regards, Martín
--
Martín Marqués
It’s not that I have something to hide,
it’s t
ting pg_read_all_stats to users, like the attached patch.
I did some re-writing of the doc, which is pretty close to what you
proposed above.
> By the way, the attachements of your mail are out-of-order. I'm not
> sure that that does something bad, though.
That's likely Gmail giving
nge fits what you've kindly pointed out.
> 0004:
>
> Looks fine by me.
Here goes v3 of the patch
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 87c00782c691f2c6c13768cd6d96b19de69cab16 Mon Sep 17 00:00:00 200
d an entry to the commitfest so we can track this there as well.
Regards,
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 87c00782c691f2c6c13768cd6d96b19de69cab16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mart=C3=ADn=20Ma
()`
doesn't expose any data that `pg_read_all_stats` or `pg_monitor`
shouldn't be able to read. Removing or obfuscating `external_id`
and/or `remote_lsn` would make the view somehow pointless, in
particular for monitoring and diagnostic tools.
I'll upload new patches shortly following Michael's suggestions.
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
_read_all_settings TO pg_monitor;
GRANT pg_read_all_stats TO pg_monitor;
GRANT pg_stat_scan_tables TO pg_monitor;
Regards,
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
GRANT execution of the functions. A grant
on the view should be enough.
I'll think about it.
El dom., 31 de may. de 2020 a la(s) 12:13, Martín Marqués
(mar...@2ndquadrant.com) escribió:
>
> Hi Michael,
>
> > Wouldn't it be just better to remove this hardcoded superuser chec
See for example
> e79350fe.
Looking at that, it seems a better solution. Let me wrap up a new
patch, likely later today or early tomorrow as it's Sunday ;-)
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
progress() and
pg_replication_origin_progress().
Once option could be to add a third bool argument check_superuser to
replorigin_check_prerequisites() and have it set to false for the
functions which a none superuser could execute.
Patch attached
--
Martín Marquéshttp://www.
reason for pg_monitor not to have access to it.
Regards,
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
overy. In that case the server was always a primary.
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
the values from ` XLogCtl`
after finishing recovery, or document that we might see non-NULL values
in certain cases.
Regards,
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
that change, I believe this patch is good for commit.
Regards,
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
El vie., 1 de mar. de 2019 a la(s) 06:21, David Steele
(da...@pgmasters.net) escribió:
>
>
> I also addressed a comment from another thread by adding pg_basebackup
> as .e.g. rather than or.
Thanks David,
This looks very good!
--
Martín Marquéshttp://www.2nd
El jue., 28 de feb. de 2019 a la(s) 23:50, Michael Paquier
(mich...@paquier.xyz) escribió:
>
> On Thu, Feb 28, 2019 at 11:07:47PM -0300, Martín Marqués wrote:
> > El 28/2/19 a las 15:13, David Steele escribió:
> > +
> > + The exclusive backup method is deprecated
od is deprecated and should be avoided in
favor
+ of the non-exclusive backup method or
+ pg_basebackup.
+
Isn't pg_basebackup a non-exclusive backup method?
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
El 11/04/18 a las 02:04, David Rowley escribió:
> On 11 April 2018 at 09:13, Martín Marqués wrote:
>> This is a patch to add some further description, plus the upper and
>> lower limits it has.
>
> Hi,
>
> + for vacuum_cost_delay. The parameter can take a
Hi,
Today looking for information on hard limits for
autovacuum_vacuum_cost_limit I found myself with a very short
description in the docs.
This is a patch to add some further description, plus the upper and
lower limits it has.
--
Martín Marqués
select 'martin.marques' || '@
Arthur,
Thank you very much for reviewing the patch and for your valuable
input (you made me read the Microsoft Visual C specs ;))
Regards,
2017-11-21 8:11 GMT-03:00 Arthur Zakirov :
> On Tue, Nov 21, 2017 at 07:16:46AM -0300, Martín Marqués wrote:
>>
>> Ups! Attached the co
El 21/11/17 a las 04:56, Arthur Zakirov escribió:
> On Mon, Nov 20, 2017 at 04:45:48PM -0300, Martín Marqués wrote:
>> New version of patch, without the --batch-mode option and using isatty()
>>
>
> Great!
>
>> +fprintf(stderr, "waiting for check
/* if (!batchmode) */
> /* or */
> if (isatty(fileno(stderr)))
> fprintf(stderr, "\n"); /* Need to move to next line */
> }
New version of patch, without the --batch-mode option and using isatty()
I send in a separate thread a proposal to make isa
y/ms235388.aspx
P.D.: Which would be the correct usage, per-standards: with or without
the _ prefix?
--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/include/port/win32.h b/src/include/port/win32.h
new fil
El 14/11/17 a las 06:25, Arthur Zakirov escribió:
> On Fri, Nov 10, 2017 at 10:32:23AM -0300, Martín Marqués wrote:
>> An example where using isatty() might fail is if you run pg_basebackup
>> from a tty but redirect the output to a file, I believe that in that
>> case isat
27 matches
Mail list logo
