On 2 July 2016 at 22:31, Craig Ringer wrote:
>
> - Microsoft VSS is NOT safe, as it fails point 2. It is atomic only on a
> per-file level. You MUST use pg_start_backup() and pg_stop_backup() with
> WAL archiving or automated copy of the extra WAL if you use MS VSS. Most
> Windows backup products
On 2 July 2016 at 22:42, Bruce Momjian wrote:
>
> > I suspect, but cannot prove, that it is also safe to snapshot pg_xlog on
> a
> > separate filesystem if and only if you take the datadir snapshot before
> the
> > pg_xlog snapshot and you have wal_keep_segments high enough to ensure
> that WAL
>
On Sat, Jul 2, 2016 at 10:31:32PM +0800, Craig Ringer wrote:
> - Microsoft VSS is NOT safe, as it fails point 2. It is atomic only on a
> per-file level. You MUST use pg_start_backup() and pg_stop_backup() with WAL
> archiving or automated copy of the extra WAL if you use MS VSS. Most Windows
> ba
Hi all
I just noticed that the Pg docs on backups don't discuss what kind of
snapshots are safe for use without a pg_start_backup() and pg_stop_backup()
then copying the extra WAL.
I'd like to remedy that. My understanding is that it's safe to use a
filesystem or block device level snapshot witho
On Fri, Feb 19, 2016 at 12:05 PM, Alvaro Herrera
wrote:
> But those pages are supposed to be used as the index grows. So unless
> they are forgotten by the FSM, they shouldn't accumulate. (Except where
> the table doesn't grow but only shrinks, so there's no need for new
> index pages, but I don
Peter Geoghegan wrote:
> On Thu, Feb 18, 2016 at 4:53 PM, Tom Lane wrote:
> >> there are usage patterns where half-dead pages might accumulate.
> >
> > Other than a usage pattern of "randomly SIGKILL backends every few
> > seconds", I don't see how that would happen.
>
> I meant where pages coul
On Thu, Feb 18, 2016 at 4:53 PM, Tom Lane wrote:
> Only a physical-order scan, ie vacuum, would visit a dead page
> (ignoring transient corner cases like a page getting deleted while an
> indexscan is in flight to it). So I think treating it as part of the
> fragmentation measure is completely wr
Peter Geoghegan writes:
> On Thu, Feb 18, 2016 at 4:15 PM, Tom Lane wrote:
>> Because they've been removed from the right-link/left-link chains.
> That isn't the same thing as being inaccessible by scans, clearly
> (just what you call the "leaf scan sequence").
Only a physical-order scan, ie va
On Thu, Feb 18, 2016 at 4:15 PM, Tom Lane wrote:
> Because they've been removed from the right-link/left-link chains.
That isn't the same thing as being inaccessible by scans, clearly
(just what you call the "leaf scan sequence"). Besides, half-dead
pages still have right-link/left-link chains, a
Peter Geoghegan writes:
> Why would dead pages not get traversed by scans?
Because they've been removed from the right-link/left-link chains.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On Thu, Feb 18, 2016 at 3:06 PM, Tom Lane wrote:
> Don't see why; the documentation and field names clearly imply that those
> numbers are accumulated only over leaf pages.
Then I guess what might be lacking is a delineation of what a leaf
page is for the purposes of pgstatindex().
> I certainly
Peter Geoghegan writes:
> I think that the P_ISLEAF() instrumentation of free space and
> fragments might still need to happen for deleted and/or half dead
> pages.
Don't see why; the documentation and field names clearly imply that those
numbers are accumulated only over leaf pages. I certainly
On Thu, Feb 18, 2016 at 11:52 AM, Tom Lane wrote:
> It looks like this was done correctly to begin with, and I broke it in
> d287818eb514d431b1a68e1f3940cd958f82aa34. Not sure what I was thinking :-(
I think that you might not have simply changed the order in a totally
misguided way back in 2008
I wrote:
> Peter Geoghegan writes:
>> I think we should change it. It seems like a bug to me.
> Me too. Is it enough bug-like to be something to back-patch, or should
> we just change it in HEAD?
Actually, there's a significantly worse bug here: I just realized that the
page type tests are done
I vote back patch. Subtle differences between the branches should be
avoided.
--
Peter Geoghegan
Peter Geoghegan writes:
> On Thu, Feb 18, 2016 at 10:49 AM, Tom Lane wrote:
>> Yeah, that seems a bit strange to me as well. Should we change it to
>> count the root as an internal page, or is that going too far?
> I think we should change it. It seems like a bug to me.
Me too. Is it enough b
On Thu, Feb 18, 2016 at 10:49 AM, Tom Lane wrote:
> Yeah, that seems a bit strange to me as well. Should we change it to
> count the root as an internal page, or is that going too far?
I think we should change it. It seems like a bug to me. I've had the
same point come up ("leaf-ness/internal-ne
Peter Geoghegan writes:
> That's odd. Having taken a quick look at pgstatindex_impl(), I dislike
> that it counts the root separately from internal pages. That's not how
> they're actually presented and understood in the code.
Yeah, that seems a bit strange to me as well. Should we change it to
On Thu, Feb 18, 2016 at 10:01 AM, Tom Lane wrote:
> Yeah ... the numbers already appear not to add up because the root page
> is counted in index_size but not any other column, so there's already
> something worthy of explanation there. Maybe something like "The reported
> index_size will normall
Peter Geoghegan writes:
> On Thu, Feb 18, 2016 at 9:40 AM, Tom Lane wrote:
>> I think this is a bug and we ought to fix the code to include the
>> metapage in the reported index_size. Thoughts?
> I tend to agree, but I think you should note that specifically in the
> documentation. I'm in favor
On Thu, Feb 18, 2016 at 9:40 AM, Tom Lane wrote:
> I think this is a bug and we ought to fix the code to include the
> metapage in the reported index_size. Thoughts?
I tend to agree, but I think you should note that specifically in the
documentation. I'm in favor of tools like pgstattuple and pa
=?UTF-8?B?5aSn5aGa5oay5Y+4?= writes:
> It seems that description of index_size that is returned by pgstatindex() is
> wrong.
> The document says "Total number of pages in index".
> But it looks like the number of bytes is stored in index_size.
Hmm, you're right, because what the code does is
On Sun, Jan 3, 2016 at 9:05 PM, Ian Barwick wrote:
> Like the docs say, vacuumdb is a "wrapper around the SQL command VACUUM"
> which I used to use in dim-and-distant pre-autovacuum days came for cronjobs,
> but until messing around with pg_upgrade recently I hadn't really had much
> use for it. A
Alvaro Herrera wrote:
> Not sure what is going on; my reading of the code certainly says that
> the data should be there. I'm looking into it.
>
> I also noticed that I didn't actually push the whole of the patch
> yesterday -- I neglected to "git add" the latest changes, the ones that
> fix the
On Wed, Dec 9, 2015 at 4:21 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao wrote:
>
>> > So firstly you will push those "latest" changes soon?
>>
>> It seems like these changes haven't been pushed yet, and unfortunately
>> that's probably a beta bloc
Robert Haas wrote:
> On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao wrote:
> > So firstly you will push those "latest" changes soon?
>
> It seems like these changes haven't been pushed yet, and unfortunately
> that's probably a beta blocker.
I'm on this.
--
Álvaro Herrerahttp://w
On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao wrote:
> On Sat, Dec 5, 2015 at 12:56 AM, Alvaro Herrera
> wrote:
>> Fujii Masao wrote:
>>
>>> Sorry for not reviewing the patch before you push it...
>>>
>>> In HEAD, I ran very simple test case:
>>>
>>> 1. enable track_commit_timestamp
>>> 2. start th
On Sat, Dec 5, 2015 at 12:56 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>
>> Sorry for not reviewing the patch before you push it...
>>
>> In HEAD, I ran very simple test case:
>>
>> 1. enable track_commit_timestamp
>> 2. start the server
>> 3. run some transactions
>> 4. execute pg_last_commi
Fujii Masao wrote:
> Sorry for not reviewing the patch before you push it...
>
> In HEAD, I ran very simple test case:
>
> 1. enable track_commit_timestamp
> 2. start the server
> 3. run some transactions
> 4. execute pg_last_committed_xact() -- returns non-null values
> 5. shutdown the server w
On Tue, Nov 17, 2015 at 6:43 AM, Alvaro Herrera
wrote:
> I paraphrase Fujii Masao, who wrote:
>
>> 1. Start the master and standby servers with track_commit_timestamp enabled.
>> 2. Disable track_commit_timestamp in the master and restart the master
>> server.
>> 3. Run checkpoint in the master.
Petr Jelinek wrote:
> While this seems good, I'd code it slightly differently. I didn't like the
> addition of new bool when it's not really needed. This brings the question
> if we actually need the BootStrapCommitTs and StartupCommitTs functions
> which really don't do much though.
Thanks, it's
On 2015-11-16 22:43, Alvaro Herrera wrote:
I paraphrase Fujii Masao, who wrote:
1. Start the master and standby servers with track_commit_timestamp enabled.
2. Disable track_commit_timestamp in the master and restart the master server.
3. Run checkpoint in the master.
4. Run restartpoint in the
I paraphrase Fujii Masao, who wrote:
> 1. Start the master and standby servers with track_commit_timestamp enabled.
> 2. Disable track_commit_timestamp in the master and restart the master server.
> 3. Run checkpoint in the master.
> 4. Run restartpoint in the standby after the checkpoint WAL reco
On Thu, Oct 29, 2015 at 5:41 PM, Fujii Masao wrote:
> I found another strange behavior on track_commit_timestamp.
> Here are the steps to reproduce it.
>
> 1. Start the master and standby servers with track_commit_timestamp enabled.
> Since committs is activated in standby, pg_last_committed_x
On Wed, Oct 28, 2015 at 3:07 AM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>> Robert Haas wrote:
>> > On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
>> > > I agree with that sentiment.
>> > >
>> > > Attached patch adds variable to the shmem which is used for module
>> > > activation tra
Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
> > > I agree with that sentiment.
> > >
> > > Attached patch adds variable to the shmem which is used for module
> > > activation tracking - set to true in ActiveCommitTs() and false in
> > > Deact
Robert Haas wrote:
> On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
> > I agree with that sentiment.
> >
> > Attached patch adds variable to the shmem which is used for module
> > activation tracking - set to true in ActiveCommitTs() and false in
> > DeactivateCommitTs(). All the checks insi
On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
> I agree with that sentiment.
>
> Attached patch adds variable to the shmem which is used for module
> activation tracking - set to true in ActiveCommitTs() and false in
> DeactivateCommitTs(). All the checks inside the commit_ts code were chan
On 2015-10-02 22:02, Robert Haas wrote:
On Fri, Oct 2, 2015 at 2:59 PM, Alvaro Herrera wrote:
Robert Haas wrote:
The standby can have the feature enabled even though the master has it
disabled? That seems like it can only lead to heartache.
Can you elaborate?
Sort of. Our rule up until n
On Fri, Oct 2, 2015 at 11:58 PM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>
>> What happens if pg_xact_commit_timestamp() is called in standby after
>> track_commit_timestamp is disabled in master, DeactivateCommitTs() is
>> called and all commit_ts files are removed in standby? I tried that cas
On Fri, Oct 2, 2015 at 2:59 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> The standby can have the feature enabled even though the master has it
>> disabled? That seems like it can only lead to heartache.
>
> Can you elaborate?
Sort of. Our rule up until now has always been that the standby
Robert Haas wrote:
> The standby can have the feature enabled even though the master has it
> disabled? That seems like it can only lead to heartache.
Can you elaborate?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Se
On Fri, Oct 2, 2015 at 10:58 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>
>> What happens if pg_xact_commit_timestamp() is called in standby after
>> track_commit_timestamp is disabled in master, DeactivateCommitTs() is
>> called and all commit_ts files are removed in standby? I tried that cas
Fujii Masao wrote:
> What happens if pg_xact_commit_timestamp() is called in standby after
> track_commit_timestamp is disabled in master, DeactivateCommitTs() is
> called and all commit_ts files are removed in standby? I tried that case
> and got the following assertion failure.
Ah. So the stan
On Fri, Oct 2, 2015 at 3:12 AM, Alvaro Herrera wrote:
> Fujii Masao wrote:
>
>> I've not read the patch yet, but the patched server with
>> track_commit_timestamp
>> enabled caused the following PANIC error when I ran pgbench.
>
> Ah, that was a stupid typo: I used || instead of &&. Fixed that.
Fujii Masao wrote:
> I've not read the patch yet, but the patched server with
> track_commit_timestamp
> enabled caused the following PANIC error when I ran pgbench.
Ah, that was a stupid typo: I used || instead of &&. Fixed that.
I also changed DeactivateCommitTs() so that it removes all slru
On Thu, Oct 1, 2015 at 7:48 AM, Alvaro Herrera wrote:
> oonish...@nttdata.co.jp wrote:
>
>> The below error messages were shown in standby server log:
>>
>> FATAL: could not access status of transaction 9009
>> DETAIL: Could not read from file "pg_commit_ts/" at offset 90112:
>> Success.
>>
> Here's a patch.
Thank you!
With this patch, the standby server down disappears in my environment.
Regards,
Takashi Ohnishi
oonish...@nttdata.co.jp
-Original Message-
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Sent: Thursday, October 01, 2015 7:48 AM
To: Fujii Mas
oonish...@nttdata.co.jp wrote:
> The below error messages were shown in standby server log:
>
> FATAL: could not access status of transaction 9009
> DETAIL: Could not read from file "pg_commit_ts/" at offset 90112:
> Success.
> CONTEXT: xlog redo Transaction/COMMIT: 2015-09-30 15:52:41.92
On 2015-09-03 15:03, Fujii Masao wrote:
On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas wrote:
There's no existing precedent for a feature that lets the standby be
different from the master *in any way*. So I don't see why we should
start here. I think the reasonable definition is that the GUC
c
Hi Stephen
> On 15.09.2015, at 17:13, Stephen Frost wrote:
>
> Charles,
>
> * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
>> Yes, that helped a lot! In the attachment now a single patch file
>> with all changes.
>
> I've pushed this fix now.
>
> Thanks!
>
> Stephen
Thanks, too
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> Yes, that helped a lot! In the attachment now a single patch file
> with all changes.
I've pushed this fix now.
Thanks!
Stephen
signature.asc
Description: Digital signature
Hi Stephen
On 13/09/2015 16:56, Stephen Frost wrote:
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
I noticed that the position of the parameter "policy_name" in the
description list of parameters was not at the (alphabetically)
correct position. I changed that and the re
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> I noticed that the position of the parameter "policy_name" in the
> description list of parameters was not at the (alphabetically)
> correct position. I changed that and the result is attached.
Thanks!
> I think/hope that is
Stephen
On 13/09/2015 15:26, Charles Clavadetscher wrote:
Hello Stephen
On 13/09/2015 14:49, Stephen Frost wrote:
Charles,
Just FYI, on these lists, we'd prefer it if you wouldn't top-post.
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
Yes, of course. I will take care of that
Hello Stephen
On 13/09/2015 14:49, Stephen Frost wrote:
Charles,
Just FYI, on these lists, we'd prefer it if you wouldn't top-post.
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
Yes, of course. I will take care of that and send a new patch.
Thanks!
Who will then git push it?
Charles,
Just FYI, on these lists, we'd prefer it if you wouldn't top-post.
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> Yes, of course. I will take care of that and send a new patch.
Thanks!
> Who will then git push it?
I'd be happy to take care of it, though any of the commi
hen Frost
> Sent: Sonntag, 13. September 2015 14:31
> To: Charles Clavadetscher
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [DOCS] Missing COMMENT ON POLICY
>
> Charles,
>
> * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> > Well I gave it a
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> Well I gave it a try. I am still not very well aware how the process for
> suggesting or submitting corrections work, but this is as far as I got.
> In the attachment is a patch for the missing entry for POLICY in the
> documen
Hello
Well I gave it a try. I am still not very well aware how the process for
suggesting or submitting corrections work, but this is as far as I got.
In the attachment is a patch for the missing entry for POLICY in the
documentation on COMMENT that I mentioned earlier on pgsql-docs.
Hope this he
On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas wrote:
> On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera
> wrote:
>>> I think it's totally reasonable for the standby to follow the master's
>>> behavior rather than the config file. That should be documented, but
>>> otherwise, no problem. If it wer
On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera wrote:
>> I think it's totally reasonable for the standby to follow the master's
>> behavior rather than the config file. That should be documented, but
>> otherwise, no problem. If it were technologically possible for the
>> standby to follow the c
On 2015-08-05 00:13, Alvaro Herrera wrote:
Robert Haas wrote:
On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
wrote:
The alternative is to turn the feature on automatically if it sees that
the master also has it on, i.e. the value would not be what the config
file says it is. Doing this wou
Adding CC to hackers, since this is clearly not just a docs issue. Also
CCing Petr and Craig since they are the ones that know how this is used
in BDR.
Robert Haas wrote:
> On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
> wrote:
> > The alternative is to turn the feature on automatically if it
Thank you, it's ideal for me :)
2015-02-27 15:21 GMT+03:00 Michael Paquier :
> On Fri, Feb 27, 2015 at 9:13 PM, Vadim Gribanov
> wrote:
> > Hi! Where i can find explanation about how postgresql works with shared
> > memory?
>
> Perhaps this video of Bruce's presentation about the subject would h
On Fri, Feb 27, 2015 at 9:13 PM, Vadim Gribanov
wrote:
> Hi! Where i can find explanation about how postgresql works with shared
> memory?
Perhaps this video of Bruce's presentation about the subject would help:
https://www.youtube.com/watch?v=Nwk-UfjlUn8
--
Michael
--
Sent via pgsql-hackers
Hi! Where i can find explanation about how postgresql works with shared
memory?
---
Best regard Vadim Gribanov
Linkedin: https://www.linkedin.com/in/yoihito
Skype: v1mk550
Github: https://github.com/yoihito
On 04/02/15 19:02, Fujii Masao wrote:
> On Wed, Feb 4, 2015 at 5:27 PM, Ian Barwick wrote:
>> Hi
>>
>> A superfluous '/' in an xref tag is producing an unintended '>'
>> in the "Warning" box on this page:
>>
>>
>> http://www.postgresql.org/docs/current/interactive/sql-createtablespace.html
>
>
On Wed, Feb 4, 2015 at 5:27 PM, Ian Barwick wrote:
> Hi
>
> A superfluous '/' in an xref tag is producing an unintended '>'
> in the "Warning" box on this page:
>
> http://www.postgresql.org/docs/current/interactive/sql-createtablespace.html
I found that logicaldecoding.sgml also has the same t
Hi
A superfluous '/' in an xref tag is producing an unintended '>'
in the "Warning" box on this page:
http://www.postgresql.org/docs/current/interactive/sql-createtablespace.html
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On Fri, Jul 4, 2014 at 12:51 AM, Kevin Grittner wrote:
> Fujii Masao wrote:
>
>> This seems to make sense. Barring objection, I will commit this
>> only in HEAD.
Committed.
> I'm inclined to think this is a slight improvement, just for the
> sake of consistency with peer level information. You
Fujii Masao wrote:
> This seems to make sense. Barring objection, I will commit this
> only in HEAD.
I'm inclined to think this is a slight improvement, just for the
sake of consistency with peer level information. You probably
already noticed, but the patch as submitted neglects to close the
p
On Thu, Jul 3, 2014 at 4:34 AM, Michael Banck wrote:
> Hi,
>
> While reading through the Explicit Locking section of the manual today,
> I felt the last paragraph of section 13.3.2. (Row-level Locks) might
> merit its own subsection. It talks about page-level locks as distinct
> from table- and r
Hi,
While reading through the Explicit Locking section of the manual today,
I felt the last paragraph of section 13.3.2. (Row-level Locks) might
merit its own subsection. It talks about page-level locks as distinct
from table- and row-level locks. Then again, it is just one paragraph,
so maybe t
Robert Haas wrote:
> On Mon, May 5, 2014 at 1:30 PM, Bruce Momjian wrote:
> > Seems there is no documentation for the 9.4 worker_spi contrib module. Is
> > this OK? The comment at the top of the C file says:
> >
> > * Sample background worker code that demonstrates various coding
> > *
On Mon, May 5, 2014 at 1:30 PM, Bruce Momjian wrote:
> Seems there is no documentation for the 9.4 worker_spi contrib module. Is
> this OK? The comment at the top of the C file says:
>
> * Sample background worker code that demonstrates various coding
> * patterns: establishing a dat
Seems there is no documentation for the 9.4 worker_spi contrib module. Is
this OK? The comment at the top of the C file says:
* Sample background worker code that demonstrates various coding
* patterns: establishing a database connection; starting and committing
* transactions;
On Wed, Apr 16, 2014 at 12:35:26PM +0900, Amit Langote wrote:
> Hi,
>
> Attached adds CREATE MATERIALIZED VIEW AS to the list of statements
> that can be EXPLAINed.
Patch applied. Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprise
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Tue, Apr 8, 2014 at 4:41 PM, Tom Lane wrote:
>>> http://www.postgresql.org/docs/devel/static/gist-builtin-opclasses.html
>>> http://www.postgresql.org/docs/devel/static/gin-builtin-opclasses.html
>>> http://www.postgresql.org/docs/devel/static/spg
Robert Haas wrote:
> On Tue, Apr 8, 2014 at 4:41 PM, Tom Lane wrote:
> > I just created sections in the SGML manual chapters about GIST, GIN, and
> > SP-GIST to hold documentation about the standard opclasses provided for
> > them:
> >
> > http://www.postgresql.org/docs/devel/static/gist-builtin-o
On Tue, Apr 8, 2014 at 4:41 PM, Tom Lane wrote:
> I just created sections in the SGML manual chapters about GIST, GIN, and
> SP-GIST to hold documentation about the standard opclasses provided for
> them:
>
> http://www.postgresql.org/docs/devel/static/gist-builtin-opclasses.html
> http://www.post
On Tue, Sep 17, 2013 at 5:45 AM, Etsuro Fujita
wrote:
> I think the document in advanced.sgml should be corrected, though I might
> misunderstand the rules of usage. Attached is a patch.
I think you're right, because the existing text makes it sounds like
the operator is >=, but the query says >
I think the document in advanced.sgml should be corrected, though I might
misunderstand the rules of usage. Attached is a patch.
Thanks,
Best regards,
Etsuro Fujita
docsfix-20130917.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Wed, Apr 10, 2013 at 11:56 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > So, again, it is not guaranteed that all the scans on a relation will
> > synchronize with each other. Hence my proposal to include the term
> > 'probability' in the definition.
>
> Yeah, it's definitely not "guarantee
Gurjeet Singh writes:
> On Wed, Apr 10, 2013 at 11:10 PM, Tom Lane wrote:
>> The point you're missing is that the synchronization is self-enforcing:
> Let's consider a pathological case where a scan is performed by a user
> controlled cursor, whose scan speed depends on how fast the user presses
On Wed, Apr 10, 2013 at 11:10 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > If I'm reading the code right [1], this GUC does not actually
> *synchronize*
> > the scans, but instead just makes sure that a new scan starts from a
> block
> > that was reported by some other backend performing a sc
Gurjeet Singh writes:
> If I'm reading the code right [1], this GUC does not actually *synchronize*
> the scans, but instead just makes sure that a new scan starts from a block
> that was reported by some other backend performing a scan on the same
> relation.
Well, that's the only *direct* effec
On Fri, Feb 22, 2013 at 08:25:31AM +0900, Ian Lawrence Barwick wrote:
> > The point is we can
> > remove the module when someone fixes and replaces the functionality that's
> > left in there that some people rely on. So far nobody has stepped up to the
> > plate, although now that we have lateral a
On 24 February 2013 13:46, Peter Eisentraut wrote:
>
> done
>
The patch included the word 'so' in the email address by accident.
On Fri, 2013-02-22 at 08:25 +0900, Ian Lawrence Barwick wrote:
> 2013/2/22 Andrew Dunstan :
> >
> > On 02/21/2013 12:56 PM, Magnus Hagander wrote:
> >>
> >> On Thu, Feb 21, 2013 at 6:39 PM, Robert Haas
> >> wrote:
> >>>
> >>> On Wed, Feb 20, 2013 at 11:58 AM, Ian Lawrence Barwick
> >>> wrote:
> >
2013/2/22 Andrew Dunstan :
>
> On 02/21/2013 12:56 PM, Magnus Hagander wrote:
>>
>> On Thu, Feb 21, 2013 at 6:39 PM, Robert Haas
>> wrote:
>>>
>>> On Wed, Feb 20, 2013 at 11:58 AM, Ian Lawrence Barwick
>>> wrote:
I'm not sure if this is a documentation or hackers issue, but the
doc
On 02/21/2013 12:56 PM, Magnus Hagander wrote:
On Thu, Feb 21, 2013 at 6:39 PM, Robert Haas wrote:
On Wed, Feb 20, 2013 at 11:58 AM, Ian Lawrence Barwick
wrote:
I'm not sure if this is a documentation or hackers issue, but the
documentation page for contrib module "xml2" refers to PostgreSQL
On Thu, Feb 21, 2013 at 6:39 PM, Robert Haas wrote:
> On Wed, Feb 20, 2013 at 11:58 AM, Ian Lawrence Barwick
> wrote:
>> I'm not sure if this is a documentation or hackers issue, but the
>> documentation page for contrib module "xml2" refers to PostgreSQL 8.4 in the
>> future tense:
>>
>>"It
On Wed, Feb 20, 2013 at 11:58 AM, Ian Lawrence Barwick
wrote:
> I'm not sure if this is a documentation or hackers issue, but the
> documentation page for contrib module "xml2" refers to PostgreSQL 8.4 in the
> future tense:
>
>"It is planned that this module will be removed in PostgreSQL 8.4
Hi folks
There's no mention anywhere in `SET ROLE` of the ability of `DISCARD
ALL` to reset the role to default. Ditto `SET SESSION AUTHORIZATION`.
That's pretty important, since an app that wants to allow arbitrary SQL
to be executed as an assumed user identity might be guarding against
"RE
It looks like commit 09ff76fcdb275769ac4d1a45a67416735613d04b that
changed the name of pg_constraint.conisonly to connoinherit neglected to
change the System Catalog docs :-(
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On Tuesday, July 3, 2012, Alvaro Herrera wrote:
>
> Excerpts from Greg Smith's message of lun jul 02 20:30:07 -0400 2012:
> > A documentation comment came in recently about ssl-tcp.html not
> > specifying what format is expected for the CRL file. Seems like
> > something that could be described b
Excerpts from Greg Smith's message of lun jul 02 20:30:07 -0400 2012:
> A documentation comment came in recently about ssl-tcp.html not
> specifying what format is expected for the CRL file. Seems like
> something that could be described better now that I look at it, so I'm
> passing that alon
On Apr 14, 2012 8:09 AM, "Peter Eisentraut" wrote:
>
> On tor, 2012-04-12 at 11:59 +0200, Magnus Hagander wrote:
> > The SELECT manpage has:
> >
> > and with_query is:
> >
> > with_query_name [ ( column_name [, ...] ) ] AS ( select | insert |
> > update | delete )
> >
> >
> > Should that list
On tor, 2012-04-12 at 11:59 +0200, Magnus Hagander wrote:
> The SELECT manpage has:
>
> and with_query is:
>
> with_query_name [ ( column_name [, ...] ) ] AS ( select | insert |
> update | delete )
>
>
> Should that list that you can use values as well? Or is it something
> we generally con
1 - 100 of 356 matches
Mail list logo
