On Sat, 2019-04-27 at 14:16 +0200, Peter Eisentraut wrote:
> On 2019-04-26 15:37, Laurenz Albe wrote:
> > What do you think of the patch I just posted on this thread to
> > remove ownership automatically when the default is dropped, as Michael
> > suggested? I think that w
m
the user's perspective.
Correct me if I am wrong, but the sequence behind identity columns
should be an implementation detail that the user doesn't have to know about.
So the error message about "owned sequences" is likely to confuse users.
I have had a report by a confused user, so I think the problem is real.
Yours,
Laurenz Albe
On Thu, 2019-04-25 at 09:55 +0900, Michael Paquier wrote:
> On Sun, Apr 14, 2019 at 05:51:47PM +0200, Laurenz Albe wrote:
> > test=> INSERT INTO ser (id) VALUES (DEFAULT);
> > ERROR: more than one owned sequence found
>
> Yes this should never be user-triggerable,
t.
>
> These seem a bit redundant to me [...]
>
> OK, how about something like the attached? I reworded this a bit, though.
I like your patch better than my wording.
Thanks for the effort!
Yours,
Laurenz Albe
problem
> without forbidding anything, since normal OWNED BY dependencies are "auto".
>
> What do you think?
Here is a patch that illustrates the second approach.
I'll add this thread to the next commitfest.
Yours,
Laurenz Albe
From 7f7bae5315b7770f1327a80eb192bb098ee9df89 Mo
with write support is currently broken.
As Andres has argued above, it is too late to do anything more about
it than to document this and warn FDW authors as good as we can.
Yours,
Laurenz Albe
n by that API change as well
if it hasn't been patched.
At the very least, this should have been mentioned in the list of
incompatible changes for v11.
Yours,
Laurenz Albe
n.
That may wall be a bug in oracle_fdw, since I have no reports of
anybody running it on that operating system.
Maybe you should open an oracle_fdw issue, but I don't know how
much I can help you, since this is the first time I have heard
of SmartOS.
Yours,
Laurenz Albe
I think this
> ship simply has sailed.
I can accept that (having fixed my own FDW), but I am worried that it will
cause problems for FDW users. Well, I guess they can always avoid COPY if
they don't want FDWs to crash.
Yours,
Laurenz Albe
On Mon, 2019-04-22 at 13:27 -0700, Andres Freund wrote:
> On 2019-04-22 21:37:25 +0200, Laurenz Albe wrote:
> > Commit 3d956d956a introduced support for foreign tables as partitions
> > and COPY FROM on foreign tables.
> >
> > If a foreign data wrapper supports data mo
On Mon, 2019-04-22 at 16:24 -0400, Robert Haas wrote:
> On Mon, Apr 22, 2019 at 3:37 PM Laurenz Albe wrote:
> > Sure, it is not hard to modify a FDW to continue working with v11.
> >
> > My point is that this should not be necessary.
>
> I'm not sure whether t
On Mon, 2019-04-22 at 21:45 +0900, Etsuro Fujita wrote:
Thanks for looking into this!
> (2019/04/20 20:53), Laurenz Albe wrote:
> > On Fri, 2018-04-06 at 23:24 +, Robert Haas wrote:
> > > Allow insert and update tuple routing and COPY for foreign tables.
> &
reign table if the FDW
implements BeginForeignInsert. The attached patch implements that.
I think this should be backpatched to v11.
Yours,
Laurenz Albe
From c4b0e871658c757124dad992578da0b60fccf962 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sat, 20 Apr 2019 13:36:56 +0200
Subject: [PATCH] COP
ithout forbidding anything, since normal OWNED BY dependencies are "auto".
What do you think?
Yours,
Laurenz Albe
y column.
I think this should be backpatched.
Yours,
Laurenz Albe
From ab536da87fa8ffc70469d3dbdaf3e1b84b0ef793 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sun, 14 Apr 2019 17:37:03 +0200
Subject: [PATCH] Make sure identity columns own only a single sequence
If an identity column owns more t
use he has been superuser at some time in the past
(and doesn't hold the privilege himself).
So I'd say the behavior is fine as it is, but it would not harm to
document it better (or at all).
Yours,
Laurenz Albe
since they
> should rely on the base tables rather than on the views.
This may make things easier for those who are confused by a negative
entry, but it will obfuscate matters for those who are not.
I don't think that is a win, particularly since the semantics are
explained in great detail in the documentation of "pg_stats".
So I am -1 on that one.
Yours,
Laurenz Albe
Michael Paquier wrote:
> On Thu, Mar 07, 2019 at 09:00:24PM +0100, Laurenz Albe wrote:
> > This should be backpatched down to 9.6 where the functions have been
> > added.
>
> Thanks, applied. The second argument name of heap_page_item_attrs is
> actually "page&quo
backpatched down to 9.6 where the functions have been added.
Yours,
Laurenz Albe
From 4e9655a24a8f86b020c50431eba2376f624a3def Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 7 Mar 2019 20:50:05 +0100
Subject: [PATCH] Fix documentation of pageinspect function signatures
---
doc/src/sgm
insist that *everything*
is encrypted, even your commit log (unencrypted log? everyone can
read the commits?).
Yours,
Laurenz Albe
Magnus Hagander wrote:
> Maybe have the first note say "This method is deprecated bceause it has
> serious
> risks (see bellow)" and then list the actual risks at the end?
Good idea. That may attract the attention of the dogs among the readers.
Yours,
Laurenz Albe
David Steele wrote:
> I added some extra language to the warning that gets emitted in the log.
> Users are more like to see that than the documentation.
>
> I also addressed a comment from another thread by adding pg_basebackup
> as .e.g. rather than or.
Looks good to me.
ld say "*may* not start", because it will if the WAL segment is still
there.
> + recommends that backup_label be removed if not
> + restoring from a backup.
> +
Yours,
Laurenz Albe
a table where taking a truncation lock would be too disruptive.
> If we want to change a given execution of VACUUM, then we can ALTER TABLE
> SET, VACUUM,
> and ALTER TABLE SET back.
True. That ALTER TABLE would probably need a SHARE UPDATE EXCLUSIVE lock on the
table,
and that's no worse than
o "on").
+1
Yours,
Laurenz Albe
t;backup_label" *before*
pg_stop_backup(). Is there a good reason why it is pg_stop_backup()
and not pg_start_backup() that provides that information?
Yours,
Laurenz Albe
Robert Haas wrote:
> Not sure exactly what value would accomplish that goal.
I think autovacuum_vacuum_cost_limit = 2000 is a good starting point.
Yours,
Laurenz Albe
up is in my opinion the safest variant: it refuses
to create a corrupted cluster without manual intervention and gives you a dire
warning to consider if you are doing the right thing.
Yours,
Laurenz Albe
ging them is as quite a no-brainer as the vacuum_cost_limit, so
> the attached patch just does the vacuum_cost_limit.
>
> I decided to do the times by 10 option that I had mentioned Ensue
> debate about that...
>
> I'll add this to the March commitfest and set the target version as
e exclusive backup, and I see how it can hurt people.
I just think that removing exclusive backup without some kind of help
like Andres sketched above will make people unhappy.
Yours,
Laurenz Albe
kup_label file...
Yours,
Laurenz Albe
people.
It will be harder for those whose backup solution is driven by
a central backup software that backs up the file system and just offers
"pre-backup" and "post-backup" hooks.
Yours,
Laurenz Albe
ther functions in pg_proc and
> leakproof the ones that can be, I would be happy to write the corresponding
> patches.
Thanks, and I think that every function that can safely be marked leakproof
is a progress!
Yours,
Laurenz Albe
informal:
3.1.6.8 distinct (of a pair of comparable values): Capable of being
distinguished within a given context.
Informally, not equal, not both null. A null value and a non-null value are
distinct.
Yours,
Laurenz Albe
ts active at the same time.
Yours,
Laurenz Albe
s a similarly-named autovacuum_enabled option.
I like "shrink_enabled".
It may sound weird in the ears of PostgreSQL hackers, but will make sense to
users.
Perhaps "vacuum_shrink_enabled" would be even better.
Yours,
Laurenz Albe
as being overly pedantic.
Yours,
Laurenz Albe
dified.
I don't know if that is a good enough argument, though.
Currently there is "orafce" which provides DUAL, and it might be
good enough if it defines DUAL as a view on DUMMY.
Yours,
Laurenz Albe
Tsunakawa, Takayuki wrote:
> From: Laurenz Albe [mailto:laurenz.a...@cybertec.at]
> > I think that transaction_read_only is good.
> >
> > If it is set to false, we are sure to be on a replication primary or
> > stand-alone server, which is enough to know for
is good.
If it is set to false, we are sure to be on a replication primary or
stand-alone server, which is enough to know for the load balancing use case.
I deem it unlikely that someone will set default_transaction_read_only to
FALSE and then complain that the feature is not working as expected, but again
I cannot prove that claim.
As Robert said, transaction_read_only might even give you the option to
use the feature for more than just load balancing between replication master
and standby.
Yours,
Laurenz Albe
e must rush to remove it.
>
> It's not all there is to it though.
>
> This issue leads to extended downtime regularly and is definitely a huge
> 'gotcha' for users, even if you don't want to call it outright broken,
Only if PostgreSQL crashes regularly, right?
Yours,
Laurenz Albe
d the database is the best place to persist
data for a database extension, I'd use a table in the extension schema, so I'd
go for 3.
Why is that heavier than 2?
Yours,
Laurenz Albe
ustomary 5 years.
And yes, a prominent warning in the next major release notes would be
a good thing.
Yours,
Laurenz Albe
t, I could do it in the "pre" script. But since I have no idea how the
actual backup is performed and how the "backup_label" file is going to
be saved, I thought it best to return the information to the caller and
persist it somewhere, and only the "post" script can actually return the
information.
Yours,
Laurenz Albe
safe-backup
This just uses bash and psql.
Does that look reasonably safe?
It's probably too big to be introduced into the documentation, but maybe
we could add it to the Wiki.
Yours,
Laurenz Albe
t
(mostly) is, so why complicate matters unnecessarily?
Yours,
Laurenz Albe
even if they might change owing to bug fixes, I didn't make it clear that
each such occurrence would necessitate a fat warning in the release notes
that indexes using them have to be rebuilt.
Yours,
Laurenz Albe
he release notes that certain indexes
have to be rebuilt after upgrade.
Of course, there is no problem to mark pg_config as stable, because
there is little chance it will be used in an index anyway.
Yours,
Laurenz Albe
imple to come up with one that doesn't exhibit
the problems of the existing exclusive backup.
Perhaps it's theoretically impossible. The goal is to disambiguate what a file
system backup sees in backup mode and what the startup process sees after a
crash
in backup mode, and I can't see how that could be done.
Yours,
Laurenz Albe
tion, but it sure is
> > inconvenient. Simplicity is good in backup solutions, because complicated
> > things tend to break more easily.
>
> Not sure what communication is necessary here..? The data needed for the
> backup
> label file comes from pg_stop_backup in a non-exclusive backup.
Right, and pg_stop_backup has to be run from the "pre-backup" script.
Yours,
Laurenz Albe
the issues that it has doesn’t change that.
I don't think I'm ignoring the issues, I just think there is a valid use case
for
the exclusive backup API, with all its caveats.
Of course I'm not arguing on behalf of organizations running lots of databases
for whom manual intervention after a crash is unacceptable.
I'm arguing on behalf of users that run a few databases, want a simple backup
solution and are ready to deal with the shortcomings.
But I will gladly accept defeat in this matter, I just needed to vent my
opinion.
Yours,
Laurenz Albe
r backup method at the price of having to
manually restart the server after a crash, what's wrong with that?
Why not give them the choice?
I'd say that one could write a server start script that just removes
"backup_label", but I am sure someone will argue that then somebody
will restore a backup and then restart the server without first
recovering the database...
Yours,
Laurenz Albe
a backup
without first creating "recovery.conf"), but we could add another
big warning.
I'd say that the people who ignore such a warning are the same
people that happily remove "backup_label" when they see the following
message upon starting a cluster from a backup without recovery:
If you are not restoring from a backup, try removing the file "backup_label".
Yours,
Laurenz Albe
when
> you want prefer-slave.
If you know which is which, certainly.
But in a setup with automated failover you cannot be certain which is which.
That's what the proposed feature targets.
Yours,
Laurenz Albe
the relation?
If the answer is "just because we can do it easily", then I think it would be
ok to disable the feature in cases where it causes problems.
Yours,
Laurenz Albe
Tom Lane wrote:
> Laurenz Albe writes:
> > Haribabu Kommi wrote:
> > > Added comments along the lines that you mentioned. And also try
> > > to update some more comments.
> > Looks ok to me, I'll mark it as "ready for committer".
>
> I don't like
Haribabu Kommi wrote:
> Added comments along the lines that you mentioned. And also try
> to update some more comments.
Looks ok to me, I'll mark it as "ready for committer".
Yours,
Laurenz Albe
ving the relcache call
> cost_qual_eval.
That was my impression too when I had a closer look at this feature.
What about an option "hot_update_check" with values "off" (default),
"on" and "always"?
Yours,
Laurenz Albe
is tempted to run his application with a superuser for
simplicitly's sake will not be the person to set a connection limit
for superusers.
I concur with Tom that this will do more harm than good.
Yours,
Laurenz Albe
Michael Paquier wrote:
> On Mon, Oct 29, 2018 at 09:41:08AM +0100, Laurenz Albe wrote:
> > I think that the question if pg_promote allows a parallel plan or not
> > is mostly academic, but the two definitions should be kept in sync.
>
> It seems to me that the presence of the
e right from the start.
>
> Attached is a patch to fix that. Any comments or objections?
Hmm, I should have noticed that.
I think that the question if pg_promote allows a parallel plan or not
is mostly academic, but the two definitions should be kept in sync.
Yours,
Laurenz Albe
ist.
> So, I wrote a prototype patch.
Thank you!
You should add this to the next commitfest:
https://commitfest.postgresql.org/20/
Please make sure to read the Developer FAQ if you haven't already done it:
https://wiki.postgresql.org/wiki/Developer_FAQ
Yours,
Laurenz Albe
MyungKyu LIM wrote:
> I saw this topic in todo list,
>
> so I implemented simple patch.
>
> https://www.postgresql.org/message-id/flat/1657809367.407321.1533027417725.JavaMail.jboss%40ep2ml404
For the archives' sake, please always reply on the original thread.
Yours,
Laurenz Albe
g me than it would have taken you to write this yourself.
Yours,
Laurenz Albe
to me; surely you wouldn't change the syntax in
postgresql.conf.
One good road to get into PostgreSQL development is by reviewing patches.
That allows you to learn from others and get to know parts of the code
you are not yet familiar with.
There is always a shortage of reviewers!
Yours,
Laurenz Albe
> + ereport(ERROR,
> + (errcode_for_file_access(),
> +errmsg("could not write file \"%s\": %m",
> + PROMOTE_SIGNAL_FILE)));
>
> Maybe we should unlink PROMOTE_SIGNAL_FILE before erroring.
Yes, that cannot hurt.
Yours,
Laurenz Albe
I wrote:
> Fixed.
Here is another version, with a fix in pg_proc.dat, an improved comment
and "wait_seconds" exercised in the regression test.
Yours,
Laurenz Albe
From a2a7f9fd1b23ad102d11992b22158dab8b5451d5 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sat, 20 Oct 2018 0
60s.
Ok, added as a new parameter "wait_seconds".
> Is the function marked as strict? Per the code it should be, I am not
> able to test now though.
Yes, it is.
> You are missing REVOKE EXECUTE ON FUNCTION pg_promote() in
> system_views.sql, or any users could trigger a p
Ashwin Agrawal wrote:
> Just curious to know, is promotion via function only allowed for
> hot-standby or works for any standby?
Only for hot standby - how do you want to execute a function on a standby
server that doesn't allow connections?
Yours,
Laurenz Albe
ll to pg_promote should
> trigger an error. This is not handled in the patch.
So far I had returned "false" in the last case, but I am fine with
throwing an error in that case. Done.
> An other thing which has value is to implement a "wait" mode for this
> feature, or
bose if that avoids confusion.
Yours,
Laurenz Albe
From a5de6f9893e049bf97810e41530907e237f909d7 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 8 Oct 2018 17:59:37 +0200
Subject: [PATCH] Add pg_promote() to promote standby servers
---
doc/src/sgml/func.sgml | 20
he attached. Thoughts?
I'm fine with it.
"cannot use ONLY for foreign key on partitioned table" has a funny ring
to it (after all, ONLY was used for the table, not the foreign key), but
since I could not come up with anything better, I guess there is just
no entirely satisfactory way to phrase it tersely.
Yours,
Laurenz Albe
Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 09:45:09PM +0200, Laurenz Albe wrote:
> > That message is wrong, because "rel" and not "pkrel" is the partitioned
> > table.
> > I think it should be
> >
> > ereport(ERROR,
&
Haribabu Kommi wrote:
> On Thu, Jul 19, 2018 at 10:59 PM Haribabu Kommi
> wrote:
> > On Wed, Jul 18, 2018 at 10:53 PM Robert Haas wrote:
> > > On Wed, Jul 4, 2018 at 9:14 AM, Laurenz Albe
> > > wrote:
> > > > What about keeping the fi
default to the pg_default tablespace.
> >
> > That would be pretty bletcherous, so +1 for just making two C functions.
>
> Alright, here's an updated patch.
Looks, good; marking as "ready for committer".
Yours,
Laurenz Albe
allback_promote? My gut tells me no, and that we ought to drop
> this option at some point in the future, still that's worth mentioning.
>
> You may want to move PROMOTE_SIGNAL_FILE in a position where xlogfuncs.c
> could use it.
Good, idea; updated patch
on pg_default.
I looked at that, and I don't think you can add a DEFAULT for
system functions installed during bootstrap.
At least I failed in the attempt.
Yours,
Laurenz Albe
g_ls_waldir",
and I can imagine new requests, e.g. pg_ls_datafiles() to list the
data files in a database directory.
It may make sense to have a generic function like
pg_ls_dir(dirname text, tablespace oid)
instead. But maybe that's taking it too far...
I'll set the patch to "waiting for author".
Yours,
Laurenz Albe
CT_TYPE),
errmsg("foreign key cannot be defined on ONLY \"%s\" for a
partitioned table",
Relatio
nGetRelationName(rel;
Yours,
Laurenz Albe
Providing SQL access for administrative tasks seems to be a
good thing, see ALTER SYSTEM and pg_reload_conf().
In that vein, I propose a function pg_promote() to promote
physical standby servers.
If there are no fundamental objections, I'll add it to the
next commitfest.
Yours,
Laurenz Albe
Michael Paquier wrote:
> Thanks, I have pushed the solution from Laurenz to maintain pure
> compatibility.
Thanks for all the work!
Yours,
Laurenz Albe
Tom Lane wrote:
> Laurenz Albe writes:
> > Would it be an option to have pgwin32_open default to text mode in
> > frontend code and to binary mode in backend code?
>
> Well, the question is why Michael's latest proposed patch doesn't
> accomplish that.
I was thinking o
code suddenly defaulting
to binary mode when it was text mode before.
Would it be an option to have pgwin32_open default to text mode in
frontend code and to binary mode in backend code?
Yours,
Laurenz Albe
Michael Paquier wrote:
> On Thu, Sep 13, 2018 at 03:55:20PM +0200, Laurenz Albe wrote:
> > Attached is the new, improved version of the patch.
>
> Thanks, finally pushed. I have made sure that recovery TAP tests,
> upgrade tests and bin/ tests are working properly.
Thanks fo
Michael Paquier wrote:
> On Mon, Sep 10, 2018 at 04:46:40PM +0200, Laurenz Albe wrote:
> > I didn't get pg_upgrade to work without the log file hacks; I suspect
> > that there is more than just log file locking going on, but my Windows
> > skills are limited.
> >
>
On Wed, 2018-09-12 at 14:43 +0900, Michael Paquier wrote:
> On Mon, Sep 10, 2018 at 04:46:40PM +0200, Laurenz Albe wrote:
> > I didn't get pg_upgrade to work without the log file hacks; I suspect
> > that there is more than just log file locking going on, but my Windows
> &g
Noah Misch wrote:
> On Wed, Jun 27, 2018 at 12:09:24PM +0200, Laurenz Albe wrote:
> > Michael Paquier wrote:
> > > > I have added it to the July commitfest.
> > >
> > > Have you looked at the possibility of removing the log file constraints
> > >
nsistency, attached patch divides the Options section of oid2name
> into two sections, Options and Connection options.
I don't think it is super important, but +1 for consistency.
Yours,
Laurenz Albe
Thomas Munro wrote:
> It looks like initdb is failing with this patch:
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.6732
>
> Unfortunately cfbot is not clever enough to print out the contents of
> the initdb log so I don't have any more information...
Sorry for the
a.
ALTER USER MAPPING has to be restricted to superusers as well.
Yours,
Laurenz Albe
ndows Server 2012 R2
>
> I think this is a bug.
> I think it has not been fixed in the latest version, is my understanding
> correct?
> If it is correct, I will fix it.
I agree that this is not nice.
How do you propose to fix it?
Yours,
Laurenz Albe
Haribabu Kommi wrote:
> > On Wed, Jul 4, 2018 at 11:14 PM Laurenz Albe
> > wrote:
> > > Haribabu Kommi wrote:
> > >
> > > - I think the construction with "read_write_host_index" makes the code
> > > even more
> > > complica
t allows read-write
transactions will be accepted.
- I think the construction with "read_write_host_index" makes the code even more
complicated than it already is.
What about keeping the first successful connection open and storing it in a
variable if we are in "prefer-read" mode.
If we get the read-only connection we desire, close that cached connection,
otherwise use it.
Yours,
Laurenz Albe
code on the
> way?
Can you explain what the "log file constraints" are?
If it is in any way related, and I can handle it, sure.
Yours,
Laurenz Albe
ildfarm thinks about the attached?
>
> +1
I have added it to the July commitfest.
Yours,
Laurenz Albe
y long silence.
If I remove the "#ifndef FRONTEND", building with MSVC fails for all
call sites that use the two-argument version of open(2).
If I use the three-argument version throughout, which should be no problem,
PostgreSQL builds just fine with MSVC.
How about checking what the b
Alvaro Herrera wrote:
> On 2018-Mar-01, Laurenz Albe wrote:
>
> > I noticed that commit 25fff40798fc4ac11a241bfd9ab0c45c085e2212 forgot
> > to teach SHOW ALL to show all GUCs when the user belongs to
> > pg_read_all_settings.
> >
> > Patch attached; I think t
ughts?
I thought of a better way.
pg_test_fsync is properly listed as a server application in the documentation,
so I think it should be built as such, as per the attached patch.
Yours,
Laurenz AlbeFrom 032a0463072097e489f912337ea08f7373a4f107 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Fri, 8 Jun
Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 8:18 PM, Laurenz Albe wrote:
> > Amit Kapila wrote:
> > > On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe
> > > wrote:
> > > > I recently read our documentation about reliability on Windows:
> >
Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe wrote:
> > I recently read our documentation about reliability on Windows:
> >
> > > On Windows, if wal_sync_method is open_datasync (the default), write
> > > caching can
> > > be dis
601 - 700 of 721 matches
Mail list logo
