Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sat, Mar 20, 2021 at 05:37:47PM +0900, Michael Paquier wrote:
> > It seems to me that this would make the tests faster, that the test
> > would not need to wait for the logging collector and that the code
> > could just use slurp_file(
On Sun, Mar 21, 2021 at 2:57 PM Alvaro Herrera wrote:
>
> On 2021-Mar-21, Magnus Hagander wrote:
>
> > On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote:
> > >
> > > Let's get someone to go into the "database" and adjust it. ;-)
> >
> > Yeah, we probably can clean that up on the database side
On 2021-Mar-21, Magnus Hagander wrote:
> On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote:
> >
> > Let's get someone to go into the "database" and adjust it. ;-)
>
> Yeah, we probably can clean that up on the database side :)
Thank you!
> But what is it we *want* it to do? That is, what sh
On Fri, Mar 19, 2021 at 6:03 PM Bruce Momjian wrote:
>
> On Fri, Mar 19, 2021 at 10:53:53AM -0400, David Steele wrote:
> > On 3/19/21 10:44 AM, Alvaro Herrera wrote:
> > > On 2021-Mar-19, David Steele wrote:
> > >
> > > > Since it does not appear this is being worked on for PG14 perhaps we
> > >
Le 21/03/2021 à 12:07, e...@xs4all.nl a écrit :
>> On 2021.03.20. 19:48 Gilles Darold wrote:
>>
>> This is a new version of the patch that now implements all the XQUERY
>> regexp functions as described in the standard, minus the differences of
>> PostgerSQL regular expression explain in [1].
>>
On Sat, Mar 20, 2021 at 4:59 PM Michael Paquier wrote:
>
> On Sat, Mar 20, 2021 at 05:37:47PM +0900, Michael Paquier wrote:
> > It seems to me that this would make the tests faster, that the test
> > would not need to wait for the logging collector and that the code
> > could just use slurp_file($
On 3/20/21 12:55 PM, Jan Wieck wrote:
> On 3/20/21 11:23 AM, Tom Lane wrote:
>> Jan Wieck writes:
>>> All that aside, the entire approach doesn't scale.
>>
>> Yeah, agreed. When we gave large objects individual ownership and ACL
>> info, it was argued that pg_dump could afford to treat each one
> On 2021.03.20. 19:48 Gilles Darold wrote:
>
> This is a new version of the patch that now implements all the XQUERY
> regexp functions as described in the standard, minus the differences of
> PostgerSQL regular expression explain in [1].
>
> The standard SQL describe functions like_regex(), o
Hello
On Sunday, March 21, 2021 4:37 PM Amit Kapila
> On Sat, Mar 20, 2021 at 10:09 AM Ajin Cherian wrote:
> >
> > On Sat, Mar 20, 2021 at 1:35 AM Amit Kapila
> wrote:
> >>
> >> On Fri, Mar 19, 2021 at 5:03 AM Ajin Cherian wrote:
> >> >
> >> > Missed the patch - 0001, resending.
> >> >
> >>
>
On Sat, Mar 13, 2021 at 3:43 PM Amit Kapila wrote:
>
> On Thu, Mar 11, 2021 at 2:44 PM Markus Wanner
> wrote:
> >
> > On 11.03.21 04:58, Amit Kapila wrote:
> > > But this happens when we are decoding prepare, so it is clear that the
> > > transaction is prepared, why any additional check?
> >
> >
so 20. 3. 2021 v 23:45 odesílatel Thomas Munro
napsal:
> On Thu, Mar 4, 2021 at 11:28 PM Pavel Stehule
> wrote:
> > čt 4. 3. 2021 v 7:37 odesílatel Pavel Stehule
> napsal:
> >> Here is a little bit updated patch - detection of end of any child
> process cannot be used on WIN32.
>
> Yeah, it's O
On Sun, Mar 21, 2021 at 2:56 AM Andres Freund wrote:
>
> On 2021-03-20 09:25:40 +0530, Amit Kapila wrote:
> > On Sat, Mar 20, 2021 at 12:22 AM Andres Freund wrote:
> > >
> > > And then more generally about the feature:
> > > - If a slot was used to stream out a large amount of changes (say an
> >
On Sun, Mar 21, 2021 at 2:57 AM Andres Freund wrote:
>
> Hi,
>
> On 2021-03-20 10:28:06 +0530, Amit Kapila wrote:
> > On Sat, Mar 20, 2021 at 9:25 AM Amit Kapila wrote:
> > > This idea is worth exploring to address the complaints but what do we
> > > do when we detect that the stats are from the
On Sat, Mar 20, 2021 at 12:54 PM Peter Smith wrote:
>
> PSA my patch to correct this by firstly doing a HASH_FIND, then only
> HASH_REMOVE after we've finished using the ent.
>
Why can't we keep using HASH_REMOVE as it is but get the output (entry
found or not) in the last parameter of hash_searc
On Sun, Mar 21, 2021 at 2:47 PM Markus Wanner
wrote:
>
> On 20.03.21 16:14, Amit Kapila wrote:
> > Right, but I guess in our case using user-provided GID will conflict
> > if we use multiple subscriptions on the same node. So, it is better to
> > generate a unique identifier like we are discussing
ne 21. 3. 2021 v 0:42 odesílatel Thomas Munro
napsal:
> On Sun, Mar 21, 2021 at 11:44 AM Thomas Munro
> wrote:
> > [review]
>
> Oh, just BTW, to save confusion for others who might try this: It
> seems there is something wrong with pspg --stream on macOS, at least
> when using MacPorts. I assu
> The feature is a little disappointing because if someone has partition
> tables then probably they have a lot of data and probably they would
> like freeze to work there. Maybe freeze would work on table partitions
> themselves, but I do not think it is worth the effort to do that.
Agreed.
> Ab
Le 20/03/2021 à 19:48, Gilles Darold a écrit :
>
> Hi,
>
>
> This is a new version of the patch that now implements all the XQUERY
> regexp functions as described in the standard, minus the differences
> of PostgerSQL regular expression explain in [1].
>
>
> The standard SQL describe functions like
On 20.03.21 16:14, Amit Kapila wrote:
Right, but I guess in our case using user-provided GID will conflict
if we use multiple subscriptions on the same node. So, it is better to
generate a unique identifier like we are discussing here, something
like (origin_id of subscription + xid of the publis
V3 works for me and looks ok. I changed it to ready in the CF app.
Thank you for your review!
Unfortunately it seems cfbot is not happy with the patch.
Argh. Indeed, I did not thought of testing on a partitioned table:-( ISTM
I did "make check" in pgbench to trigger tap tests, but possib
On Wed, Jan 27, 2021 at 12:35:30PM -0500, Robert Haas wrote:
> On Mon, Jan 25, 2021 at 2:11 PM Heikki Linnakangas wrote:
> > Having a separate FullTransactionIdToLatestPageNumber() function for
> > this seems like overkill to me.
>
> I initially thought so too, but it turned out to be pretty usef
On Thu, 18 Mar 2021 at 14:37, Peter Geoghegan wrote:
> They usually involve some *combination* of Postgres problems,
> application code problems, and DBA error. Not any one thing. I've seen
> problems with application code that runs DDL at scheduled intervals,
> which interacts badly with vacuum
On Wed, 10 Mar 2021 at 20:25, Tom Lane wrote:
>
> So this means that in less-than-bleeding-edge kernels, syncfs can
> only be regarded as a dangerous toy. If we expose an option to use
> it, there had better be large blinking warnings in the docs.
Isn't that true for fsync and everything else re
On Sat, Mar 20, 2021 at 8:53 PM Amit Kapila wrote:
>
> On Sat, Mar 20, 2021 at 4:02 PM Dilip Kumar wrote:
> >
> > On Sat, Mar 20, 2021 at 7:50 AM Amit Kapila wrote:
> > >
> > > On Fri, Mar 19, 2021 at 9:22 PM Markus Wanner
> > > wrote:
> >
> > > So, I think you are using xid of publisher and or
On Sun, Mar 21, 2021 at 7:03 AM Tom Lane wrote:
> Also, I see some diffs in the
> indirect_toast test, which seems perhaps worthy of investigation.
> (The diffs look to be just row ordering, but why?)
I have investigated that, actually in the below insert, after
compression the data size of (rep
On 19.03.21 21:06, Peter Eisentraut wrote:
On 18.03.21 07:34, Craig Ringer wrote:
In patch 0001, why was the TRACE_POSTGRESQL_LWLOCK_RELEASE() call
moved?
Is there some correctness issue? If so, we should explain that
(at
least in the commit message, or as a separate patch)
101 - 126 of 126 matches
Mail list logo