Hi,
When I was reading vacuum.c, I found that the parameter 'stmttype' of
get_rel_oids() is not used at all. The parameter had been used as
command tag in the notice message about "invalid object type", but now
such messages are reported by other functions.
Please find attached remove-unused-par
2010/11/18 Tom Lane :
> Merlin Moncure writes:
>> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova
>> wrote:
>>> i will start the review of this one... but before that sorry for
>>> suggesting this a bit later but about using UNNEST as part of the
>>> sintax?
>
>> Does for-in-array do what unnset
On Wed, Nov 17, 2010 at 10:35 PM, Magnus Hagander wrote:
> Currently, we overload "indent" meaning both "unix socket
> authentication" and "ident over tcp", depending on what type of
> connection it is. This is quite unfortunate - one of them being one of
> the most secure options we have, the oth
Merlin Moncure writes:
> On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova wrote:
>> i will start the review of this one... but before that sorry for
>> suggesting this a bit later but about using UNNEST as part of the
>> sintax?
> Does for-in-array do what unnset does?
Yes, which begs the questi
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova wrote:
> On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> this patch implement a new iteration construct - iteration over an
>> array. The sense of this new iteration is:
>> * a simple and cleaner syntax
>
> i will start the
On 2010-11-18 00:14, Magnus Hagander wrote:
If it was a matter of changing it for those who use ident over tcp, I
really wouldn't hesitate - they're few :-) But the problem is that
it's the ident-over-tcp that's correctly named, not the other one...
True.
By the way ISTR we don't fall back to
I wrote:
> What this example suggests is that we should consider ways to pass
> down the top-N-ness to sorts executed as part of a MergeAppend tree.
> That seems a tad messy though, both in the executor and the planner.
Actually the executor side of it doesn't seem too bad. A Limit node
already p
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Possibly the cleanest fix is to implement pg_ping as a libpq function.
> >> You do have to distinguish connection failures (ie connection refused)
> >> from errors that came back from the postmaster, and the easiest place to
> >> be
2010/11/17 KaiGai Kohei :
> I revised my patch as I attached.
>
> The hook function is modified and consolidated as follows:
>
> typedef enum FunctionCallEventType
> {
> FCET_BE_HOOKED,
> FCET_PREPARE,
> FCET_START,
> FCET_END,
> FCET_ABORT,
> } FunctionCallEventType;
>
> ty
2010/11/17 KaiGai Kohei :
> I also fixed up regression test, dummy_seclabel module and its
> documentation as Robert pointed out in another topic.
I have committed the documentation portion of this patch with some
editing. I also fixed the markup, which was broken, because you used
_ in several p
On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule wrote:
> Hello
>
> this patch implement a new iteration construct - iteration over an
> array. The sense of this new iteration is:
> * a simple and cleaner syntax
i will start the review of this one... but before that sorry for
suggesting this a bit
Itagaki Takahiro writes:
> On Thu, Nov 18, 2010 at 08:35, Tom Lane wrote:
>> Well, the way to deal with that would be to add a GUC that enables
>> reporting of those messages at LOG level. Â But it's a bit hard to argue
>> that we need such a thing without more evidence. Â Maybe you could just
>>
On Thu, Nov 18, 2010 at 08:35, Tom Lane wrote:
>> Yeah, it would be really good to be able to log that without bumping the
>> log levels of the server in general to DEBUG3.
>
> Well, the way to deal with that would be to add a GUC that enables
> reporting of those messages at LOG level. But it's
Josh Berkus writes:
>> There *is* an elog(DEBUG3) in autovacuum.c
>> that reports whether autovac thinks a table needs vacuumed/analyzed ...
>> maybe that needs to be a tad more user-accessible.
> Yeah, it would be really good to be able to log that without bumping the
> log levels of the server
> It's hard to tell, because you're just handwaving about what it is you
> think isn't being logged; nor is it clear whether you have any evidence
> that locks are the problem. Offhand I'd think it at least as likely
> that autovacuum thinks it doesn't need to do anything, perhaps because
> of a
Robert Haas writes:
> See the attached test case. With that setup, this uses MergeAppend:
> explain select * from ma_parent order by id limit 10;
> But this one does not:
> explain select * from ma_parent order by name limit 10;
> ...which seems odd, because the index on ma_child1 and sorting
Josh Berkus writes:
> I've been trying to diagnose in a production database why certain tables
> never get autovacuumed despite having a substantial % of updates. The
> obvious reason is locks blocking autovacuum from vacuuming the table ...
> but the trick is we don't log such blocking behavior,
Bruce Momjian writes:
> Tom Lane wrote:
>> Possibly the cleanest fix is to implement pg_ping as a libpq function.
>> You do have to distinguish connection failures (ie connection refused)
>> from errors that came back from the postmaster, and the easiest place to
>> be doing that is inside libpq.
On Wed, 2010-11-17 at 13:46 -0800, Josh Berkus wrote:
> Hackers,
>
> I've been trying to diagnose in a production database why certain tables
> never get autovacuumed despite having a substantial % of updates. The
> obvious reason is locks blocking autovacuum from vacuuming the table ...
> but th
Hackers,
I've been trying to diagnose in a production database why certain tables
never get autovacuumed despite having a substantial % of updates. The
obvious reason is locks blocking autovacuum from vacuuming the table ...
but the trick is we don't log such blocking behavior, at all. This
mean
Steve Singer writes:
> The attached patch modifies TRUNCATE ... RESTART IDENTITY so that if the
> transaction rolls back the restart of the sequence will also be rolled back.
Applied with significant editorialization (didn't much like the
refactoring you'd chosen for DefineSequence, and there we
> > >> I don't particularly care for the name UNSYNCED
> > >
> > > EVANESCENT?
> > >
> > >> I'm starting not to like UNLOGGED much either
> > >
> > > EPHEMERAL?
> > >
> > > Actually, the UNSYNCED and UNLOGGED seem fairly clear
Uhhh yeah. Let's not break out the thesaurus for this.
JD
--
Pos
Steve Singer writes:
> I will look at addressing this in an updated patch.
I've nearly finished revising the patch already, don't worry about it.
>> Should currval really be used after a failed transaction ? Right now, we can
>> have a value that has been generated inside a rollbacked transactio
On 11/17/2010 11:44 AM, Tom Lane wrote:
...because a backend crash has to be assumed to have corrupted
unlogged tables...
So in a typical use-case, say storing session data on a web-site, one
crashed backend could wreck sessions for some or all of the site? Is
there a mechanism in the propo
Excerpts from Robert Haas's message of mié nov 17 18:05:56 -0300 2010:
> CREATE VOLATILE TABLE blow_me_away (k text, v text) SOME OTHER WORDS
> THAT EXPLAIN THE DETAILS GO HERE;
What about some reloptions?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication,
On Wed, Nov 17, 2010 at 04:05:56PM -0500, Robert Haas wrote:
> On Wed, Nov 17, 2010 at 4:00 PM, Kevin Grittner
> wrote:
> > Robert Haas wrote:
> >
> >> OK, so we're proposing a hierarchy like this.
> >>
> >> 1. PERMANENT (already exists).
> >
> >> 2. UNLOGGED (what this patch currently implements
Excerpts from Robert Haas's message of mié nov 17 17:51:37 -0300 2010:
> On Wed, Nov 17, 2010 at 3:35 PM, Andres Freund wrote:
> > How can you get a buffer which was no written out *at all*? Do you want to
> > force all such pages to stay in shared_buffers? That sounds quite a bit more
> > compli
On 11/17/2010 04:00 PM, Kevin Grittner wrote:
Actually, the UNSYNCED and UNLOGGED seem fairly clear
I think Robert's right. These names won't convey much to someone not
steeped in our technology.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Wed, Nov 17, 2010 at 4:00 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> OK, so we're proposing a hierarchy like this.
>>
>> 1. PERMANENT (already exists).
>
>> 2. UNLOGGED (what this patch currently implements).
>
>> 3. UNSYNCED (future work).
>
>> 4. GLOBAL TEMPORARY (future work).
>
>>
On Nov 17, 2010, at 4:00 PM, Kevin Grittner wrote:
> Robert Haas wrote:
>
>> OK, so we're proposing a hierarchy like this.
>>
>> 1. PERMANENT (already exists).
>
>> 2. UNLOGGED (what this patch currently implements).
>
>> 3. UNSYNCED (future work).
>
>> 4. GLOBAL TEMPORARY (future work).
>
Robert Haas wrote:
> OK, so we're proposing a hierarchy like this.
>
> 1. PERMANENT (already exists).
> 2. UNLOGGED (what this patch currently implements).
> 3. UNSYNCED (future work).
> 4. GLOBAL TEMPORARY (future work).
> 5. LOCAL TEMPORARY (our current temp tables).
All of the abov
On 11/17/2010 12:48 PM, Andrew Dunstan wrote:
Maybe VOLATILE for UNSYNCED? Not sure about UNLOGGED.
UNSAFE and EXTREMELY_UNSAFE?? :)
Cheers,
Steve
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Wed, Nov 17, 2010 at 03:48:52PM -0500, Andrew Dunstan wrote:
> On 11/17/2010 03:37 PM, Robert Haas wrote:
> >I don't particularly care for the name UNSYNCED, and I'm starting
> >not to like UNLOGGED much either, although at least that one is an
> >actual word. PERMANENT and the flavors of TEMPO
On Wed, Nov 17, 2010 at 3:35 PM, Andres Freund wrote:
>> The customer is always right, but the informed customer makes better
>> decisions than the uninformed customer. This idea, as proposed, does
>> not work. If you only include dirty buffers at the final checkpoint
>> before shutting down, yo
On 11/17/2010 03:37 PM, Robert Haas wrote:
I don't particularly care for the name UNSYNCED, and I'm starting not
to like UNLOGGED much either, although at least that one is an actual
word. PERMANENT and the flavors of TEMPORARY are a reasonably
comprehensible as a description of user-visible
On Wed, Nov 17, 2010 at 2:37 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 11/17/2010 02:22 PM, Kenneth Marshall wrote:
>>> I would be fine with only having a safe shutdown with unlogged tables
>>> and skip the checkpoint I/O all other times.
>
>> Yeah, I was just thinking something like tha
On Wednesday 17 November 2010 20:54:14 Robert Haas wrote:
> On Wed, Nov 17, 2010 at 2:31 PM, Andrew Dunstan wrote:
> >>> The customer is always right, and I think we are hearing loud and clear
> >>> what the customers want. Please let's not go out of our way to create
> >>> a feature that isn't w
On 10-11-17 03:00 PM, Marc Cousin wrote:
The Wednesday 17 November 2010 19:41:19, Tom Lane wrote :
Marc Cousin writes:
- Does the feature work as advertised?
Yes. It works consistently, isn't fooled by savepoints or multiple
serials in a table, or concurrent transactions
I think there's a r
On Wed, Nov 17, 2010 at 2:42 PM, Josh Berkus wrote:
>
>> Now, a few minutes ago Robert was muttering about supporting more than
>> one kind of degraded-reliability table. I could see inventing
>> "unlogged" tables, which means exactly that (no xlog support, but we
>> still checkpoint/fsync as usu
Peter Eisentraut writes:
> Here is the patch that adds [RESTRICT|CASCADE] to ALTER TYPE ...
> ADD/ALTER/DROP/RENAME ATTRIBUTE, so that recurses to typed tables.
And here's my commitfest review of it:
- patch applies cleanly
- adds regression tests
- passes them
- is useful and needed, and so
Tom Lane wrote:
> Bruce Momjian writes:
> > Agreed. So how do we pass that info to libpq without exceeding the
> > value of fixing this problem? Should we parse pg_controldata output?
> > pg_upgrade could use machine-readable output from that too.
>
> pg_controldata seems 100% unrelated to thi
The Wednesday 17 November 2010 19:41:19, Tom Lane wrote :
> Marc Cousin writes:
> >>> - Does the feature work as advertised?
> >>>
> >>> Yes. It works consistently, isn't fooled by savepoints or multiple
> >>> serials in a table, or concurrent transactions
>
> I think there's a rather nasty prob
Bruce Momjian writes:
> Agreed. So how do we pass that info to libpq without exceeding the
> value of fixing this problem? Should we parse pg_controldata output?
> pg_upgrade could use machine-readable output from that too.
pg_controldata seems 100% unrelated to this problem. You cannot even
On Wed, Nov 17, 2010 at 2:31 PM, Andrew Dunstan wrote:
>>> The customer is always right, and I think we are hearing loud and clear
>>> what the customers want. Please let's not go out of our way to create
>>> a feature that isn't what they want.
>>
>> I would be fine with only having a safe shutd
On 11/17/2010 02:44 PM, Tom Lane wrote:
[ forgot to comment on this part ]
Andrew Dunstan writes:
To answer another point I see Tom made on the -general list: while
individual backends may crash from time to time, crashes of the whole
Postgres server are very rare in my experience in product
Magnus Hagander wrote:
> On Wed, Nov 17, 2010 at 19:54, Bruce Momjian wrote:
> > Looking here:
> >
> > ? ? ? ?http://wiki.postgresql.org/wiki/Working_with_Git
> >
> > the script we recommend for doing context diffs for git,
> > git-external-diff, is not portable:
> >
> > ? ? ? ?http://anarazel.de/
Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Nov 17, 2010 at 19:57, Bruce Momjian wrote:
> >> Is FATAL, in general, enough to conclude the server is running?
>
> > No - specifically, we will send FATAL when "the database system is
> > starting up", which is exactly the one we want to *a
[ forgot to comment on this part ]
Andrew Dunstan writes:
> To answer another point I see Tom made on the -general list: while
> individual backends may crash from time to time, crashes of the whole
> Postgres server are very rare in my experience in production
> environments.
Well, if you me
> Now, a few minutes ago Robert was muttering about supporting more than
> one kind of degraded-reliability table. I could see inventing
> "unlogged" tables, which means exactly that (no xlog support, but we
> still checkpoint/fsync as usual), and "unsynced" tables which
> also/instead suppress f
Andrew Dunstan writes:
> On 11/17/2010 02:22 PM, Kenneth Marshall wrote:
>> I would be fine with only having a safe shutdown with unlogged tables
>> and skip the checkpoint I/O all other times.
> Yeah, I was just thinking something like that would be good, and should
> overcome Robert's objectio
Excerpts from Robert Haas's message of mié nov 17 15:48:56 -0300 2010:
> On Wed, Nov 17, 2010 at 1:11 PM, Josh Berkus wrote:
> > Robert, All:
> >
> > I hope you're following the thread on -general about this feature.
> > We're getting a lot of feedback.
>
> I haven't been; I'm not subscribed to g
On 11/17/2010 02:22 PM, Kenneth Marshall wrote:
On Wed, Nov 17, 2010 at 02:16:06PM -0500, Tom Lane wrote:
Robert Haas writes:
On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane wrote:
Robert is probably going to object that he wanted to prevent any
fsyncing for unlogged tables, but the discussion o
On Wed, Nov 17, 2010 at 02:16:06PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane wrote:
> >> Robert is probably going to object that he wanted to prevent any
> >> fsyncing for unlogged tables, but the discussion over in pgsql-general
> >> is crystal cl
Magnus Hagander writes:
> On Wed, Nov 17, 2010 at 19:57, Bruce Momjian wrote:
>> Is FATAL, in general, enough to conclude the server is running?
> No - specifically, we will send FATAL when "the database system is
> starting up", which is exactly the one we want to *avoid*.
> I think we should
Robert Haas writes:
> On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane wrote:
>> Robert is probably going to object that he wanted to prevent any
>> fsyncing for unlogged tables, but the discussion over in pgsql-general
>> is crystal clear that people do NOT want to lose unlogged data over
>> a clean sh
On Wed, Nov 17, 2010 at 6:33 PM, Robert Haas wrote:
> I think you're missing the point. If we switch databases, all cached
> relations and plans have to be flushed anyway. We're talking about
> what might NOT need to be flushed on switching databases.
Oh sorry, yes, I missed that point.
I will
On Wed, Nov 17, 2010 at 19:57, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Wed, Nov 17, 2010 at 19:50, Bruce Momjian wrote:
>> > Magnus Hagander wrote:
>> >> Does this actually solve the *problem*, though? The problem is not
>> >> what is reported ?on stdout/stderr, the problem is that th
On Wednesday 17 November 2010 19:54:49 Bruce Momjian wrote:
> Looking here:
>
> http://wiki.postgresql.org/wiki/Working_with_Git
>
> the script we recommend for doing context diffs for git,
> git-external-diff, is not portable:
>
> http://anarazel.de/pg/git-external-diff
>
> It uses
See the attached test case. With that setup, this uses MergeAppend:
explain select * from ma_parent order by id limit 10;
But this one does not:
explain select * from ma_parent order by name limit 10;
...which seems odd, because the index on ma_child1 and sorting the
other two ought to still b
On Wed, Nov 17, 2010 at 19:54, Bruce Momjian wrote:
> Looking here:
>
> http://wiki.postgresql.org/wiki/Working_with_Git
>
> the script we recommend for doing context diffs for git,
> git-external-diff, is not portable:
>
> http://anarazel.de/pg/git-external-diff
>
> It uses diff -L,
Magnus Hagander wrote:
> On Wed, Nov 17, 2010 at 19:50, Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> Does this actually solve the *problem*, though? The problem is not
> >> what is reported ?on stdout/stderr, the problem is that the net result
> >> is that the server is reported as not sta
On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 17.11.2010 17:11, Tom Lane wrote:
>>> The objection to that was not about performance. It was about how
>>> to find out what needs to be fsync'd.
>
>> I must be missing something: we handle that just fine with no
Looking here:
http://wiki.postgresql.org/wiki/Working_with_Git
the script we recommend for doing context diffs for git,
git-external-diff, is not portable:
http://anarazel.de/pg/git-external-diff
It uses diff -L, which is not supported by FreeBSD, and I imagine many
other operat
On Wed, Nov 17, 2010 at 19:50, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> Does this actually solve the *problem*, though? The problem is not
>> what is reported on stdout/stderr, the problem is that the net result
>> is that the server is reported as not started (by the service control
>> m
Magnus Hagander wrote:
> > I basically report the connection error string if it starts with "FATAL:".
> >
> > I originally tried to check for an ERRCODE_INVALID_PASSWORD error field
> > (see // comments), but it seems there is no way to access this, i.e.
> > PQgetResult(conn) on a connection failur
On Wed, Nov 17, 2010 at 1:11 PM, Josh Berkus wrote:
> Robert, All:
>
> I hope you're following the thread on -general about this feature.
> We're getting a lot of feedback.
I haven't been; I'm not subscribed to general; it'd be useful to CC me
next time.
Reading through the thread in the archive
Heikki Linnakangas writes:
> On 17.11.2010 17:11, Tom Lane wrote:
>> The objection to that was not about performance. It was about how
>> to find out what needs to be fsync'd.
> I must be missing something: we handle that just fine with normal
> tables, why is it a problem for unlogged tables?
Marc Cousin writes:
>>> - Does the feature work as advertised?
>>>
>>> Yes. It works consistently, isn't fooled by savepoints or multiple
>>> serials in a table, or concurrent transactions
I think there's a rather nasty problem here, which is what to do with
the cached nextval/currval state. As
On Wed, Nov 17, 2010 at 12:42 PM, Greg Stark wrote:
> On Wed, Nov 17, 2010 at 4:52 PM, Robert Haas wrote:
>> However, that test doesn't capture everything. For example, imagine a
>> connection pooler sitting in front of PG. Rebinding to a new database
>> means disconnecting a TCP connection and
On 17.11.2010 17:11, Tom Lane wrote:
Heikki Linnakangas writes:
fsync()ing the file at shutdown doesn't seem too bad to me from
performance point of view, we tolerate that for all other tables. And
you can always truncate the table yourself before shutdown.
The objection to that was not about
On 17.11.2010 19:46, Teodor Sigaev wrote:
I disagree with that opinion: if we crash between 2 and 3 then why will
somebody update parent before WAL replay? WAL replay process in this
case should complete child split by inserting "invalid" pointer and tree
become correct again, although it needs t
Magnus Hagander writes:
> If it was a matter of changing it for those who use ident over tcp, I
> really wouldn't hesitate - they're few :-) But the problem is that
> it's the ident-over-tcp that's correctly named, not the other one...
Yeah, renaming the TCP version would be quite wrong. If we'r
Robert, All:
I hope you're following the thread on -general about this feature.
We're getting a lot of feedback.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sen
Sorry, I missed beginning of discussion on GiST, so I read it on the web mail
archive.
You wrote:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00939.php
[skip]
0. (the child page is locked)
1. The parent page is locked.
2. The child page is split. The original page becomes the left ha
On Wed, Nov 17, 2010 at 4:52 PM, Robert Haas wrote:
> However, that test doesn't capture everything. For example, imagine a
> connection pooler sitting in front of PG. Rebinding to a new database
> means disconnecting a TCP connection and establishing a new one.
> Switching databases might save
Hmm, will have to do some benchmarking on that. I'm using the Consistent
function when walking down to check if the downlink needs to be updated,
and assumed that it would be insignificant compared to the cost of
calling Penalty on all the keys on the page.
Why consistent?! It's impossible - you d
On Sun, Nov 14, 2010 at 1:12 PM, Heikki Linnakangas
wrote:
> On 14.11.2010 00:29, Robert Haas wrote:
>>
>> On Sat, Nov 13, 2010 at 12:13 PM, Tom Lane wrote:
>>>
>>> Hannu Krosing writes:
On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
>
> If a table has no indexes, we will a
On Wed, Nov 17, 2010 at 2:13 AM, Itagaki Takahiro
wrote:
> On Wed, Nov 17, 2010 at 10:51, Itagaki Takahiro
> wrote:
>> On Wed, Nov 17, 2010 at 03:36, Robert Haas wrote:
>>> On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane wrote:
I am of the opinion that a run-time-extensible set of plan node type
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstrom wrote:
> On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
>> On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
>> > If we don't need a PoC module for each new hooks, I'm not strongly
>> > motivated to push it into contrib tree.
>>
On Wed, Nov 17, 2010 at 17:31, Peter Eisentraut wrote:
> On ons, 2010-11-17 at 16:35 +0100, Magnus Hagander wrote:
>> Currently, we overload "indent" meaning both "unix socket
>> authentication" and "ident over tcp", depending on what type of
>> connection it is. This is quite unfortunate - one of
On Wed, Nov 17, 2010 at 11:00 AM, Greg Stark wrote:
> On Wed, Nov 17, 2010 at 3:11 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> fsync()ing the file at shutdown doesn't seem too bad to me from
>>> performance point of view, we tolerate that for all other tables. And
>>> you can always tr
On Wed, Nov 17, 2010 at 17:10, Jeroen Vermeulen wrote:
> On 2010-11-17 22:43, Magnus Hagander wrote:
>
>> at the advantage of not confusing new users. We could of course also
>> just drop ident-over-tcp completely, but there might be some poor guy
>> out there who actually *uses* it :-)
>
> As far
On Wed, Nov 17, 2010 at 5:04 AM, Markus Wanner wrote:
> The question obviously is whether or not this is faster than just
> terminating one backend and starting a new one.
I agree.
> Which basically costs an
> additional termination and re-creation of a process (i.e. fork())
> AFAICS. Or what ot
Greg Stark wrote:
> If this is a clean shutdown then all the non-unlogged tables have
> been checkpointed so they should have no dirty pages in them
> anyways. So we could just fsync everything.
Or just all the unlogged tables.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On ons, 2010-11-17 at 16:35 +0100, Magnus Hagander wrote:
> Currently, we overload "indent" meaning both "unix socket
> authentication" and "ident over tcp", depending on what type of
> connection it is. This is quite unfortunate - one of them being one of
> the most secure options we have, the oth
On 2010-11-17 22:43, Magnus Hagander wrote:
at the advantage of not confusing new users. We could of course also
just drop ident-over-tcp completely, but there might be some poor guy
out there who actually *uses* it :-)
As far as I know, companies do use it in their internal networks where
th
On Wed, Nov 17, 2010 at 04:43:00PM +0100, Magnus Hagander wrote:
> On Wed, Nov 17, 2010 at 16:39, Tom Lane wrote:
> > Magnus Hagander writes:
> >> Currently, we overload "indent" meaning both "unix socket
> >> authentication" and "ident over tcp", depending on what type of
> >> connection it is.
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of s??b nov 13 22:36:31 -0300 2010:
>
> > OK, I found out how to get the IP address with the attached patch. The
> > problem is that only pghost is set, never pghostaddr. I am not even
> > sure how that would get set for this code bec
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
> On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
> > If we don't need a PoC module for each new hooks, I'm not strongly
> > motivated to push it into contrib tree.
> > How about your opinion?
>
> I'd say let it go, unless someone
On Wed, Nov 17, 2010 at 3:11 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> fsync()ing the file at shutdown doesn't seem too bad to me from
>> performance point of view, we tolerate that for all other tables. And
>> you can always truncate the table yourself before shutdown.
>
> The objectio
On 11/17/2010 04:25 PM, Tom Lane wrote:
> I'm afraid that any such change would trade a visible, safe failure
> mechanism (no avworker) for invisible, impossible-to-debug data
> corruption scenarios (due to failure to reset some bit of cached state).
> It certainly won't give me any warm fuzzy feel
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié nov 17 12:20:06 -0300 2010:
>> What's the point of the InvalidOid check?
> If the check is not there, the calling query will have to prevent the
> function from being called on rows having OID=0 in pg_depend. (These
> rows show up
On Wed, Nov 17, 2010 at 16:39, Tom Lane wrote:
> Magnus Hagander writes:
>> Currently, we overload "indent" meaning both "unix socket
>> authentication" and "ident over tcp", depending on what type of
>> connection it is. This is quite unfortunate - one of them being one of
>> the most secure opt
Excerpts from Tom Lane's message of mié nov 17 12:20:06 -0300 2010:
> Alvaro Herrera writes:
> > A customer of ours (Enova Financial) requested the ability to describe
> > objects in pg_depend. The wiki contains a simplistic SQL snippet that
> > does the task, but only for some of the object type
Magnus Hagander writes:
> Currently, we overload "indent" meaning both "unix socket
> authentication" and "ident over tcp", depending on what type of
> connection it is. This is quite unfortunate - one of them being one of
> the most secure options we have, the other one being one of the most
> *i
Currently, we overload "indent" meaning both "unix socket
authentication" and "ident over tcp", depending on what type of
connection it is. This is quite unfortunate - one of them being one of
the most secure options we have, the other one being one of the most
*insecure* ones (really? ident over t
Markus Wanner writes:
> On 11/17/2010 02:19 PM, Alvaro Herrera wrote:
>> Well, the autovacuum mechanism involves a lot of back-and-forth between
>> launcher and postmaster, which includes some signals, a fork() and
>> backend initialization. The failure possibilities are endless.
>>
>> Fork fail
Magnus Hagander writes:
> Do you still have a reference to the page that said they will never be
> assigned that high?
http://msdn.microsoft.com/en-us/library/ms810720.aspx
which says
USER and GDI handles are sign extended 32b values
To facilitate the porting, a decision has been m
Alvaro Herrera writes:
> A customer of ours (Enova Financial) requested the ability to describe
> objects in pg_depend. The wiki contains a simplistic SQL snippet that
> does the task, but only for some of the object types, and it's rather
> ugly. It struck me that we could fulfill this very eas
Heikki Linnakangas writes:
> fsync()ing the file at shutdown doesn't seem too bad to me from
> performance point of view, we tolerate that for all other tables. And
> you can always truncate the table yourself before shutdown.
The objection to that was not about performance. It was about how
t
1 - 100 of 115 matches
Mail list logo
