On 2024/5/18 14:38, Will Mortensen wrote:
> On Tue, Mar 26, 2024 at 7:14 PM Will Mortensen wrote:
>> This comment on ProcSleep() seems to have the values of dontWait
>> backward (double negatives are tricky):
>>
>> * Result: PROC_WAIT_STATUS_OK if we acquired the lock,
>> PROC_WAIT_STATUS_ERRO
On 5/18/24 08:51, Andrey M. Borodin wrote:
>
>
>> On 18 May 2024, at 00:41, Tomas Vondra
>> wrote:
>>
>> if the opclass supports sorted builds, because then we could
>> parallelize the sort.
>
> Hi Tomas!
>
> Yup, I'd also be glad to see this feature. PostGIS folks are using
> their geomet
On 5/17/24 14:20, Robert Haas wrote:
> On Fri, May 17, 2024 at 1:18 AM David Steele wrote:
>> However, I think allowing the user to optionally validate the input
>> would be a good feature. Running pg_verifybackup as a separate step is
>> going to be a more expensive then verifying/copying at t
On Fri, May 17, 2024 at 11:38:35PM -0700, Will Mortensen wrote:
> On Tue, Mar 26, 2024 at 7:14 PM Will Mortensen wrote:
>> This comment on ProcSleep() seems to have the values of dontWait
>> backward (double negatives are tricky):
>>
>> * Result: PROC_WAIT_STATUS_OK if we acquired the lock,
>>
> On 18 May 2024, at 15:22, Tomas Vondra wrote:
>
> Let's continue working on that patch/thread, I'll take a look in the
> next CF.
Cool! I'd be happy to review the patch before CF when Bernd or Christoph will
address current issues.
Best regards, Andrey Borodin.
On 5/18/24 02:00, Paul A Jungwirth wrote:
> On Fri, May 17, 2024 at 12:41 PM Tomas Vondra
> wrote:
>> I've been looking at GiST to see if there could be a good way to do
>> parallel builds - and there might be, if the opclass supports sorted
>> builds, because then we could parallelize the sort.
>
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
Hi, works out well everything. This is my first review, so if
On 2024-05-17 Fr 02:34, Peter Eisentraut wrote:
On 17.05.24 08:09, Yasir wrote:
I have been playing with PG on the Windows platform recently. An
annoying thing I faced is that a lot of Visual Studio's temp files
kept appearing in git changed files. Therefore, I am submitting this
very trivia
pá 17. 5. 2024 v 8:09 odesílatel Yasir napsal:
>
> Hi Hackers,
>
> I have been playing with PG on the Windows platform recently. An annoying
> thing I faced is that a lot of Visual Studio's temp files kept appearing in
> git changed files. Therefore, I am submitting this very trivial patch to
>
On Thu, May 16, 2024 at 03:35:17PM +1200, David Rowley wrote:
> On Thu, 16 May 2024 at 14:48, Bruce Momjian wrote:
> >
> > On Wed, May 15, 2024 at 09:13:14AM -0400, Melanie Plageman wrote:
> > > Also +1 on the Sawada/Naylor change being on the highlight section of
> > > the release (as David sugge
For some reason the review indicated "failed".
It should of course read:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
On Wed, May 15, 2024 at 08:48:02PM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote:
> > I disagree with this. IMO the impact of the Sawada/Naylor change is
> > likely to be enormous for people with large tables and large numbers of
> > tuples to clean up (
On Thu, May 16, 2024 at 09:09:11AM -0400, Melanie Plageman wrote:
> On Wed, May 15, 2024 at 11:48 PM Andres Freund wrote:
> >
> > On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote:
> > > I disagree with this. IMO the impact of the Sawada/Naylor change is
> > > likely to be enormous for people wi
On Thu, May 16, 2024 at 04:29:38PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
> >
>
> >> Add json
On 2024-May-17, Robert Haas wrote:
> Anyone else want to vote?
I had pretty much the same thought as you. It seems a waste to leave
the code in existing branches be slow only because we have a much better
approach for a branch that doesn't even exist yet.
--
Álvaro Herrera PostgreSQL D
On 2024-Jan-30, Dmitry Dolgov wrote:
> Yep, in this constellation the implementation holds much better (in
> terms of memory) in my create/let/drop testing.
>
> I've marked the CF item as ready for committer, but a note for anyone
> who would like to pick up it from here -- we're talking about fi
On Thu, May 16, 2024 at 11:50:20AM -0400, Andrew Dunstan wrote:
> > Maybe "Introduce an incremental JSON parser" would have been a better
> > > headline.
> > Well, this gets into a level of detail that is beyond the average
> > reader. I think at that level people will need to read the git logs or
Alvaro Herrera writes:
> On 2024-May-17, Robert Haas wrote:
>> Anyone else want to vote?
> I had pretty much the same thought as you. It seems a waste to leave
> the code in existing branches be slow only because we have a much better
> approach for a branch that doesn't even exist yet.
I won't
> On 17 May 2024, at 21:41, Tomas Vondra wrote:
>
> Hi,
>
> I've been looking at GiST to see if there could be a good way to do
> parallel builds - and there might be, if the opclass supports sorted
> builds, because then we could parallelize the sort.
>
> But then I noticed we support this
Hi!
In a thread about sorting comparators[0] Andres noted that we have
infrastructure to help compiler optimize sorting. PFA attached PoC
implementation. I've checked that it indeed works on the benchmark from that
thread.
postgres=# CREATE TABLE arrays_to_sort AS
SELECT array_shuffle(a) ar
Hello Thomas,
18.05.2024 07:47, Thomas Munro wrote:
After more debugging, we learned a lot more things...
1. That query produces spectacularly bad estimates, so we finish up
having to increase the number of buckets in a parallel hash join many
times. That is quite interesting, but unrelated t
On Sat, May 18, 2024 at 7:27 PM Josef Šimánek
wrote:
> pá 17. 5. 2024 v 8:09 odesílatel Yasir
> napsal:
> >
> > Hi Hackers,
> >
> > I have been playing with PG on the Windows platform recently. An
> annoying thing I faced is that a lot of Visual Studio's temp files kept
> appearing in git change
On Sat, May 18, 2024 at 7:27 PM Josef Šimánek
wrote:
> pá 17. 5. 2024 v 8:09 odesílatel Yasir
> napsal:
> >
> > Hi Hackers,
> >
> > I have been playing with PG on the Windows platform recently. An
> annoying thing I faced is that a lot of Visual Studio's temp files kept
> appearing in git change
Yasir writes:
> We can add it to "~/.config/git/ignore" as it will ignore globally on
> windows which we don't want. Also we don't have ".git/info/exclude" in PG
> project's so the best place left is projects's .gitignore. That's what was
> patched.
As Peter said, we're not going to do that. The
On 2024-05-18 Sa 12:50, Bruce Momjian wrote:
On Thu, May 16, 2024 at 11:50:20AM -0400, Andrew Dunstan wrote:
Maybe "Introduce an incremental JSON parser" would have been a better
headline.
Well, this gets into a level of detail that is beyond the average
reader. I think at that level people
so 18. 5. 2024 v 22:36 odesílatel Tom Lane napsal:
>
> Yasir writes:
> > We can add it to "~/.config/git/ignore" as it will ignore globally on
> > windows which we don't want. Also we don't have ".git/info/exclude" in PG
> > project's so the best place left is projects's .gitignore. That's what w
On 2024-05-18 Sa 15:43, Yasir wrote:
On Sat, May 18, 2024 at 7:27 PM Josef Šimánek
wrote:
pá 17. 5. 2024 v 8:09 odesílatel Yasir
napsal:
>
> Hi Hackers,
>
> I have been playing with PG on the Windows platform recently. An
annoying thing I faced is that a lot of
On Sun, May 19, 2024 at 1:45 AM Andrew Dunstan wrote:
>
> On 2024-05-18 Sa 15:43, Yasir wrote:
>
>
>
> On Sat, May 18, 2024 at 7:27 PM Josef Šimánek
> wrote:
>
>> pá 17. 5. 2024 v 8:09 odesílatel Yasir
>> napsal:
>> >
>> > Hi Hackers,
>> >
>> > I have been playing with PG on the Windows platfor
On Mon, Jan 22, 2024 at 11:43 PM Heikki Linnakangas wrote:
> On 22/01/2024 21:58, Vladimir Churyukin wrote:
> > A question about protocol design - would it be possible to extend the
> > protocol, so it can handle multiple startup / authentication messages
> > over a single connection? Are there a
=?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> But this is different. If I understand it well, just by following
> https://www.postgresql.org/docs/16/install-windows-full.html you'll
> get those files no matter what is your specific environment (or
> specific set of tools).
Hm? Visual Studio seems l
Robert Haas wrote on 5/15/2024 9:29 PM:
On Mon, Mar 4, 2024 at 5:03 AM Przemysław Sztoch wrote:
Apparently the functionality is identical to date_bin.
When I saw date_bin in the documentation, I thought it solved all my problems.
Unfortunately, DST problems have many corner cases.
I tried to ch
so 18. 5. 2024 v 23:16 odesílatel Tom Lane napsal:
>
> =?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> > But this is different. If I understand it well, just by following
> > https://www.postgresql.org/docs/16/install-windows-full.html you'll
> > get those files no matter what is your specific environ
On Sun, May 19, 2024 at 2:16 AM Tom Lane wrote:
> =?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> > But this is different. If I understand it well, just by following
> > https://www.postgresql.org/docs/16/install-windows-full.html you'll
> > get those files no matter what is your specific environment
On Sun, May 19, 2024 at 2:23 AM Josef Šimánek
wrote:
> so 18. 5. 2024 v 23:16 odesílatel Tom Lane napsal:
> >
> > =?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
> > > But this is different. If I understand it well, just by following
> > > https://www.postgresql.org/docs/16/install-windows-full.html y
so 18. 5. 2024 v 23:29 odesílatel Yasir napsal:
>
>
>
> On Sun, May 19, 2024 at 2:23 AM Josef Šimánek wrote:
>>
>> so 18. 5. 2024 v 23:16 odesílatel Tom Lane napsal:
>> >
>> > =?UTF-8?B?Sm9zZWYgxaBpbcOhbmVr?= writes:
>> > > But this is different. If I understand it well, just by following
>> >
On 2024-05-16 Th 17:34, Tom Lane wrote:
Andrew Dunstan writes:
On 2024-05-16 Th 17:15, Tom Lane wrote:
I'd rather have some visible status on the BF dashboard. Invariably,
with a problem like this, the animal's owner is unaware there's a
problem. If it's just silently not reporting, then n
On 2024-05-18 Sa 16:54, Yasir wrote:
On Sun, May 19, 2024 at 1:45 AM Andrew Dunstan
wrote:
On 2024-05-18 Sa 15:43, Yasir wrote:
On Sat, May 18, 2024 at 7:27 PM Josef Šimánek
wrote:
pá 17. 5. 2024 v 8:09 odesílatel Yasir
napsal:
>
> Hi Hack
On Fri, May 17, 2024 at 09:22:59PM +0800, jian he wrote:
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
> >
> > It will be i
On Sun, May 19, 2024 at 2:35 AM Andrew Dunstan wrote:
>
> On 2024-05-18 Sa 16:54, Yasir wrote:
>
>
>
> On Sun, May 19, 2024 at 1:45 AM Andrew Dunstan
> wrote:
>
>>
>> On 2024-05-18 Sa 15:43, Yasir wrote:
>>
>>
>>
>> On Sat, May 18, 2024 at 7:27 PM Josef Šimánek
>> wrote:
>>
>>> pá 17. 5. 2024 v
On Wed, May 15, 2024 at 02:56:54PM +0900, Masahiko Sawada wrote:
> On Sat, May 4, 2024 at 7:36 AM Joe Conway wrote:
> > On 5/3/24 11:44, Peter Eisentraut wrote:
> > > On 03.05.24 16:13, Tom Lane wrote:
> > >> Peter Eisentraut writes:
> > >>> On 30.04.24 19:29, Tom Lane wrote:
> > Also, the b
On Fri, May 17, 2024 at 01:30:03PM -0700, Jeff Davis wrote:
> On Thu, 2024-05-09 at 00:03 -0400, Bruce Momjian wrote:
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
>
> For this item
On Sun, May 19, 2024 at 2:20 AM Przemysław Sztoch
wrote:
> Robert Haas wrote on 5/15/2024 9:29 PM:
>
> On Mon, Mar 4, 2024 at 5:03 AM Przemysław Sztoch
> wrote:
>
> Apparently the functionality is identical to date_bin.
> When I saw date_bin in the documentation, I thought it solved all my pro
Andrew Dunstan writes:
> I've pushed a small change, that should just mark with an asterisk any
> gitref that is more than 2 days older than the tip of the branch at the
> time of reporting.
Thanks!
regards, tom lane
On 5/18/24 21:06, Tomas Vondra wrote:
On 5/17/24 14:20, Robert Haas wrote:
On Fri, May 17, 2024 at 1:18 AM David Steele wrote:
However, I think allowing the user to optionally validate the input
would be a good feature. Running pg_verifybackup as a separate step is
going to be a more expensiv
On Wed, May 15, 2024 at 07:20:09AM +0200, Peter Eisentraut wrote:
> Yes, let's get that v3-0001 patch into PG17.
Upon seeing this get committed in 4dd29b6833, I noticed that the docs
still advertise the llvm-config-$version search dance. That's still
correct for Meson-based builds since we use the
On Fri, May 17, 2024 at 11:44:40AM -0400, Melanie Plageman wrote:
> So, anyway, I'd argue that we need a parking lot for patches which we
> all agree are important and have a path forward but need someone to do
> the last 20-80% of the work. To avoid this being a dumping ground,
> patches should _o
040_pg_createsubscriber.pl seems to be failing occasionally on
culicidae near "--dry-run on node S". I couldn't immediately see why.
That animal is using EXEC_BACKEND and I also saw a one-off failure a
bit like that on my own local Linux + EXEC_BACKEND test run
(sorry I didn't keep the details aro
On Sun, May 19, 2024 at 10:46 AM Ole Peder Brandtzæg
wrote:
> On Wed, May 15, 2024 at 07:20:09AM +0200, Peter Eisentraut wrote:
> > Yes, let's get that v3-0001 patch into PG17.
>
> Upon seeing this get committed in 4dd29b6833, I noticed that the docs
> still advertise the llvm-config-$version sear
On Sun, May 19, 2024 at 11:05:49AM +1200, Thomas Munro wrote:
> Oops, right I didn't know we had that documented. Thanks. Will hold
> off doing anything until the thaw.
No worries, thanks!
> Hmm, I also didn't know that Meson had its own list like our just-removed one:
>
> https://github.com/m
Thomas Munro writes:
> Oops, right I didn't know we had that documented. Thanks. Will hold
> off doing anything until the thaw.
FWIW, I don't think the release freeze precludes docs-only fixes.
But if you prefer to sit on this, that's fine too.
regards, tom lane
On Sun, May 19, 2024 at 7:00 AM Alexander Lakhin wrote:
> With blocknums[1], timing is changed, but the effect is not persistent.
> 10 query15 executions in a row, b7b0f3f27:
> 277.932 ms
> 281.805 ms
> 278.335 ms
> 281.565 ms
> 284.167 ms
> 283.171 ms
> 281.165 ms
> 281.615 ms
> 285.394 ms
> 277.
When deploying RLS, I was surprised to find that certain queries which used
only builtin indexes and operators had dramatically different query plans when
a policy is applied. In my case, the query `tsvector @@ tsquery` over a GIN
index was no longer able to use that index. I was able to find one
Em sáb., 18 de mai. de 2024 às 15:52, Andrey M. Borodin <
x4...@yandex-team.ru> escreveu:
> Hi!
>
> In a thread about sorting comparators[0] Andres noted that we have
> infrastructure to help compiler optimize sorting. PFA attached PoC
> implementation. I've checked that it indeed works on the ben
On Fri, 20 Jan 2023 at 08:39, Tom Lane wrote:
> I spent some time re-reading this whole thread, and the more I read
> the less happy I got. We are adding a lot of complexity and introducing
> coding hazards that will surely bite somebody someday. And after awhile
> I had what felt like an epipha
David Rowley writes:
> With the caveat of not yet having looked at the latest patch, my
> thoughts are that having the executor startup responsible for taking
> locks is a bad idea and I don't think we should go down this path.
OK, it's certainly still up for argument, but ...
> 1. No ability to
On Sun, 19 May 2024 at 13:27, Tom Lane wrote:
>
> David Rowley writes:
> > 1. No ability to control the order that the locks are obtained. The
> > order in which the locks are taken will be at the mercy of the plan
> > the planner chooses.
>
> I do not think I buy this argument, because plancache
I noticed that PlannedStmt.hasReturning and hasModifyingCTE have an
outdated comment now that MERGE supports RETURNING (per commit
c649fa24a)
i.e. these two:
> bool hasReturning; /* is it insert|update|delete RETURNING? */
> bool hasModifyingCTE; /* has insert|update|delete in WITH? */
transfor
On Sun, 19 May 2024 at 02:40, Bruce Momjian wrote:
>
> On Thu, May 16, 2024 at 03:35:17PM +1200, David Rowley wrote:
> > "Additionally, vacuum no longer silently imposes a 1GB tuple reference
> > limit even when maintenance_work_mem or autovacuum_work_mem are set to
> > higher values"
> Slightly
Hello Erik,
18.05.2024 04:31, Erik Wienhold wrote:
On 2024-05-17 02:06 +0200, Michael Paquier wrote:
On Thu, May 16, 2024 at 08:41:11AM +0200, Peter Eisentraut wrote:
On this specific patch, maybe reword "parameter too large" to "parameter
number too large".
WFM here.
Done in v3.
Thank you
On Sat, 18 May 2024 at 23:10, Vladimir Churyukin wrote:
> I guess the process of passing control from child processes to the parent
> could be a bit tricky for that one, but doable?
> Is there anything I'm missing that can be a no-go for this?
One seriously difficult/possibly impossible thing is
60 matches
Mail list logo
