On Fri, May 19, 2023 at 09:42:35AM +0800, tender wang wrote:
> postgres=# \d
> Did not find any relations.
> postgres=# CREATE TEMP TABLE t0(c0 inet, c1 money, c2 TEXT);
> CREATE TABLE
> postgres=# CREATE TEMP TABLE IF NOT EXISTS t1(LIKE t0);
> CREATE TABLE
> postgres=# CREATE TEMP TABLE t2(c0
On Thu, May 18, 2023 at 10:22:32PM -0400, Bruce Momjian wrote:
> Patch applied.
Thanks, Bruce.
--
Michael
signature.asc
Description: PGP signature
Op 5/19/23 om 06:17 schreef Jonathan S. Katz:
Hi,
Attached is a draft of the release announcement for PostgreSQL 16 Beta
Hi,
The usual small fry:
'continues to to' should be
'continues to'
'continues to give users to the ability' should be
'continues to give users the ability to'
> On 18 May 2023, at 02:23, Kirk Wolak wrote:
>
> I labelled this v2.
+1 to the feature and the patch looks good to me.
I have a question, but mostly for my own knowledge. Translation changes seem
trivial for all languages, do we typically fix .po files in such cases? Or do
we leave it
Hi,
Attached is a draft of the release announcement for PostgreSQL 16 Beta
1. The goal of this announcement is to get people excited about testing
the beta and highlight many of the new features.
Please review for inaccuracies, omissions, and other suggestions / errors.
Please provide
On Wednesday, May 17, 2023 11:05 AM Amit Kapila wrote:
>
> On Wed, May 17, 2023 at 7:18 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Currently, the main loop of apply worker looks like below[1]. Since
> > there are two loops, the inner loop will keep receiving and applying
> > message from
On Fri, May 19, 2023 at 12:33 AM Tom Lane wrote:
> Bleah. The other solution I'd been poking at involved adding an
> extra check for clone clauses, as attached (note this requires
> 8a2523ff3). This survives your example, but I wonder if it might
> reject all the clones in some cases. It
On Fri, May 19, 2023 at 10:41:59AM +0800, jian he wrote:
> On Fri, May 19, 2023 at 4:49 AM Bruce Momjian wrote:
> * When granting role membership, require the granted-by role to be a role
> that has appropriate permissions (Robert Haas)
> This is a requirement even when the superuser
On Thu, May 18, 2023 at 07:15:26PM -0700, Peter Geoghegan wrote:
> On Thu, May 18, 2023 at 6:44 PM Bruce Momjian wrote:
> > > I don't understand what you mean by that. The changes to
> > > *_till_end_of_wal() (the way that those duplicative functions were
> > > removed, and more permissive
At Thu, 18 May 2023 20:11:11 +0530, Bharath Rupireddy
wrote in
> > > + ConditionVariableInit(>physicalWALSndCV);
> > > + ConditionVariableInit(>logicalWALSndCV);
> >
> > It's not obvious to me that it's worth having two CVs, because it's more
> > expensive to find no
On Fri, May 19, 2023 at 4:49 AM Bruce Momjian wrote:
> I have completed the first draft of the PG 16 release notes. You can
> see the output here:
>
> https://momjian.us/pgsql_docs/release-16.html
>
> I will adjust it to the feedback I receive; that URL will quickly show
> all updates.
On Wed, May 10, 2023 at 01:33:26PM -0400, Bruce Momjian wrote:
> In writing the PG 16 release notes, I came upon an oddity in our new
> createuser syntax, specifically --role and --member. It turns out that
> --role matches CREATE ROLE ... ROLE IN (and has prior to PG 16) while
> the new --member
On Thu, May 18, 2023 at 6:44 PM Bruce Momjian wrote:
> > I don't understand what you mean by that. The changes to
> > *_till_end_of_wal() (the way that those duplicative functions were
> > removed, and more permissive end_lsn behavior was added) is unrelated
> > to all of the other changes. Plus
On Fri, May 19, 2023 at 01:33:17AM +0200, Matthias van de Meent wrote:
> On Thu, 18 May 2023 at 22:49, Bruce Momjian wrote:
> >
> > I have completed the first draft of the PG 16 release notes. You can
> > see the output here:
> >
> > https://momjian.us/pgsql_docs/release-16.html
> >
> >
On Thu, May 18, 2023 at 04:12:26PM -0700, Peter Geoghegan wrote:
> On Thu, May 18, 2023 at 3:52 PM Bruce Momjian wrote:
> > So, I looked at this and the problem is that this is best as a single
> > release note entry because we are removing and adding, and if I moved it
> > to compatibility, I am
Hi hackers,
I found $subject problem when using SQLancer.
How to repeat:
CREATE TEMP TABLE t0(c0 inet, c1 money, c2 TEXT);
CREATE TEMP TABLE IF NOT EXISTS t1(LIKE t0); CREATE TEMP TABLE t2(c0
boolean , c1 DECIMAL NOT NULL UNIQUE); CREATE TEMPORARY TABLE t3(LIKE t1);
CREATE VIEW v0(c0) AS
On 5/18/23 20:45, Tomas Vondra wrote:
> ...
>
> 0001 fixes the issue. 0002 is the original fix, and 0003 is just the
> pageinspect changes (for master only).
>
> For the backbranches, I thought about making the code more like master
> (by moving some of the handling from opclasses to brin.c), but
I wrote:
> Debian Code Search doesn't know of any outside code touching
> relsubs_done, so I think we are safe in dropping that code in
> ExecScanReScan. It seems quite pointless anyway considering
> that up to now, EvalPlanQualBegin has always zeroed the whole
> array.
Oh, belay that. What I'd
Greetings,
* Kirk Wolak (wol...@gmail.com) wrote:
> My approach for now is to develop this as the \st command.
> After reviewing the code/output from the 3 sources (psql, fdw, and
> pg_dump). This trivializes the approach,
> and requires the smallest set of changes (psql is already close with
>
On Thu, 18 May 2023 at 18:22, Heikki Linnakangas wrote:
>
> On 18/05/2023 17:59, Matthias van de Meent wrote:
> Perhaps we should introduce a few generic inline functions to do varint
> encoding. That could be useful in many places, while this scheme is very
> tailored for XLogRecordBlockHeader.
On Thu, 18 May 2023 at 22:49, Bruce Momjian wrote:
>
> I have completed the first draft of the PG 16 release notes. You can
> see the output here:
>
> https://momjian.us/pgsql_docs/release-16.html
>
> I will adjust it to the feedback I receive; that URL will quickly show
> all updates.
On Thu, May 18, 2023 at 7:17 PM Joseph Koshakow wrote:
>
>I looked into this function and that is correct. We fail to find a
>match for the revoked privilege here:
>
>/*
>* Search the ACL for an existing entry for this grantee and grantor. If
>* one exists, just modify the
On Wed, May 17, 2023 at 11:48 PM Nathan Bossart
wrote:
>
>The thread for the aforementioned change [0] mentions the standard
quite a
>bit, which might explain the current behavior.
I went through that thread and the quoted parts of the SQL standard. It
seems clear that if a user tries to
On Thu, May 18, 2023 at 3:52 PM Bruce Momjian wrote:
> So, I looked at this and the problem is that this is best as a single
> release note entry because we are removing and adding, and if I moved it
> to compatibility, I am concerned the new feature will be missed. Since
> WAL inspection is a
On Thu, May 18, 2023 at 02:53:25PM -0700, Peter Geoghegan wrote:
> On Thu, May 18, 2023 at 1:49 PM Bruce Momjian wrote:
> > I will adjust it to the feedback I receive; that URL will quickly show
> > all updates.
> >
> > I learned a few things creating it this time:
> >
> > * I can get confused
On Thu, 2023-05-18 at 20:11 +0200, Matthias van de Meent wrote:
> As I complain about in [0], since 5cd1a5af --no-locale has been
> broken
> / bahiving outside it's description: Instead of being equivalent to
> `--locale=C` it now also overrides `--locale-provider=libc`,
> resulting
> in
On Thu, May 18, 2023 at 12:28:20PM -0400, Robert Haas wrote:
> I mean, I agree that it would probably be hard to measure any real
> performance difference. But I'm not sure that's a good reason to add
> cycles to a path where we don't really need to.
Honestly, I am not sure that it's worth
On Wed, May 17, 2023 at 6:35 PM Jehan-Guillaume de Rorthais
wrote:
>
> On Wed, 17 May 2023 13:46:35 -0400
> Melanie Plageman wrote:
>
> > On Wed, May 17, 2023 at 07:10:08PM +0200, Jehan-Guillaume de Rorthais wrote:
> > > On Tue, 16 May 2023 16:00:52 -0400
> > > Melanie Plageman wrote:
> > > >
Nathan Bossart writes:
> On Thu, May 18, 2023 at 04:03:36PM -0400, Tom Lane wrote:
>> What we need to do, I think, is set epqstate->relsubs_done[] for
>> all target relations except the one we are stuffing a tuple into.
> This seems generally reasonable to me.
Here's a draft patch for this. I
On Thu, May 18, 2023 at 1:49 PM Bruce Momjian wrote:
> I will adjust it to the feedback I receive; that URL will quickly show
> all updates.
>
> I learned a few things creating it this time:
>
> * I can get confused over C function names and SQL function names in
>commit messages.
The
On Thu, May 18, 2023 at 05:39:08PM -0400, Jonathan Katz wrote:
> On 5/18/23 4:49 PM, Bruce Momjian wrote:
> > I have completed the first draft of the PG 16 release notes. You can
> > see the output here:
> >
> > https://momjian.us/pgsql_docs/release-16.html
> >
> > I will adjust it to the
Przemysław Sztoch wrote on 17.05.2023 17:46:
||
|2. Another common usability problem is a quick dump of the selected
parent table.
It is important that it should includes all inherited tables or
subpartitions.
Now you can't just specify -t root-table-name, because you'll usually
get an
On 5/18/23 4:49 PM, Bruce Momjian wrote:
I have completed the first draft of the PG 16 release notes. You can
see the output here:
https://momjian.us/pgsql_docs/release-16.html
I will adjust it to the feedback I receive; that URL will quickly show
all updates.
Still reading, but
On Thu, May 18, 2023 at 04:03:36PM -0400, Tom Lane wrote:
> Yeah. I see the problem: when starting up an EPQ recheck, we stuff
> the tuple-to-test into the epqstate->relsubs_slot[] entry for the
> relation it came from, but we do nothing to the EPQ state for the
> other target relations, which
On 5/18/23 4:49 PM, Bruce Momjian wrote:
I have completed the first draft of the PG 16 release notes. You can
see the output here:
https://momjian.us/pgsql_docs/release-16.html
I will adjust it to the feedback I receive; that URL will quickly show
all updates.
Thanks for going
For me, it would be a big help if you could specify a simple from/to
range as the source version:
myext--1.0.0-1.9.9--2.0.0.sql
myext--2.0.0-2.9.9--3.0.0.sql
myext--3.0.0-3.2.3--3.2.4.sql
The idea of % wildcard in my opinion is fully contained in the from/to
range.
The name "ANY" should also
Andres Freund writes:
> What about an interval / interval -> double operator that errors out whenever
> month is non-zero? As far as I can tell that would always be deterministic.
We have months, days, and microseconds, and microseconds-per-day isn't
much more stable than days-per-month (because
I have completed the first draft of the PG 16 release notes. You can
see the output here:
https://momjian.us/pgsql_docs/release-16.html
I will adjust it to the feedback I receive; that URL will quickly show
all updates.
I learned a few things creating it this time:
* I can get
Hi,
I've open-coded $subject many times. I wonder if we should add at least a
restricted version of it.
I did find one past discussion of it on the list:
https://www.postgresql.org/message-id/24948.1259797531%40sss.pgh.pa.us
We have workarounds for it on the wiki:
Nathan Bossart writes:
> On Thu, May 18, 2023 at 11:22:54AM -0400, Tom Lane wrote:
>> Ugh. Bisecting says it broke at
>> commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35
>> which was absolutely not supposed to be breaking any concurrent-execution
>> guarantees. I wonder what we got wrong.
>
On Thu, May 18, 2023 at 11:22:54AM -0400, Tom Lane wrote:
> Ugh. Bisecting says it broke at
>
> 86dc90056dfdbd9d1b891718d2e5614e3e432f35 is the first bad commit
> commit 86dc90056dfdbd9d1b891718d2e5614e3e432f35
> Author: Tom Lane
> Date: Wed Mar 31 11:52:34 2021 -0400
>
> Rework planning
On 5/15/23 12:06, Alvaro Herrera wrote:
> On 2023-May-07, Tomas Vondra wrote:
>
>>> Álvaro wrote:
In backbranches, the new field to BrinMemTuple needs to be at the end of
the struct, to avoid ABI breakage.
>>
>> Unfortunately, this is not actually possible :-(
>>
>> The BrinMemTuple has
Robert Haas writes:
> This discussion made me go back and look at the commit in question. My
> opinion is that the feature as it was committed is quite hard to
> understand. The documentation for it said this: "Specifies that
> variable should be set on behalf of ordinary role." But what does
On Thu, 2023-05-18 at 13:58 -0400, Jonathan S. Katz wrote:
> From my read of them, as an app developer I'd be very unlikely to
> use
> this. Maybe there is something with building out some collation rules
> vis-a-vis an extension, but I have trouble imagining the use-case. I
> may
> also not be
On Fri, 21 Apr 2023 at 22:46, Jeff Davis wrote:
>
> On Fri, 2023-04-21 at 19:00 +0100, Andrew Gierth wrote:
> > > > > >
> > Also, somewhere along the line someone broke initdb --no-locale,
> > which
> > should result in C locale being the default everywhere, but when I
> > just
> > tested it it
On 5/18/23 1:55 PM, Jeff Davis wrote:
On Wed, 2023-05-17 at 19:59 -0400, Jonathan S. Katz wrote:
I did a quicker read through this time. LGTM overall. I like what you
did with the explanations around sensitivity (now it makes sense).
Committed, thank you.
\o/
There are a few things I
On Wed, 2023-05-17 at 19:59 -0400, Jonathan S. Katz wrote:
> I did a quicker read through this time. LGTM overall. I like what you
> did with the explanations around sensitivity (now it makes sense).
Committed, thank you.
There are a few things I don't understand that would be good to
document
Joel Jacobson wrote:
> I've been using that trick myself many times in the past, but thanks to this
> deep-dive into this topic, it looks to me like TEXT would be a better format
> fit when dealing with unquoted TSV files, or?
>
> OTOH, one would then need to inspect the TSV file doesn't
Richard Guo writes:
> On Thu, May 18, 2023 at 3:34 AM Tom Lane wrote:
>> After some poking at it I hit on what seems like a really simple
>> solution: we should be checking syn_righthand not min_righthand
>> to see whether a Var should be considered nullable by a given OJ.
> I thought about
On Wed, May 17, 2023 at 7:38 PM Andres Freund wrote:
> On 2023-05-17 09:22:19 -0400, Robert Haas wrote:
> > Adding pgstat_get_wait_extension adds runtime cost for no corresponding
> > benefit. Having a special case in the code to avoid that seems worthwhile.
>
> I don't think that should ever be
On 18/05/2023 17:59, Matthias van de Meent wrote:
Attached is a patch that reduces this overhead by up to 2 bytes by
encoding how large the block data length field is into the block ID,
and thus optionally reducing the block data's length field to 0 bytes.
Examples: cross-page update records
Hi!
Matthias, in the Pluggable TOAST thread we proposed additional pointer
definition, without modification
of the original varatt_external - we have to keep it untouched for
compatibility issues. The following extension
for the TOAST pointer was proposed:
typedef struct varatt_custom
{
uint16
On Wed, May 17, 2023 at 1:31 PM Alexander Korotkov wrote:
> I have carefully noted your concerns regarding the USER SET patch that
> I've committed. It's clear that you have strong convictions about
> this, particularly in relation to your plan of storing the setter role
> OID in
Hi,
I took some time to look at the Meson build for Postgres. I contribute
some of the time to Meson, itself. Within this patchset you will find
pretty small changes. Most of the commits are attempting to create more
consistency with the surrounding code. I think there is more that can be
done to
Hi,
> I wonder what we got wrong.
One thing we noticed is that the description for EvalPlanQual may be wrong [1]:
"""
In UPDATE/DELETE, only the target relation needs to be handled this way.
In SELECT FOR UPDATE, there may be multiple relations flagged FOR UPDATE,
so we obtain lock on the
I wrote:
> Aleksander Alekseev writes:
>> A colleague of mine, Ante Krešić, got puzzled by the following behavior:
> That's not a documentation problem. That's a bug, and an extremely
> nasty one. A quick check shows that it works as expected up through
> v13, but fails as described in v14 and
On Thu, May 18, 2023 at 10:53:35AM -0400, Tom Lane wrote:
> That's not a documentation problem. That's a bug, and an extremely
> nasty one. A quick check shows that it works as expected up through
> v13, but fails as described in v14 and later. Needs bisecting ...
git-bisect points me to
Hi all,
As was previously discussed at the thread surrounding [1]: Currently
any block registration in WAL takes up at least 8 bytes in xlog
overhead, regardless of how much data is included in that block: 1
byte for block ID, 1 byte for fork and flags, 2 bytes for the block
data length, and 4
Aleksander Alekseev writes:
> A colleague of mine, Ante Krešić, got puzzled by the following behavior:
That's not a documentation problem. That's a bug, and an extremely
nasty one. A quick check shows that it works as expected up through
v13, but fails as described in v14 and later. Needs
On Thu, May 18, 2023 at 1:23 AM Andres Freund wrote:
>
> On 2023-05-15 20:09:00 +0530, Bharath Rupireddy wrote:
> > > [1]
> > > max_wal_senders = 100
> > > before regression(ms)after regression(ms)v2 patch(ms)
> > > 13394.4013 14141.2615
Richard Guo writes:
> On Thu, May 18, 2023 at 3:42 AM Tom Lane wrote:
>> ... BTW, something I'd considered in an earlier attempt at fixing this
>> was to change clause_is_computable_at's API to pass the clause's
>> RestrictInfo not just the clause_relids, along the lines of
> This change looks
On Thu, 18 May 2023 at 15:12, Aleksander Alekseev
wrote:
>
> Hi,
>
> > I agree that va_tag can have another use. But since we are going to
> > make varatt_external variable in size (otherwise I don't see how it
> > could be really **extendable**) I don't think this is the right
> > approach.
Why
Hi,
Sorry for jumping late in this thread.
I started experimenting with the functionality. Maybe something that
was already discussed earlier. Given that the thread is being
discussed for so long and has gone several changes, revalidating the
functionality is useful.
I considered following
Hi hackers,
A colleague of mine, Ante Krešić, got puzzled by the following behavior:
Setup:
postgres=# create table inh_test (id serial, value float);
CREATE TABLE
postgres=# create table inh_child_1 () INHERITS ( inh_test);
CREATE TABLE
postgres=# create table inh_child_2 () INHERITS (
Hi,
> I agree that va_tag can have another use. But since we are going to
> make varatt_external variable in size (otherwise I don't see how it
> could be really **extendable**) I don't think this is the right
> approach.
On second thought, perhaps we are talking more or less about the same
On 18.05.2023 05:42, Jonathan S. Katz wrote:
That said, from a readability standpoint, it was easier for me to
follow the tabular form vs. the sentence form.
May be possible to reach a agreement on the sentence form. Similar
descriptions used for referential constraints in the \d command:
Andrew Dunstan writes:
> On 2023-05-17 We 18:14, Tom Lane wrote:
>> I did a preliminary test run of pgindent today, and was dismayed
>> to see a bunch of misformatting in backend/jit/llvm/, which
>> evidently is because the typedefs list available from the
>> buildfarm no longer includes any LLVM
On 2023-05-17 We 17:10, Tom Lane wrote:
I wrote:
Andrew Dunstan writes:
I doubt there's something like that.
I had a read-through of the latest version's man page, and found
this promising-looking entry:
-boc, --break-at-old-comma-breakpoints
Sadly, this seems completely not ready
Hi,
> No, that's inaccurate. The complete on-disk representation of a varatt is
>
> {
> uint8 va_header; /* Always 0x80 or 0x01 */
> uint8 va_tag; /* Type of datum */
> charva_data[FLEXIBLE_ARRAY_MEMBER]; /* Type-dependent
> data, for toasted values
On 2023-05-18 Th 02:19, Joel Jacobson wrote:
On Thu, May 18, 2023, at 08:00, Joel Jacobson wrote:
> 1. How about adding a `WITHOUT QUOTE` or `QUOTE NONE` option in
conjunction
> with `COPY ... WITH CSV`?
More ideas:
[ QUOTE 'quote_character' | UNQUOTED ]
or
[ QUOTE 'quote_character' |
On 2023-05-17 We 18:14, Tom Lane wrote:
I did a preliminary test run of pgindent today, and was dismayed
to see a bunch of misformatting in backend/jit/llvm/, which
evidently is because the typedefs list available from the
buildfarm no longer includes any LLVM typedefs. We apparently
used to
On Thu, 18 May 2023 at 12:52, Aleksander Alekseev
wrote:
>
> Hi Nikita,
>
> > this part of the PostgreSQL screams to be revised and improved
>
> I completely agree. The problem with TOAST pointers is that they are
> not extendable at the moment which prevents adding new compression
> algorithms
Hi,
> I think either a specific pg_ctl command to return the port like Greg had
> initially mentioned or simply a separate file to store the port numbers would
> be ideal.
+1, if we are going to do this we definitely need a pg_ctl command
and/or a file.
> The standalone file being the simpler
Hi Nikita,
> this part of the PostgreSQL screams to be revised and improved
I completely agree. The problem with TOAST pointers is that they are
not extendable at the moment which prevents adding new compression
algorithms (e.g. ZSTD), new features like compression dictionaries
[1], etc. I
On Sat, April 1, 2023 at 11:00 AM Thomas Munro wrote:
>
Hi,
Thanks for your patch.
I tried to test this patch on Windows. And I did cover the new code path below:
```
+ /* We have another event to decode. */
+ cur_event = >events[next_pos + (rc - WAIT_OBJECT_0)];
```
On Thu, May 18, 2023, at 08:35, Pavel Stehule wrote:
> Maybe there is another third implementation in Libre Office.
>
> Generally TSV is not well specified, and then the implementations are not
> consistent.
Thanks Pavel, that was a very interesting case indeed:
Libre Office (tested on Mac)
On Thu, May 18, 2023 at 3:42 AM Tom Lane wrote:
> ... BTW, something I'd considered in an earlier attempt at fixing this
> was to change clause_is_computable_at's API to pass the clause's
> RestrictInfo not just the clause_relids, along the lines of
>
> @@ -541,9 +547,10 @@
On Thu, May 18, 2023 at 3:34 AM Tom Lane wrote:
> After some poking at it I hit on what seems like a really simple
> solution: we should be checking syn_righthand not min_righthand
> to see whether a Var should be considered nullable by a given OJ.
> Maybe that's still not quite right, but it
čt 18. 5. 2023 v 8:01 odesílatel Joel Jacobson napsal:
> On Thu, May 18, 2023, at 00:18, Kirk Wolak wrote:
> > Here you go. Not horrible handling. (I use DataGrip so I saved it from
> there
> > directly as TSV, just for an extra datapoint).
> >
> > FWIW, if you copy/paste in windows, the data,
On Thu, May 18, 2023, at 08:00, Joel Jacobson wrote:
> 1. How about adding a `WITHOUT QUOTE` or `QUOTE NONE` option in conjunction
> with `COPY ... WITH CSV`?
More ideas:
[ QUOTE 'quote_character' | UNQUOTED ]
or
[ QUOTE 'quote_character' | NO_QUOTE ]
Thinking about it, I recall another hack;
On Thu, May 18, 2023, at 00:18, Kirk Wolak wrote:
> Here you go. Not horrible handling. (I use DataGrip so I saved it from there
> directly as TSV, just for an extra datapoint).
>
> FWIW, if you copy/paste in windows, the data, the field with the tab gets
> split into another column in Excel. But
81 matches
Mail list logo
