23.03.2023 20:10, Tomas Vondra wrote:
So pushed all three parts, after updating the commit messages a bit.
This leaves the empty-data issue (which we have a fix for) and the
switch to LZ4F. And then the zstd part.
I'm sorry that I haven't noticed/checked that before, but when trying to
perfor
On 05.05.23 00:33, Andrew Dunstan wrote:
On 2023-05-04 Th 02:40, Peter Eisentraut wrote:
On 25.04.23 12:27, Peter Eisentraut wrote:
On 20.11.22 16:10, Andrew Dunstan wrote:
On 2022-11-19 Sa 15:16, Andres Freund wrote:
Hi,
On 2022-11-19 10:56:33 -0500, Andrew Dunstan wrote:
Perhaps we shoul
Hi,
On 5/4/23 6:43 AM, Amit Kapila wrote:
On Thu, May 4, 2023 at 8:37 AM vignesh C wrote:
Thanks for posting the updated patch, I had run this test in a loop of
100 times to verify that there was no failure because of race
conditions. The 100 times execution passed successfully.
One suggesti
On Wednesday, May 3, 2023 3:17 PM Amit Kapila wrote:
>
> On Tue, May 2, 2023 at 9:46 AM Amit Kapila
> wrote:
> >
> > On Tue, May 2, 2023 at 9:06 AM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > On Friday, April 28, 2023 2:18 PM Masahiko Sawada
> wrote:
> > > >
> > > > >
> > > > > Alexander, does
On Thu, May 4, 2023 at 12:59 AM Peter Geoghegan wrote:
> I'd quite like to drop this topic, and get on with the work at hand.
I'd be grateful, and the other points you made are, of course, valid.
--
John Naylor
EDB: http://www.enterprisedb.com
Sorry for not responding to this thread for a long time and a huge thank
you for pushing it forward!
Best Regards,
Xing
On Fri, May 5, 2023 at 7:42 AM Nathan Bossart
wrote:
> On Thu, May 04, 2023 at 08:39:03AM -0400, Tom Lane wrote:
> > Hmm, I'm not sure why PLy_trigger_build_args's plta
Hi,
On 2023-05-03 09:20:28 -0400, Andrew Dunstan wrote:
> On 2023-04-27 Th 18:18, Andres Freund wrote:
> > On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> > > Still running into this, and I am rather stumped. This is a blocker for
> > > buildfarm support for meson:
> > >
> > > Here's a simpl
On Thu, May 04, 2023 at 08:39:03AM -0400, Tom Lane wrote:
> Hmm, I'm not sure why PLy_trigger_build_args's pltargs needs to
> gain a "volatile" here? LGTM otherwise.
I removed that new "volatile" marker before committing. I was trying to
future-proof a bit and follow elog.h's recommendation to t
On 2023-05-04 Th 02:40, Peter Eisentraut wrote:
On 25.04.23 12:27, Peter Eisentraut wrote:
On 20.11.22 16:10, Andrew Dunstan wrote:
On 2022-11-19 Sa 15:16, Andres Freund wrote:
Hi,
On 2022-11-19 10:56:33 -0500, Andrew Dunstan wrote:
Perhaps we should just export a directory in configure ins
Hi,
On Wed, May 3, 2023 at 3:48 PM Peter Geoghegan wrote:
> On Wed, May 3, 2023 at 2:59 PM Peter Geoghegan wrote:
> > Coming up with a new user-facing name for xidStopLimit is already on
> > my TODO list (it's surprisingly hard). I have used that name so far
> > because it unambiguously refers
Alvaro Herrera writes:
> Thanks for looking! I have pushed it now. And many thanks to Oleg for
> noticing and reporting it.
It looks like this patch caused a change in the order of output from
the sepgsql tests [1]. If you expected it to re-order permissions
checking then this is probably fine
Hi,
On Wed, May 3, 2023 at 2:59 PM Peter Geoghegan wrote:
> Hi Samay,
>
> On Tue, May 2, 2023 at 11:40 PM samay sharma
> wrote:
> > Thanks for taking the time to do this. It is indeed difficult work.
>
> Thanks for the review! I think that this is something that would
> definitely benefit from
On 5/4/23 12:46 PM, Andres Freund wrote:
Hi,
On 2023-05-03 11:36:10 -0400, Jonathan S. Katz wrote:
It'd be good if we can get this into Beta 1 if everyone is comfortable with
the patch.
I think we need one more iteration, then I think it can be committed. The
changes are docs phrasing and pol
On 2023-Mar-09, Amit Langote wrote:
> On Thu, Mar 9, 2023 at 7:39 PM Alvaro Herrera wrote:
> > I didn't like very much this business of setting the perminfoindex
> > directly to '2' and '1'. It looks ugly with no explanation. What do
> > you think of creating the as we go along and set each ind
Hi,
On Fri, 21 Apr 2023 16:44:48 -0400
Melanie Plageman wrote:
> On Fri, Apr 7, 2023 at 8:01 PM Jehan-Guillaume de Rorthais
> wrote:
> >
> > On Fri, 31 Mar 2023 14:06:11 +0200
> > Jehan-Guillaume de Rorthais wrote:
> >
> > > > [...]
> > > > >> Hmmm, not sure is WARNING is a good approach,
Hi,
On 2023-04-24 21:29:48 -0400, Melanie Plageman wrote:
> 1) Does it make sense for writebacks to count the number of blocks for
> which writeback was requested or the number of calls to smgrwriteback() or
> the number of actual syscalls made? We don't actually know from outside
> of mdwriteback
Hi,
On 2023-05-03 11:36:10 -0400, Jonathan S. Katz wrote:
> It'd be good if we can get this into Beta 1 if everyone is comfortable with
> the patch.
I think we need one more iteration, then I think it can be committed. The
changes are docs phrasing and polishing the API a bit, which shouldn't be
Hi,
On 2023-04-27 11:36:49 -0400, Melanie Plageman wrote:
> > > /* and finally tell the kernel to write the data to storage
> > > */
> > > reln = smgropen(currlocator, InvalidBackendId);
> > > smgrwriteback(reln, BufTagGetForkNum(&tag), tag.blockNum,
> >
Hi Alvaro,
On Thu, May 4, 2023 at 19:44 Alvaro Herrera wrote:
> On 2023-May-02, Alvaro Herrera wrote:
>
> > We have an open item about this, and I see no reason not to do it. I
> > checked, and putting things back is just a matter of reverting
> > 589bb816499e and ec386948948, cleaning up some
Nathan Bossart writes:
> Gah, right after I sent that, I realized we can remove one more volatile
> marker. Sorry for the noise.
Hmm, I'm not sure why PLy_trigger_build_args's pltargs needs to
gain a "volatile" here? LGTM otherwise.
regards, tom lane
"Anton A. Melnikov" writes:
> The thing is that for custom scan nodes as readme says:
> "INDEX_VAR is abused to signify references to columns of a custom scan tuple
> type"
> But INDEX_VAR has a negative value, so it can not be used in varnullingrels
> bitmapset.
> And therefore this improvement
> On 4 May 2023, at 14:09, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> When reading a memory contexts log I realized that we have this:
>> LOG: level: 2; EventTriggerCache: 8192 total in 1 blocks; 7928 free (4
>> chunks); 264 used
>> LOG: level: 3; Event Trigger Cache: 8192 total in 1 bl
Andrew Gierth writes:
> And checking other versions, 9.6 is the same, it's only with pg 10 that
> it switches to creating a dummy view instead of a table (and using
> CREATE OR REPLACE VIEW, no mention of rules).
9.6.16 or later will use CREATE OR REPLACE VIEW, cf 404cbc562.
> So if the goal was
Daniel Gustafsson writes:
> When reading a memory contexts log I realized that we have this:
> LOG: level: 2; EventTriggerCache: 8192 total in 1 blocks; 7928 free (4
> chunks); 264 used
> LOG: level: 3; Event Trigger Cache: 8192 total in 1 blocks; 2616 free (0
> chunks); 5576 used
> The reaso
When reading a memory contexts log I realized that we have this:
LOG: level: 2; EventTriggerCache: 8192 total in 1 blocks; 7928 free (4
chunks); 264 used
LOG: level: 3; Event Trigger Cache: 8192 total in 1 blocks; 2616 free (0
chunks); 5576 used
The reason is that BuildEventTriggerCache sets
On 2023-May-02, Alvaro Herrera wrote:
> We have an open item about this, and I see no reason not to do it. I
> checked, and putting things back is just a matter of reverting
> 589bb816499e and ec386948948, cleaning up some trivial pgindent-induced
> conflicts, and bumping catversion once more. W
On 2023-May-04, Anton Kirilov wrote:
> Thank you all for the feedback! Do you have any thoughts on the other
> issue with PQpipelineSync() I have mentioned in my previous message?
Eh, I hadn't seen that one.
> Am I just misunderstanding what the code comment means and how the API
> is supposed t
Hello,
> On 3 May 2023, at 11:03, Alvaro Herrera wrote:
>
> On 2023-May-02, Robert Haas wrote:
>
>> On Mon, May 1, 2023 at 8:42 PM Michael Paquier wrote:
>>> Another thing that may matter in terms of extensibility? Would a
>>> boolean argument really be the best design? Could it be better to
When working on the improper qual pushdown issue [1], there is a need in
the proposed fix to avoid scanning all the SpecialJoinInfos, since that
is too expensive. I think this might be a common requirement. In the
current codes there are several places where we need to scan all the
SpecialJoinInf
Hello!
I'm having doubts about this fix but most likely i don't understand something.
Could you help me to figure it out, please.
The thing is that for custom scan nodes as readme says:
"INDEX_VAR is abused to signify references to columns of a custom scan tuple
type"
But INDEX_VAR has a negati
30 matches
Mail list logo
