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
worried that there might be loads of Windows installations out there
happily
running productive databases with an unsafe setup, so I'd even suggest
backpatching
such a change.
Yours,
Laurenz Albe
uild the .bc from.
I have been bitten by that when building PostGIS.
A simple patch could fix it, but I agree that it would be better
to not build them.
Yours,
Laurenz Albe
gs nothing.
The attached patch would take care of it, but I'm not sure
if that's the right place to check.
Yours,
Laurenz AlbeFrom d474e7b41298944e43bb9141eb33adbdd9ea1098 Mon Sep 17 00:00:00 2001
From: Laurenz Albe <laurenz.a...@cybertec.at>
Date: Tue, 22 May 2018 18:13:31 +0200
Subject: [
the subplan, with the correlation vars as the
> cache key.
I like the idea.
I think the cache should be limited in size, perhaps by work_mem.
Also, there probably should be a GUC for this, defaulting to "off".
Yours,
Laurenz Albe
band-aid for badly written applications, but it will
only help in certain cases and hurts in many others.
Yours,
Laurenz Albe
Michael Paquier wrote:
> On Mon, Apr 16, 2018 at 02:32:10PM +0200, Laurenz Albe wrote:
> > Now that the dust from the last commitfest is settling, I'll make a second
> > attempt to attract attention for this small bug fix.
> >
> > The original commit was Simon'
t from the last commitfest is settling, I'll make a second
attempt to attract attention for this small bug fix.
The original commit was Simon's.
Yours,
Laurenz Albe
t; pg_constraint too, which is more work that I'm going to do for this
> patch.
That makes sense; thanks for explaining.
Yours,
Laurenz Albe
functionally determine the other
> columns in the relation. The patch includes regression test cases.
Would it be very difficult to extend that to "if any unique constraints are
contained in the DISTINCT clause"?
Yours,
Laurenz Albe
doesn't mean that they are unloved.
Yours,
Laurenz Albe
From: Laurenz Albe <laurenz.a...@cybertec.at>
Date: Thu, 1 Mar 2018 16:18:04 +0100
Subject: [PATCH] Teach SHOW ALL to honor pg_read_all_settings membership
This was an oversight in commit 25fff40798fc4ac11a241bfd9ab0c45c085e2212.
---
src/backend/utils/misc/guc.c | 4 ++--
1 file chan
Ashutosh Bapat wrote:
> On Tue, Feb 20, 2018 at 8:39 PM, Laurenz Albe <laurenz.a...@cybertec.at>
> wrote:
> > Tom Lane wrote:
> > > Laurenz Albe <laurenz.a...@cybertec.at> writes:
> > > > The SQL standard has the expression "NEXT VALUE FOR
Tom Lane wrote:
> Laurenz Albe <laurenz.a...@cybertec.at> writes:
> > The SQL standard has the expression "NEXT VALUE FOR asequence" to do
> > what we traditionally do with "nextval('asequence')".
> > This is an attempt to implement this on top of
lation with OID 24836
If not, what could be done about it?
Yours,
Laurenz AlbeFrom 57e42f0a32be39eea541808979a41ab6feac6b73 Mon Sep 17 00:00:00 2001
From: Laurenz Albe <laurenz.a...@cybertec.at>
Date: Mon, 19 Feb 2018 12:17:59 +0100
Subject: [PATCH] Add support for NEXT VALUE FOR
NEXT
t having \desc and \describe as an
alternative to \d would help beginners who come e.g. from Oracle,
but that would mean a change of the current behavior:
test=> \describe
List of foreign servers
Name | Owner | Foreign-data wrapper
+--+--
oracle | postgres | oracle_fdw
(1 row)
This is because \des lists foreign servers, and the rest of the command is
ignored.
Yours,
Laurenz Albe
all replication slots.
Yours,
Laurenz Albe
Geoff Winkless wrote:
> Can we not just say "ctrl-D to quit" instead of \q? Doesn't that work
> everywhere?
Not on Windows, as far as I know.
Yours,
Laurenz Albe
; autovacuum and track_commit_timestamp parameters).
The feature would be most useful with some kind of "moving xid
horizon" that guarantees that only dead tuples whose xmax lies
more than a certain time interval in the past can be vacuumed.
Yours,
Laurenz Albe
to introduce new ASOF keyword. May be yacc experts can propose
> how to solve this conflict without introducing new keyword...
I think it would be highly desirable to have AS OF, because that's
the way the SQL standard has it.
Yours,
Laurenz Albe
t see any clear statement as to the error guarantees
that the neural network prediction can give, and if it is possible that
it may degrade to scanning relevant parts of the table in some cases.
Yours,
Laurenz Albe
thing that is a psql command starts with a backslash.
It might reach out to newcomers, but it will confuse people who know psql.
And frankly, anybody who has used sqlplus is used to suffering anyway.
Yours,
Laurenz Albe
601 - 685 of 685 matches
Mail list logo
