On Fri, Sep 17, 2021 at 3:03 PM Greg Nancarrow wrote:
>
> On Thu, Sep 16, 2021 at 10:36 PM Amit Kapila wrote:
> >
> > I think here the reason is that the first_lsn of a transaction is
> > always equal to end_lsn of the previous transaction (See comments
> > above first_lsn and end_lsn fields of
I have been trying to get a reply or interest in either updating
PostgreSQL to support the following, or for there to be a public,
free for any use Extension put out there, that will support the following:
# High Precision Numeric and
On Fri, Sep 17, 2021 at 9:50 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Sep 14, 2021 at 10:51:42AM +0200, Antonin Houska wrote:
>
> * What happened with the idea of abandoning discard worker for the sake
> of simplicity? From what I see limiting everything to foreground undo
>
On Fri, Sep 17, 2021 at 8:08 PM Fabrice Chapuis wrote:
>
> the publisher and the subscriber run on the same postgres instance.
>
Okay, but there is no log corresponding to operations being performed
by the publisher. By looking at current logs it is not very clear to
me what might have caused
+1 backporting
Tony
On 2021/9/19 01:06, Tom Lane wrote:
> We had left it as an open issue whether or not to risk back-patching
> 5c056b0c2 into stable branches [1]. While updating the v14 release notes,
> I realized that we can't put off that decision any longer, because we
> have to decide now
In reviewing Paul's application period patch, I noticed some very curious
syntax in the test cases. I learned that Paul is equally confused by it,
and has asked about it in his PgCon 2020 presentation
> SELECT '2018-03-04' AT TIME ZONE INTERVAL '2' HOUR TO MINUTE;
timezone
In IBM DB2 you can only have one because application-time periods must
> be named "business_time" (not joking).
>
I saw that as well, and it made me think that someone at IBM is a fan of
Flight Of The Conchords.
> Personally I feel like it's a weird limitation and I wouldn't mind
> supporting
>
>
>
> 1. Much of what I have read about temporal tables seemed to imply or
> almost assume that system temporal tables would be implemented as two
> actual separate tables. Indeed, SQLServer appears to do it that way [1]
> with syntax like
>
> WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE =
On Sat, 18 Sep 2021, 18:06 Tom Lane, wrote:
>
> I'm inclined to back-patch
>
+1
Regards,
Dean
>
On Sat, Sep 18, 2021 at 05:15:39PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > I think the release notes for the autovacuum item (which was first reverted
> > and
> > then partially un-reverted) should say something like "Partitioned tables
> > are
> > now included in
Justin Pryzby writes:
> I think the release notes for the autovacuum item (which was first reverted
> and
> then partially un-reverted) should say something like "Partitioned tables are
> now included in pg_stat_all_tables":
> | e1efc5b465 Keep stats up to date for partitioned tables
Hmm. If
I think the release notes for the autovacuum item (which was first reverted and
then partially un-reverted) should say something like "Partitioned tables are
now included in pg_stat_all_tables":
| e1efc5b465 Keep stats up to date for partitioned tables
Remove some internal question/marks:
On 2021-Sep-18, Alexander Korotkov wrote:
> I see now. I think I'm rather favoring splitting visibilitymap.h.
Agreed, this looks sane to me. However, I think the
VM_ALL_{VISIBLE,FROZEN} macros should remain in visibilitymap.h, since
they depend on the visibilitymap_get_status function (and
On 2021-Sep-18, Michael Paquier wrote:
> Could it be possible to rely on a combination of wait events set in WAL
> senders and pg_stat_replication to assume that a WAL sender is in a
> stopped state?
Hmm, sounds a possibly useful idea to explore, but I would only do so if
the other ideas prove
Hi,
On Sat, Sep 18, 2021 at 3:06 AM Andres Freund wrote:
> On 2021-09-18 02:51:09 +0300, Alexander Korotkov wrote:
> > On Tue, Sep 14, 2021 at 6:53 AM Tom Lane wrote:
> > > Without having looked at the details, I think using a forward-declare
> > > to avoid including relcache.h in
On Sat, Sep 18, 2021 at 10:06 AM Tom Lane wrote:
> We had left it as an open issue whether or not to risk back-patching
> 5c056b0c2 into stable branches [1]. While updating the v14 release notes,
> I realized that we can't put off that decision any longer, because we
> have to decide now
Andrew Dunstan writes:
> The Release Management Team (Michael Paquier, Peter Geoghegan and
> myself) in consultation with the release team proposes the following
> release schedule:
> * PostgreSQL 14 Release Candidate 1 (RC1) will be released on September 23,
> 2021.
> * In the absence of any
We had left it as an open issue whether or not to risk back-patching
5c056b0c2 into stable branches [1]. While updating the v14 release notes,
I realized that we can't put off that decision any longer, because we
have to decide now whether to document that as a new behavior in v14.
I'm inclined
On 9/8/21 8:05 AM, Dilip Kumar wrote:
On Tue, Sep 7, 2021 at 8:41 PM Tomas Vondra
mailto:tomas.von...@enterprisedb.com>>
wrote:
Hi,
The numbers presented in this thread seem very promising - clearly
there's significant potential for improvements. I'll run similar
On Sat, 18 Sep 2021 at 12:57, Thomas Habets wrote:
>
> But these are two changes:
> 1. Actually verify against a CA
> 2. Actually check the CN/altnames
>
> Anything short of "verify-full" is in my view "not checking". Even with a
> private CA this allows for a lot of lateral movement in an org,
On Sat, 18 Sept 2021 at 00:10, Cameron Murdoch wrote:
> I also agree that the proposed patch is not the right way to go as it is
> essentially the same as verify-full, and I think that the correct fix would
> be to change the default.
>
But these are two changes:
1. Actually verify against a CA
On Fri, Sep 17, 2021 at 08:41:00PM -0700, Noah Misch wrote:
> If this fixes things for the OP, I'd like it slightly better than the "ps"
> approach. It's less robust, but I like the brevity.
>
> Another alternative might be to have walreceiver reach walsender via a proxy
> Perl script. Then,
On Fri, Sep 17, 2021 at 08:12:42AM +, gkokola...@pm.me wrote:
> Yeah, I was considering it to split them over to a separate commit,
> then decided against it. Will do so in the future.
I have been digging into the issue I saw in the TAP tests when closing
a segment, and found the problem.
23 matches
Mail list logo
