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 R
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 E
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 thi
+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 mo
>
>
>
> 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 = dbo.Web
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 pg_stat_all_tables":
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'
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:
ACCURATE
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 pg_u
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 fr
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 visibilitymap.
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 whether
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 cri
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 t
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
benchmarks
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, a
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
21 matches
Mail list logo
