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
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
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, 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
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
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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 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
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
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
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 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
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.
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
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
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
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.
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
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
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
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 ;
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
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
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
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
...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
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
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:
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
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
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
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
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
---
Hello
After some thinking i can rewrite this patch in another way.
This is better or worse?
regards, Sergei
> 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
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
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
72 matches
Mail list logo
