a specific set of
permissions to each of 3 groups for every object created.
The problem is not having many users that all share the exact same
permissions; the problem is having to assign separate permissions on a
per-object basis.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list
On Sun, 2009-06-28 at 14:32 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
My idea is to have a GRANT mask:
CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo;
You haven't really explained what foo is here. If it's a single
object then I don't think
be solved?
The performance issue is something to consider, but I think it would
just be an extra catalog lookup (for each level), and the users of this
feature would probably be willing to pay that cost.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
screwed up, so I
crontabbed the script to run every 20 minutes. This works, but it
doesn't bleed elegance.
I have written scripts to handle some of this in the past, and it's
always awkward. That's what made me start thinking about alternatives.
Regards,
Jeff Davis
--
Sent via pgsql
permissions checks, unless I
missed something.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
is a better
alternative than my idea?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
are overlapping, but
generally different.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of a
synchronized scan is stored in shared memory; otherwise, it wouldn't
know where to stop.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
We could probably fix this specific issue by refactoring things in such
a way that the seqscan start point is frozen on the first read and
re-used after rewinds.
I don't know what you
and easier to fix.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
need some way to detect that this is happening,
give it a few tries, and then resort to full serialization for a few
transactions so that the application can make progress.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
--TEXT.
I observe that the casts (VARCHAR - TEXT and TEXT - VARCHAR) are
marked WITHOUT FUNCTION. If that's the case, can't we use that to say
that no heap rebuild is required? Perhaps we'll need to combine this
with the typmod checks to see if we need to check the heap.
Regards,
Jeff Davis
as a
migration path, or something that would exist forever?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
avoid more serialization anomalies but not all?
2. various granularities of predicate locking?
Should these be things the user controls per-transaction? If so, how?
Regards,
Jeff Davis
[1] http://archives.postgresql.org/pgsql-hackers/2009-05/msg01128.php
--
Sent via pgsql-hackers
On Wed, 2009-05-27 at 19:51 -0500, Kevin Grittner wrote:
Jeff Davis pg...@j-davis.com wrote:
1. implementation of the paper's technique sans predicate locking,
that would avoid more serialization anomalies but not all?
I saw that as a step along the way to support for fully
the way toward true serializability, and doesn't need to be
separately distinguished.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, and then COMMIT
PREPARED on the first one. Then, you go to COMMIT PREPARED on the second
one, and the time has lapsed so you can't (and you can't rollback the
first one, either).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
kind of warning a long time before it
becomes a real problem. Should the staleness of a prepared transaction
be measured in time or xid age or both? Maybe have a reasonable default
of a few minutes or a couple thousand transactions before it starts
issuing warnings?
Regards,
Jeff Davis
transactions generally have released all their snapshots
(where possible), thus allowing VACUUM to work. I would think something
similar could work for prepared transactions.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
progress in the
next couple weeks.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
end of the
range is exclusive or inclusive.
Constructing from a single string is easy. What happens when you want to
say ( 2009-01-01, now() ], or pass a timestamptz from a table? Ideas
welcome.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
BY in a subselect, but it's still a
deviation from the standard.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, 2009-03-28 at 15:35 +, Andrew Gierth wrote:
Jeff == Jeff Davis pg...@j-davis.com writes:
On Sat, 2009-03-28 at 11:57 +, Andrew Gierth wrote:
The array_agg() does, I believe, match the standard one, at least
my reading of the spec doesn't reveal any obvious issues
(as the documentation says should happen), they can do that easily
enough without being forced. However, if the opclass author finds all
match to be useful behavior (which seems reasonable), I don't see a
reason to stop them.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql
fine with either
an error or assuming nothing matches. I don't see a functionality
difference either way, so we should just document whatever seems to make
the most sense.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
insert-only tables is a lot
less. Does that possibly justify running VACUUM on insert-only tables?
On tables without GIN indexes, that wouldn't be a complete waste,
because it could set hint bits, which needs to be done sometime anyway.
Regards,
Jeff Davis
--
Sent via pgsql-hackers
is a pretty
significant problem.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the support for regular, non-bitmap, index scans with GIN,
that could be cleaned up as well. Even if we don't do that, gingetbitmap
should not error when the bitmap becomes lossy, but just return the
lossy bitmap.
That sounds reasonable to me.
Regards,
Jeff Davis
--
Sent via pgsql
predicate on a non-first attribute means that it's not
really a range scan.
I don't see an easy solution to this other than just saying that a
predicate on a second attribute is not a range scan at all, unless the
predicate is not very selective.
Regards,
Jeff Davis
--
Sent via pgsql
group
(correct me if I'm wrong here).
I wonder how many people really use GIN with non-bitmap scans for some
benefit? And even if the benefit exists, does the planner have a way to
identify those cases reliably, or does it have to be done manually?
Regards,
Jeff Davis
--
Sent via pgsql
]) AS foo and then doing ORDER BY foo.
It seems a little strange to me, too, but I assume that it's SQL
standard behavior.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis pg...@j-davis.com wrote:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
Can you clarify the circumstances in which this patch would show
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
;
The VACUUM should be able to clean up the deleted tuple, because it's no
longer visible to anyone.
Attached a small patch to accomplish this. I don't expect it to be put
in 8.4, but it's small enough that I thought I should at least send it
in just in case.
Regards,
Jeff Davis
diff
be misinterpreted as an array of void**.
Would void *(*extra_data)[] be more descriptive? I'm not an expert on
style questions like this, but it seems to match the parameter lists for
comparePartial() and consistent().
void ***extra_data seems reasonable, too.
Regards,
Jeff Davis
--
Sent
== BTLessStrategyNumber ||
data-strategy == BTLessEqualStrategyNumber ) ?
PointerGetDatum(data-datum) : a
rather than just using:
PointerGetDatum(data-datum)
Also, it might be a little less confusing if you used two separate
variables rather than using res for two purposes.
Regards,
Jeff Davis
was that FOR SHARE/UPDATE really change the
isolation semantics, and that it's more like UPDATE than SELECT.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the plan choice on the most
current data, even if it is transient?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to expect a plan to be a good plan
for very long. Can you think of an example where we applied this rule
before?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on ignorance, I haven't followed your
patch as closely as others involved in this discussion.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
will try with a better test case.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
than the two patches above and it's more
complex, so if you think this deserves to be put off, that's
understandable. I think it would be worth a look for any committer not
on the critical path for release though.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Tue, 2009-01-27 at 15:09 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 27, 2009 at 1:50 PM, Jeff Davis pg...@j-davis.com wrote:
I think both of these deserve at least a glance by a committer before
bouncing them.
While we're at it, I think the Ramon
be?
It does show improvement, and I think my test case might just be too
small. It seems like a lot of time is used inserting into the pending
list, but it seems like it should be a simple operation. Maybe that can
be optimized?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
.
Regards,
Jeff Davis.
*: It appears that SELECT ... FOR UPDATE is not in the standard, which
would indicate to me that the SELECT statement should still behave
according to SELECT isolation/snapshot rules. But when I guess about the
standard, I'm usually wrong.
--
Sent via pgsql-hackers
, it doesn't hold for SELECT.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
condition? Do you update the new value in all the tuples that
you found that still match the search condition? Do you update the old
value, perhaps overwriting changes made by the first UPDATE?
What does sybase do in that case?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list
=10. So
can you tell me a little more about the mechanism by which Sybase solves
this problem?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
you want without it?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
snapshots and
re-run the query until no concurrent transaction interferes.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that's the
case already.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
not as if we could have srrialized the
transaction as a whole with respect to whatever other transaction we
failed.
Isn't this back to the discussion about PostgreSQL serializability
versus true serializability?
I agree that's not true serializability.
Regards,
Jeff Davis
given a lot of thought to whether my improvement could be made
a plugin or not, nor have I read your patch, but it seems possible to
me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Thu, 2009-01-22 at 18:20 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-01-21 at 15:08 -0800, Jeff Davis wrote:
If we keep the permission check in LockTableCommand(), I can make a
patch that produces a more useful error message when the table is
removed right
, gincostestimate could use that information for cost estimation, but is
index opening and metapge reading in amcostestimate acceptable?
That sounds reasonable to me. I think that's what the index-specific
cost estimators are for. Do you expect a performance impact?
Regards,
Jeff Davis
--
Sent via
is undesirable.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2009-01-21 at 15:08 -0800, Jeff Davis wrote:
If we keep the permission check in LockTableCommand(), I can make a
patch that produces a more useful error message when the table is
removed right before the pg_class_aclcheck().
Attached.
Regards,
Jeff Davis
diff --git a/src
those that are inserting single tuples at a time should not
encounter the long insert time.
I'm still looking at the rest of the patch.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Mon, 2009-01-19 at 11:35 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
I like the fact that this patch does not modify the numeric ADT. It
still relies on the fact that the numeric type will never make use of
the minimal varlena struct, however. I bring this up in case
?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of argument.
GIN doesn't do anything with values returned by gin_extract_query_numeric
except
providing they as an argument for comparing functions.
Ok, looks good. I updated the wiki to show this as the latest version of
the patch.
Thanks,
Jeff Davis
--
Sent via pgsql-hackers mailing
wiki to point to this patch.
I like the fact that this patch does not modify the numeric ADT. It
still relies on the fact that the numeric type will never make use of
the minimal varlena struct, however. I bring this up in case someone
sees it as a problem.
Thanks,
Jeff Davis
--
Sent
://archives.postgresql.org/pgsql-hackers/2008-12/msg00065.php
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the query a second time in the transaction with ORDER BY.)
I like Lee's idea of a WARNING plus a documentation note -- seems like a
reasonable compromise. Maybe we can add the prohibition later if we
still don't have a fix for it.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing
.
If they are using FOR UPDATE, they clearly expect concurrent updates. If
they're using ORDER BY, they clearly expect the results to be in order.
So who is the target user of this functionality we're trying to protect?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers
is quite awkward to meet.
OK, nobody ever update these fields in this table..
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mention.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, 2008-12-28 at 23:41 -0800, Jeff Davis wrote:
2. Why do you create a shell type int32 from btree_gin.sql? I tried
doing a search-and-replace to use int4 instead, and it seems to work
fine (and eliminates the warnings). I left it with int32 in my version
of the patch because I thought
,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, 2009-01-10 at 13:36 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
I ran 5 times on both old and new code, eliminating the top and bottom
and taking the average of the remaining 3, and I got a 6.9% performance
improvement with the new code.
The question that has been
much time with that.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that max and min really mean the same
thing here.
I don't think we can perfectly capture the meaning of these GUCs in the
name. I think our goal should be to avoid confusion between them.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
performance of the new code on a reasonable-looking distribution
of data. The hash index build that you showed only took a second or two
-- it would be nice to see a test that lasted at least a minute.
Regards,
Jeff Davis
test_results.tar.gz
Description: application/compressed-tar
diff
() should have some performance benefit,
right?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
it's a big improvement, and I don't have a better suggestion.
Thanks,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
on. If I don't see any comments later
this week, I'll post a new patch.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a = 2 for update;
The single tuple in bar affects both results, but the second connection
is not blocked.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the warnings). I left it with int32 in my version
of the patch because I thought you may have some reason for using it.
Regards,
Jeff Davis
btree-gin.20081228.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
. The information could be obsolete, but
if it succeeds, it would at least mean they had permissions at some time
in the past.
Or, we could just remove the ACL checks from LOCK TABLE, so that it's at
least consistent. Mostly it's the inconsistency that bothers me.
Regards,
Jeff Davis
--
Sent via
On Tue, 2008-12-23 at 00:42 -0500, Emmanuel Cecchet wrote:
I still don't
get why people would use SERIALIZABLE since there is no efficient
implementation of it.
If they need true serializable transactions, and don't care about
efficiency.
Regards,
Jeff Davis
--
Sent via pgsql
) when
something (tuple xmin or relfrozenxid) exceeds some number. Why is one
called a min and the other a max?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
an updatable view that uses a function that
updates a table in a remote database, it would be nice to be able to
pass that value back to the client.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
guarantees about preventing denial-of-service
attacks from users that can connect, but if possible we should be
consistent about checking the permissions.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
. It may not be
useful for text search in normal situations (as Teodor mentioned), but
it may be useful for indexing arrays, which might be more likely to be
inserted in order.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
happy with either.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
inserts are logged, so during recovery the
tuple would be put in the table but the index would not be updated.
What am I missing?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Wed, 2008-12-17 at 18:20 -0800, Jeff Davis wrote:
On Wed, 2008-12-17 at 17:10 -0600, Kenneth Marshall wrote:
On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote:
On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall k...@rice.edu wrote:
Rebuilding a hash index for the case
on the
primary.
I'm not advocating this option in particular, other than saying that it
seems like a reasonable option to me.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
to make it actually simultaneous,
then that implies that it's visible on the slave for some brief period
of time before it's committed on the master.
That situation is still asymmetric, so why is that a better use of the
term synchronous?
Regards,
Jeff Davis
--
Sent via pgsql-hackers
informing me that the commit
has completed. Since the message takes some finite time to reach me,
there is a window of time after the commit has completed and before I
know that the commit has been completed.
Oh, I see the distinction now.
Thanks for the detailed reply.
Regards,
Jeff
On Fri, 2008-12-12 at 12:53 +0900, Fujii Masao wrote:
Or, should I create the feature for the user to confirm whether it's in
synch rep via SQL?
I think this would be useful.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Masao offers to provide a SQL function that will tell you
definitively whether you are in full sync rep, or some degraded mode. I
assume that there will also be server log messages to identify whether
you ever left sync rep mode.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list
time it helps is when the failure is temporary, i.e. you didn't
really lose the storage on the standby. But you would need to rely on
some guarantee that the storage is still intact on the standby system
even though the standby is unresponsive.
Is that the use case?
Regards,
Jeff Davis
by Fujii Masao?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
primary and standby, i.e. option (1). My understanding was that you were
asking for such a use case with this question:
So, why would you want to run with multiple archives?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
the value must become a variable at that
time.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1201 - 1300 of 1608 matches
Mail list logo
