Hi,
Thanks for splitting. It makes sense, because, as you know, the bug that
causes the crash is a separate problem from unintuitive error messages
which result from the way in which we parse expressions.
On 2019/03/22 14:09, Michael Paquier wrote:
> On Wed, Mar 20, 2019 at 06:17:27PM +0900,
On Thu, Mar 21, 2019 at 11:41:01PM +0800, Shaoqi Bai wrote:
> Have updated the patch doing as you suggested
+ RewindTest::setup_cluster($test_mode, ['-g']);
+ RewindTest::start_master();
There is no need to test for group permissions here, 002_databases.pl
already looks after that.
+ #
On Wed, Mar 20, 2019 at 06:17:27PM +0900, Michael Paquier wrote:
> The thing is that in order to keep the tests for the crash, we finish
> with the inintuitive RTE-related errors, so it is also inconsistent to
> not group things..
As I have seen no feedback from others regarding the changes in
On Fri, Mar 22, 2019 at 4:53 AM Robert Haas wrote:
>
> On Tue, Mar 19, 2019 at 7:26 AM Masahiko Sawada wrote:
> > In parsing vacuum command, since only PARALLEL option can have an
> > argument I've added the check in ExecVacuum to erroring out when other
> > options have an argument. But it
On 2019-Mar-21, Robert Haas wrote:
> I don't have a strong position on what the "right" thing
> to do here is, but I think if you want to know how many client
> transactions are being executed, you should count them on the client
> side, as pgbench does.
I think counting on the client side is
On Fri, 22 Mar 2019 at 05:04, Tom Lane wrote:
> Pushed with mostly-cosmetic adjustments.
Thanks for pushing this.
> I noticed a couple of loose ends that are somewhat outside the scope
> of the bug report, but maybe are worth considering now:
>
> 1. There's some inconsistency in the wording of
On Fri, Mar 22, 2019 at 10:15:59AM +0800, Andrey Borodin wrote:
> It seems to me that we have consensus that:
> 1. We need special role to create subscription
> 2. This role can create subscription with some security checks
> 3. We have complete list of possible security checks
These are
On Fri, Mar 22, 2019 at 02:35:41PM +1100, Haribabu Kommi wrote:
> Thanks for the correction. Yes, that is correct and it works fine.
Thanks for double-checking. Are there any objections with this patch?
--
Michael
signature.asc
Description: PGP signature
On Fri, Mar 22, 2019 at 02:45:24PM +1100, Haribabu Kommi wrote:
> How about letting the pg_basebackup to decide group permissions of the
> standby directory irrespective of the primary directory permissions.
>
> Default - permissions are same as primary
> --allow-group-access - standby directory
On Fri, 22 Mar 2019, 03:14 Nikita Glukhov, wrote:
> Hi.
>
> Attached patch enables throwing of errors in jsonb_path_match() in its
> non-silent mode when the jsonpath expression failed to return a singleton
> boolean. Previously, NULL was always returned, and it seemed to be
> inconsistent with
On Fri, Mar 22, 2019 at 11:42 AM Michael Paquier
wrote:
> On Thu, Mar 21, 2019 at 02:56:24PM -0400, Robert Haas wrote:
> > On Tue, Mar 19, 2019 at 2:29 AM Michael Paquier
> wrote:
> >> Hm. We have been assuming that the contents of a base backup inherit
> >> the permission of the source when
On Fri, Mar 22, 2019 at 12:24 PM Michael Paquier
wrote:
> On Thu, Mar 21, 2019 at 12:52:14PM +1100, Haribabu Kommi wrote:
> > Earlier attached patch is wrong.
>
> - oumask = umask(pg_file_create_mode);
> + oumask = umask(pg_mode_mask);
> Indeed that was wrong.
>
> > Correct patch attached.
On Thu, Mar 21, 2019 at 9:59 PM Alexander Korotkov
wrote:
> Attaches patches improving jsonpath parser. First one introduces
> cosmetic changes, while second gets rid of backtracking. I'm also
> planning to add high-level comment for both grammar and lexer.
The cosmetic changes look good to
Jesper, Imai-san,
Thanks for testing and reporting your findings.
On 2019/03/21 23:10, Imai Yoshikazu wrote:
> On 2019/03/20 23:25, Jesper Pedersen wrote:> Hi,
> > My tests - using hash partitions - shows that the extra time is spent in
> > make_partition_pruneinfo() for the relid_subplan_map
> 22 марта 2019 г., в 9:28, Michael Paquier написал(а):
>
> On Thu, Mar 21, 2019 at 10:06:03AM -0300, Euler Taveira wrote:
>> It will be really strange but I can live with that. Another idea is
>> CREATE bit to create subscriptions (without replicate) and SUBSCRIBE
>> bit to replicate tables.
On 22/03/19 3:05 PM, Tom Lane wrote:
> Michael Paquier writes:
>> I would be curious to hear the reason why such tool names have been
>> chosen from the start. The tools have been switched to C in 9e0ab71
>> from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from
>> 1999, and I
Michael Paquier writes:
> I would be curious to hear the reason why such tool names have been
> chosen from the start. The tools have been switched to C in 9e0ab71
> from 2003, have been introduced by Peter Eisentraut as of 240e4c9 from
> 1999, and I cannot spot the thread from the time where
On Thu, Mar 21, 2019 at 10:06:03AM -0300, Euler Taveira wrote:
> It will be really strange but I can live with that. Another idea is
> CREATE bit to create subscriptions (without replicate) and SUBSCRIBE
> bit to replicate tables. It is not just a privilege to create a
> subscription but also to
On Thu, Mar 21, 2019 at 12:52:14PM +1100, Haribabu Kommi wrote:
> Earlier attached patch is wrong.
- oumask = umask(pg_file_create_mode);
+ oumask = umask(pg_mode_mask);
Indeed that was wrong.
> Correct patch attached. Sorry for the inconvenience.
This looks better for the umask setting,
Hi Nagata-san,
sorry for te late reply.
Thank you for your comments, I have attached a patch that reflected it.
On Tue, 19 Mar 2019 15:13:04 +0900
Yugo Nagata wrote:
> I reviewed the patch. Here are some comments:
>
> /*
> + * RangeVarCheckNamespaceAccessNoError
> + * Returns true if
On Thu, Mar 21, 2019 at 02:56:24PM -0400, Robert Haas wrote:
> On Tue, Mar 19, 2019 at 2:29 AM Michael Paquier wrote:
>> Hm. We have been assuming that the contents of a base backup inherit
>> the permission of the source when using pg_basebackup because this
>> allows users to keep a nodes in a
On Thu, Mar 21, 2019 at 10:02:40AM -0400, Tom Lane wrote:
> So there seems like a real risk that taking away createuser would
> result in security holes, not just annoying-but-trivial script update
> work. That puts me more in the camp of "if we're going to do anything,
> rename it with a pg_
On Thu, Mar 21, 2019 at 08:17:32AM +0100, Fabien COELHO wrote:
> I can try, but I must admit that I'm fuzzy about the actual issue. Is there
> a problem on a streaming replication with inconsistent checksum settings, or
> not?
>
> You seem to suggest that the issue is more about how some commands
On 2019/03/22 2:23, David Steele wrote:
> On 3/14/19 6:19 AM, Amit Langote wrote:
>> On 2019/03/14 2:11, Pavel Stehule wrote:
>>>
I've attached v11 of the patch, which merges most of Justin's changes and
some of my own on top -- documentation and partition size column names.
>>
>> Maybe,
Hi.
Attached patch enables throwing of errors in jsonb_path_match() in its
non-silent mode when the jsonpath expression failed to return a singleton
boolean. Previously, NULL was always returned, and it seemed to be
inconsistent with the behavior of other functions, in which structural and
Hi everyone,
A very common question among new users is how wal_level works and it
levels. I heard about some situations like that, a user create a new
publication in its master database and he/she simply does not change
wal_level to logical, sometimes, this person lost maintenance window, or a
Hi Jesper
On 2019-Mar-21, Jesper Pedersen wrote:
> running
>
> pgbench -M prepared -f select.sql
>
> I'm seeing 82.64% spent in GetCachedPlan(). plan_cache_mode is auto.
Hmm, I can't reproduce this at all ... I don't even see GetCachedPlan
in the profile. Do you maybe have some
On 2019-Mar-18, Alvaro Herrera wrote:
> A pretty silly bug remains here. Watch:
>
> create table pk (a int primary key) partition by list (a);
> create table pk1 partition of pk for values in (1);
> create table fk (a int references pk);
> insert into pk values (1);
> insert into fk values (1);
David Rowley writes:
> [ eclass_indexes_v4.patch ]
I still don't like this approach too much. I think we can fairly easily
construct the eclass_indexes at a higher level instead of trying to
manage them in add_eq_member, and after some hacking I have the attached.
Some notes:
* To be sure of
On 2019-Mar-21, Alexander Korotkov wrote:
> However, I think this still can be backpatched correctly. We can
> determine whether xlog record data contains deleteXid by its size.
> See the attached patch. I haven't test this yet. I'm going to test
> it. If OK, then push.
Wow, this is so
On 2019-Mar-21, Robert Haas wrote:
> On Wed, Mar 20, 2019 at 4:42 PM Alvaro Herrera
> wrote:
> > Unless there are any objections to fixing the REPLICA IDENTITY bug, I
> > intend to push that tomorrow.
>
> I still think that this is an ill-considered, piecemeal approach to a
> problem that
On 2019-Mar-21, Alvaro Herrera wrote:
> I figured this out. It's actually a bug in pg11, whereby we're setting
> a dependency wrongly. If you try to do pg_describe_object() the
> pg_depend entries for tables set up the way the regression test does it,
> it'll fail with a "cache lookup failed
On Fri, Mar 22, 2019 at 6:57 AM Robert Haas wrote:
> On Thu, Mar 21, 2019 at 2:26 AM Haribabu Kommi
> wrote:
> > Based on the above new options that can be added to target_session_attrs,
> >
> > primary - it is just an alias to the read-write option.
> > standby, prefer-standby - These options
On 2019-Mar-18, Alvaro Herrera wrote:
> > I'm getting a failure in the pg_upgrade test:
> >
> > --
> > +-- Name: pk5 pk5_pkey; Type: CONSTRAINT; Schema: regress_fk; Owner:
> > jpedersen
> > +--
> > +
> > +ALTER TABLE ONLY regress_fk.pk5
> > +ADD CONSTRAINT pk5_pkey PRIMARY KEY (a);
> > +
>
On Thu, 21 Mar 2019 at 15:18, Alexander Korotkov
wrote:
> On Thu, Mar 21, 2019 at 9:26 PM Simon Riggs wrote:
>
>
> > It's been pointed out to me that 52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478
> > introduced a WAL incompatibility that has not been flagged.
> >
> > In ginRedoDeletePage() we use
On Fri, Mar 22, 2019 at 5:16 AM Andres Freund wrote:
> Hi,
>
> Attached is a version of just the first patch. I'm still updating it,
> but it's getting closer to commit:
>
> - There were no tests testing EPQ interactions with DELETE, and only an
> accidental test for EPQ in UPDATE with a
On Thu, Mar 21, 2019 at 7:46 AM Antonin Houska wrote:
> Nevertheless, with the current version of our patch, PG should be resistant
> against such a partial write anyway because we chose to align XLOG records to
> 16 bytes (as long as the encryption is enabled) for the following reasons:
>
> If
On Thu, Mar 21, 2019 at 2:18 AM Haribabu Kommi wrote:
> With Inclusion of parallel worker transactions, the TPS will be a higher
> number,
> thus user may find it as better throughput. This is the case with one of our
> tool.
> The tool changes the configuration randomly to find out the best
On 3/19/19 4:44 PM, Chris Travers wrote:
>
>
> On Tue, Mar 19, 2019 at 12:19 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
>
> On 3/19/19 10:59 AM, Chris Travers wrote:
> >
> >
> > Not discussing whether any particular committer should pick this
> up
On Thu, Mar 21, 2019 at 2:26 AM Haribabu Kommi wrote:
> Based on the above new options that can be added to target_session_attrs,
>
> primary - it is just an alias to the read-write option.
> standby, prefer-standby - These options should check whether server is
> running in recovery mode or not
On Tue, Mar 19, 2019 at 7:26 AM Masahiko Sawada wrote:
> In parsing vacuum command, since only PARALLEL option can have an
> argument I've added the check in ExecVacuum to erroring out when other
> options have an argument. But it might be good to make other vacuum
> options (perhaps except for
On Tue, Mar 19, 2019 at 3:59 AM Kyotaro HORIGUCHI
wrote:
> The leader doesn't continue heap-scan while index vacuuming is
> running. And the index-page-scan seems eat up CPU easily. If
> index vacuum can run simultaneously with the next heap scan
> phase, we can make index scan finishes almost
On Wed, Mar 20, 2019 at 9:24 PM Tom Lane wrote:
> Joel Jacobson writes:
> > I've seen a performance trick in other hash functions [1]
> > to instead read multiple bytes in each iteration,
> > and then handle the remaining bytes after the loop.
> > [1]
On Wed, Mar 20, 2019 at 4:42 PM Alvaro Herrera wrote:
> Unless there are any objections to fixing the REPLICA IDENTITY bug, I
> intend to push that tomorrow.
I still think that this is an ill-considered, piecemeal approach to a
problem that deserves a better solution.
--
Robert Haas
On Fri, Jan 4, 2019 at 6:23 AM Peter Eisentraut
wrote:
> What bothers me about this patch is that it subtly changes what a
> trigger means. It currently means, say, INSERT was executed on this
> table. You are expanding that to mean, a row was inserted into this
> table -- somehow.
Yeah. The
On Tue, Dec 25, 2018 at 10:05 PM Alvaro Herrera
wrote:
> Well, REFRESH CONCURRENTLY runs completely different than non-concurrent
> REFRESH. The former updates the existing data by observing the
> differences with the previous data; the latter simply re-runs the query
> and overwrites
On Thu, Mar 21, 2019 at 9:26 PM Simon Riggs wrote:
> On Thu, 13 Dec 2018 at 14:48, Alexander Korotkov wrote:
>> On Thu, Dec 13, 2018 at 10:46 PM Andres Freund wrote:
>> > On 2018-12-13 22:40:59 +0300, Alexander Korotkov wrote:
>> > > It doesn't mater, because we release all locks on every
>
> I find this to be unactionably vague. What does it mean to claim "an
> LSN is visible"? An LSN might not even point to a WAL record, or it
> might point to one that has nontransactional effects. Moreover, any
> behavior of this sort would destroy what I regard as a bedrock property
> of
On Tue, Mar 19, 2019 at 2:29 AM Michael Paquier wrote:
> Hm. We have been assuming that the contents of a base backup inherit
> the permission of the source when using pg_basebackup because this
> allows users to keep a nodes in a consistent state without deciding
> which option to use. Do you
On Thursday, March 21, 2019 7:47 PM, Tom Lane wrote:
> David Steele da...@pgmasters.net writes:
>
> > > > > > Why are you not including a test for \set VERBOSITY verbose?
>
> > What do you think, Peter? Is the extra test valuable or will it cause
> > unpredictable outputs as Tom and Michael
David Steele writes:
> Why are you not including a test for \set VERBOSITY verbose?
> What do you think, Peter? Is the extra test valuable or will it cause
> unpredictable outputs as Tom and Michael predict?
I'm not really sure why this is open for discussion.
regression=# \set VERBOSITY
On Wed, Mar 20, 2019 at 9:20 PM Bruno Hass wrote:
> I would like to optimize the jsonb key access operations. I could not find
> the discussion you've mentioned, but I am giving some thought to the idea.
>
> Instead of storing lengths, could we dedicate the first chunk of the TOASTed
> jsonb to
On Thu, 13 Dec 2018 at 14:48, Alexander Korotkov
wrote:
> On Thu, Dec 13, 2018 at 10:46 PM Andres Freund wrote:
> > On 2018-12-13 22:40:59 +0300, Alexander Korotkov wrote:
> > > It doesn't mater, because we release all locks on every buffer at one
> > > time. The unlock order can have effect
Hi Andreas,
On 2/15/19 11:59 AM, Peter Eisentraut wrote:
On 14/02/2019 20:13, Andres Freund wrote:
On 2019-02-04 11:02:44 +0900, Michael Paquier wrote:
+1. I have just looked at the patch, and my take is that listing all
the ways to build Postgres directly in the README is just a
duplication
On 2/4/19 5:54 AM, Michael Paquier wrote:
On Mon, Jan 07, 2019 at 10:44:24PM +0100, didier wrote:
On Sat, Jan 5, 2019 at 6:30 PM Tom Lane wrote:
Peter Eisentraut writes:
Why are you not including a test for \set VERBOSITY verbose?
Stability of the output would be a problem ...
Yes it
On 2/22/19 9:44 PM, Fabien COELHO wrote:
Hmmm, I do not buy the typing argument: "host" is actually for
everything, including directories. I do not think that adding "hostdir"
would be desirable.
In any case, the existing doco never comes out and states either
rule set in so many words.
On Tue, Mar 19, 2019 at 4:15 PM Peter Geoghegan wrote:
> Heikki and I discussed this issue privately, over IM, and reached
> final agreement on remaining loose ends. I'm going to use his code for
> _bt_findsplitloc(). Plan to push a final version of the first four
> patches tomorrow morning PST.
Hi Hironobu,
On 3/3/19 12:55 PM, Fabien COELHO wrote:
Indeed, the patch needs a rebase & conflit resolution. I'll do it. Later.
Here is an update:
- take advantage of pg_bitutils (although I noted that the "slow"
popcount there could be speeded-up and shorten with a bitwise operator
On 3/14/19 6:19 AM, Amit Langote wrote:
On 2019/03/14 2:11, Pavel Stehule wrote:
I've attached v11 of the patch, which merges most of Justin's changes and
some of my own on top -- documentation and partition size column names.
Maybe, we should set this ready for committer then?
There
On 21/03/2019 18:06, Andrey Borodin wrote:
21 марта 2019 г., в 2:30, Heikki Linnakangas
написал(а): one remaining issue that needs to be fixed:
During Hot Standby, the B-tree code writes a WAL reord, when a
deleted page is recycled, to prevent the deletion from being
replayed too early in the
> 21 марта 2019 г., в 2:30, Heikki Linnakangas написал(а):
> one remaining issue that needs to be fixed:
>
> During Hot Standby, the B-tree code writes a WAL reord, when a deleted
> page is recycled, to prevent the deletion from being replayed too early
> in the hot standby. See
David Rowley writes:
> [ drop_func_if_not_exists_fix_v9.patch ]
Pushed with mostly-cosmetic adjustments.
I noticed a couple of loose ends that are somewhat outside the scope
of the bug report, but maybe are worth considering now:
1. There's some inconsistency in the wording of the error
On Tue, Mar 12, 2019 at 10:27 AM Michael Paquier
wrote:
> It could be an idea to split the patch in two pieces:
> - One patch which refactors the code for the new option in
> PostgresNode.pm
> - Second patch for the new test with integration in RewindTest.pm.
> This should touch different parts
On Mon, 18 Mar 2019 at 02:18, Tomas Vondra wrote:
> Yes, it was using the toasted value directly. The attached patch
> detoasts the value explicitly, similarly to the per-column stats, and it
> also removes the 1MB limit.
I just made a pass over 0001 and 0002.
0002 is starting to look pretty
Hi Alvaro,
On 3/18/19 6:02 PM, Alvaro Herrera wrote:
I spent a few hours studying this and my conclusion is the opposite of
yours: we should make addFkRecurseReferencing the recursive one, and
CloneFkReferencing a non-recursive caller of that. So we end up with
both addFkRecurseReferenced and
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This patch is particularly helpful in processing OpenStreetMap Data in
On Thu, Mar 14, 2019 at 3:54 PM Masahiko Sawada
wrote:
>
> >
> >
> > Ok. I will run some tests. But please note that this patch is a bug fix
> to address the performance issue that is caused by having to rewrite the
> entire table when all-visible bit is set on the page during first vacuum.
> So
Jeremy Finzel writes:
>> I'd be in favor of that for recovery_target_xid, but I'm not at all
>> convinced about changing the behavior for a target LSN. The fact that
>> the target is a subcommit seems irrelevant when you specify by LSN.
> For this use case, my goal is simply to be able to
Hi Jesper,
On 2019/03/20 23:25, Jesper Pedersen wrote:> Hi,
>
> On 3/19/19 11:15 PM, Imai, Yoshikazu wrote:
>> Here the details.
>>
>> [creating partitioned tables (with 1024 partitions)]
>> drop table if exists rt;
>> create table rt (a int, b int, c int) partition by range (a);
>> \o
Andreas Karlsson writes:
> On 3/21/19 7:07 AM, Chris Travers wrote:
>> 1. createuser/dropuser are things that I don't consider good ways of
>> creating users anyway.
> Those binaries are pretty convenient to use in scripts since they handle
> SQL escaping for you, but probably not convenient
Sure, please go ahead.
Regards,
Prajwal.
On Thu, 21 Mar 2019, 19:11 Ramanarayana, wrote:
> Hi,
> Can I take this up?
>
> Regards,
> Ram
>
On Tue, Mar 19, 2019 at 8:10 PM Alexander Korotkov
wrote:
> On Sun, Mar 17, 2019 at 6:03 PM Tom Lane wrote:
> > Andrew Dunstan writes:
> > > Why are we installing the jsonpath_gram.h file? It's not going to be
> > > used by anything else, is it? TBH, I'm not sure I see why we're
> > >
Hi,
Can I take this up?
Regards,
Ram
Hi,
On Thu, Mar 21, 2019 at 3:10 AM Shaun Thomas
wrote:
>
> I can't really speak for the discussion related to `storage.sgml`, but
> I based my investigation on the existing patch to `create_table.sgml`.
> About the only thing I would suggest there is to possibly tweak the
> wording.
>
> * "The
Then someone who don't want the symlinks could delete them.
Or the symlinks could ship in an optional postgesql-legacy-symlinks package.
On Wed, Mar 20, 2019 at 6:32 PM Alvaro Herrera wrote:
>
> On 2019-Mar-20, Fred .Flintstone wrote:
>
> > Even just creating symlinks would be a welcome change.
The binaries:
* clusterdb
* createdb
* createuser
* dropdb
* dropuser
* reindexdb
* vacuumdb
On Wed, Mar 20, 2019 at 8:13 PM Jonathan S. Katz wrote:
>
> On 3/20/19 2:08 PM, Alvaro Herrera wrote:
> > On 2019-Mar-20, Euler Taveira wrote:
> >
> >> Em qua, 20 de mar de 2019 às 14:57, Tom Lane
I would be fine with that.
We can make an exception for psql.
As long as we get rid of:
* clusterdb
* createdb
* createuser
* dropdb
* dropuser
* reindexdb
* vacuumdb
On Wed, Mar 20, 2019 at 7:11 PM Tom Lane wrote:
>
> "Fred .Flintstone" writes:
> > Even just creating symlinks would be a
Le 20/03/2019 à 10:06, Amit Langote a écrit :
> Hi Thibaut,
>
> On 2019/03/19 23:58, Thibaut Madelaine wrote:
>> I kept on testing with sub-partitioning.
> Thanks.
>
>> I found a case, using 2 default partitions, where a default partition is
>> not pruned:
>>
>> --
>>
>> create table
>
> It would seem like what you're asking for is to continue until the commit
> of the parent transaction, not just the next commit after the subcommit.
> Otherwise (if that's an unrelated xact) the subxact would still not be
> committed, so that you might as well have stopped short of it.
>
Em qua, 20 de mar de 2019 às 21:57, Michael Paquier
escreveu:
>
> Perhaps we would want something at database level different from GRANT
> CREATE ON DATABASE, but only for subscriptions? This way, it is
> possible to have per-database groups having the right to create
> subscriptions, and I'd
Hi Amit,
On 3/19/19 8:41 PM, Amit Langote wrote:
I have fixed all. Attached updated patches.
The comments in the thread has been addressed, so I have put the CF
entry into Ready for Committer.
Best regards,
Jesper
On 3/21/19 7:07 AM, Chris Travers wrote:
1. createuser/dropuser are things that I don't consider good ways of
creating users anyway. I think we should just consider removing these
binaries. The SQL queries are better, more functional, and can be
rolled back as a part of a larger
On 2019-Mar-20, Tomas Vondra wrote:
> So to me this seems like a fairly invasive change (potentially breaking
> quite a few scripts/tools) just to address a minor inconvenience.
I don't think anything would break, actually. What are you thinking
would break?
--
Álvaro Herrera
Re: David Steele 2019-03-20 <8a85bece-b18f-0433-acf3-d106b31f0...@pgmasters.net>
> > > Oh, right. So the way to go would be to use _("FAILED "), and
> > > ask translators to use the same length.
> >
> > Note there's no translation for pg_regress. All these _() markers are
> > currently
Tom Lane wrote:
> Robert Haas writes:
> > If the WAL *is* encrypted, the state at this point is that the block
> > is unreadable, because the first 4kB of the block is the first half of
> > the bits that resulted from encrypting 8kB of data that includes the
> > new record, and the second 4kB
Hello
> * in_parallel is true if we're performing parallel lazy vacuum. Since any
> * updates are not allowed during parallel mode we don't update statistics
> * but set the index bulk-deletion result to *stats. Otherwise we update it
> * and set NULL.
lazy_cleanup_index has in_parallel argument
Hi!
> Perhaps we would want something at database level different from GRANT
> CREATE ON DATABASE, but only for subscriptions?
How about 4 checks to create subscription for nonsuperuser?
1. Special role for create subscription
2. CREATE ON DATABASE privilege
3. INSERT, UPDATE, DELETE, TRUNCATE,
Hi!
> - If the user's permissions are later revoked, the subscription is unaffected.
Now it work the same, if we revoke superuser, subscription is unaffected and
replication still work
Don't check grants in target database is very dangerous, i create publication
with system tables(it's not
Anyway, as this stuff is very useful for upgrade scenarios
a-la-pg_upgrade, for backup validation and as it does not produce false
positives, I would really like to get something committed for v12 in its
simplest form...
Fine with me, the detailed doc is not a showstopper and can be
Bonjour Michaël,
On Wed, Mar 20, 2019 at 05:46:32PM +0100, Fabien COELHO wrote:
I think that the motivation/risks should appear before the solution. "As xyz
..., ...", or there at least the logical link should be outlined.
It is not clear for me whether the following sentences, which seems
On Thu, Mar 21, 2019 at 12:45:57PM +1100, Haribabu Kommi wrote:
> The commit f2ab389 is later back-patch to version till 9.3 in commit
> 19acfd65. I guess that building the windows installer for all the
> versions using the same visual studio is may be the reason behind
> that back-patch.
I did
On Thu, Mar 21, 2019 at 07:59:24AM +0900, Michael Paquier wrote:
> Please note that we do that in other tools as well and we live fine
> with that as pg_basebackup, pg_rewind just to name two. I am not
> saying that it is not a problem in some cases, but I am saying that
> this is not a problem
On Wed, Mar 20, 2019 at 5:01 PM Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Robert Haas [mailto:robertmh...@gmail.com]
> > I really dislike having both target_sesion_attrs and
> > target_server_type. It doesn't solve any actual problem. master,
> > slave, prefer-save,
On Wed, Mar 20, 2019 at 7:38 PM Amit Kapila wrote:
> On Sun, Feb 10, 2019 at 10:54 AM Haribabu Kommi
> wrote:
> > On Sat, Feb 9, 2019 at 4:07 PM Amit Kapila
> wrote:
> >>
> >> I don't think so. It seems to me that we should consider it as a
> >> single transaction. Do you want to do the leg
On Thu, Mar 21, 2019 at 1:49 AM Michael Paquier wrote:
> On Thu, Mar 21, 2019 at 08:41:32AM +0900, Tatsuo Ishii wrote:
> >> Can someone describe a scenario where this (name of the binary not
> >> clearly indicating it's related postgres) causes issues in practice? On
> >> my system, there are
On 3/20/19 8:19 PM, Andres Freund wrote:
On 2019-03-20 15:15:02 -0400, Jonathan S. Katz wrote:
If we are evaluating this whole symlink / renaming thing, there could be
arguments for a "pgsql" alias to psql (or vice versa), but I don't think
"pg_sql" makes any sense and could be fairly
96 matches
Mail list logo
