Antonin Houska wrote:
> If the comment tells that t_hoff can be computed (i.e. it's no necessary to
> include it in the structure), I think the comment should tell why it's yet
> included. Maybe something about "historical reasons"? Perhaps we can say that
> the storage used to be free due to pad
Bruce Momjian wrote:
> On Wed, Jul 22, 2020 at 06:58:33AM +0200, Antonin Houska wrote:
> > Tom Lane wrote:
> >
> > > I don't particularly want to remove the field, but we ought to
> > > change or remove the comment.
> >
> > I'm not concerned about the existence of the field as well. The commen
Bruce Momjian writes:
> Updated patch.
FWIW, I concur with the idea of just dropping that sentence altogether.
It's not likely that getting rid of that field is a line of development
that will ever be pursued; if anyone does get concerned about cutting
WAL size, there's a lot of more-valuable dir
On Fri, Aug 21, 2020 at 08:07:34PM -0700, David G. Johnston wrote:
> On Fri, Aug 21, 2020 at 5:41 PM Bruce Momjian wrote:
>
> On Wed, Jul 22, 2020 at 06:58:33AM +0200, Antonin Houska wrote:
> > Tom Lane wrote:
> >
> > > I don't particularly want to remove the field, but we ought
Amit Kapila writes:
> On Thu, Aug 20, 2020 at 10:28 PM Tom Lane wrote:
>> 2. On the other hand, the code is *releasing* the
>> ReplicationSlotControlLock before it calls
>> ProcArraySetReplicationSlotXmin, and that seems like a flat out
>> concurrency bug.
> It is not clear to me how those value
On Fri, Aug 21, 2020 at 11:27:06PM +0900, torikoshia wrote:
> OK. Added a regression test on sysviews.sql.
> (0001-Added-a-regression-test-for-pg_backend_memory_contex.patch)
>
> Fujii-san gave us an example, but I added more simple one considering
> the simplicity of other tests on that.
What yo
On Thu, Aug 20, 2020 at 10:28 PM Tom Lane wrote:
>
> While trying to make sense of Adam Sjøgren's problem [1], I found
> myself staring at ReplicationSlotsComputeRequiredXmin() in slot.c.
> It seems to me that that is very shaky code, on two different
> grounds:
>
> 1. Sometimes it's called with P
Hi hackers,
I am sorry for the question which may be already discussed multiple times.
But I have not found answer for it neither in internet neither in
pgsql-hackers archieve.
UPSERT (INSERT ... IN CONFLICT...) clause was added to the Postgres a
long time ago.
As far as I remember there was lo
