On Sun, Dec 10, 2023 at 2:18 AM Jeff Davis wrote:
>
> On Sat, 2023-12-09 at 18:52 +0700, John Naylor wrote:
> > > I tested using the new hash function APIs for my search path cache,
> > > and
> > > there's a significant speedup for cases not benefiting from
> > > a86c61c9ee.
> > > It's enough
On Sun, Dec 10, 2023 at 4:44 AM Sutou Kouhei wrote:
>
> Hi,
>
> Thanks for reviewing our latest patch!
>
> In
>
>
> "RE: Make COPY format extendable: Extract COPY TO format implementations"
> on Sat, 9 Dec 2023 02:43:49 +,
> "Hayato Kuroda (Fujitsu)" wrote:
>
> > (I remember that
Andres Freund writes:
> On 2023-12-09 12:41:30 -0500, Tom Lane wrote:
>> On further reflection I realized that you're right so far as the SSL
>> code path goes, because SSL_write() can involve physical reads as well
>> as writes, so at least in principle it's possible that we'd see EOF
>>
On Tue, Mar 21, 2023 at 3:37 PM Peter Geoghegan wrote:
> I think that we should do something like the attached, to completely
> avoid this ambiguity. This patch adds a new XLOG_HEAP2 bit that's
> similar to XLOG_HEAP_INIT_PAGE -- XLOG_HEAP2_BYVACUUM. This allows all
> XLOG_HEAP2 record types to
On Sat, Dec 2, 2023 at 9:49 AM Jeff Davis wrote:
> Your definition is too wide in my opinion, because it mixes together
> different sources of variation that are best left separate:
> a. region/language
> b. technical requirements
> c. versioning
> d. implementation variance
>
> (a) is not a
Hi,
On 2023-12-09 12:41:30 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> I was wondering about that too. But if we do so, why not also do it for
> >> writes?
>
> > Writes don't act that way, do they? EOF on a pipe gives you an error,
> > not silently reporting that zero
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 9 Dec 2023 12:38:46 +0100,
Hannu Krosing wrote:
> Please also see my presentation slides from last years PostgreSQL
> Conference in Berlin (attached)
Thanks for sharing your idea here.
> The main
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 8 Dec 2023 15:42:06 +0900,
Masahiko Sawada wrote:
> So a custom COPY extension would not be able to define SQL functions
> just like arrow(internal) for example. We might need to define a rule
> like
Hi,
Thanks for reviewing our latest patch!
In
"RE: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 9 Dec 2023 02:43:49 +,
"Hayato Kuroda (Fujitsu)" wrote:
> (I remember that this theme was talked at Japan PostgreSQL conference)
Yes. I should have
On Sat, 2023-12-09 at 18:52 +0700, John Naylor wrote:
> > I tested using the new hash function APIs for my search path cache,
> > and
> > there's a significant speedup for cases not benefiting from
> > a86c61c9ee.
> > It's enough that we almost don't need a86c61c9ee. So a definite +1
> > to
> >
I wrote:
> Andres Freund writes:
>> I was wondering about that too. But if we do so, why not also do it for
>> writes?
> Writes don't act that way, do they? EOF on a pipe gives you an error,
> not silently reporting that zero bytes were written and leaving you
> to retry indefinitely.
On
Hi,
On 2023-12-08 19:39:20 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-12-08 17:29:45 -0500, Tom Lane wrote:
> >> Agreed. I think we want to do that after the initial handshake,
> >> too, so maybe as attached.
>
> > I was wondering about that too. But if we do so, why not also do
Charan K writes:
> I hope this email finds you well. We are currently in the process of
> migrating from PostgreSQL 13.2 to PostgreSQL 15, and we've encountered some
> issues during the restoration process.
> Error Details:
>1. pg_restore: error: could not execute query: ERROR: column
Dear Postgres Team,
We are contacting you today to get your feedback on a service degradation, that
occurred, after upgrading related postgres databases to db-Version 15.
We upgraded several Live- and Non-Live-Landscapes to db-Version 15, coming from
db-version 11. One AWS-Live-Landscape
Hi Team,
I hope this email finds you well. We are currently in the process of
migrating from PostgreSQL 13.2 to PostgreSQL 15, and we've encountered some
issues during the restoration process.
Error Details:
1. pg_restore: error: could not execute query: ERROR: column reference
On 12/8/23 23:11, Melanie Plageman wrote:
On Wed, Nov 8, 2023 at 9:23 PM Melanie Plageman
wrote:
The next step is to devise different heuristics and measure their
efficacy. IMO, the goal of the algorithm it is to freeze pages in a
relation such that we drive early unfreezes/freezes -> 0 and
Hello Hannu,
On 2023-Dec-09, Hannu Krosing wrote:
> Does anyone know why we have decided that the wal_keep_size,
> max_slot_wal_keep_size GUCs "can only be set in the postgresql.conf
> file or on the server command line." [1]?
I think you misread that boilerplate text. If a GUC can be set in
>
On Sat, Dec 2, 2023 at 4:11 PM Tom Lane wrote:
>
> Joe Conway writes:
> >> I noticed that, with the PoC patch, "json" is the only format that must be
> >> quoted. Without quotes, I see a syntax error.
In longer term we should move any specific COPY flag names and values
out of grammar and
On Sat, Dec 9, 2023 at 3:32 AM Jeff Davis wrote:
>
> On Wed, 2023-11-29 at 20:31 +0700, John Naylor wrote:
> > Attached is a rough start with Andres's earlier ideas, to get
> > something concrete out there.
>
> The implementation of string hash in 0004 forgot to increment 'buf'.
Yeah, that was
Hello fellow Hackers,
Does anyone know why we have decided that the wal_keep_size,
max_slot_wal_keep_size GUCs "can only be set in the postgresql.conf
file or on the server command line." [1]?
It does not seem fundamentally needed , as they are "kind of
guidance", especially the second one.
On 09/12/2023 02:41, Thomas Munro wrote:
On Sat, Dec 9, 2023 at 7:25 AM Andres Freund wrote:
On 2023-11-30 13:01:46 +1300, Thomas Munro wrote:
On Thu, Nov 30, 2023 at 12:16 PM Heikki Linnakangas wrote:
Maybe we should bite the bullet and always retry short writes in
FileWriteV(). Is that
On Sat, Dec 9, 2023 at 10:43 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Junagn, Sutou-san,
>
> Basically I agree your point - improving a extendibility is good.
> (I remember that this theme was talked at Japan PostgreSQL conference)
> Below are my comments for your patch.
>
> 01. General
>
>
22 matches
Mail list logo
