On 02/12/2018 15:40, Andrey Borodin wrote:
> Daniel have raised important interface question in his review. Using
> libc-style locale in lc_collate is not a perfect choice for many ICU-only
> collations.
> I'd work on patch if I knew how to improve the interface, but I need input
> from communit
Hello
thank you for review!
> but I think that this patch should document clearly that if
> primary_conninfo or primary_slot_name are changed then the WAL receiver
> is stopped immediately.
Good idea, will change.
> /*
> - * replication slot name; is also used for walreceiver to connect with
> On Tue, Dec 11, 2018 at 3:13 AM Andres Freund wrote:
>
> Hi,
>
> On 2018-11-26 17:55:57 -0800, Andres Freund wrote:
> > FWIW, now that oids are removed, and the tuple table slot abstraction
> > got in, I'm working on rebasing the pluggable storage patchset ontop of
> > that.
>
> I've pushed a ve
Hello
After some thinking i can rewrite this patch in another way.
This is better or worse?
regards, Sergei
oops, forgot attach patch
11.12.2018, 13:14, "Sergei Kornilov" :
> Hello
>
> After some thinking i can rewrite this patch in another way.
>
> This is better or worse?
>
> regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 4a7121a..bce99ce 100644
--- a/doc/src/sgm
Hello,
a customer recently mentioned that they'd like to be able to see when a
(md5, scram) role had their password last changed.
Use-cases for this would be issueing an initial password and then later
making sure it got changed, or auditing that all passwords get changed
once a year. You can do
On 11/12/2018 23:33, Michael Banck wrote:
Hello,
a customer recently mentioned that they'd like to be able to see when a
(md5, scram) role had their password last changed.
Use-cases for this would be issueing an initial password and then later
making sure it got changed, or auditing that all pa
We were just busy shooting down a different suggestion of
behavior-changing GUCs. A GUC that turns all ALTERs into no-ops
sure seems like a foot-gun to me.
Yeah, I like EXPLAIN better.
+1 for EXPLAIN
IMVHO, and for "symmetry" with existing mechanisms:
* EXPLAIN ALTER TABLE ==> "DDL dry ru
Hi,
Am Dienstag, den 11.12.2018, 23:45 +1300 schrieb Gavin Flower:
> On 11/12/2018 23:33, Michael Banck wrote:
> > a customer recently mentioned that they'd like to be able to see when a
> > (md5, scram) role had their password last changed.
> >
> > Use-cases for this would be issueing an initial
On 12/8/18 8:21 PM, Jeremy Finzel wrote:
There are 2.1 million files in pg_replslot which I don't think is
normal? Any ideas as to where I should be looking or what could cause this?
Postgres spills changes on disk when you have a big transaction:
https://blog.anayrat.info/en/2018/03/10/logic
Hello,
This candidate patch is kind of a bug-solving patch, it applies to one
unique file : src/backend/parser/parse_utilcmd.c,
on function transformTableLikeClause.
Its aim is to include the "top-level" comment of the object (table,
view, matview...)
that is being copied ; alongside the lower-le
...with thunderbird plain-text sorted...
$ diff -c parse_utilcmd_old.c parse_utilcmd.c
*** parse_utilcmd_old.c 2018-12-11 12:44:52.288309000 +0100
--- parse_utilcmd.c 2018-12-11 12:44:52.208308782 +0100
***
*** 918,923
--- 918,941
On 2018-Dec-11, Jose Luis Tallon wrote:
> * EXPLAIN PERFORM ALTER TABLE (EXPLAIN EXEC?) would explain + do
>
> ...and bonus points for explaining each step just before it is
> performed. This way, It'd be easy for users to verify that a particular step
> (i.e. table rewrite) is the one
Hi Michael,
On 12/10/18 8:43 PM, Michael Paquier wrote:
> On Mon, Dec 10, 2018 at 10:21:23AM -0500, David Steele wrote:
>> We recommend that archive commands not overwrite an existing segment.
>> Some backup tools will compare the contents and succeed if they are
>> equal, but in this case that wi
Andres Freund writes:
> I don't quite get why we don't instead just represent "never vacuumed"
> by storing a more meaningful value in relpages?
Mostly, not wanting to break clients that look at these fields.
If catalog compatibility weren't a concern, I'd seriously consider
replacing both of the
Hi,
On 4/24/17 22:26, Florin Asavoaie wrote:
> If there's nobody against this, I can try to do the patch myself,
> doesn't look too difficult (I expect it to simply work by
> calling SSL_set_tlsext_host_name(SSL_context, PQhost(conn))) somewhere
> in initialize_SSL in fe-secure-openssl.c.
I had
Michael Banck writes:
> The same was requested in https://dba.stackexchange.com/questions/91252/
> how-to-know-when-postgresql-password-is-changed so I was wondering
> whether this would be a welcome change/addition, or whether people think
> it's not worth bothering to implement it?
This has all
maxzor writes:
> This candidate patch is kind of a bug-solving patch, it applies to one
> unique file : src/backend/parser/parse_utilcmd.c,
> on function transformTableLikeClause.
> Its aim is to include the "top-level" comment of the object (table,
> view, matview...)
> that is being copied ; alo
On 12/11/18 3:52 PM, Pablo Iranzo Gómez wrote:> I came to this old
thread while trying to figure out on how to setup
postgres replication behind OpenShift/Kubernetes behind a route (which
only forwards 80 or 443 traffic), but could work if SNI is supported on
the client using it.
I haven't fou
Hi,
On 2018-12-11 09:47:38 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I don't quite get why we don't instead just represent "never vacuumed"
> > by storing a more meaningful value in relpages?
>
> Mostly, not wanting to break clients that look at these fields.
> If catalog compatibility
Andres Freund writes:
> On 2018-12-11 09:47:38 -0500, Tom Lane wrote:
>> And why do you blame it on this representation? We don't believe that
>> relpages is the actual size of the table.
> No, but we assume that there's 10 pages. Even if both relpages and the
> actual relation stats say there's
Hi,
On 2018-12-11 13:43:47 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-12-11 09:47:38 -0500, Tom Lane wrote:
> >> And why do you blame it on this representation? We don't believe that
> >> relpages is the actual size of the table.
>
> > No, but we assume that there's 10 pages. Ev
Andres Freund writes:
> How's being unable to distinguish "never vacuumed" from "table is
> knowingly empty right now" not constrained by the representation?
Well, OK, it is constrained, but even if it weren't I'd be afraid to
assume a table is totally empty, even if it was so the last time
ANALY
On 12/11/18 9:56 AM, Tom Lane wrote:
> I've heard that if you want to implement a password aging policy, PAM
> authentication can manage that for you; but I don't know the details.
Interesting idea ... could use pam-pgsql[1] and PAM as the
authentication method. Might result in another connection
Hi,
On 2018-12-11 13:59:55 -0500, Tom Lane wrote:
> Andres Freund writes:
> > How's being unable to distinguish "never vacuumed" from "table is
> > knowingly empty right now" not constrained by the representation?
>
> Well, OK, it is constrained, but even if it weren't I'd be afraid to
> assume
Andres Freund writes:
> To me the whole logic around this largely seems to be cargo culting
> things forward.
Well, feel free to propose some other behavior --- but I'm more
worried about how badly it will fail when wrong than whether the
plans are better when right.
rega
On Tue, Dec 11, 2018 at 3:06 PM Tom Lane wrote:
> > ... but this step sounds particularly scary. Nothing
> > guarantees that the second WAL record ever gets replayed.
>
> I'm not following? How would a slave not replay that record, other
> than by diverging to a new timeline? (in which case it'
Robert Haas writes:
> On Tue, Dec 11, 2018 at 3:06 PM Tom Lane wrote:
>> Anyway, if your assumption is that WAL replay must yield bit-for-bit
>> the same state of the not-truncated pages that the master would have,
>> then I doubt we can make this work. In that case we're back to the
>> type of
On Tue, Dec 11, 2018 at 12:39 PM Robert Haas wrote:
> How much have you considered the possibility that my rejection of that
> approach was a stupid and wrong-headed idea? I'm not sure I still
> believe that not writing those buffers would have a meaningful
> performance cost. Truncating relatio
Hi,
On 2018-12-10 15:38:55 -0500, Tom Lane wrote:
> Also, I'm not entirely sure whether there's anything in our various
> replication logic that's dependent on vacuum truncation taking AEL.
> Offhand I'd expect the reduced use of AEL to be a plus, but maybe
> I'm missing something.
It'd be a *MAJ
On 11/26/18 10:13 PM, David Steele wrote:
> Hackers,
>
> I propose we remove the deprecated exclusive backup mode of
> pg_start_backup()/pg_stop_backup() for Postgres 12.
>
> The exclusive backup mode has a serious known issue. If Postgres
> terminates ungracefully during a backup (due to hardwa
On Tue, Dec 11, 2018 at 10:14 AM Andrey Borodin wrote:
> > 11 дек. 2018 г., в 3:43, Alexander Korotkov
> > написал(а):
> >
> > Attached patch appears to be incomplete. GinPageSetDeleteXid() is
> > called only in ginRedoDeletePage(), so only in recovery, while it
> > should be set during normal
On Mon, 2018-11-26 at 10:18 +0100, Magnus Hagander wrote:
> > [about managing backups from pre- and post-file-system-backup scrips]
> > > I agree with your point that it's not an uncommon thing to need. If a
> > > good solution
> > > for it can be proposed that requires the exclusive backup interf
Hi,
On 2018-12-09 18:43:14 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
> >> Well, that's just a different very-easily-broken assumption. There are
> >> a lot of things that make auto-assigned OIDs unstable, and I do not think
> >> that we want
While using printf to do some good old fashioned print debugging, I
noticed that it seemed like my printf statements in the executor were
sometimes not getting printed to the log at all, and sometimes getting
printed out *before* the ones I have in the planner.
Upon further investigation I realize
Hi,
On 2018-12-10 15:38:55 -0500, Tom Lane wrote:
> Reflecting on that some more, it seems to me that we're never going to
> get to a solution that everybody finds acceptable without some rather
> significant restructuring at the buffer-access level.
I'm thinking about your proposal RN. Here's w
On Tue, Dec 11, 2018 at 1:50 AM Alexander Korotkov wrote:
> On Sun, Dec 9, 2018 at 10:25 PM Alexander Korotkov
> wrote:
> > On Sat, Dec 8, 2018 at 12:48 PM Andrey Borodin wrote:
> > > > 8 дек. 2018 г., в 6:54, Alexander Korotkov
> > > > написал(а):
> > > >
> > > > Yep, please find attached dr
James Coleman writes:
> While using printf to do some good old fashioned print debugging, I
> noticed that it seemed like my printf statements in the executor were
> sometimes not getting printed to the log at all, and sometimes getting
> printed out *before* the ones I have in the planner.
> Upo
On 12/11/18, Andres Freund wrote:
> I've attached a patch implementing that. I'm not particularly in love
> with FirstGenbkiObjectId as the symbol, but I couldn't think of
> something more descriptive.
How about FirstAutoAssignedObjectId?
-John Naylor
Hi,
On 2018-12-11 19:33:23 -0500, John Naylor wrote:
> On 12/11/18, Andres Freund wrote:
> > I've attached a patch implementing that. I'm not particularly in love
> > with FirstGenbkiObjectId as the symbol, but I couldn't think of
> > something more descriptive.
>
> How about FirstAutoAssignedO
On Mon, Dec 10, 2018 at 10:52:37PM +0900, Michael Paquier wrote:
> OK. Sure, let's do as you suggest then. I'll wait a couple of days
> before committing the patch so as if someone has extra comments they
> have the time to post. So please feel free to comment!
And done this way. Thanks for th
On Fri, Dec 07, 2018 at 11:46:05AM +0900, Michael Paquier wrote:
> On Thu, Dec 06, 2018 at 10:48:59PM -0300, Alvaro Herrera wrote:
>> I think adding a pg_partition_root() call to as many pg_partition_tree
>> tests as you modified is overkill ... OTOH I'd have one test that
>> invokes pg_partition_t
On Wed, Dec 12, 2018 at 6:08 AM Tom Lane wrote:
> Well, if *you're* willing to entertain that possiblity, I'm on board.
> That would certainly lead to a much simpler, and probably back-patchable,
> fix.
I think we should, then. Simple is good.
Just thinking about this a bit, the problem with tru
Hi,
On 2018-12-12 10:49:59 +0900, Robert Haas wrote:
> Just thinking about this a bit, the problem with truncating first and
> then writing the WAL record is that if the WAL record never makes it
> to disk, any physical standbys will end up out of sync with the
> master, leading to disaster. But t
On Wed, Dec 12, 2018 at 7:24 AM David Steele wrote:
> Attached is the patch.
>
> I was a bit surprised by how much code went away. There was a lot of
> code dedicated to making sure that backup_label got renamed on shutdown,
> that there was not an exclusive backup running, etc.
>
> There were no
On Tue, Dec 11, 2018 at 09:15:16AM -0500, David Steele wrote:
> It looks to me like the history file is written first, and then the
> .partial. But because we process WAL alphabetically the .partial ends
> up being pushed first.
Yes, that's right.
> The idea is to stake a claim to the timeline a
On Wed, Dec 12, 2018 at 11:05:36AM +0900, Robert Haas wrote:
> I wish to point out that there currently seem to be more votes against
> this proposal than for it, and that nobody should commit a patch
> unless there is a consensus that it should be committed, whether or
> not the committer personal
Hi,
On 2018-12-12 11:05:36 +0900, Robert Haas wrote:
> As for my vote, I do not buy the idea that because we're changing some
> stuff about recovery.conf we should go ahead and do this too. Yes,
> they are related, but just because you adjust your backup/restore
> script/tool to cope with one cha
On 2018-12-12 11:32:55 +0900, Michael Paquier wrote:
> On Wed, Dec 12, 2018 at 11:05:36AM +0900, Robert Haas wrote:
> > I wish to point out that there currently seem to be more votes against
> > this proposal than for it, and that nobody should commit a patch
> > unless there is a consensus that it
On Wed, Dec 12, 2018 at 11:29 AM Michael Paquier wrote:
> I really don't think that it is a good idea to link a future timeline
> within a segment which includes in its name a direct reference to its
> current timeline. Also I don't buy much the argument that those
> segments are a nuisance as w
On 12/11/18 9:05 PM, Robert Haas wrote:
> On Wed, Dec 12, 2018 at 7:24 AM David Steele wrote:
>> Attached is the patch.
>
> As for my vote, I do not buy the idea that because we're changing some
> stuff about recovery.conf we should go ahead and do this too. Yes,
> they are related, but just bec
On Tue, Dec 11, 2018 at 11:47 PM Tom Lane wrote:
> Andres Freund writes:
> > I don't quite get why we don't instead just represent "never vacuumed"
> > by storing a more meaningful value in relpages?
>
> Mostly, not wanting to break clients that look at these fields.
> If catalog compatibility we
On 12/11/18 11:06 PM, Robert Haas wrote:
> On Wed, Dec 12, 2018 at 11:29 AM Michael Paquier wrote:
>> I really don't think that it is a good idea to link a future timeline
>> within a segment which includes in its name a direct reference to its
>> current timeline. Also I don't buy much the argu
On Wed, Dec 12, 2018 at 1:13 PM David Steele wrote:
> On 12/11/18 11:06 PM, Robert Haas wrote:
> > On Wed, Dec 12, 2018 at 11:29 AM Michael Paquier
> > wrote:
> >> I really don't think that it is a good idea to link a future timeline
> >> within a segment which includes in its name a direct refe
On Wed, Dec 12, 2018 at 11:44 AM Andres Freund wrote:
> On 2018-12-12 11:32:55 +0900, Michael Paquier wrote:
> > On Wed, Dec 12, 2018 at 11:05:36AM +0900, Robert Haas wrote:
> > > I wish to point out that there currently seem to be more votes against
> > > this proposal than for it, and that nobo
On Wed, Dec 12, 2018 at 1:09 PM David Steele wrote:
> On 12/11/18 9:05 PM, Robert Haas wrote:
> > On Wed, Dec 12, 2018 at 7:24 AM David Steele
> wrote:
> >> Attached is the patch.
> >
> > As for my vote, I do not buy the idea that because we're changing some
> > stuff about recovery.conf we shou
On 11/27/18 10:05 AM, Andreas Karlsson wrote:
> On 11/27/18 3:46 PM, Stephen Frost wrote:
>> I'm concerned, seriously, that people don't have anywhere near the
>> concern about the recovery side of things as they do about the backup
>> side of things and that's really concerning.
>
> I think we sh
On 12/11/18 9:44 PM, Andres Freund wrote:
> On 2018-12-12 11:32:55 +0900, Michael Paquier wrote:
>>
>> +1 on all that. Per the trend of this thread, I see a bunch of
>> committers and contributors commenting about *not* removing this code,
>> so sending a patch to actually remove it looks like a t
On 12/11/18 11:14 PM, Robert Haas wrote:
> On Wed, Dec 12, 2018 at 1:13 PM David Steele wrote:
>> On 12/11/18 11:06 PM, Robert Haas wrote:
>>> On Wed, Dec 12, 2018 at 11:29 AM Michael Paquier
>>> wrote:
I really don't think that it is a good idea to link a future timeline
within a segm
On Wed, Dec 12, 2018 at 1:23 PM David Steele wrote:
> I didn't get the impression that Peter was against, he just thought that
> it needed to stand on its own, rather than be justified by the
> recovery.conf changes, which I agree with.
>
> Simon rather clearly said that he thinks we should wait u
On Tue, Dec 11, 2018 at 11:59:08AM +0300, Sergei Kornilov wrote:
>> but I think that this patch should document clearly that if
>> primary_conninfo or primary_slot_name are changed then the WAL receiver
>> is stopped immediately.
>
> Good idea, will change.
+
+ walreceiver will b
On 12/11/18 5:33 PM, Laurenz Albe wrote:
> On Mon, 2018-11-26 at 10:18 +0100, Magnus Hagander wrote:
>>> [about managing backups from pre- and post-file-system-backup scrips]
I agree with your point that it's not an uncommon thing to need. If a good
solution
for it can be proposed t
On Tue, Dec 11, 2018 at 11:27:30PM -0500, David Steele wrote:
> And yeah, I'm not sure that I'm totally sold on this idea either, but I
> wanted to get a conversation going.
Another idea which I think we could live with is to embed within the
segment file name the LSN switch point, in a format con
Hi all,
Since 2dedf4d, recovery.conf is dead and all recovery parameters are now
GUCs. While looking at a patch to switch primary_conninfo and
primary_slot_name to be reloadable, Sergei Kornilov had a very good
point that the WAL receiver uses a connection string and a physical slot
name based on
On December 11, 2018 9:30:42 PM PST, Michael Paquier
wrote:
>Hi all,
>
>Since 2dedf4d, recovery.conf is dead and all recovery parameters are
>now
>GUCs. While looking at a patch to switch primary_conninfo and
>primary_slot_name to be reloadable, Sergei Kornilov had a very good
>point that the
On Sat, Dec 8, 2018 at 7:52 PM Amit Kapila wrote:
> On Tue, Dec 4, 2018 at 3:00 PM Dilip Kumar wrote:
> >
> > On Sat, Dec 1, 2018 at 12:58 PM Amit Kapila
> wrote:
> > >
> > >
> > > 13.
> > > PrepareUndoInsert()
> > > {
> > > ..
> > > if (!UndoRecPtrIsValid(prepared_urec_ptr))
> > > + urecptr =
On Tue, Dec 11, 2018 at 09:34:58PM -0800, Andres Freund wrote:
> I am not convinced this is a good idea. This allows the state of
> walrcv and startup to diverge, they could e.g. have different
> configuration, due to differently time config reloads. And they need
> to communicate via shmem anyway
On Tue, 2018-12-11 at 23:43 -0500, David Steele wrote:
> > > > [about managing backups from pre- and post-file-system-backup scrips]
> > I have come up with some sample code here:
> > https://github.com/cybertec-postgresql/safe-backup
> >
> > This just uses bash and psql.
> > Does that look reason
On Tue, Dec 4, 2018 at 12:44 PM Alvaro Herrera
wrote:
> After reading this thread, I think I like WHERE better than FILTER.
> Tally:
>
> WHERE: Adam Berlin, Lim Myungkyu, Dean Rasheed, yours truly
> FILTER: Tomas Vondra, Surafel Temesgen
>
>
>
accepting tally result i change the keyword to WHERE
On Mon, Dec 10, 2018 at 2:50 AM Tom Lane wrote:
> I feel like #2 is probably really the Right Thing,
I think so, too.
> Also, I think that either solution would lead to some subtle changes
> in semantics. For example, right now if you compare a name column
> to a text value, you get a text (col
On Wed, Dec 12, 2018 at 01:31:53PM +0900, Robert Haas wrote:
> Most of the features I've been involved in removing have been
> deprecated for 5+ years. The first release where this one was
> deprecated was only 2 years ago. So it feels dramatically faster to
> me than what I think we have typical
On December 11, 2018 10:10:00 PM PST, Michael Paquier
wrote:
>By the way, David and others, my apologies for my latest email, I hope
>you did not take that badly, my impression of this thread about the
>opinions gathered was wrong.
Even if it had been 10:1 it doesn't seem like it'd have been
On Wed, 2018-12-12 at 13:31 +0900, Robert Haas wrote:
> On Wed, Dec 12, 2018 at 1:23 PM David Steele wrote:
> > I didn't get the impression that Peter was against, he just thought that
> > it needed to stand on its own, rather than be justified by the
> > recovery.conf changes, which I agree with.
Hi all,
Function check_outerjoin_delay() is used to detect whether a qual
referencing the given relids must be delayed in application due to the
presence of a lower outer join.
If the given relids are empty, we should be able to return from this
function via the same fast path as for the case tha
74 matches
Mail list logo
